{children};
}
diff --git a/src/components/MDX/Recap.tsx b/src/components/MDX/Recap.tsx
index d91ed48b48..d59c2a5db1 100644
--- a/src/components/MDX/Recap.tsx
+++ b/src/components/MDX/Recap.tsx
@@ -13,7 +13,7 @@ function Recap({children}: RecapProps) {
return (
diff --git a/src/components/MDX/Sandpack/CustomPreset.tsx b/src/components/MDX/Sandpack/CustomPreset.tsx
index 7d6e566d27..e07b49aeda 100644
--- a/src/components/MDX/Sandpack/CustomPreset.tsx
+++ b/src/components/MDX/Sandpack/CustomPreset.tsx
@@ -59,7 +59,7 @@ const SandboxShell = memo(function SandboxShell({
return (
<>
{
const nextIsExpanded = !isExpanded;
flushSync(() => {
@@ -103,7 +103,7 @@ const SandboxShell = memo(function SandboxShell({
className="inline me-1.5 text-xl"
displayDirection={isExpanded ? 'up' : 'down'}
/>
- {isExpanded ? 'Show less' : 'Show more'}
+ {isExpanded ? 'Скрыть' : 'Раскрыть'}
)}
diff --git a/src/components/MDX/Sandpack/DownloadButton.tsx b/src/components/MDX/Sandpack/DownloadButton.tsx
index 94cf13ddc3..b850883956 100644
--- a/src/components/MDX/Sandpack/DownloadButton.tsx
+++ b/src/components/MDX/Sandpack/DownloadButton.tsx
@@ -102,7 +102,7 @@ ${css}
onClick={downloadHTML}
title="Download Sandbox"
type="button">
-
Download
+
Загрузить
);
}
diff --git a/src/components/MDX/Sandpack/OpenInCodeSandboxButton.tsx b/src/components/MDX/Sandpack/OpenInCodeSandboxButton.tsx
index a27122ed60..ad4b8f0f5c 100644
--- a/src/components/MDX/Sandpack/OpenInCodeSandboxButton.tsx
+++ b/src/components/MDX/Sandpack/OpenInCodeSandboxButton.tsx
@@ -15,7 +15,7 @@ export const OpenInCodeSandboxButton = () => {
width="1em"
height="1em"
/>
-
Fork
+
Отрыть в песочнице
);
};
diff --git a/src/components/MDX/Sandpack/ResetButton.tsx b/src/components/MDX/Sandpack/ResetButton.tsx
index 0d1e22c806..dcc953a6d3 100644
--- a/src/components/MDX/Sandpack/ResetButton.tsx
+++ b/src/components/MDX/Sandpack/ResetButton.tsx
@@ -15,7 +15,7 @@ export function ResetButton({onReset}: ResetButtonProps) {
onClick={onReset}
title="Reset Sandbox"
type="button">
-
Reset
+
Сбросить
);
}
diff --git a/src/content/learn/index.md b/src/content/learn/index.md
index e8a95d2955..bc4a7c0565 100644
--- a/src/content/learn/index.md
+++ b/src/content/learn/index.md
@@ -296,7 +296,7 @@ function MyButton() {
}
```
-Заметьте: у `onClick={handleClick}` нет скобок в конце! Не _вызывайте_ функцию обработчика событий: вам нужно просто её *передать*. React вызовет ваш обработчик событий, когда пользователь кликнет по кнопке.
+Заметьте: у `onClick={handleClick}` нет круглых скобок в конце! Не _вызывайте_ функцию обработчика событий: вам нужно просто её *передать*. React вызовет ваш обработчик событий, когда пользователь кликнет по кнопке.
## Обновление экрана {/*updating-the-screen*/}
diff --git a/src/content/learn/updating-objects-in-state.md b/src/content/learn/updating-objects-in-state.md
index 93ea93bd2d..451cae953a 100644
--- a/src/content/learn/updating-objects-in-state.md
+++ b/src/content/learn/updating-objects-in-state.md
@@ -1,57 +1,57 @@
---
-title: Updating Objects in State
+title: Обновление объектов в состоянии
---
-State can hold any kind of JavaScript value, including objects. But you shouldn't change objects that you hold in the React state directly. Instead, when you want to update an object, you need to create a new one (or make a copy of an existing one), and then set the state to use that copy.
+Состояние может содержать в себе любые JavaScript-значения, включая объекты. Значения объектов, которые находятся в состоянии, нельзя изменять напрямую. Вместо этого, если вы хотите обновить состояние, вам необходимо создать новый объект или копию текущего объекта, а затем установить состоянию этот объект.
-- How to correctly update an object in React state
-- How to update a nested object without mutating it
-- What immutability is, and how not to break it
-- How to make object copying less repetitive with Immer
+- Как правильно в React обновлять объект в состоянии
+- Как обновить вложенный объект без мутации
+- Что такое иммутабельность, как её не нарушить
+- Как упростить копирование объектов с Immer
-## What's a mutation? {/*whats-a-mutation*/}
+## Что такое мутация? {/*whats-a-mutation*/}
-You can store any kind of JavaScript value in state.
+Вы можете хранить любое JavaScript-значение в состоянии.
```js
const [x, setX] = useState(0);
```
-So far you've been working with numbers, strings, and booleans. These kinds of JavaScript values are "immutable", meaning unchangeable or "read-only". You can trigger a re-render to _replace_ a value:
+До сих пор вы работали с числами, строками и логическими значениями. Эти виды значений в JavaScript являются "иммутабельными" (еще один вариант определения — неизменяемыми) -- это значит, что они не изменяются и доступны "только для чтения". Вы можете запустить повторный рендер для _замены_ значения:
```js
setX(5);
```
-The `x` state changed from `0` to `5`, but the _number `0` itself_ did not change. It's not possible to make any changes to the built-in primitive values like numbers, strings, and booleans in JavaScript.
+Значение состояния `x` изменилось с `0` на `5`, но _число `0` само по себе_ не изменилось. Невозможно проводить изменения со встроенными (built-in) примитивами, такими как числа, строки и логические значения в JavaScript.
-Now consider an object in state:
+Рассмотрим объект в состоянии:
```js
const [position, setPosition] = useState({ x: 0, y: 0 });
```
-Technically, it is possible to change the contents of _the object itself_. **This is called a mutation:**
+Технически возможно изменить содержимое _самого объекта_. **Это называется мутацией:**
```js
position.x = 5;
```
-However, although objects in React state are technically mutable, you should treat them **as if** they were immutable--like numbers, booleans, and strings. Instead of mutating them, you should always replace them.
+На самом деле, объекты в состоянии в React мутабельны (изменяемы), но вы должны относиться к ним так, будто они иммутабельны, как и числа, строки, логические значения. Вместо того, чтобы изменять объекты напрямую, вы должны _заменять_ их.
-## Treat state as read-only {/*treat-state-as-read-only*/}
+## Рассматривайте состояние как доступное "только для чтения" {/*treat-state-as-read-only*/}
-In other words, you should **treat any JavaScript object that you put into state as read-only.**
+Иными словами, **вам необходимо рассматривать любой объект JavaScript, который находится в состоянии, доступным только для чтения.**
-This example holds an object in state to represent the current pointer position. The red dot is supposed to move when you touch or move the cursor over the preview area. But the dot stays in the initial position:
+В примере ниже состояние хранит в себе объект -- текущее положение курсора. Красная точка должна двигаться, когда вы касаетесь или перемещаете курсор над областью предварительного просмотра. Точка в данном примере остаётся в своей исходной позиции:
@@ -95,7 +95,7 @@ body { margin: 0; padding: 0; height: 250px; }
-The problem is with this bit of code.
+Существует проблема в фрагменте кода:
```js
onPointerMove={e => {
@@ -104,9 +104,9 @@ onPointerMove={e => {
}}
```
-This code modifies the object assigned to `position` from [the previous render.](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time) But without using the state setting function, React has no idea that object has changed. So React does not do anything in response. It's like trying to change the order after you've already eaten the meal. While mutating state can work in some cases, we don't recommend it. You should treat the state value you have access to in a render as read-only.
+Этот код изменяет объект `position` в [предыдущем рендере.](/learn/state-as-a-snapshot#rendering-takes-a-snapshot-in-time) React не знает об изменении объекта, так как не применялась функция установки состояния. Следовательно, React ничего не делает в ответ. Представьте, будто вы пытаетесь изменить заказ после того, как уже поели. Конечно, в некоторых случаях такое изменение может работать, но мы не рекомендуем подобным образом обновлять состояние. Вы всегда должны рассматривать значение состояния, к которому у вас есть доступ, как доступное "только для чтения".
-To actually [trigger a re-render](/learn/state-as-a-snapshot#setting-state-triggers-renders) in this case, **create a *new* object and pass it to the state setting function:**
+Для того чтобы [запустить повторный рендер](/learn/state-as-a-snapshot#setting-state-triggers-renders), **необходимо создать *новый* объект и передать его в функцию установки состояния:**
```js
onPointerMove={e => {
@@ -117,12 +117,12 @@ onPointerMove={e => {
}}
```
-With `setPosition`, you're telling React:
+С `setPosition` вы сообщаете React:
-* Replace `position` with this new object
-* And render this component again
+* Заменить `position` новым объектом;
+* Запустить новый рендер.
-Notice how the red dot now follows your pointer when you touch or hover over the preview area:
+В новом примере кода красная точка следует за вашим указателем, когда вы касаетесь или наводите курсор на область предварительного просмотра:
@@ -170,16 +170,16 @@ body { margin: 0; padding: 0; height: 250px; }
-#### Local mutation is fine {/*local-mutation-is-fine*/}
+#### Локальная мутация допустима {/*local-mutation-is-fine*/}
-Code like this is a problem because it modifies an *existing* object in state:
+Код ниже является проблемным, потому что изменяет *существующий* объект состояния:
```js
position.x = e.clientX;
position.y = e.clientY;
```
-But code like this is **absolutely fine** because you're mutating a fresh object you have *just created*:
+А этот фрагмент кода **абсолютно нормальный,** потому что вы мутируете *только что созданный* объект:
```js
const nextPosition = {};
@@ -188,7 +188,7 @@ nextPosition.y = e.clientY;
setPosition(nextPosition);
```
-In fact, it is completely equivalent to writing this:
+На самом деле, это полностью эквивалентно:
```js
setPosition({
@@ -197,15 +197,15 @@ setPosition({
});
```
-Mutation is only a problem when you change *existing* objects that are already in state. Mutating an object you've just created is okay because *no other code references it yet.* Changing it isn't going to accidentally impact something that depends on it. This is called a "local mutation". You can even do local mutation [while rendering.](/learn/keeping-components-pure#local-mutation-your-components-little-secret) Very convenient and completely okay!
+Мутация становится проблемой, когда вы изменяете *существующий* объект, который уже в состоянии. Мутировать объект, который вы только что создали, допустимо, так как *никакой код не ссылается на этот объект*. От изменения такого объекта ничего не зависит, он ничего не может случайно сломать. Это и есть "локальная мутация". Вы даже можете проводить локальную мутацию объекта [пока идёт рендер.](/learn/keeping-components-pure#local-mutation-your-components-little-secret) Это удобно и совершенно нормально!
-## Copying objects with the spread syntax {/*copying-objects-with-the-spread-syntax*/}
+## Копирование объектов с использованием оператора расширения {/*copying-objects-with-the-spread-syntax*/}
-In the previous example, the `position` object is always created fresh from the current cursor position. But often, you will want to include *existing* data as a part of the new object you're creating. For example, you may want to update *only one* field in a form, but keep the previous values for all other fields.
+В предыдущем примере объект `position` всегда создаётся заново, исходя из текущей позиции курсора. На практике чаще всего вы захотите включать уже *существующие* данные в новый объект, который вы создаёте. Например, вы можете захотеть обновить *только одно* поле в форме, остальные значения полей сохранить без изменений.
-These input fields don't work because the `onChange` handlers mutate the state:
+Эти поля ввода не работают, потому что обработчики `onChange` изменяют состояние:
@@ -234,21 +234,21 @@ export default function Form() {
return (
<>
- First name:
+ Имя:
- Last name:
+ Фамилия:
- Email:
+ Почта:
@@ -336,21 +336,21 @@ export default function Form() {
return (
<>
- First name:
+ Имя:
- Last name:
+ Фамилия:
- Email:
+ Почта:
-#### Using a single event handler for multiple fields {/*using-a-single-event-handler-for-multiple-fields*/}
+#### Использование одного обработчика событий для нескольких полей {/*using-a-single-event-handler-for-multiple-fields*/}
-You can also use the `[` and `]` braces inside your object definition to specify a property with a dynamic name. Here is the same example, but with a single event handler instead of three different ones:
+Также вы можете использовать скобки `[` и `]` внутри определения вашего объекта, чтобы указывать свойство с динамическим именем. Ниже представлен тот же самый пример, но с одним обработчиком событий вместо трёх разных:
@@ -403,7 +403,7 @@ export default function Form() {
return (
<>
- First name:
+ Имя:
- Last name:
+ Фамилия:
- Email:
+ Почта:
-## Updating a nested object {/*updating-a-nested-object*/}
+## Обновление вложенного объекта {/*updating-a-nested-object*/}
-Consider a nested object structure like this:
+Рассмотрим структуру вложенных объектов, подобную этой:
```js
const [person, setPerson] = useState({
@@ -462,13 +462,13 @@ const [person, setPerson] = useState({
});
```
-If you wanted to update `person.artwork.city`, it's clear how to do it with mutation:
+Если вы хотите обновить `person.artwork.city`, то понятно как это сделать с помощью мутации:
```js
person.artwork.city = 'New Delhi';
```
-But in React, you treat state as immutable! In order to change `city`, you would first need to produce the new `artwork` object (pre-populated with data from the previous one), and then produce the new `person` object which points at the new `artwork`:
+Но в React состояние иммутабельное! Чтобы изменить `city`, вам сначала нужно создать новый объект `artwork` (предварительно заполненный данными из предыдущего `artwork`), а затем создать новый объект `person`, который указывает на новый `artwork`:
```js
const nextArtwork = { ...person.artwork, city: 'New Delhi' };
@@ -476,19 +476,19 @@ const nextPerson = { ...person, artwork: nextArtwork };
setPerson(nextPerson);
```
-Or, written as a single function call:
+Или записанный как вызов одной функции:
```js
setPerson({
- ...person, // Copy other fields
- artwork: { // but replace the artwork
- ...person.artwork, // with the same one
- city: 'New Delhi' // but in New Delhi!
+ ...person, // копируем поля
+ artwork: { // но заменяем artwork
+ ...person.artwork, // с тем же значением
+ city: 'New Delhi' // но с New Delhi!
}
});
```
-This gets a bit wordy, but it works fine for many cases:
+Это немного многословно, но во многих случаях работает хорошо:
@@ -545,28 +545,28 @@ export default function Form() {
return (
<>
- Name:
+ Автор:
- Title:
+ Название:
- City:
+ Город:
- Image:
+ Изображение:
-#### How does Immer work? {/*how-does-immer-work*/}
+#### Как работает Immer? {/*how-does-immer-work*/}
-The `draft` provided by Immer is a special type of object, called a [Proxy](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy), that "records" what you do with it. This is why you can mutate it freely as much as you like! Under the hood, Immer figures out which parts of the `draft` have been changed, and produces a completely new object that contains your edits.
+`Черновик`, предоставленный Immer, является особенным типом объекта, который называется [прокси](https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Proxy), он "записывает" то, что вы с ним делаете. Вот почему вы можете мутировать его столько раз, сколько захотите! Под капотом Immer выясняет, какие части `черновика` были изменены, и создаёт новый объект с наличием этих изменений.
-To try Immer:
+Попробуйте Immer:
-1. Run `npm install use-immer` to add Immer as a dependency
-2. Then replace `import { useState } from 'react'` with `import { useImmer } from 'use-immer'`
+1. Запустите в терминале `npm install use-immer`, чтобы добавить Immer как зависимость
+2. Далее замените `import { useState } from 'react'` на `import { useImmer } from 'use-immer'`
-Here is the above example converted to Immer:
+Ниже представлен пример с использованием Immer:
@@ -721,28 +721,28 @@ export default function Form() {
return (
<>
- Name:
+ Автор:
- Title:
+ Название:
- City:
+ Город:
- Image:
+ Изображение:
-#### Why is mutating state not recommended in React? {/*why-is-mutating-state-not-recommended-in-react*/}
+#### Почему мутирование состояния не рекомендовано в React? {/*why-is-mutating-state-not-recommended-in-react*/}
-There are a few reasons:
+Существует ряд причин:
-* **Debugging:** If you use `console.log` and don't mutate state, your past logs won't get clobbered by the more recent state changes. So you can clearly see how state has changed between renders.
-* **Optimizations:** Common React [optimization strategies](/reference/react/memo) rely on skipping work if previous props or state are the same as the next ones. If you never mutate state, it is very fast to check whether there were any changes. If `prevObj === obj`, you can be sure that nothing could have changed inside of it.
-* **New Features:** The new React features we're building rely on state being [treated like a snapshot.](/learn/state-as-a-snapshot) If you're mutating past versions of state, that may prevent you from using the new features.
-* **Requirement Changes:** Some application features, like implementing Undo/Redo, showing a history of changes, or letting the user reset a form to earlier values, are easier to do when nothing is mutated. This is because you can keep past copies of state in memory, and reuse them when appropriate. If you start with a mutative approach, features like this can be difficult to add later on.
-* **Simpler Implementation:** Because React does not rely on mutation, it does not need to do anything special with your objects. It does not need to hijack their properties, always wrap them into Proxies, or do other work at initialization as many "reactive" solutions do. This is also why React lets you put any object into state--no matter how large--without additional performance or correctness pitfalls.
+* **Отладка:** если вы используете `console.log` и не мутируете состояние, ваши прошлые логи не будут затёрты более поздними изменениями состояния. Вы можете явно проследить, как состояние менялось между рендерами.
+* **Oптимизация:** [общие стратегии оптимизации работы в React](/reference/react/memo) основаны на пропуске работы, если прошлые пропсы и/или состояние не изменились. Можно быстро проверить были ли какие-то изменения и мутировалось ли состояние. Если выполняется равенство `prevObj === obj`, вы можете быть уверены, что действительно ничего не изменилось.
+* **Новая функциональность:** разработчики React, когда создают новую функциональность, полагаются на то, что [состояние рассматривается как снимок.](/learn/state-as-a-snapshot) Если вы мутируете прошлые версии состояния, это может помешать вам использовать новую функциональность.
+* **Изменения требований:** некоторые функции приложения, например, такие как реализация Undo/Redo, отображение истории изменений или предоставление пользователю возможности сбросить форму до более ранних значений, проще сделать, когда ничего не изменяется. Это связано с тем, что вы можете хранить прошлые копии состояния в памяти и повторно использовать их при необходимости. Если вы будете использовать подход мутирования, впоследствии будет сложно добавить такие функции.
+* **Более простая реализация:** поскольку React не полагается на мутацию, ему не нужно делать ничего особенного с вашими объектами: не нужно захватывать их свойства, всегда оборачивать их в прокси или выполнять другую работу при инициализации, как это делают многие «реактивные» решения. По этой же причине React позволяет помещать в состояние любой объект, независимо от его размера, без дополнительных проблем с производительностью или корректностью.
-In practice, you can often "get away" with mutating state in React, but we strongly advise you not to do that so that you can use new React features developed with this approach in mind. Future contributors and perhaps even your future self will thank you!
+На практике вы часто можете "уйти" от мутации состояния в React, но мы настоятельно рекомендуем вам не делать этого, чтобы вы могли использовать новые функции React, разработанные с учётом этого подхода.
-* Treat all state in React as immutable.
-* When you store objects in state, mutating them will not trigger renders and will change the state in previous render "snapshots".
-* Instead of mutating an object, create a *new* version of it, and trigger a re-render by setting state to it.
-* You can use the `{...obj, something: 'newValue'}` object spread syntax to create copies of objects.
-* Spread syntax is shallow: it only copies one level deep.
-* To update a nested object, you need to create copies all the way up from the place you're updating.
-* To reduce repetitive copying code, use Immer.
+* Рассматривайте все состояния в React как иммутабельные (неизменяемые).
+* Когда вы храните объекты в состоянии, их прямое изменение не вызовет повторный рендер и изменит состояние в предыдущих "снимках" рендера.
+* Вместо этого создайте *новую* версию объекта и активируйте повторный рендер, установив для него состояние.
+* Вы можете использовать оператор расширения, чтобы создать новый объект на основе копии старого. Например, `{...obj, something: 'newValue'}`.
+* Синтаксис расширения "поверхностный": копирование объекта происходит только на одном уровне в глубину.
+* Чтобы обновить вложенный объект, вам нужно создать копии на всем пути от того места, которое вы обновляете.
+* Для написания лаконичного кода копирования сложного объекта используйте Immer.
@@ -824,11 +824,11 @@ In practice, you can often "get away" with mutating state in React, but we stron
-#### Fix incorrect state updates {/*fix-incorrect-state-updates*/}
+#### Исправить некорректные обновления состояния {/*fix-incorrect-state-updates*/}
-This form has a few bugs. Click the button that increases the score a few times. Notice that it does not increase. Then edit the first name, and notice that the score has suddenly "caught up" with your changes. Finally, edit the last name, and notice that the score has disappeared completely.
+Форма имеет несколько ошибок. Нажмите кнопку, которая увеличивает счёт. Обратите внимание, он не увеличивается визуально. Затем отредактируйте имя и обратите внимание, что счёт внезапно "догнал" ваши изменения. Наконец, отредактируйте фамилию и обратите внимание, что счёт полностью исчез.
-Your task is to fix all of these bugs. As you fix them, explain why each of them happens.
+Необходимо исправить эти ошибки. Когда вы завершите исправления, объясните, почему происходили ошибки.
@@ -862,21 +862,21 @@ export default function Scoreboard() {
return (
<>
- Score: {player.score}
+ Счёт: {player.score}
{' '}
+1
- First name:
+ Имя:
- Last name:
+ Фамилия:
@@ -934,21 +934,21 @@ export default function Scoreboard() {
return (
<>
- Score: {player.score}
+ Счёт: {player.score}
{' '}
+1
- First name:
+ Имя:
- Last name:
+ Фамилия:
-If something unexpected changes, there is a mutation. Find the mutation in `App.js` and fix it.
+Если что-то неожиданно меняется, то происходит мутация. Найдите мутацию в `App.js` и исправьте её.
@@ -1034,7 +1034,7 @@ export default function Canvas() {
position={shape.position}
onMove={handleMove}
>
- Drag me!
+ Перетащи!
);
@@ -1132,9 +1132,9 @@ select { margin-bottom: 10px; }
-The problem was in the mutation inside `handleMove`. It mutated `shape.position`, but that's the same object that `initialPosition` points at. This is why both the shape and the background move. (It's a mutation, so the change doesn't reflect on the screen until an unrelated update--the color change--triggers a re-render.)
+Проблема заключалась в мутации внутри `handleMove`. Он изменил `shape.position`, но это тот же объект, на который указывает `initialPosition`. Вот почему блок и фон двигаются. (Это мутация, поэтому изменение не отражается на экране до тех пор, пока несвязанное обновление -- изменение цвета -- не вызовет повторный рендер)
-The fix is to remove the mutation from `handleMove`, and use the spread syntax to copy the shape. Note that `+=` is a mutation, so you need to rewrite it to use a regular `+` operation.
+Необходимо удалить мутацию из `handleMove` и использовать оператор расширения для копирования формы. Обратите внимание, что `+=` -- мутация, вам нужно переписать её, чтобы использовать обычную операцию `+`
@@ -1189,7 +1189,7 @@ export default function Canvas() {
position={shape.position}
onMove={handleMove}
>
- Drag me!
+ Перетащи!
);
@@ -1287,9 +1287,9 @@ select { margin-bottom: 10px; }
-#### Update an object with Immer {/*update-an-object-with-immer*/}
+#### Обновление объекта с Immer {/*update-an-object-with-immer*/}
-This is the same buggy example as in the previous challenge. This time, fix the mutation by using Immer. For your convenience, `useImmer` is already imported, so you need to change the `shape` state variable to use it.
+Это тот же некорректный пример, что и в предыдущем задании. На этот раз воспользуйтесь Immer. Для вашего удобства `useImmer` уже импортирован, вам нужно изменить переменную состояния `shape`.
@@ -1340,7 +1340,7 @@ export default function Canvas() {
position={shape.position}
onMove={handleMove}
>
- Drag me!
+ Перетащи!
);
@@ -1456,7 +1456,7 @@ select { margin-bottom: 10px; }
-This is the solution rewritten with Immer. Notice how the event handlers are written in a mutating fashion, but the bug does not occur. This is because under the hood, Immer never mutates the existing objects.
+Ниже представлено решение с использованием Immer. Обратите внимание, что обработчики событий написаны мутирующим образом, однако, ошибка не возникает. Это связано с тем, что Immer под капотом никогда не мутирует существующие объекты.
@@ -1507,7 +1507,7 @@ export default function Canvas() {
position={shape.position}
onMove={handleMove}
>
- Drag me!
+ Перетащи!
);
diff --git a/src/content/learn/you-might-not-need-an-effect.md b/src/content/learn/you-might-not-need-an-effect.md
index a009793ab6..b937dbc7f4 100644
--- a/src/content/learn/you-might-not-need-an-effect.md
+++ b/src/content/learn/you-might-not-need-an-effect.md
@@ -1,45 +1,45 @@
---
-title: 'You Might Not Need an Effect'
+title: 'Возможно, вам не нужен Эффект'
---
-Effects are an escape hatch from the React paradigm. They let you "step outside" of React and synchronize your components with some external system like a non-React widget, network, or the browser DOM. If there is no external system involved (for example, if you want to update a component's state when some props or state change), you shouldn't need an Effect. Removing unnecessary Effects will make your code easier to follow, faster to run, and less error-prone.
+Эффекты - это лазейка для выхода из парадигмы React. С их помощью вы можете «выйти за ее рамки» и синхронизировать компоненты с какой-либо внешней средой: сторонним виджетом, сетью или браузерным DOM. Если это не ваш случай (например, вы просто хотите обновить состояние компонента при изменении пропсов), то эффект вам не нужен. Избавив код от лишних эффектов, вы сделаете его проще для восприятия, быстрее в выполнении и менее подверженным ошибкам.
-* Why and how to remove unnecessary Effects from your components
-* How to cache expensive computations without Effects
-* How to reset and adjust component state without Effects
-* How to share logic between event handlers
-* Which logic should be moved to event handlers
-* How to notify parent components about changes
+* Как и зачем избавляться от ненужных эффектов в ваших компонентах
+* Как кешировать затратные вычисления, не используя эффекты
+* Как сбрасывать и менять состояние компонента без эффектов
+* Как разделять логику между обработчиками событий
+* Какую логику следует перемещать в обработчики событий
+* Как уведомлять родительские компоненты об изменениях
-## How to remove unnecessary Effects {/*how-to-remove-unnecessary-effects*/}
+## Как удалить лишние эффекты {/*how-to-remove-unnecessary-effects*/}
-There are two common cases in which you don't need Effects:
+Есть два распространенных случая, когда эффекты ни к чему:
-* **You don't need Effects to transform data for rendering.** For example, let's say you want to filter a list before displaying it. You might feel tempted to write an Effect that updates a state variable when the list changes. However, this is inefficient. When you update the state, React will first call your component functions to calculate what should be on the screen. Then React will ["commit"](/learn/render-and-commit) these changes to the DOM, updating the screen. Then React will run your Effects. If your Effect *also* immediately updates the state, this restarts the whole process from scratch! To avoid the unnecessary render passes, transform all the data at the top level of your components. That code will automatically re-run whenever your props or state change.
-* **You don't need Effects to handle user events.** For example, let's say you want to send an `/api/buy` POST request and show a notification when the user buys a product. In the Buy button click event handler, you know exactly what happened. By the time an Effect runs, you don't know *what* the user did (for example, which button was clicked). This is why you'll usually handle user events in the corresponding event handlers.
+* **Вам не нужны Эффекты чтобы трансформировать данные для рендера.** Например, для фильтра списка перед тем, как отобразить его. Это не совсем эффективно. Когда вы обновляете состояние, React сначала вызовет функции вашего компонента для расчета того, что должно быть на экране. Затем, React ["фиксирует"](/learn/render-and-commit) текущие изменения в DOM обновляя экран, и уже после перечисленного выполнит Эффекты. Если Эффект *еще* и изменяет состояние компонента, то весь процесс начнётся заново! Чтобы избежать ненужных фаз рендеринга, трансформируйте все данные в начале ваших компонентов. Этот код будет автоматически выполнен повторно как только изменятся пропсы или состояние.
+* **Вам не нужны Эффекты для обработчиков событий.** Допустим вы хотите отправить POST-запрос на `/api/buy` и показать уведомление, как только пользователь приобретёт товар. Вы точно знаете что произошло в обработчике событий кнопки "Купить". К моменту выполнения эффекта вы не знаете, *что* сделал пользователь (например, какая кнопка была нажата). Вот почему предпочтительно обрабатывать пользовательские события в соответствующих обработчиках.
-You *do* need Effects to [synchronize](/learn/synchronizing-with-effects#what-are-effects-and-how-are-they-different-from-events) with external systems. For example, you can write an Effect that keeps a jQuery widget synchronized with the React state. You can also fetch data with Effects: for example, you can synchronize the search results with the current search query. Keep in mind that modern [frameworks](/learn/start-a-new-react-project#production-grade-react-frameworks) provide more efficient built-in data fetching mechanisms than writing Effects directly in your components.
+Вам *нужны* эффекты для [синхронизации](/learn/synchronizing-with-effects#what-are-effects-and-how-are-they-different-from-events) с внешней средой. Например, вы можете написать эффект, который синхронизирует виджет jQuery с состоянием React. Также можно запрашивать данные с помощью эффектов: например, синхронизировать результаты поиска с самим поисковым запросом. Учтите, что современные [фреймворки](/learn/start-a-new-react-project#production-grade-react-frameworks) предоставляют более эффективные встроенные механизмы получения данных, чем написание эффектов непосредственно в компонентах.
-To help you gain the right intuition, let's look at some common concrete examples!
+Чтобы помочь вам развить интуицию, давайте рассмотрим несколько распространенных конкретных примеров!
-### Updating state based on props or state {/*updating-state-based-on-props-or-state*/}
+### Обновление состояния на основе пропсов или состояния компонента {/*updating-state-based-on-props-or-state*/}
-Suppose you have a component with two state variables: `firstName` and `lastName`. You want to calculate a `fullName` from them by concatenating them. Moreover, you'd like `fullName` to update whenever `firstName` or `lastName` change. Your first instinct might be to add a `fullName` state variable and update it in an Effect:
+Предположим, есть компонент с двумя переменными состояния: `firstName` и `lastName`. Вы хотите вычислить `fullName`, объединив их. Более того, вы хотите, чтобы `fullName` обновлялся при изменении `firstName` или `lastName`. Может возникнуть мысль добавить переменную состояния `fullName` и обновлять её с помощью эффекта:
```js {5-9}
function Form() {
const [firstName, setFirstName] = useState('Taylor');
const [lastName, setLastName] = useState('Swift');
- // 🔴 Avoid: redundant state and unnecessary Effect
+ // 🔴 Избегайте: избыточное состояние и ненужный эффект
const [fullName, setFullName] = useState('');
useEffect(() => {
setFullName(firstName + ' ' + lastName);
@@ -48,29 +48,29 @@ function Form() {
}
```
-This is more complicated than necessary. It is inefficient too: it does an entire render pass with a stale value for `fullName`, then immediately re-renders with the updated value. Remove the state variable and the Effect:
+Этот код переусложнен, а также неэффективен: выполняется полный цикл рендера со старым значением `fullName`, а затем же еще один с обновленным значением. Удалите переменную состояния и эффект:
```js {4-5}
function Form() {
const [firstName, setFirstName] = useState('Taylor');
const [lastName, setLastName] = useState('Swift');
- // ✅ Good: calculated during rendering
+ // ✅ Лучше: значение вычислено во время рендера
const fullName = firstName + ' ' + lastName;
// ...
}
```
-**When something can be calculated from the existing props or state, [don't put it in state.](/learn/choosing-the-state-structure#avoid-redundant-state) Instead, calculate it during rendering.** This makes your code faster (you avoid the extra "cascading" updates), simpler (you remove some code), and less error-prone (you avoid bugs caused by different state variables getting out of sync with each other). If this approach feels new to you, [Thinking in React](/learn/thinking-in-react#step-3-find-the-minimal-but-complete-representation-of-ui-state) explains what should go into state.
+**Когда что-то можно вычислить из текущих пропсов или состояния, [не помещайте это в состояние](/learn/choosing-the-state-structure#avoid-redundant-state) лучше, вычислите значение во время рендера.** Это делает ваш код быстрее (избегая дополнительных "каскадных" обновлений), проще (удаляя часть кода) и менее подверженным ошибкам (вы избегаете ошибок, вызванных различными переменными состояния, которые рассинхронизируются друг с другом). Если этот подход кажется вам новым, [мышление в React](/learn/thinking-in-react#step-3-find-the-minimal-but-complete-representation-of-ui-state) объясняет что нужно хранить в состоянии.
-### Caching expensive calculations {/*caching-expensive-calculations*/}
+### Кэширование затратных вычислений {/*caching-expensive-calculations*/}
-This component computes `visibleTodos` by taking the `todos` it receives by props and filtering them according to the `filter` prop. You might feel tempted to store the result in state and update it from an Effect:
+Этот компонент вычисляет `visibleTodos`, принимая `todos` в качестве пропсов, и фильтрует их согласно пропсу `filter`. Вам может показаться заманчивым хранить результат в состоянии и обновлять его с помощью эффекта:
```js {4-8}
function TodoList({ todos, filter }) {
const [newTodo, setNewTodo] = useState('');
- // 🔴 Avoid: redundant state and unnecessary Effect
+ // 🔴 Избегайте: избыточное состояние и ненужный эффект
const [visibleTodos, setVisibleTodos] = useState([]);
useEffect(() => {
setVisibleTodos(getFilteredTodos(todos, filter));
@@ -80,20 +80,20 @@ function TodoList({ todos, filter }) {
}
```
-Like in the earlier example, this is both unnecessary and inefficient. First, remove the state and the Effect:
+Как и в примере выше, этот код неэффективен. Для начала удалите ненужное состояние и эффект:
```js {3-4}
function TodoList({ todos, filter }) {
const [newTodo, setNewTodo] = useState('');
- // ✅ This is fine if getFilteredTodos() is not slow.
+ // ✅ Хорошо, если функция getFilteredTodos() не медленная.
const visibleTodos = getFilteredTodos(todos, filter);
// ...
}
```
-Usually, this code is fine! But maybe `getFilteredTodos()` is slow or you have a lot of `todos`. In that case you don't want to recalculate `getFilteredTodos()` if some unrelated state variable like `newTodo` has changed.
+Как правило, это хорошо работающий код! Но иногда `getFilteredTodos()` может быть медленной или у вас может быть много `todos`. В таком случае лучше не пересчитывать `getFilteredTodos()` если одна из несвязанных переменных изменилась, например, `newTodo`.
-You can cache (or ["memoize"](https://en.wikipedia.org/wiki/Memoization)) an expensive calculation by wrapping it in a [`useMemo`](/reference/react/useMemo) Hook:
+Вы можете кэшировать (или ["мемоизировать"](https://ru.wikipedia.org/wiki/Мемоизация)) дорогое вычисление обернув его в [`useMemo`](/reference/react/useMemo) хук:
```js {5-8}
import { useMemo, useState } from 'react';
@@ -101,35 +101,35 @@ import { useMemo, useState } from 'react';
function TodoList({ todos, filter }) {
const [newTodo, setNewTodo] = useState('');
const visibleTodos = useMemo(() => {
- // ✅ Does not re-run unless todos or filter change
+ // ✅ Не вызовется повторно, пока todos или filter не изменятся
return getFilteredTodos(todos, filter);
}, [todos, filter]);
// ...
}
```
-Or, written as a single line:
+Альтернативная запись в одну строку:
```js {5-6}
import { useMemo, useState } from 'react';
function TodoList({ todos, filter }) {
const [newTodo, setNewTodo] = useState('');
- // ✅ Does not re-run getFilteredTodos() unless todos or filter change
+ // ✅ Не вызывает повторно getFilteredTodos() пока todos или filter не изменятся
const visibleTodos = useMemo(() => getFilteredTodos(todos, filter), [todos, filter]);
// ...
}
```
-**This tells React that you don't want the inner function to re-run unless either `todos` or `filter` have changed.** React will remember the return value of `getFilteredTodos()` during the initial render. During the next renders, it will check if `todos` or `filter` are different. If they're the same as last time, `useMemo` will return the last result it has stored. But if they are different, React will call the inner function again (and store its result).
+**Этот код говорит React, что вы не хотите чтобы внутренняя функция вызывалась пока `todos` или `filter` не изменятся.** React запомнит результат выполнения `getFilteredTodos()` из первого рендера. Во время следующего, он проверит если `todos` или `filter` отличаются. Если их значение не изменилось, `useMemo` вернёт последний "мемоизированный" результат. Но если значения отличаются, React вызовет внутреннюю функцию повторно (и снова запомнит результат).
-The function you wrap in [`useMemo`](/reference/react/useMemo) runs during rendering, so this only works for [pure calculations.](/learn/keeping-components-pure)
+Функции обёрнутые в [`useMemo`](/reference/react/useMemo) выполняются во время рендеринга, поэтому это работает только для [чистых вычислений.](/learn/keeping-components-pure)
-#### How to tell if a calculation is expensive? {/*how-to-tell-if-a-calculation-is-expensive*/}
+#### Как определить, что вычисление дорогостоящее? {/*how-to-tell-if-a-calculation-is-expensive*/}
-In general, unless you're creating or looping over thousands of objects, it's probably not expensive. If you want to get more confidence, you can add a console log to measure the time spent in a piece of code:
+Как правило, если вы не создаете или не перебираете тысячи объектов, скорее всего, это не дорого. Для уверенности, добавьте запись в консоль для измерения времени, затраченного на выполнение части кода:
```js {1,3}
console.time('filter array');
@@ -137,33 +137,33 @@ const visibleTodos = getFilteredTodos(todos, filter);
console.timeEnd('filter array');
```
-Perform the interaction you're measuring (for example, typing into the input). You will then see logs like `filter array: 0.15ms` in your console. If the overall logged time adds up to a significant amount (say, `1ms` or more), it might make sense to memoize that calculation. As an experiment, you can then wrap the calculation in `useMemo` to verify whether the total logged time has decreased for that interaction or not:
+Выполните действие, которое хотите измерить (например, ввод текста в поле ввода). Вы увидите записи вроде `filter array: 0.15ms` в консоли. Если общее указанное время в журнале, составляет значительную сумму (1 мс или больше), имеет смысл закэшировать этот расчет. В качестве эксперимента оберните процесс в useMemo, чтобы проверить, уменьшилось ли общее время:
```js
console.time('filter array');
const visibleTodos = useMemo(() => {
- return getFilteredTodos(todos, filter); // Skipped if todos and filter haven't changed
+ return getFilteredTodos(todos, filter); // Повторного вызова не произойдет, если filter и todos не изменились
}, [todos, filter]);
console.timeEnd('filter array');
```
-`useMemo` won't make the *first* render faster. It only helps you skip unnecessary work on updates.
+`useMemo` не ускорит *первый* рендер, но он спасёт от ненужных выполнений при обновлениях.
-Keep in mind that your machine is probably faster than your users' so it's a good idea to test the performance with an artificial slowdown. For example, Chrome offers a [CPU Throttling](https://developer.chrome.com/blog/new-in-devtools-61/#throttling) option for this.
+Учтите, что ваше устройство, скорее всего, быстрее чем у пользователей, поэтому будет хорошей идеей протестировать производительность с искусственным замедлением. Например, в браузере Chrome встроенно [искусственное замедление процессора](https://developer.chrome.com/blog/new-in-devtools-61/#throttling) для подобных случаев.
-Also note that measuring performance in development will not give you the most accurate results. (For example, when [Strict Mode](/reference/react/StrictMode) is on, you will see each component render twice rather than once.) To get the most accurate timings, build your app for production and test it on a device like your users have.
+Так же учитывайте то, что измерение производительности в режиме разработки не покажет самых точных результатов. (Например, в [строгом режиме](/reference/react/StrictMode), вы заметите, что компоненты рендерятся дважды) Чтобы получить наиболее точные результаты, соберите приложение в продакшен-режиме и протестируйте его на устройстве, аналогичном тому, которым пользуются ваши пользователи.
-### Resetting all state when a prop changes {/*resetting-all-state-when-a-prop-changes*/}
+### Сброс состояния при изменении пропсов {/*resetting-all-state-when-a-prop-changes*/}
-This `ProfilePage` component receives a `userId` prop. The page contains a comment input, and you use a `comment` state variable to hold its value. One day, you notice a problem: when you navigate from one profile to another, the `comment` state does not get reset. As a result, it's easy to accidentally post a comment on a wrong user's profile. To fix the issue, you want to clear out the `comment` state variable whenever the `userId` changes:
+Компонент `ProfilePage` получает `userId` через пропсы. На страннице находится поле ввода для комментария и используется состояние `comment` для сохранения его значения. Как-то раз вы заметили проблему: во время навигации с одного профиля на другой, состояние `comment` не сбрасывается и в результате, очень просто допустить ошибку случайно опубликовав комментарий в профиле не того пользователя. Чтобы исправить проблему, покажется хорошей идеей очистить состояние `comment` при изменении `userId`:
```js {4-7}
export default function ProfilePage({ userId }) {
const [comment, setComment] = useState('');
- // 🔴 Avoid: Resetting state on prop change in an Effect
+ // 🔴 Избегайте: Сброс состояния при изменении пропсов в Эффекте
useEffect(() => {
setComment('');
}, [userId]);
@@ -171,9 +171,9 @@ export default function ProfilePage({ userId }) {
}
```
-This is inefficient because `ProfilePage` and its children will first render with the stale value, and then render again. It is also complicated because you'd need to do this in *every* component that has some state inside `ProfilePage`. For example, if the comment UI is nested, you'd want to clear out nested comment state too.
+Это неэффективно, потому что `ProfilePage` и его дочерние компоненты сначала отрендерятся со старым значением, и затем, отрендерятся повторно. Это также усложняет код, потому что вам придется делать это в *каждом* компоненте, в котором есть какое-то состояние внутри `ProfilePage`. Например, если пользовательский интерфейс комментариев вложен, вы также захотите очистить состояние вложенных комментариев.
-Instead, you can tell React that each user's profile is conceptually a _different_ profile by giving it an explicit key. Split your component in two and pass a `key` attribute from the outer component to the inner one:
+Вместо этого можно сказать React, что профиль каждого пользователя концептуально является _разным_ профилем, присвоив ему явный ключ. Разделите свой компонент на два и передайте атрибут `key` из внешнего компонента во внутренний:
```js {5,11-12}
export default function ProfilePage({ userId }) {
@@ -186,28 +186,28 @@ export default function ProfilePage({ userId }) {
}
function Profile({ userId }) {
- // ✅ This and any other state below will reset on key change automatically
+ // ✅ Это и любое другое состояние сбросится автоматически как только key изменится.
const [comment, setComment] = useState('');
// ...
}
```
-Normally, React preserves the state when the same component is rendered in the same spot. **By passing `userId` as a `key` to the `Profile` component, you're asking React to treat two `Profile` components with different `userId` as two different components that should not share any state.** Whenever the key (which you've set to `userId`) changes, React will recreate the DOM and [reset the state](/learn/preserving-and-resetting-state#option-2-resetting-state-with-a-key) of the `Profile` component and all of its children. Now the `comment` field will clear out automatically when navigating between profiles.
+Обычно React сохраняет состояние, когда один и тот же компонент отображается в одном месте. **Передавая `userId` в качестве ключа `key` компоненту `Profile`, вы как бы просите React рассматривать два компонента `Profile` с разными `userId` как два разных компонента, которые не должны делить между собой никакого состояния.** Всякий раз, когда key (установленный на `userId`) меняется, React обновит DOM и [сбросит состояние](/learn/preserving-and-resetting-state#option-2-resetting-state-with-a-key) компонента `Profile` и всех его дочерних. Теперь поле `comment` будет автоматически очищаться при переходе между профилями.
-Note that in this example, only the outer `ProfilePage` component is exported and visible to other files in the project. Components rendering `ProfilePage` don't need to pass the key to it: they pass `userId` as a regular prop. The fact `ProfilePage` passes it as a `key` to the inner `Profile` component is an implementation detail.
+Обратите внимание, что в данном примере только внешний компонент `ProfilePage` экспортируется и виден другим файлам в проекте. Компоненты, которые рендерят `ProfilePage`, не должны передавать ему ключ: они передают `userId` в качестве обычного пропса. Тот факт, что `ProfilePage` передает его в качестве ключа `key` внутреннему компоненту `Profile`, является деталью реализации.
-### Adjusting some state when a prop changes {/*adjusting-some-state-when-a-prop-changes*/}
+### Изменение части состояния при изменении пропсов {/*adjusting-some-state-when-a-prop-changes*/}
-Sometimes, you might want to reset or adjust a part of the state on a prop change, but not all of it.
+Иногда при изменении пропсов хочется сбросить часть состояния, но не всего.
-This `List` component receives a list of `items` as a prop, and maintains the selected item in the `selection` state variable. You want to reset the `selection` to `null` whenever the `items` prop receives a different array:
+Компонент `List` получает список `items` в качестве пропсов и сохраняет выбранный элемент в переменной состояния `selection`. Вы захотели сбрасывать значение `selection` каждый раз, когда свойство `items` получает другой массив:
```js {5-8}
function List({ items }) {
const [isReverse, setIsReverse] = useState(false);
const [selection, setSelection] = useState(null);
- // 🔴 Avoid: Adjusting state on prop change in an Effect
+ // 🔴 Избегайте: Изменение состояния при изменении свойства в Effect
useEffect(() => {
setSelection(null);
}, [items]);
@@ -215,16 +215,16 @@ function List({ items }) {
}
```
-This, too, is not ideal. Every time the `items` change, the `List` and its child components will render with a stale `selection` value at first. Then React will update the DOM and run the Effects. Finally, the `setSelection(null)` call will cause another re-render of the `List` and its child components, restarting this whole process again.
+Пример выше так же не идеален. Каждый раз, когда `items` меняются, компонент `List` и его дочерние компоненты будут рендериться со старым значением `selection`. Затем React обновит DOM и выполнит Эффекты. В конце концов, вызов `setSelection(null)` вызовет еще один рендер `List` и его дочерних компонентов, перезапуская весь этот процесс снова.
-Start by deleting the Effect. Instead, adjust the state directly during rendering:
+Начните с удаления Эффекта. Вместо него, изменяйте состояние напрямую во время рендеринга:
```js {5-11}
function List({ items }) {
const [isReverse, setIsReverse] = useState(false);
const [selection, setSelection] = useState(null);
- // Better: Adjust the state while rendering
+ // Уже лучше: состояние изменяется во время рендеринга
const [prevItems, setPrevItems] = useState(items);
if (items !== prevItems) {
setPrevItems(items);
@@ -234,31 +234,31 @@ function List({ items }) {
}
```
-[Storing information from previous renders](/reference/react/useState#storing-information-from-previous-renders) like this can be hard to understand, but it’s better than updating the same state in an Effect. In the above example, `setSelection` is called directly during a render. React will re-render the `List` *immediately* after it exits with a `return` statement. React has not rendered the `List` children or updated the DOM yet, so this lets the `List` children skip rendering the stale `selection` value.
+[Хранение информации из предыдущих рендеров](/reference/react/useState#storing-information-from-previous-renders) может быть сложным для понимания, но этот способ лучше, чем обновление одного и того же состояния в Эффекте. В приведенном выше примере `setSelection` вызывается непосредственно во время отрисовки. React отрендерит `List` *сразу же* после выхода через `return`. React еще не отрисовал дочерние элементы `List` и не обновил DOM, поэтому это позволяет дочерним элементам `List` пропустить рендеринг так как значение `selection` не меняется.
-When you update a component during rendering, React throws away the returned JSX and immediately retries rendering. To avoid very slow cascading retries, React only lets you update the *same* component's state during a render. If you update another component's state during a render, you'll see an error. A condition like `items !== prevItems` is necessary to avoid loops. You may adjust state like this, but any other side effects (like changing the DOM or setting timeouts) should stay in event handlers or Effects to [keep components pure.](/learn/keeping-components-pure)
+Когда вы обновляете компонент во время рендеринга, React отбрасывает возвращаемый JSX и тут же повторяет рендеринг. Чтобы избежать очень медленных каскадных повторных попыток, React позволяет вам обновлять состояние только *текущего* компонента во время рендеринга. Если вы обновите состояние другого компонента во время рендеринга, вы заметите ошибку. Условие вроде `items !== prevItems` необходимо, чтобы избежать зацикливания. Таким образом можно изменить не только состояние, но любые другие побочные эффекты (например, изменение DOM или установка таймеров) должны оставаться в обработчиках событий или эффектах, чтобы [сохранить чистоту компонентов.](/learn/keeping-components-pure)
-**Although this pattern is more efficient than an Effect, most components shouldn't need it either.** No matter how you do it, adjusting state based on props or other state makes your data flow more difficult to understand and debug. Always check whether you can [reset all state with a key](#resetting-all-state-when-a-prop-changes) or [calculate everything during rendering](#updating-state-based-on-props-or-state) instead. For example, instead of storing (and resetting) the selected *item*, you can store the selected *item ID:*
+**Не смотря на то, что этот паттерн более эффективен, чем Эффект, большинство компонентов не должны его использовать.** Независимо от того, как вы это делаете, настройка состояния на основе свойств или другого состояния усложняет понимание и отладку потока данных. Всегда проверяйте, можете ли вы [сбросить все состояния ключом](#resetting-all-state-when-a-prop-changes) или [рассчитать все во время рендеринга](#updating-state-based-on-props-or-state). Например, вместо хранения (и сброса) выбранного *элемента*, можно хранить выбранный *ID элемента:*
```js {3-5}
function List({ items }) {
const [isReverse, setIsReverse] = useState(false);
const [selectedId, setSelectedId] = useState(null);
- // ✅ Best: Calculate everything during rendering
+ // ✅ Лучше: Вычисляйте всё во время рендеринга
const selection = items.find(item => item.id === selectedId) ?? null;
// ...
}
```
-Now there is no need to "adjust" the state at all. If the item with the selected ID is in the list, it remains selected. If it's not, the `selection` calculated during rendering will be `null` because no matching item was found. This behavior is different, but arguably better because most changes to `items` preserve the selection.
+Теперь нет необходимости "настраивать" состояние вообще. Если элемент с выбранным ID находится в списке, он остается выбранным. Если его нет, `selection`, вычисленный во время рендеринга, будет равен `null`, потому что соответствующий элемент не был найден. Это поведение отличается, но, возможно, лучше, так как большинство изменений в `items` сохраняют выбор.
-### Sharing logic between event handlers {/*sharing-logic-between-event-handlers*/}
+### Обмен логикой между обработчиками событий {/*sharing-logic-between-event-handlers*/}
-Let's say you have a product page with two buttons (Buy and Checkout) that both let you buy that product. You want to show a notification whenever the user puts the product in the cart. Calling `showNotification()` in both buttons' click handlers feels repetitive so you might be tempted to place this logic in an Effect:
+Допустим, у вас есть страница товара с двумя кнопками (Купить и Оформить заказ), обе позволяют купить товар. Вы хотите показать уведомление всякий раз, когда пользователь добавляет товар в корзину. Вызов `showNotification()` в обработчиках нажатия обеих кнопок кажется повторяющимся, возникает мысль поместить эту логику в Эффект:
```js {2-7}
function ProductPage({ product, addToCart }) {
- // 🔴 Avoid: Event-specific logic inside an Effect
+ // 🔴 Избегайте: специфическая логика ивента внутри Эффекта
useEffect(() => {
if (product.isInCart) {
showNotification(`Added ${product.name} to the shopping cart!`);
@@ -277,13 +277,13 @@ function ProductPage({ product, addToCart }) {
}
```
-This Effect is unnecessary. It will also most likely cause bugs. For example, let's say that your app "remembers" the shopping cart between the page reloads. If you add a product to the cart once and refresh the page, the notification will appear again. It will keep appearing every time you refresh that product's page. This is because `product.isInCart` will already be `true` on the page load, so the Effect above will call `showNotification()`.
+Этот Эффект лишний. Он также, скорее всего, вызовет ошибки. Представьте, что приложение "запоминает" корзину покупок между перезагрузками страницы. Если вы добавите товар в корзину один раз и обновите страницу, уведомление появится снова. Оно будет продолжать появляться каждый раз, когда вы обновляете страницу товара. Это происходит потому, что `product.isInCart` будет `true` при загрузке страницы, и вышеуказанный Эффект вызовет `showNotification()`.
-**When you're not sure whether some code should be in an Effect or in an event handler, ask yourself *why* this code needs to run. Use Effects only for code that should run *because* the component was displayed to the user.** In this example, the notification should appear because the user *pressed the button*, not because the page was displayed! Delete the Effect and put the shared logic into a function called from both event handlers:
+**Когда есть сомнения, должен ли какой-то код быть в Эффекте или в обработчике событий, спросите себя, *почему* этот код должен выполняться. Используйте Эффекты только для кода, который должен выполняться *потому что* компонент был показан пользователю.** В данном примере уведомление должно появляться потому, что пользователь *нажал на кнопку*, а не потому что страница была загружена! Удалите Эффект и поместите общую логику в функцию, вызываемую из обоих обработчиков событий:
```js {2-6,9,13}
function ProductPage({ product, addToCart }) {
- // ✅ Good: Event-specific logic is called from event handlers
+ // ✅ Лучше: специфическая ивент-логика вызывается из обработчиков.
function buyProduct() {
addToCart(product);
showNotification(`Added ${product.name} to the shopping cart!`);
@@ -301,23 +301,23 @@ function ProductPage({ product, addToCart }) {
}
```
-This both removes the unnecessary Effect and fixes the bug.
+Этот код удаляет ненужный Эффект, и исправляет ошибку.
-### Sending a POST request {/*sending-a-post-request*/}
+### Отправка POST-запроса {/*sending-a-post-request*/}
-This `Form` component sends two kinds of POST requests. It sends an analytics event when it mounts. When you fill in the form and click the Submit button, it will send a POST request to the `/api/register` endpoint:
+Представим, что компонент `Form` делает два типа POST-запросов. Он отправляет событие аналитики при монтировании. А когда вы заполняете форму и нажимаете кнопку «Отправить», он отправит POST-запрос на конечную точку `/api/register`:
```js {5-8,10-16}
function Form() {
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
- // ✅ Good: This logic should run because the component was displayed
+ // ✅ Хорошо: Этот код должен сработать когда компонент отрендерится
useEffect(() => {
post('/analytics/event', { eventName: 'visit_form' });
}, []);
- // 🔴 Avoid: Event-specific logic inside an Effect
+ // 🔴 Излишне: специфическая логика ивента внутри Эффекта
const [jsonToSubmit, setJsonToSubmit] = useState(null);
useEffect(() => {
if (jsonToSubmit !== null) {
@@ -333,36 +333,36 @@ function Form() {
}
```
-Let's apply the same criteria as in the example before.
+Давайте применим те же критерии, что и в предыдущем примере.
-The analytics POST request should remain in an Effect. This is because the _reason_ to send the analytics event is that the form was displayed. (It would fire twice in development, but [see here](/learn/synchronizing-with-effects#sending-analytics) for how to deal with that.)
+POST-запрос аналитики должен остаться в Эффекте. Это связано с тем, что _причина_ отправки события аналитики заключается в том, что форма была отображена. (Она сработает дважды в процессе разработки, но [смотреть тут](/learn/synchronizing-with-effects#sending-analytics) о том, как с этим работать.)
-However, the `/api/register` POST request is not caused by the form being _displayed_. You only want to send the request at one specific moment in time: when the user presses the button. It should only ever happen _on that particular interaction_. Delete the second Effect and move that POST request into the event handler:
+Но POST-запрос `/api/register` не вызывается с рендерингом формы. Вы хотели бы, чтобы запрос происходил только в один конкретный момент времени: когда пользователь нажимает кнопку. Это должно произойти только _при этом конкретном взаимодействии_. Удалите второй Эффект и переместите POST-запрос в обработчик событий:
```js {12-13}
function Form() {
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
- // ✅ Good: This logic runs because the component was displayed
+ // ✅ Хорошо: Эта код должен сработать когда компонент отрендерился
useEffect(() => {
post('/analytics/event', { eventName: 'visit_form' });
}, []);
function handleSubmit(e) {
e.preventDefault();
- // ✅ Good: Event-specific logic is in the event handler
+ // ✅ Хорошо: специфическая ивент-логика вызывается из обработчиков.
post('/api/register', { firstName, lastName });
}
// ...
}
```
-When you choose whether to put some logic into an event handler or an Effect, the main question you need to answer is _what kind of logic_ it is from the user's perspective. If this logic is caused by a particular interaction, keep it in the event handler. If it's caused by the user _seeing_ the component on the screen, keep it in the Effect.
+При выборе между размещением логики в обработчике событий или в Эффекте, основной вопрос, на который вам нужно ответить, это какой это вид логики с точки зрения пользователя. Если логика вызвана определенным взаимодействием, оставьте ее в обработчике событий. Если она вызвана тем, что пользователь видит компонент на экране, поместите ее в Эффект.
-### Chains of computations {/*chains-of-computations*/}
+### Цепочки вычислений {/*chains-of-computations*/}
-Sometimes you might feel tempted to chain Effects that each adjust a piece of state based on other state:
+Иногда может показаться заманчивым связать Эффекты, каждый из которых корректирует часть состояния на основе другого:
```js {7-29}
function Game() {
@@ -371,7 +371,7 @@ function Game() {
const [round, setRound] = useState(1);
const [isGameOver, setIsGameOver] = useState(false);
- // 🔴 Avoid: Chains of Effects that adjust the state solely to trigger each other
+ // 🔴 Избегайте: Цепочки Эффектов, которые корректируют состояние в зависимости от друг друга
useEffect(() => {
if (card !== null && card.gold) {
setGoldCardCount(c => c + 1);
@@ -406,13 +406,15 @@ function Game() {
// ...
```
-There are two problems with this code.
+У этого кода две проблемы.
-The first problem is that it is very inefficient: the component (and its children) have to re-render between each `set` call in the chain. In the example above, in the worst case (`setCard` → render → `setGoldCardCount` → render → `setRound` → render → `setIsGameOver` → render) there are three unnecessary re-renders of the tree below.
-The second problem is that even if it weren't slow, as your code evolves, you will run into cases where the "chain" you wrote doesn't fit the new requirements. Imagine you are adding a way to step through the history of the game moves. You'd do it by updating each state variable to a value from the past. However, setting the `card` state to a value from the past would trigger the Effect chain again and change the data you're showing. Such code is often rigid and fragile.
+Первая заключается в том, что это очень неэффективно: компонент (и его дочерние элементы) должны перерисовываться между каждым вызовом `set` в цепочке. В приведенном выше примере, в худшем случае (`setCard` → рендер → `setGoldCardCount` → рендер → `setRound` → рендер → `setIsGameOver` → рендер) происходят три ненужные перерисовки дерева.
-In this case, it's better to calculate what you can during rendering, and adjust the state in the event handler:
+
+Даже если это кажется быстрым, с течением времени, при росте вашего кода, вы столкнетесь с ситуациями, когда созданная вами "цепочка" не соответствует требованиям. Представьте, что нужно добавить возможность просматривать историю ходов игры. Этого можно было бы добиться, обновляя каждую переменную состояния до прошлого значения. Однако установка состояния `card` на значение из рендера снова запустит цепочку эффектов и изменит отображаемые данные. Такой код часто является очень хрупким.
+
+В этом случае лучше вычислять то, что можно, во время рендеринга, и корректировать состояние в обработчике событий:
```js {6-7,14-26}
function Game() {
@@ -420,7 +422,7 @@ function Game() {
const [goldCardCount, setGoldCardCount] = useState(0);
const [round, setRound] = useState(1);
- // ✅ Calculate what you can during rendering
+ // ✅ Вычисление во время рендеринга
const isGameOver = round > 5;
function handlePlaceCard(nextCard) {
@@ -428,7 +430,7 @@ function Game() {
throw Error('Game already ended.');
}
- // ✅ Calculate all the next state in the event handler
+ // ✅ Вычисление следующего состояния в обработчике событий
setCard(nextCard);
if (nextCard.gold) {
if (goldCardCount <= 3) {
@@ -446,21 +448,21 @@ function Game() {
// ...
```
-This is a lot more efficient. Also, if you implement a way to view game history, now you will be able to set each state variable to a move from the past without triggering the Effect chain that adjusts every other value. If you need to reuse logic between several event handlers, you can [extract a function](#sharing-logic-between-event-handlers) and call it from those handlers.
+Это код намного эффективней. Кроме того, если вы реализовали возможность просмотра истории игры, теперь так же можно установить каждую переменную состояния на ход из прошлого, не запуская цепочку эффектов, которая корректирует другие значения. Если вам нужно повторно использовать логику между несколькими обработчиками событий, вы можете [извлечь функцию](#sharing-logic-between-event-handlers) и вызывать ее из этих обработчиков.
-Remember that inside event handlers, [state behaves like a snapshot.](/learn/state-as-a-snapshot) For example, even after you call `setRound(round + 1)`, the `round` variable will reflect the value at the time the user clicked the button. If you need to use the next value for calculations, define it manually like `const nextRound = round + 1`.
+Помните, что внутри обработчиков событий [состояние ведет себя как снимок.](/learn/state-as-a-snapshot) К примеру, даже после вызова `setRound(round + 1)`, переменная `round` будет отражать значение на момент нажатия пользователем кнопки. Если вам нужно использовать следующее значение для расчётов, определите его вручную, например, `const nextRound = round + 1`.
-In some cases, you *can't* calculate the next state directly in the event handler. For example, imagine a form with multiple dropdowns where the options of the next dropdown depend on the selected value of the previous dropdown. Then, a chain of Effects is appropriate because you are synchronizing with network.
+В некоторых случаях вы *не можете* вычислить следующее состояние непосредственно в обработчике событий. Например, представьте форму с несколькими выпадающими списками, где варианты следующего выпадающего списка зависят от выбранного значения предыдущего выпадающего списка. Тогда цепочка эффектов будет уместной, потому что вы синхронизируете её с сетью.
-### Initializing the application {/*initializing-the-application*/}
+### Инициализация приложения {/*initializing-the-application*/}
-Some logic should only run once when the app loads.
+Некоторая логика должна выполняться только один раз при загрузке приложения.
-You might be tempted to place it in an Effect in the top-level component:
+Может показаться хорошей идеей разместить ее в эффекте в компоненте верхнего уровня:
```js {2-6}
function App() {
- // 🔴 Avoid: Effects with logic that should only ever run once
+ // 🔴 Избегайте: в эффекте логика которая выполняются один раз за всё время
useEffect(() => {
loadDataFromLocalStorage();
checkAuthToken();
@@ -469,9 +471,9 @@ function App() {
}
```
-However, you'll quickly discover that it [runs twice in development.](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development) This can cause issues--for example, maybe it invalidates the authentication token because the function wasn't designed to be called twice. In general, your components should be resilient to being remounted. This includes your top-level `App` component.
+Однако вы быстро обнаружите, что эффект [выполняется дважды в режиме разработки.](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development) Это может создать проблемы - например, возможно, это аннулирует токен аутентификации, потому что функция не была разработана для двойного вызова. В целом, компоненты должны быть устойчивы к повторному монтированию. Это включает и компонент верхнего уровня `App`.
-Although it may not ever get remounted in practice in production, following the same constraints in all components makes it easier to move and reuse code. If some logic must run *once per app load* rather than *once per component mount*, add a top-level variable to track whether it has already executed:
+Хотя на практике он может никогда не быть смонтирован заново в продакшен-режиме, соблюдение одних и тех же ограничений во всех компонентах упрощает их перемещение и повторное использование кода. Если некоторая логика должна выполняться *один раз при загрузке приложения*, а не *один раз при монтировании компонента*, добавьте переменную верхнего уровня для отслеживания того, была ли она уже выполнена:
```js {1,5-6,10}
let didInit = false;
@@ -480,7 +482,7 @@ function App() {
useEffect(() => {
if (!didInit) {
didInit = true;
- // ✅ Only runs once per app load
+ // ✅ Будут вызваны один раз при загрузке приложения
loadDataFromLocalStorage();
checkAuthToken();
}
@@ -489,11 +491,11 @@ function App() {
}
```
-You can also run it during module initialization and before the app renders:
+Так же можно сделать вызов во время инициализации модуля, до того как приложение отрендерится:
```js {1,5}
-if (typeof window !== 'undefined') { // Check if we're running in the browser.
- // ✅ Only runs once per app load
+if (typeof window !== 'undefined') { // Проверка на то, что код выполняется в браузере.
+ // ✅ Выполнится один раз с загрузкой приложения
checkAuthToken();
loadDataFromLocalStorage();
}
@@ -503,17 +505,17 @@ function App() {
}
```
-Code at the top level runs once when your component is imported--even if it doesn't end up being rendered. To avoid slowdown or surprising behavior when importing arbitrary components, don't overuse this pattern. Keep app-wide initialization logic to root component modules like `App.js` or in your application's entry point.
+Код на верхнем уровне выполняется один раз при импорте вашего компонента, даже если он не будет отображаться. Чтобы избежать замедления или неожиданного поведения при импорте произвольных компонентов, не злоупотребляйте этим паттерном. Держите логику инициализации приложения в модулях корневых компонентов, таких как `App.js`, или в точке входа вашего приложения.
-### Notifying parent components about state changes {/*notifying-parent-components-about-state-changes*/}
+### Уведомление родительских компонентов об изменении состояния {/*notifying-parent-components-about-state-changes*/}
-Let's say you're writing a `Toggle` component with an internal `isOn` state which can be either `true` or `false`. There are a few different ways to toggle it (by clicking or dragging). You want to notify the parent component whenever the `Toggle` internal state changes, so you expose an `onChange` event and call it from an Effect:
+Допустим, вы пишете компонент `Toggle` с внутренним состоянием `isOn`, которое может быть либо `true`, либо `false`. Есть несколько способов переключить его (кликом или перетаскиванием). Вы хотите уведомить родительский компонент при каждом изменении внутреннего состояния `Toggle`, поэтому вы "пробрасываете" событие `onChange` и вызываете его из эффекта:
```js {4-7}
function Toggle({ onChange }) {
const [isOn, setIsOn] = useState(false);
- // 🔴 Avoid: The onChange handler runs too late
+ // 🔴 Избегайте: Событие onChange выполнится слишком поздно
useEffect(() => {
onChange(isOn);
}, [isOn, onChange])
@@ -534,16 +536,16 @@ function Toggle({ onChange }) {
}
```
-Like earlier, this is not ideal. The `Toggle` updates its state first, and React updates the screen. Then React runs the Effect, which calls the `onChange` function passed from a parent component. Now the parent component will update its own state, starting another render pass. It would be better to do everything in a single pass.
+Как и ранее, это не идеально. `Toggle` сначала обновит свое состояние, и React обновит экран. Затем React выполняет эффект, который вызывает функцию `onChange`, переданную от родительского компонента и родительский компонент обновит свое собственное состояние, начиная еще один цикл рендеринга. Было бы лучше сделать все за один проход.
-Delete the Effect and instead update the state of *both* components within the same event handler:
+Удалите эффект и вместо этого обновите состояние *обоих* компонентов в одном обработчике событий:
```js {5-7,11,16,18}
function Toggle({ onChange }) {
const [isOn, setIsOn] = useState(false);
function updateToggle(nextIsOn) {
- // ✅ Good: Perform all updates during the event that caused them
+ // ✅ Лучше: Выполнение всех обновлений во время события, которое их вызвало
setIsOn(nextIsOn);
onChange(nextIsOn);
}
@@ -564,12 +566,12 @@ function Toggle({ onChange }) {
}
```
-With this approach, both the `Toggle` component and its parent component update their state during the event. React [batches updates](/learn/queueing-a-series-of-state-updates) from different components together, so there will only be one render pass.
+В этом подходе, компонент `Toggle`, и его родительский компонент обновляют свое состояние во время события. React [группирует обновления](/learn/queueing-a-series-of-state-updates) из разных компонентов, поэтому будет только один цикл рендеринга.
-You might also be able to remove the state altogether, and instead receive `isOn` from the parent component:
+Возможно, вы даже сможете удалить полностью состояние и вместо этого получать `isOn` из родительского компонента:
```js {1,2}
-// ✅ Also good: the component is fully controlled by its parent
+// ✅ Тоже хорошо: компонент полностью контролируется родителем
function Toggle({ isOn, onChange }) {
function handleClick() {
onChange(!isOn);
@@ -587,11 +589,11 @@ function Toggle({ isOn, onChange }) {
}
```
-["Lifting state up"](/learn/sharing-state-between-components) lets the parent component fully control the `Toggle` by toggling the parent's own state. This means the parent component will have to contain more logic, but there will be less state overall to worry about. Whenever you try to keep two different state variables synchronized, try lifting state up instead!
+["Поднятие состояния"](/learn/sharing-state-between-components) позволяет родительскому компоненту полностью контролировать `Toggle`, переключая собственное состояние. Это означает, что родительскому компоненту придется содержать больше логики, но в целом будет меньше состояний, о котором нужно беспокоиться. Всякий раз, когда вы пытаетесь синхронизировать две разные переменных состояния, попробуйте вместо этого их поднять на уровень выше!
-### Passing data to the parent {/*passing-data-to-the-parent*/}
+### Передача данных родителю {/*passing-data-to-the-parent*/}
-This `Child` component fetches some data and then passes it to the `Parent` component in an Effect:
+Компонент `Child` получает некоторые данные, а затем передает их компоненту `Parent` в эффекте:
```js {9-14}
function Parent() {
@@ -602,7 +604,7 @@ function Parent() {
function Child({ onFetched }) {
const data = useSomeAPI();
- // 🔴 Avoid: Passing data to the parent in an Effect
+ // 🔴 Избегайте: Передача данных из родителя внутрь Эффекта
useEffect(() => {
if (data) {
onFetched(data);
@@ -612,13 +614,13 @@ function Child({ onFetched }) {
}
```
-In React, data flows from the parent components to their children. When you see something wrong on the screen, you can trace where the information comes from by going up the component chain until you find which component passes the wrong prop or has the wrong state. When child components update the state of their parent components in Effects, the data flow becomes very difficult to trace. Since both the child and the parent need the same data, let the parent component fetch that data, and *pass it down* to the child instead:
+В React данные передаются от родительских компонентов к дочерним. Когда вы видите что-то неправильное на экране, то можно проследить, откуда приходит информация, поднимаясь вверх по цепочке компонентов, пока не найдете компонент, который передает неправильный пропс или с неправильное состоянием. Когда дочерние компоненты обновляют состояние своих родительских компонентов в эффектах, поток данных становится очень сложным для отслеживания. Так как и дочерний, и родительский компоненты нуждаются в одних и тех же данных, позвольте родительскому компоненту получать данные и *передавать их вниз* дочернему компоненту:
```js {4-5}
function Parent() {
const data = useSomeAPI();
// ...
- // ✅ Good: Passing data down to the child
+ // ✅ Лучше: Передача данных вниз по цепочке – дочернему компоненту
return
-- If you can calculate something during render, you don't need an Effect.
-- To cache expensive calculations, add `useMemo` instead of `useEffect`.
-- To reset the state of an entire component tree, pass a different `key` to it.
-- To reset a particular bit of state in response to a prop change, set it during rendering.
-- Code that runs because a component was *displayed* should be in Effects, the rest should be in events.
-- If you need to update the state of several components, it's better to do it during a single event.
-- Whenever you try to synchronize state variables in different components, consider lifting state up.
-- You can fetch data with Effects, but you need to implement cleanup to avoid race conditions.
+- Если вы можете вычислить что-то во время рендера, вам не нужен эффект.
+- Чтобы кэшировать дорогостоящие вычисления, добавьте `useMemo` вместо `useEffect`.
+- Чтобы сбросить состояние всего дерева компонентов, передайте другой `key`.
+- Чтобы сбросить определенную часть состояния в ответ на изменение пропса, установите его во время рендеринга.
+- Код, который запускается после того, как компонент *отображён*, должен быть в эффектах, остальное должно быть в событиях.
+- Если вам нужно обновить состояние нескольких компонентов, лучше сделать это во время одного события.
+- Всякий раз, когда вы пытаетесь синхронизировать переменные состояния в разных компонентах, рассмотрите возможность поднятия состояния.
+- Вы можете получать данные с помощью эффектов, но вам нужно реализовать очистку, чтобы избежать состояний гонки.
-#### Transform data without Effects {/*transform-data-without-effects*/}
+#### Трансформация данных без использования эффектов {/*transform-data-without-effects*/}
-The `TodoList` below displays a list of todos. When the "Show only active todos" checkbox is ticked, completed todos are not displayed in the list. Regardless of which todos are visible, the footer displays the count of todos that are not yet completed.
+Ниже, компонент `TodoList` отображает список задач. Когда установлен флажок "Show only active todos", завершенные задачи не отображаются в списке. Независимо от того, какие задачи видимы, нижняя часть страницы отображает количество задач, которые еще не завершены.
-Simplify this component by removing all the unnecessary state and Effects.
+Упростите этот компонент, удалив все ненужные состояния и эффекты.
@@ -909,15 +911,15 @@ input { margin-top: 10px; }
-If you can calculate something during rendering, you don't need state or an Effect that updates it.
+Если вы можете вычислить что-то во время рендеринга, вам не нужно состояние или эффект, который обновляет его.
-There are only two essential pieces of state in this example: the list of `todos` and the `showActive` state variable which represents whether the checkbox is ticked. All of the other state variables are [redundant](/learn/choosing-the-state-structure#avoid-redundant-state) and can be calculated during rendering instead. This includes the `footer` which you can move directly into the surrounding JSX.
+В этом примере есть только две основные части состояния: список `todos` и переменная состояния `showActive`, которая определяет, отмечен ли флажок. Все другие переменные состояния являются [избыточными](/learn/choosing-the-state-structure#avoid-redundant-state) и могут быть вычислены во время рендеринга. Это включает `footer`, который можно переместить прямо в JSX.
-Your result should end up looking like this:
+Ваш результат должен выглядеть примерно так:
@@ -1002,15 +1004,15 @@ input { margin-top: 10px; }
-#### Cache a calculation without Effects {/*cache-a-calculation-without-effects*/}
+#### Кэширование вычислений без использования Эффектов {/*cache-a-calculation-without-effects*/}
-In this example, filtering the todos was extracted into a separate function called `getVisibleTodos()`. This function contains a `console.log()` call inside of it which helps you notice when it's being called. Toggle "Show only active todos" and notice that it causes `getVisibleTodos()` to re-run. This is expected because visible todos change when you toggle which ones to display.
+В этом примере фильтрация задач была вынесена в отдельную функцию под названием `getVisibleTodos()`. Внутри этой функции есть вызов `console.log()`, который помогает следить, когда он вызывается. Переключите "Show only active todos" и обратите внимание, что это вызывает повторное выполнение `getVisibleTodos()`. Это ожидаемо, потому что видимые задачи меняются при переключении того, какие из них отображать.
-Your task is to remove the Effect that recomputes the `visibleTodos` list in the `TodoList` component. However, you need to make sure that `getVisibleTodos()` does *not* re-run (and so does not print any logs) when you type into the input.
+Ваша задача - удалить Эффект, который пересчитывает список `visibleTodos` в компоненте `TodoList`. Но вам нужно убедиться, что `getVisibleTodos()` *не* запускается повторно (и, следовательно, не выводит никаких логов) при вводе текста в поле ввода.
-One solution is to add a `useMemo` call to cache the visible todos. There is also another, less obvious solution.
+Одно из решений добавить `useMemo` чтобы закэшировать видимые todos. Но есть и другое, менее очевидное.
@@ -1096,7 +1098,7 @@ input { margin-top: 10px; }
-Remove the state variable and the Effect, and instead add a `useMemo` call to cache the result of calling `getVisibleTodos()`:
+Удалите переменную состояния и Эффект, а затем добавьте `useMemo` для кэширования результата вызова `getVisibleTodos()`:
@@ -1177,9 +1179,9 @@ input { margin-top: 10px; }
-With this change, `getVisibleTodos()` will be called only if `todos` or `showActive` change. Typing into the input only changes the `text` state variable, so it does not trigger a call to `getVisibleTodos()`.
+С этим правками `getVisibleTodos()` будет вызываться только при изменении `todos` или `showActive`. Ввод текста в поле изменяет только переменную состояния `text`, поэтому вызов `getVisibleTodos()` не вызывается повторно.
-There is also another solution which does not need `useMemo`. Since the `text` state variable can't possibly affect the list of todos, you can extract the `NewTodo` form into a separate component, and move the `text` state variable inside of it:
+Существует также другое решение, которое не требует использования `useMemo`. Поскольку переменная состояния `text` никак не может повлиять на список задач, вы можете вынести форму `NewTodo` в отдельный компонент и переместить переменную состояния `text` внутрь него:
@@ -1266,15 +1268,15 @@ input { margin-top: 10px; }
-This approach satisfies the requirements too. When you type into the input, only the `text` state variable updates. Since the `text` state variable is in the child `NewTodo` component, the parent `TodoList` component won't get re-rendered. This is why `getVisibleTodos()` doesn't get called when you type. (It would still be called if the `TodoList` re-renders for another reason.)
+Этот подход также удовлетворяет требованиям. При вводе текста в поле обновляется только переменная состояния `text`. Поскольку переменная состояния `text` находится в дочернем компоненте `NewTodo`, родительский компонент `TodoList` не будет перерисовываться. По это причине `getVisibleTodos()` не вызывается при вводе текста. (Однако, вызов `getVisibleTodos()` все равно произойдет, если компонент `TodoList` ререндерится по другой причине.)
-#### Reset state without Effects {/*reset-state-without-effects*/}
+#### Сброс состояния без использования эффектов {/*reset-state-without-effects*/}
-This `EditContact` component receives a contact object shaped like `{ id, name, email }` as the `savedContact` prop. Try editing the name and email input fields. When you press Save, the contact's button above the form updates to the edited name. When you press Reset, any pending changes in the form are discarded. Play around with this UI to get a feel for it.
+Компонент `EditContact` получает объект контакта с такой структурой `{ id, name, email }` как проп `savedContact`. Попробуйте отредактировать поля для имени и адреса электронной почты. Как только вы нажмёте кнопку "Сохранить", кнопка контакта над формой обновляется с измененным именем. Если нажать кнопку "Сброс", все изменения в форме отменяются. Поиграйте с этим интерфейсом, чтобы разобраться в нем.
-When you select a contact with the buttons at the top, the form resets to reflect that contact's details. This is done with an Effect inside `EditContact.js`. Remove this Effect. Find another way to reset the form when `savedContact.id` changes.
+Когда вы выбираете контакт с помощью кнопок сверху, форма сбрасывается, чтобы отобразить данные выбранного контакта. Это делается с помощью эффекта внутри `EditContact.js`. Удалите этот эффект. Найдите другой способ сбросить форму, когда изменяется `savedContact.id`.
@@ -1432,13 +1434,13 @@ button {
-It would be nice if there was a way to tell React that when `savedContact.id` is different, the `EditContact` form is conceptually a _different contact's form_ and should not preserve state. Do you recall any such way?
+Было бы здорово, если бы был способ сообщить React, что когда `savedContact.id` отличается, форма `EditContact` концептуально является _формой другого контакта_ и не должна сохранять состояние. Припоминаете что-нибудь?
-Split the `EditContact` component in two. Move all the form state into the inner `EditForm` component. Export the outer `EditContact` component, and make it pass `savedContact.id` as the `key` to the inner `EditForm` component. As a result, the inner `EditForm` component resets all of the form state and recreates the DOM whenever you select a different contact.
+Разделите компонент `EditContact` на две части. Переместите все состояние формы во внутренний компонент `EditForm`. Экспортируйте внешний компонент `EditContact` и передайте `savedContact.id` в качестве `key` внутреннему компоненту `EditContact`. В результате внутренний компонент `EditForm` сбросит все состояние формы и воссоздаст DOM в каждый раз, когда будет выбран другой контакт.
@@ -1600,17 +1602,17 @@ button {
-#### Submit a form without Effects {/*submit-a-form-without-effects*/}
+#### Отправить форму без Эффекта {/*submit-a-form-without-effects*/}
-This `Form` component lets you send a message to a friend. When you submit the form, the `showForm` state variable is set to `false`. This triggers an Effect calling `sendMessage(message)`, which sends the message (you can see it in the console). After the message is sent, you see a "Thank you" dialog with an "Open chat" button that lets you get back to the form.
+Компонент `Form` позволяет отправить сообщение другу. Когда вы отправляете форму, переменная состояния `showForm` устанавливается в значение `false`. Это вызывает Эффект, который вызывает `sendMessage(message)`, отправляя сообщение (вы можете увидеть его в консоли). После отправки сообщения вы видите диалоговое окно "Thank you" с кнопкой "Open chat", которая позволяет вернуться к форме.
-Your app's users are sending way too many messages. To make chatting a little bit more difficult, you've decided to show the "Thank you" dialog *first* rather than the form. Change the `showForm` state variable to initialize to `false` instead of `true`. As soon as you make that change, the console will show that an empty message was sent. Something in this logic is wrong!
+Пользователи приложения отправляют слишком много сообщений. Чтобы немного усложнить чат, вы решили сначала показать диалоговое окно "Thank you", а не форму. Измените переменную состояния `showForm`, чтобы она инициализировалась значением `false` вместо `true`. Как только вы внесете это изменение, консоль покажет, что было отправлено пустое сообщение. В этой логике что-то не так!
-What's the root cause of this problem? And how can you fix it?
+В чем корень этой проблемы? И как его исправить?
-Should the message be sent _because_ the user saw the "Thank you" dialog? Or is it the other way around?
+Должно ли сообщение быть отправлено _потому что_ пользователь увидел диалог "Thank you"? Или это наоборот?
@@ -1675,7 +1677,7 @@ label, textarea { margin-bottom: 10px; display: block; }
-The `showForm` state variable determines whether to show the form or the "Thank you" dialog. However, you aren't sending the message because the "Thank you" dialog was _displayed_. You want to send the message because the user has _submitted the form._ Delete the misleading Effect and move the `sendMessage` call inside the `handleSubmit` event handler:
+Переменная состояния `showForm` определяет, показывать ли форму или диалоговое окно "Thank you". Но, ведь, вы отправляете сообщение не потому, что было _отображено_ диалоговое окно, а потому что пользователь _отправил форму_. Удалите вводящий в заблуждение эффект и переместите вызов `sendMessage` в обработчик события `handleSubmit`:
@@ -1731,8 +1733,8 @@ label, textarea { margin-bottom: 10px; display: block; }
-Notice how in this version, only _submitting the form_ (which is an event) causes the message to be sent. It works equally well regardless of whether `showForm` is initially set to `true` or `false`. (Set it to `false` and notice no extra console messages.)
+Обратите внимание, что в этой версии сообщение отправляется только при _отправке формы_ (что является событием). Это работает одинаково хорошо, независимо от того, установлено ли изначально значение `showForm` в `true` или `false`. (Установите его в `false` и заметьте, что нет лишних сообщений в консоли.)
-
+
\ No newline at end of file
diff --git a/src/content/reference/react-dom/components/select.md b/src/content/reference/react-dom/components/select.md
index 0dbdc15375..a55ec458cc 100644
--- a/src/content/reference/react-dom/components/select.md
+++ b/src/content/reference/react-dom/components/select.md
@@ -4,12 +4,12 @@ title: ""
-The [built-in browser `` component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select) lets you render a select box with options.
+[Встроенный в браузер компонент ``](https://developer.mozilla.org/ru/docs/Web/HTML/Element/select) отвечает за рендер поля выбора с пунктами списка.
```js
- Some option
- Other option
+ Пункт списка
+ Другой пункт списка
```
@@ -19,68 +19,68 @@ The [built-in browser `` component](https://developer.mozilla.org/en-US/
---
-## Reference {/*reference*/}
+## Справочник {/*reference*/}
### `` {/*select*/}
-To display a select box, render the [built-in browser ``](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select) component.
+Чтобы отобразить поле выбора, отрендерите [встроенный в браузер компонент ``.](https://developer.mozilla.org/ru/docs/Web/HTML/Element/select)
```js
- Some option
- Other option
+ Пункт списка
+ Другой пункт списка
```
-[See more examples below.](#usage)
+[См. больше примеров ниже.](#usage)
-#### Props {/*props*/}
+#### Пропсы {/*props*/}
-`` supports all [common element props.](/reference/react-dom/components/common#props)
+`` поддерживает все [общие пропсы HTML-элементов.](/reference/react-dom/components/common#props)
-You can [make a select box controlled](#controlling-a-select-box-with-a-state-variable) by passing a `value` prop:
+Можно сделать [поле выбора управляемым](#controlling-a-select-box-with-a-state-variable), передав проп `value`:
-* `value`: A string (or an array of strings for [`multiple={true}`](#enabling-multiple-selection)). Controls which option is selected. Every value string match the `value` of some `` nested inside the ``.
+* `value`: строка (или массив строк для [`multiple={true}`](#enabling-multiple-selection)). Управляет выбранным вариантом. Значение каждой строки `value` соответствует некоторому ``, вложенному в ``.
-When you pass `value`, you must also pass an `onChange` handler that updates the passed value.
+При передаче `value`, также необходимо передать обработчик `onChange`, который будет отвечать за обновление переданного значения.
-If your `` is uncontrolled, you may pass the `defaultValue` prop instead:
+Если не передать `value`, то `` считается неуправляемым, и нужно использовать проп `defaultValue`:
-* `defaultValue`: A string (or an array of strings for [`multiple={true}`](#enabling-multiple-selection)). Specifies [the initially selected option.](#providing-an-initially-selected-option)
+* `defaultValue`: строка (или массив строк для [`multiple={true}`](#enabling-multiple-selection)). Указывает [значение по умолчанию.](#providing-an-initially-selected-option)
-These `` props are relevant both for uncontrolled and controlled select boxes:
+Эти пропсы `` актуальны для неуправляемых и управляемых полей выбора:
-* [`autoComplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#autocomplete): A string. Specifies one of the possible [autocomplete behaviors.](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#values)
-* [`autoFocus`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#autofocus): A boolean. If `true`, React will focus the element on mount.
-* `children`: `` accepts [``](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option), [` `](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/optgroup), and [``](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist) components as children. You can also pass your own components as long as they eventually render one of the allowed components. If you pass your own components that eventually render `` tags, each ` ` you render must have a `value`.
-* [`disabled`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#disabled): A boolean. If `true`, the select box will not be interactive and will appear dimmed.
-* [`form`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select#form): A string. Specifies the `id` of the `