From f6695225388c1e58cccce7576af082803d44a872 Mon Sep 17 00:00:00 2001 From: ntishkevich Date: Mon, 18 Feb 2019 09:14:04 +0300 Subject: [PATCH 01/20] Translate "Strict Mode" into Russian --- content/docs/nav.yml | 2 +- content/docs/strict-mode.md | 44 ++++++++++++++++++------------------- 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/content/docs/nav.yml b/content/docs/nav.yml index 1f5f547d6..ab851e84b 100644 --- a/content/docs/nav.yml +++ b/content/docs/nav.yml @@ -72,7 +72,7 @@ - id: static-type-checking title: Static Type Checking - id: strict-mode - title: Strict Mode + title: Строгий режим - id: typechecking-with-proptypes title: Проверка типов с помощью PropTypes - id: uncontrolled-components diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index e803a32d4..d743e2493 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -1,30 +1,30 @@ --- id: strict-mode -title: Strict Mode +title: Строгий режим permalink: docs/strict-mode.html --- -`StrictMode` is a tool for highlighting potential problems in an application. Like `Fragment`, `StrictMode` does not render any visible UI. It activates additional checks and warnings for its descendants. +`StrictMode` – инструмент, позволяющий обнаружить потенциальные проблемы в приложении. Как и `Fragment`, `StrictMode` не рендерит никакого видимого UI. Он активирует дополнительные проверки и предупреждения длясвоих потомков. -> Note: +> Примечание: > -> Strict mode checks are run in development mode only; _they do not impact the production build_. +> Проверки строгого режима работают только в режиме разработки; _они не оказывают влияния на продакшен сборку_. -You can enable strict mode for any part of your application. For example: +Строгий режим может бтыь включён для любой части приложения. Например: `embed:strict-mode/enabling-strict-mode.js` -In the above example, strict mode checks will *not* be run against the `Header` and `Footer` components. However, `ComponentOne` and `ComponentTwo`, as well as all of their descendants, will have the checks. +В примере выше, проверки строгого режима *не* будут выполняться для компонентов `Header` и `Footer`. Однако, эти проверки будут выполнены для `ComponentOne` и `ComponentTwo`, а также для всех их потомков. -`StrictMode` currently helps with: -* [Identifying components with unsafe lifecycles](#identifying-unsafe-lifecycles) -* [Warning about legacy string ref API usage](#warning-about-legacy-string-ref-api-usage) -* [Warning about deprecated findDOMNode usage](#warning-about-deprecated-finddomnode-usage) -* [Detecting unexpected side effects](#detecting-unexpected-side-effects) -* [Detecting legacy context API](#detecting-legacy-context-api) +На данный момент `StrictMode` помогает с: +* [Обнаружение компонентов с небезопасными методами жизненного цикла](#identifying-unsafe-lifecycles) +* [Предепреждением об использовании устаревшего строкового API для реф](#warning-about-legacy-string-ref-api-usage) +* [Предупреждения об использовании устравшего метода findDOMNode](#warning-about-deprecated-finddomnode-usage) +* [Обраружением неожиданных побочных эффектов](#detecting-unexpected-side-effects) +* [Обнаружением устаревшего API контекста](#detecting-legacy-context-api) -Additional functionality will be added with future releases of React. +Дополнительные проверки будут добавлены в будущих релизах React. -### Identifying unsafe lifecycles {#identifying-unsafe-lifecycles} +### Обнаружение компонентов с небезопасными методами жизненного цикла {#identifying-unsafe-lifecycles} As explained [in this blog post](/blog/2018/03/27/update-on-async-rendering.html), certain legacy lifecycle methods are unsafe for use in async React applications. However, if your application uses third party libraries, it can be difficult to ensure that these lifecycles aren't being used. Fortunately, strict mode can help with this! @@ -34,7 +34,7 @@ When strict mode is enabled, React compiles a list of all class components using Addressing the issues identified by strict mode _now_ will make it easier for you to take advantage of async rendering in future releases of React. -### Warning about legacy string ref API usage {#warning-about-legacy-string-ref-api-usage} +### Предепреждением об использовании устаревшего строкового API для реф {#warning-about-legacy-string-ref-api-usage} Previously, React provided two ways for managing refs: the legacy string ref API and the callback API. Although the string ref API was the more convenient of the two, it had [several downsides](https://github.com/facebook/react/issues/1373) and so our official recommendation was to [use the callback form instead](/docs/refs-and-the-dom.html#legacy-api-string-refs). @@ -43,7 +43,7 @@ React 16.3 added a third option that offers the convenience of a string ref with Since object refs were largely added as a replacement for string refs, strict mode now warns about usage of string refs. -> **Note:** +> **Примечание:** > > Callback refs will continue to be supported in addition to the new `createRef` API. > @@ -51,7 +51,7 @@ Since object refs were largely added as a replacement for string refs, strict mo [Learn more about the new `createRef` API here.](/docs/refs-and-the-dom.html) -### Warning about deprecated findDOMNode usage {#warning-about-deprecated-finddomnode-usage} +### Предупреждения об использовании устравшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} React used to support `findDOMNode` to search the tree for a DOM node given a class instance. Normally you don't need this because you can [attach a ref directly to a DOM node](/docs/refs-and-the-dom.html#creating-refs). @@ -73,11 +73,11 @@ class MyComponent extends React.Component { } ``` -> Note: +> Примечание: > > In CSS, the [`display: contents`](https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents) attribute can be used if you don't want the node to be part of the layout. -### Detecting unexpected side effects {#detecting-unexpected-side-effects} +### Обраружением неожиданных побочных эффектов {#detecting-unexpected-side-effects} Conceptually, React does work in two phases: * The **render** phase determines what changes need to be made to e.g. the DOM. During this phase, React calls `render` and then compares the result to the previous render. @@ -104,7 +104,7 @@ Strict mode can't automatically detect side effects for you, but it can help you * `setState` updater functions (the first argument) * The static `getDerivedStateFromProps` lifecycle -> Note: +> Примечание: > > This only applies to development mode. _Lifecycles will not be double-invoked in production mode._ @@ -115,10 +115,10 @@ At first glance, this code might not seem problematic. But if `SharedApplication By intentionally double-invoking methods like the component constructor, strict mode makes patterns like this easier to spot. -### Detecting legacy context API {#detecting-legacy-context-api} +### Обнаружением устаревшего API контекста {#detecting-legacy-context-api} The legacy context API is error-prone, and will be removed in a future major version. It still works for all 16.x releases but will show this warning message in strict mode: ![](../images/blog/warn-legacy-context-in-strict-mode.png) -Read the [new context API documentation](/docs/context.html) to help migrate to the new version. +Ознакомьтесь с [документацией нового API контекста](/docs/context.html) для миграции на новую версию. From fbce67edbb20ed1fd2bff7132ffad973e50670d3 Mon Sep 17 00:00:00 2001 From: Nick Tishkevich Date: Mon, 18 Feb 2019 19:08:45 +0300 Subject: [PATCH 02/20] Translate "Strict Mode" into Russian --- content/docs/strict-mode.md | 58 ++++++++++++++++++------------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index d743e2493..9bb3ca9e2 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -4,21 +4,21 @@ title: Строгий режим permalink: docs/strict-mode.html --- -`StrictMode` – инструмент, позволяющий обнаружить потенциальные проблемы в приложении. Как и `Fragment`, `StrictMode` не рендерит никакого видимого UI. Он активирует дополнительные проверки и предупреждения длясвоих потомков. +`StrictMode` – инструмент для обнаружения потенциальных проблем в приложении. Как и `Fragment`, `StrictMode` не рендерит никакого видимого UI. Этот режим активирует дополнительные проверки и предупреждения для своих потомков. > Примечание: > -> Проверки строгого режима работают только в режиме разработки; _они не оказывают влияния на продакшен сборку_. +> Проверки строгого режима работают только в режиме разработки; _они не оказывают никакого эффекта в продакшен сборке_. -Строгий режим может бтыь включён для любой части приложения. Например: +Строгий режим может быть включён для любой части приложения. Например: `embed:strict-mode/enabling-strict-mode.js` -В примере выше, проверки строгого режима *не* будут выполняться для компонентов `Header` и `Footer`. Однако, эти проверки будут выполнены для `ComponentOne` и `ComponentTwo`, а также для всех их потомков. +В примере выше проверки строгого режима *не* будут выполняться для компонентов `Header` и `Footer`. Однако эти проверки будут выполнены для `ComponentOne` и `ComponentTwo`, а также для всех их потомков. На данный момент `StrictMode` помогает с: -* [Обнаружение компонентов с небезопасными методами жизненного цикла](#identifying-unsafe-lifecycles) +* [Обнаружением компонентов с небезопасными методами жизненного цикла](#identifying-unsafe-lifecycles) * [Предепреждением об использовании устаревшего строкового API для реф](#warning-about-legacy-string-ref-api-usage) -* [Предупреждения об использовании устравшего метода findDOMNode](#warning-about-deprecated-finddomnode-usage) +* [Предупреждением об использовании устаревшего метода findDOMNode](#warning-about-deprecated-finddomnode-usage) * [Обраружением неожиданных побочных эффектов](#detecting-unexpected-side-effects) * [Обнаружением устаревшего API контекста](#detecting-legacy-context-api) @@ -34,7 +34,7 @@ When strict mode is enabled, React compiles a list of all class components using Addressing the issues identified by strict mode _now_ will make it easier for you to take advantage of async rendering in future releases of React. -### Предепреждением об использовании устаревшего строкового API для реф {#warning-about-legacy-string-ref-api-usage} +### Предепреждение об использовании устаревшего строкового API для реф {#warning-about-legacy-string-ref-api-usage} Previously, React provided two ways for managing refs: the legacy string ref API and the callback API. Although the string ref API was the more convenient of the two, it had [several downsides](https://github.com/facebook/react/issues/1373) and so our official recommendation was to [use the callback form instead](/docs/refs-and-the-dom.html#legacy-api-string-refs). @@ -49,9 +49,9 @@ Since object refs were largely added as a replacement for string refs, strict mo > > You don't need to replace callback refs in your components. They are slightly more flexible, so they will remain as an advanced feature. -[Learn more about the new `createRef` API here.](/docs/refs-and-the-dom.html) +[Ознакомьтесь с новым API `createRef` здесь.](/docs/refs-and-the-dom.html) -### Предупреждения об использовании устравшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} +### Предупреждение об использовании устаревшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} React used to support `findDOMNode` to search the tree for a DOM node given a class instance. Normally you don't need this because you can [attach a ref directly to a DOM node](/docs/refs-and-the-dom.html#creating-refs). @@ -75,17 +75,17 @@ class MyComponent extends React.Component { > Примечание: > -> In CSS, the [`display: contents`](https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents) attribute can be used if you don't want the node to be part of the layout. +> В CSS атрибту [`display: contents`](https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents) может использоваться, чтобы узел не был частью раскладки. -### Обраружением неожиданных побочных эффектов {#detecting-unexpected-side-effects} +### Обраружение неожиданных побочных эффектов {#detecting-unexpected-side-effects} -Conceptually, React does work in two phases: -* The **render** phase determines what changes need to be made to e.g. the DOM. During this phase, React calls `render` and then compares the result to the previous render. -* The **commit** phase is when React applies any changes. (In the case of React DOM, this is when React inserts, updates, and removes DOM nodes.) React also calls lifecycles like `componentDidMount` and `componentDidUpdate` during this phase. +Концептуально, React работает в две фазы: +* **Фаза рендера (render phase)** определяет какие изменения необходимо произвести в, например, DOM. В течении данной фазы, React вызывает `render`, затем сравнивает полученный результат с результатом предыдущего рендера. +* **Фаза фиксации (commit phase)** – в ней React применяет любые изменения. (В случае React DOM – это фаза, когда React вставляет, обновляет и удаляет DOM-узлы.) В течении этой фазы React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. -The commit phase is usually very fast, but rendering can be slow. For this reason, the upcoming async mode (which is not enabled by default yet) breaks the rendering work into pieces, pausing and resuming the work to avoid blocking the browser. This means that React may invoke render phase lifecycles more than once before committing, or it may invoke them without committing at all (because of an error or a higher priority interruption). +Фаза фиксации обычно проходит быстро, однако фаза рендера может быть медленной. По этой причине, готовящийся асинхронный режим (который ещё не включён по умолчанию) делит работу рендера на части, останавливает и возобновляет работу для избежания блокировки браузера. Это означает, что React может выполнить фазу рендера lifecycles более, чем один раз перед фиксацией или может вызвать без фиксации совсем (по причине возникновения ошибки или более приоритетного прерывания). -Render phase lifecycles include the following class component methods: +Фаза рендера включает в себя следующие методы жизненного цикла: * `constructor` * `componentWillMount` * `componentWillReceiveProps` @@ -93,31 +93,31 @@ Render phase lifecycles include the following class component methods: * `getDerivedStateFromProps` * `shouldComponentUpdate` * `render` -* `setState` updater functions (the first argument) +* `setState` функция обновления (первый аргумент) -Because the above methods might be called more than once, it's important that they do not contain side-effects. Ignoring this rule can lead to a variety of problems, including memory leaks and invalid application state. Unfortunately, it can be difficult to detect these problems as they can often be [non-deterministic](https://en.wikipedia.org/wiki/Deterministic_algorithm). +Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не содержали каких-либо побочных эффектов. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и некорректное состояние приложения. К сожалению, бывает довольно трудно обнаружить эти проблемы, поскльку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). -Strict mode can't automatically detect side effects for you, but it can help you spot them by making them a little more deterministic. This is done by intentionally double-invoking the following methods: +Строгий режим не может автоматически обнаружить побочные эффекты за нас, но помогает обнаружить их, сделав их немного более детерминированными. Это достигается путим преднамеренного двойного вызовва следующих методов: -* Class component `constructor` method -* The `render` method -* `setState` updater functions (the first argument) -* The static `getDerivedStateFromProps` lifecycle +* метод `constructor` классового компонента +* метод `render` +* `setState` функция обновления (первый аргумент) +* статически метод `getDerivedStateFromProps` > Примечание: > -> This only applies to development mode. _Lifecycles will not be double-invoked in production mode._ +> Это применимо только в режиме разработки. _Методы жизненного цикла не вызываются дважды в продакшен режиме._ -For example, consider the following code: +К примеру, рассмотрим следующий код: `embed:strict-mode/side-effects-in-constructor.js` -At first glance, this code might not seem problematic. But if `SharedApplicationState.recordEvent` is not [idempotent](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning), then instantiating this component multiple times could lead to invalid application state. This sort of subtle bug might not manifest during development, or it might do so inconsistently and so be overlooked. +На первый взгляд данный пример может не показаться проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning), тогда при создании этого компонента несколько раз может привести к недопустимому состоянию приложения. Такой вид ошибок может не проявляться во время разработки, или она может быть непоследовательное и поэтому может быть проигнорирована. -By intentionally double-invoking methods like the component constructor, strict mode makes patterns like this easier to spot. +Решение преднамеренно производить двойной вызов таких методов, как конструктор компонента, строгий режим облегчает поиск такого вида ошибок. -### Обнаружением устаревшего API контекста {#detecting-legacy-context-api} +### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} -The legacy context API is error-prone, and will be removed in a future major version. It still works for all 16.x releases but will show this warning message in strict mode: +Устаревший (API) контекст подвержен ошибкам и будет удалён в будущей мажорной версии. Он ещё доступен во всех релизах 16.x, но в строгом режиме будет выведено следующее предупреждение: ![](../images/blog/warn-legacy-context-in-strict-mode.png) From 0cba465acc04f18f5634b7bfd5a6a213827dccbf Mon Sep 17 00:00:00 2001 From: ntishkevich Date: Mon, 18 Feb 2019 23:45:17 +0300 Subject: [PATCH 03/20] Translate "Strict Mode" into Russian. Need to perform a review. --- content/docs/strict-mode.md | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 9bb3ca9e2..dbe3181e9 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -26,40 +26,39 @@ permalink: docs/strict-mode.html ### Обнаружение компонентов с небезопасными методами жизненного цикла {#identifying-unsafe-lifecycles} -As explained [in this blog post](/blog/2018/03/27/update-on-async-rendering.html), certain legacy lifecycle methods are unsafe for use in async React applications. However, if your application uses third party libraries, it can be difficult to ensure that these lifecycles aren't being used. Fortunately, strict mode can help with this! +Как объясняется [в этой статье блога](/blog/2018/03/27/update-on-async-rendering.html), некоторые методы жизненного цикла не безопасны для использования в асинхронных React приложениях. Однако, если ваше приложение использует сторонние библиотеки, может оказаться тяжело обепечить, чтобы эти методы не использовались. К счастью, строкий режим может помочь разобраться с этим! -When strict mode is enabled, React compiles a list of all class components using the unsafe lifecycles, and logs a warning message with information about these components, like so: +Когда строгий режим включен, React компилирует список всех классовых компонентов, которые используют небезопасные методы жизненного цикла и отображает предупрежедние с информацией об этих компонентах, например так: ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png) -Addressing the issues identified by strict mode _now_ will make it easier for you to take advantage of async rendering in future releases of React. +Проблемы, найденные строгим режимом сейчас, облегчат использование преимуществ асинхронного рендеринга в будущих релизах React. ### Предепреждение об использовании устаревшего строкового API для реф {#warning-about-legacy-string-ref-api-usage} -Previously, React provided two ways for managing refs: the legacy string ref API and the callback API. Although the string ref API was the more convenient of the two, it had [several downsides](https://github.com/facebook/react/issues/1373) and so our official recommendation was to [use the callback form instead](/docs/refs-and-the-dom.html#legacy-api-string-refs). +Ранее, React предоставлял два способа управления рефами: устаревший строковый API и колбэк API. Хотя строковый API реф был более удобным, он имел [несколько недостатков](https://github.com/facebook/react/issues/1373) и наша рекомендация заключалась в том, чтобы [использовать колбэк](/docs/refs-and-the-dom.html#legacy-api-string-refs). -React 16.3 added a third option that offers the convenience of a string ref without any of the downsides: +React 16.3 добавил третий вариант, удобный как строковый реф без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` -Since object refs were largely added as a replacement for string refs, strict mode now warns about usage of string refs. +С тех пор как объекты рефы были по большей части добавлены как заменя строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. > **Примечание:** > -> Callback refs will continue to be supported in addition to the new `createRef` API. +> Колбэк рефы также поддерживаются в дополнеии к новому `createRef` API. > -> You don't need to replace callback refs in your components. They are slightly more flexible, so they will remain as an advanced feature. - -[Ознакомьтесь с новым API `createRef` здесь.](/docs/refs-and-the-dom.html) +> Вам не нужно заменять обратные вызовы в ваших компонентах. Они немного более гибкие, поэтому останутся как продвинутая фича. +[Ознакомьтесь с новым `createRef` API здесь.](/docs/refs-and-the-dom.html) ### Предупреждение об использовании устаревшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} -React used to support `findDOMNode` to search the tree for a DOM node given a class instance. Normally you don't need this because you can [attach a ref directly to a DOM node](/docs/refs-and-the-dom.html#creating-refs). +Ранее React использовал `findDOMNode` для поиска в дереве DOM-узла по переданному экземпляру класса. Зачастую вам это не нужно, так как вы можете [привязать рефу непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` can also be used on class components but this was breaking abstraction levels by allowing a parent to demand that certain children was rendered. It creates a refactoring hazard where you can't change the implementation details of a component because a parent might be reaching into its DOM node. `findDOMNode` only returns the first child, but with the use of Fragments, it is possible for a component to render multiple DOM nodes. `findDOMNode` is a one time read API. It only gave you an answer when you asked for it. If a child component renders a different node, there is no way to handle this change. Therefore `findDOMNode` only worked if components always return a single DOM node that never changes. +`findDOMNode` также может использоваться на классовых компонентах, однако это нарушает абстракцию, позволяя родительскому компоненту требовать рендера определенных дочерних элементов. Это создает опасность при рефакторинге, когда вы не можете изменить реализацию компонента, потому что родитель может попать в его DOM-узел. `findDOMNode` только возвращает первый дочерний элемент, но с использованием фрагментов, компонент может рендерить несколько DOM-узлов. `findDOMNode` предназначен для чтения (is a one time read API). Он возвращает результат,когда вы вызваете метод. Если дочерний компонент рендерит другой узел, способа отследить эти изменения нет. Поэтому `findDOMNode` работает только, если компоненты всегда возвращают один DOM-узел, который никогда не изменяется. -You can instead make this explicit by passing a ref to your custom component and pass that along to the DOM using [ref forwarding](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). +Вместо использования этого метода, можно явно передать реф в ваш компонент и передавать по DOM используя [передачу реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). -You can also add a wrapper DOM node in your component and attach a ref directly to it. +Вы можете добавить обёртку для DOM-узла в свой компонент и прикрепить ссылку непосредственно к обёртке. ```javascript{4,7} class MyComponent extends React.Component { @@ -75,11 +74,11 @@ class MyComponent extends React.Component { > Примечание: > -> В CSS атрибту [`display: contents`](https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents) может использоваться, чтобы узел не был частью раскладки. +> В CSS атрибут [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может использоваться, чтобы узел не был частью раскладки. ### Обраружение неожиданных побочных эффектов {#detecting-unexpected-side-effects} -Концептуально, React работает в две фазы: +React работает в две фазы: * **Фаза рендера (render phase)** определяет какие изменения необходимо произвести в, например, DOM. В течении данной фазы, React вызывает `render`, затем сравнивает полученный результат с результатом предыдущего рендера. * **Фаза фиксации (commit phase)** – в ней React применяет любые изменения. (В случае React DOM – это фаза, когда React вставляет, обновляет и удаляет DOM-узлы.) В течении этой фазы React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. @@ -111,7 +110,7 @@ class MyComponent extends React.Component { К примеру, рассмотрим следующий код: `embed:strict-mode/side-effects-in-constructor.js` -На первый взгляд данный пример может не показаться проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning), тогда при создании этого компонента несколько раз может привести к недопустимому состоянию приложения. Такой вид ошибок может не проявляться во время разработки, или она может быть непоследовательное и поэтому может быть проигнорирована. +На первый взгляд данный пример может не показаться проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда при создании этого компонента несколько раз может привести к недопустимому состоянию приложения. Такой вид ошибок может не проявляться во время разработки, или она может быть непоследовательное и поэтому может быть проигнорирована. Решение преднамеренно производить двойной вызов таких методов, как конструктор компонента, строгий режим облегчает поиск такого вида ошибок. From 14af2a0922996adab0a70cc3d6e21af05073e486 Mon Sep 17 00:00:00 2001 From: Nick Tishkevich Date: Tue, 19 Feb 2019 18:30:04 +0300 Subject: [PATCH 04/20] Translate "Strict Mode" into Russian --- content/docs/strict-mode.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index dbe3181e9..3c95b2ac1 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -13,7 +13,7 @@ permalink: docs/strict-mode.html Строгий режим может быть включён для любой части приложения. Например: `embed:strict-mode/enabling-strict-mode.js` -В примере выше проверки строгого режима *не* будут выполняться для компонентов `Header` и `Footer`. Однако эти проверки будут выполнены для `ComponentOne` и `ComponentTwo`, а также для всех их потомков. +В примере выше проверки строгого режима *не* будут выполняться для компонентов `Header` и `Footer`. Однако будут выполнены для `ComponentOne` и `ComponentTwo`, а также для всех их потомков. На данный момент `StrictMode` помогает с: * [Обнаружением компонентов с небезопасными методами жизненного цикла](#identifying-unsafe-lifecycles) @@ -22,26 +22,26 @@ permalink: docs/strict-mode.html * [Обраружением неожиданных побочных эффектов](#detecting-unexpected-side-effects) * [Обнаружением устаревшего API контекста](#detecting-legacy-context-api) -Дополнительные проверки будут добавлены в будущих релизах React. +Дополнительные проверки будут включены в будущие релизы React. ### Обнаружение компонентов с небезопасными методами жизненного цикла {#identifying-unsafe-lifecycles} -Как объясняется [в этой статье блога](/blog/2018/03/27/update-on-async-rendering.html), некоторые методы жизненного цикла не безопасны для использования в асинхронных React приложениях. Однако, если ваше приложение использует сторонние библиотеки, может оказаться тяжело обепечить, чтобы эти методы не использовались. К счастью, строкий режим может помочь разобраться с этим! +[Статья в блоге](/blog/2018/03/27/update-on-async-rendering.html) рассказывает о причинах, почему некоторые методы жизненного цикла не безопасно использовать в асинхронных React приложениях. Если приложение использует сторонние библиотеки, то отследить использование этих методов будет тяжело. К счастью, строгий режим помогает обнаружить их! -Когда строгий режим включен, React компилирует список всех классовых компонентов, которые используют небезопасные методы жизненного цикла и отображает предупрежедние с информацией об этих компонентах, например так: +Когда включён строгий режим, React сообщает о всех классовых компонентах, которые используют небезопасные методы жизненного цикла и отображает информацию они следующим образом: ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png) -Проблемы, найденные строгим режимом сейчас, облегчат использование преимуществ асинхронного рендеринга в будущих релизах React. +Проблемы, найденные на данный момент строгим режимом сейчас, облегчат использование преимуществ асинхронного рендеринга в будущих релизах React. ### Предепреждение об использовании устаревшего строкового API для реф {#warning-about-legacy-string-ref-api-usage} -Ранее, React предоставлял два способа управления рефами: устаревший строковый API и колбэк API. Хотя строковый API реф был более удобным, он имел [несколько недостатков](https://github.com/facebook/react/issues/1373) и наша рекомендация заключалась в том, чтобы [использовать колбэк](/docs/refs-and-the-dom.html#legacy-api-string-refs). +Ранее React предоставлял два способа управления рефами: устаревший строковый API и колбэк API. Хотя строковый API реф был более удобным, он имел [несколько недостатков](https://github.com/facebook/react/issues/1373) и наша рекомендация заключалась в том, чтобы [использовать колбэк](/docs/refs-and-the-dom.html#legacy-api-string-refs). -React 16.3 добавил третий вариант, удобный как строковый реф без каких-либо недостатков: +React 16.3 добавил третий вариант, удобный как строковый реф и без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` -С тех пор как объекты рефы были по большей части добавлены как заменя строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. +С тех пор как объекты-рефы были добавлены как замена строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. > **Примечание:** > @@ -52,9 +52,9 @@ React 16.3 добавил третий вариант, удобный как с ### Предупреждение об использовании устаревшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} -Ранее React использовал `findDOMNode` для поиска в дереве DOM-узла по переданному экземпляру класса. Зачастую вам это не нужно, так как вы можете [привязать рефу непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). +Ранее React использовал `findDOMNode` для поиска в дереве DOM-узла по переданному экземпляру класса. Зачастую это не требуется, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` также может использоваться на классовых компонентах, однако это нарушает абстракцию, позволяя родительскому компоненту требовать рендера определенных дочерних элементов. Это создает опасность при рефакторинге, когда вы не можете изменить реализацию компонента, потому что родитель может попать в его DOM-узел. `findDOMNode` только возвращает первый дочерний элемент, но с использованием фрагментов, компонент может рендерить несколько DOM-узлов. `findDOMNode` предназначен для чтения (is a one time read API). Он возвращает результат,когда вы вызваете метод. Если дочерний компонент рендерит другой узел, способа отследить эти изменения нет. Поэтому `findDOMNode` работает только, если компоненты всегда возвращают один DOM-узел, который никогда не изменяется. +`findDOMNode` также может использоваться на классовых компонентах, однако это нарушает абстракцию, позволяя родительскому компоненту требовать рендера определённых дочерних элементов. Это создаёт опасность при рефакторинге, когда вы не можете изменить реализацию компонента, потому что родитель может попасть в его DOM-узел. `findDOMNode` только возвращает первый дочерний элемент, но с использованием фрагментов, компонент может рендерить несколько DOM-узлов. `findDOMNode` предназначен для чтения (is a one time read API). Он возвращает результат, когда вы вызваете метод. Если дочерний компонент рендерит другой узел, способа отследить эти изменения нет. Поэтому `findDOMNode` работает только, если компоненты всегда возвращают один DOM-узел, который никогда не изменяется. Вместо использования этого метода, можно явно передать реф в ваш компонент и передавать по DOM используя [передачу реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). From 9bc85d9ea3748bd15140817b7e01e8079fc62bb2 Mon Sep 17 00:00:00 2001 From: ntishkevich Date: Wed, 20 Feb 2019 09:42:26 +0300 Subject: [PATCH 05/20] Translate "Strict Mode" into Russian. Reword some sections, still need to reword some parts --- content/docs/strict-mode.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 3c95b2ac1..849e613a7 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -4,7 +4,7 @@ title: Строгий режим permalink: docs/strict-mode.html --- -`StrictMode` – инструмент для обнаружения потенциальных проблем в приложении. Как и `Fragment`, `StrictMode` не рендерит никакого видимого UI. Этот режим активирует дополнительные проверки и предупреждения для своих потомков. +`StrictMode` – инструмент для обнаружения потенциальных проблем в приложении. Как и `Fragment`, `StrictMode` не рендерит видимого UI. Этот режим активирует дополнительные проверки и предупреждения для своих потомков. > Примечание: > @@ -26,19 +26,19 @@ permalink: docs/strict-mode.html ### Обнаружение компонентов с небезопасными методами жизненного цикла {#identifying-unsafe-lifecycles} -[Статья в блоге](/blog/2018/03/27/update-on-async-rendering.html) рассказывает о причинах, почему некоторые методы жизненного цикла не безопасно использовать в асинхронных React приложениях. Если приложение использует сторонние библиотеки, то отследить использование этих методов будет тяжело. К счастью, строгий режим помогает обнаружить их! +[В статье блога](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла не безопасно использовать в асинхронных React приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование этих методов довольно тяжело. К счастью, строгий режим помогает обнаружить их! -Когда включён строгий режим, React сообщает о всех классовых компонентах, которые используют небезопасные методы жизненного цикла и отображает информацию они следующим образом: +Когда включён строгий режим, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким обрзаом: ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png) -Проблемы, найденные на данный момент строгим режимом сейчас, облегчат использование преимуществ асинхронного рендеринга в будущих релизах React. +Решение проблем, выявленных в строгом режиме, позволит использовать все преимущества асинхронного рендеринга в будущих релизах React. ### Предепреждение об использовании устаревшего строкового API для реф {#warning-about-legacy-string-ref-api-usage} -Ранее React предоставлял два способа управления рефами: устаревший строковый API и колбэк API. Хотя строковый API реф был более удобным, он имел [несколько недостатков](https://github.com/facebook/react/issues/1373) и наша рекомендация заключалась в том, чтобы [использовать колбэк](/docs/refs-and-the-dom.html#legacy-api-string-refs). +Ранее React предоставлял два способа управления рефами: устаревший строковый API и колбэк API. Хотя строковые рефы были более удобным, он имел [несколько недостатков](https://github.com/facebook/react/issues/1373) и наша рекомендация заключалась в том, чтобы [использовать колбэк](/docs/refs-and-the-dom.html#legacy-api-string-refs). -React 16.3 добавил третий вариант, удобный как строковый реф и без каких-либо недостатков: +React 16.3 добавил третий вариант, удобный как строковые рефы и без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` С тех пор как объекты-рефы были добавлены как замена строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. @@ -52,13 +52,13 @@ React 16.3 добавил третий вариант, удобный как с ### Предупреждение об использовании устаревшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} -Ранее React использовал `findDOMNode` для поиска в дереве DOM-узла по переданному экземпляру класса. Зачастую это не требуется, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). +Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по экземпляру класса. Обычно этот метод не используют, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` также может использоваться на классовых компонентах, однако это нарушает абстракцию, позволяя родительскому компоненту требовать рендера определённых дочерних элементов. Это создаёт опасность при рефакторинге, когда вы не можете изменить реализацию компонента, потому что родитель может попасть в его DOM-узел. `findDOMNode` только возвращает первый дочерний элемент, но с использованием фрагментов, компонент может рендерить несколько DOM-узлов. `findDOMNode` предназначен для чтения (is a one time read API). Он возвращает результат, когда вы вызваете метод. Если дочерний компонент рендерит другой узел, способа отследить эти изменения нет. Поэтому `findDOMNode` работает только, если компоненты всегда возвращают один DOM-узел, который никогда не изменяется. +`findDOMNode` можно было использовать с классовыми компонентами, однако это нарушало уровни абстракции, позволяя родительскому компоненту требовать рендера определённых дочерних элементов. Это создаёт опасность при рефакторинге, когда вы не можете изменить реализацию компонента, потому что родитель может попасть в его DOM-узел. `findDOMNode` возвращает только первый дочерний элемент, но компонент может рендерить несколько DOM-узлов используя Фрагменты. `findDOMNode` – . Он возвращает результат, когда вы вызваете метод. Если дочерний компонент рендерит другой узел, то эти изменения не получится отследить. Следовательно, `findDOMNode` работает только тогда, когда компоненты всегда возвращают единственный DOM-узел, который никогда не изменяется. -Вместо использования этого метода, можно явно передать реф в ваш компонент и передавать по DOM используя [передачу реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). +Вместо этого, можно передать реф в компонент и далее передать его в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). -Вы можете добавить обёртку для DOM-узла в свой компонент и прикрепить ссылку непосредственно к обёртке. +Также можно использовать DOM-узел как обёртку в компоненте и прикрепить реф непосредственно к ней. ```javascript{4,7} class MyComponent extends React.Component { @@ -74,7 +74,7 @@ class MyComponent extends React.Component { > Примечание: > -> В CSS атрибут [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может использоваться, чтобы узел не был частью раскладки. +> CSS атрибут [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может применяться для исключения узла из раскладки. ### Обраружение неожиданных побочных эффектов {#detecting-unexpected-side-effects} @@ -116,8 +116,8 @@ React работает в две фазы: ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} -Устаревший (API) контекст подвержен ошибкам и будет удалён в будущей мажорной версии. Он ещё доступен во всех релизах 16.x, но в строгом режиме будет выведено следующее предупреждение: +Устаревший API контекста подвержен ошибкам и будет удалён в будущей мажорной версии. Он ещё доступен во всех релизах 16.x, но в строгом режиме будет выведено следующее предупреждение: ![](../images/blog/warn-legacy-context-in-strict-mode.png) -Ознакомьтесь с [документацией нового API контекста](/docs/context.html) для миграции на новую версию. +Ознакомьтесь с [документацией нового API контекста](/docs/context.html) для перехода на новую версию. From 2329e96048e9a7f49459ac46137845522e2046d6 Mon Sep 17 00:00:00 2001 From: Nick Tishkevich Date: Wed, 20 Feb 2019 20:17:08 +0300 Subject: [PATCH 06/20] Translate "Strict Mode" into Russian. Reword some sections. --- content/docs/strict-mode.md | 40 ++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 849e613a7..7c44a7123 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -16,47 +16,47 @@ permalink: docs/strict-mode.html В примере выше проверки строгого режима *не* будут выполняться для компонентов `Header` и `Footer`. Однако будут выполнены для `ComponentOne` и `ComponentTwo`, а также для всех их потомков. На данный момент `StrictMode` помогает с: -* [Обнаружением компонентов с небезопасными методами жизненного цикла](#identifying-unsafe-lifecycles) -* [Предепреждением об использовании устаревшего строкового API для реф](#warning-about-legacy-string-ref-api-usage) +* [Обнаружением небезопасных методов жизненного цикла](#identifying-unsafe-lifecycles) +* [Предепреждением об использовании устаревшего API строковых реф](#warning-about-legacy-string-ref-api-usage) * [Предупреждением об использовании устаревшего метода findDOMNode](#warning-about-deprecated-finddomnode-usage) * [Обраружением неожиданных побочных эффектов](#detecting-unexpected-side-effects) * [Обнаружением устаревшего API контекста](#detecting-legacy-context-api) Дополнительные проверки будут включены в будущие релизы React. -### Обнаружение компонентов с небезопасными методами жизненного цикла {#identifying-unsafe-lifecycles} +### Обнаружение небезопасных методов жизненного цикла {#identifying-unsafe-lifecycles} [В статье блога](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла не безопасно использовать в асинхронных React приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование этих методов довольно тяжело. К счастью, строгий режим помогает обнаружить их! -Когда включён строгий режим, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким обрзаом: +Когда включён строгий режим, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким образом: ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png) -Решение проблем, выявленных в строгом режиме, позволит использовать все преимущества асинхронного рендеринга в будущих релизах React. +Если избавиться от проблем, выявленных в строгом режиме, сейчас, это позволит получить все преимущества асинхронного рендеринга в будущих релизах React. -### Предепреждение об использовании устаревшего строкового API для реф {#warning-about-legacy-string-ref-api-usage} +### Предепреждение об использовании устаревшего API строковых реф {#warning-about-legacy-string-ref-api-usage} -Ранее React предоставлял два способа управления рефами: устаревший строковый API и колбэк API. Хотя строковые рефы были более удобным, он имел [несколько недостатков](https://github.com/facebook/react/issues/1373) и наша рекомендация заключалась в том, чтобы [использовать колбэк](/docs/refs-and-the-dom.html#legacy-api-string-refs). +Ранее React предоставлял два способа управления рефами: устаревшие строковые рефы и колбэк API. Хоть строковые рефы и были более удобным способом, они имели [различные недостатки](https://github.com/facebook/react/issues/1373). Поэтому мы рекомендовали [использовать колбэки](/docs/refs-and-the-dom.html#legacy-api-string-refs) вместо них. React 16.3 добавил третий вариант, удобный как строковые рефы и без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` -С тех пор как объекты-рефы были добавлены как замена строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. +Поскольку объекты-рефы были добавлены как замена строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. > **Примечание:** > -> Колбэк рефы также поддерживаются в дополнеии к новому `createRef` API. +> Колбэк-рефы продолжают поддерживатся вместе с новым `createRef` API. > -> Вам не нужно заменять обратные вызовы в ваших компонентах. Они немного более гибкие, поэтому останутся как продвинутая фича. +> Вам не обязательно заменять колбэк-рефы в ваших компонентах. Их запись более гибкая, поэтому они считаются продвинутой возможностью. [Ознакомьтесь с новым `createRef` API здесь.](/docs/refs-and-the-dom.html) ### Предупреждение об использовании устаревшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} -Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по экземпляру класса. Обычно этот метод не используют, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). +Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по экземпляру класса. В большинстве случаев этот метод не используется, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` можно было использовать с классовыми компонентами, однако это нарушало уровни абстракции, позволяя родительскому компоненту требовать рендера определённых дочерних элементов. Это создаёт опасность при рефакторинге, когда вы не можете изменить реализацию компонента, потому что родитель может попасть в его DOM-узел. `findDOMNode` возвращает только первый дочерний элемент, но компонент может рендерить несколько DOM-узлов используя Фрагменты. `findDOMNode` – . Он возвращает результат, когда вы вызваете метод. Если дочерний компонент рендерит другой узел, то эти изменения не получится отследить. Следовательно, `findDOMNode` работает только тогда, когда компоненты всегда возвращают единственный DOM-узел, который никогда не изменяется. +`findDOMNode` может использоваться для классовых компонентов, однако это нарушало уровни абстракции, позволяя родительскому компоненту узнавать о рендере определенного дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить реализацию компонента, потому что родительский элемент может взаимодействовать с этим DOM-узлом. `findDOMNode` возвращает только первый дочерний элемент, но используя фрагменты компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняется только один раз. Затем метод только возвращает результат после вызова. Если дочерний компонент рендерит другой узел, то эти изменения не удастся отследить. Следовательно, `findDOMNode` сработает только тогда, когда компоненты всегда возвращают единственный DOM-узел, который никогда не изменяется. -Вместо этого, можно передать реф в компонент и далее передать его в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). +Вместо этого, можно передать реф в компонент и перенаправить его в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). Также можно использовать DOM-узел как обёртку в компоненте и прикрепить реф непосредственно к ней. @@ -82,7 +82,7 @@ React работает в две фазы: * **Фаза рендера (render phase)** определяет какие изменения необходимо произвести в, например, DOM. В течении данной фазы, React вызывает `render`, затем сравнивает полученный результат с результатом предыдущего рендера. * **Фаза фиксации (commit phase)** – в ней React применяет любые изменения. (В случае React DOM – это фаза, когда React вставляет, обновляет и удаляет DOM-узлы.) В течении этой фазы React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. -Фаза фиксации обычно проходит быстро, однако фаза рендера может быть медленной. По этой причине, готовящийся асинхронный режим (который ещё не включён по умолчанию) делит работу рендера на части, останавливает и возобновляет работу для избежания блокировки браузера. Это означает, что React может выполнить фазу рендера lifecycles более, чем один раз перед фиксацией или может вызвать без фиксации совсем (по причине возникновения ошибки или более приоритетного прерывания). +Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который ещё не включён по умолчанию) делит работу рендера на части, останавливает и возобновляет её для избежания блокировки браузера. Это означает, что React может выполнить методы жизненного цикла из фазы рендера более, чем один раз перед фиксацией или может вызвать без фиксации совсем (по причине возникновения ошибки или более приоритетного прерывания). Фаза рендера включает в себя следующие методы жизненного цикла: * `constructor` @@ -92,27 +92,27 @@ React работает в две фазы: * `getDerivedStateFromProps` * `shouldComponentUpdate` * `render` -* `setState` функция обновления (первый аргумент) +* `setState` функции обновления (первый аргумент) Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не содержали каких-либо побочных эффектов. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и некорректное состояние приложения. К сожалению, бывает довольно трудно обнаружить эти проблемы, поскльку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). -Строгий режим не может автоматически обнаружить побочные эффекты за нас, но помогает обнаружить их, сделав их немного более детерминированными. Это достигается путим преднамеренного двойного вызовва следующих методов: +Строгий режим не может автоматически обнаружить побочные эффекты за нас, но помогает отслеживать их, сделав более детерминированными. Достигается путём преднамеренного двойного вызова следующих методов: * метод `constructor` классового компонента * метод `render` -* `setState` функция обновления (первый аргумент) +* `setState` функции обновления (первый аргумент) * статически метод `getDerivedStateFromProps` > Примечание: > > Это применимо только в режиме разработки. _Методы жизненного цикла не вызываются дважды в продакшен режиме._ -К примеру, рассмотрим следующий код: +Рассмотрим следующий пример: `embed:strict-mode/side-effects-in-constructor.js` -На первый взгляд данный пример может не показаться проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда при создании этого компонента несколько раз может привести к недопустимому состоянию приложения. Такой вид ошибок может не проявляться во время разработки, или она может быть непоследовательное и поэтому может быть проигнорирована. +На первый взгляд данный пример может не показаться проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз приведёт к недопустимому состоянию приложения. Такой вид ошибок может не проявляться во время разработки, или она может происходить непоследовательно и поэтому может быть проигнорирована. -Решение преднамеренно производить двойной вызов таких методов, как конструктор компонента, строгий режим облегчает поиск такого вида ошибок. +Решение преднамеренно производить двойной вызов таких методов, как конструктор компонента, в строгом режиме облегчает поиск ошибок такого вида. ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} From e0ad4e152b2e817d3a1d881bd8ebf2510b99aa1d Mon Sep 17 00:00:00 2001 From: ntishkevich Date: Wed, 20 Feb 2019 23:52:37 +0300 Subject: [PATCH 07/20] Translate "Strict Mode" into Russian. Final review was done. --- content/docs/strict-mode.md | 51 +++++++++++++++++++------------------ 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 7c44a7123..3430d2fab 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -4,7 +4,7 @@ title: Строгий режим permalink: docs/strict-mode.html --- -`StrictMode` – инструмент для обнаружения потенциальных проблем в приложении. Как и `Fragment`, `StrictMode` не рендерит видимого UI. Этот режим активирует дополнительные проверки и предупреждения для своих потомков. +`StrictMode` – инструмент для обнаружения потенциальных проблем в приложении. Также как и `Fragment`, `StrictMode` не рендерит видимого UI. Строгий режим активирует дополнительные проверки и предупреждения для своих потомков. > Примечание: > @@ -15,30 +15,30 @@ permalink: docs/strict-mode.html В примере выше проверки строгого режима *не* будут выполняться для компонентов `Header` и `Footer`. Однако будут выполнены для `ComponentOne` и `ComponentTwo`, а также для всех их потомков. -На данный момент `StrictMode` помогает с: -* [Обнаружением небезопасных методов жизненного цикла](#identifying-unsafe-lifecycles) -* [Предепреждением об использовании устаревшего API строковых реф](#warning-about-legacy-string-ref-api-usage) -* [Предупреждением об использовании устаревшего метода findDOMNode](#warning-about-deprecated-finddomnode-usage) -* [Обраружением неожиданных побочных эффектов](#detecting-unexpected-side-effects) -* [Обнаружением устаревшего API контекста](#detecting-legacy-context-api) +На данный момент `StrictMode` помогает в: +* [Обнаружении небезопасных методов жизненного цикла](#identifying-unsafe-lifecycles) +* [Предупреждении об использовании устаревшего API строковых реф](#warning-about-legacy-string-ref-api-usage) +* [Предупреждении об использовании устаревшего метода findDOMNode](#warning-about-deprecated-finddomnode-usage) +* [Обраружении неожиданных побочных эффектов](#detecting-unexpected-side-effects) +* [Обнаружении устаревшего API контекста](#detecting-legacy-context-api) -Дополнительные проверки будут включены в будущие релизы React. +Дополнительные проверки будут включены в будущих релизах React. ### Обнаружение небезопасных методов жизненного цикла {#identifying-unsafe-lifecycles} -[В статье блога](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла не безопасно использовать в асинхронных React приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование этих методов довольно тяжело. К счастью, строгий режим помогает обнаружить их! +[В данной статье блога](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла небезопасно использовать в асинхронных React приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование таких методов довольно тяжело. К счастью, строгий режим помогает сделать это! Когда включён строгий режим, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким образом: ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png) -Если избавиться от проблем, выявленных в строгом режиме, сейчас, это позволит получить все преимущества асинхронного рендеринга в будущих релизах React. +Если избавиться от проблем, выявленных в строгом режиме, _уже сегодня_, то это позволит получить все преимущества асинхронного рендеринга в будущих релизах React. -### Предепреждение об использовании устаревшего API строковых реф {#warning-about-legacy-string-ref-api-usage} +### Предупреждение об использовании устаревшего API строковых реф {#warning-about-legacy-string-ref-api-usage} -Ранее React предоставлял два способа управления рефами: устаревшие строковые рефы и колбэк API. Хоть строковые рефы и были более удобным способом, они имели [различные недостатки](https://github.com/facebook/react/issues/1373). Поэтому мы рекомендовали [использовать колбэки](/docs/refs-and-the-dom.html#legacy-api-string-refs) вместо них. +Ранее React предоставлял два способа управления рефами: устаревшие строковые рефы и колбэк API. Хотя строковые рефы и были более удобным способом, они имели [различные недостатки](https://github.com/facebook/react/issues/1373). Поэтому мы рекомендовали [использовать колбэки вместо них](/docs/refs-and-the-dom.html#legacy-api-string-refs). -React 16.3 добавил третий вариант, удобный как строковые рефы и без каких-либо недостатков: +React 16.3 добавил третий способ, удобный как строковые рефы и без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` Поскольку объекты-рефы были добавлены как замена строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. @@ -47,18 +47,19 @@ React 16.3 добавил третий вариант, удобный как с > > Колбэк-рефы продолжают поддерживатся вместе с новым `createRef` API. > -> Вам не обязательно заменять колбэк-рефы в ваших компонентах. Их запись более гибкая, поэтому они считаются продвинутой возможностью. +> Вам не обязательно заменять колбэк-рефы в ваших компонентах. Их использование более гибкое, поэтому они считаются продвинутой возможностью. + [Ознакомьтесь с новым `createRef` API здесь.](/docs/refs-and-the-dom.html) ### Предупреждение об использовании устаревшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} -Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по экземпляру класса. В большинстве случаев этот метод не используется, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). +Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по указанному экземпляру класса. В большинстве случаев этим методом не пользуются, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` может использоваться для классовых компонентов, однако это нарушало уровни абстракции, позволяя родительскому компоненту узнавать о рендере определенного дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить реализацию компонента, потому что родительский элемент может взаимодействовать с этим DOM-узлом. `findDOMNode` возвращает только первый дочерний элемент, но используя фрагменты компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняется только один раз. Затем метод только возвращает результат после вызова. Если дочерний компонент рендерит другой узел, то эти изменения не удастся отследить. Следовательно, `findDOMNode` сработает только тогда, когда компоненты всегда возвращают единственный DOM-узел, который никогда не изменяется. +`findDOMNode` может использоваться для классовых компонентов, однако это нарушало уровни абстракции, позволяя родительскому компоненту узнавать о рендере определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить реализацию компонента, так как родительский элемент завязан на DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат на каждый вызов. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работал только когда компоненты возвращали единственный и неизменяемый DOM-узел. Вместо этого, можно передать реф в компонент и перенаправить его в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). -Также можно использовать DOM-узел как обёртку в компоненте и прикрепить реф непосредственно к ней. +Также можно добавить компоненту DOM-узел как обёртку и прикрепить реф непосредственно к этой обёртке. ```javascript{4,7} class MyComponent extends React.Component { @@ -74,15 +75,15 @@ class MyComponent extends React.Component { > Примечание: > -> CSS атрибут [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может применяться для исключения узла из раскладки. +> CSS атрибут [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может применяться для исключения узла из раскладки (layout). ### Обраружение неожиданных побочных эффектов {#detecting-unexpected-side-effects} React работает в две фазы: -* **Фаза рендера (render phase)** определяет какие изменения необходимо произвести в, например, DOM. В течении данной фазы, React вызывает `render`, затем сравнивает полученный результат с результатом предыдущего рендера. +* **Фаза рендера (render phase)** определяет какие изменения необходимо произвести, например, в DOM. В течение этой фазы React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера. * **Фаза фиксации (commit phase)** – в ней React применяет любые изменения. (В случае React DOM – это фаза, когда React вставляет, обновляет и удаляет DOM-узлы.) В течении этой фазы React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. -Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который ещё не включён по умолчанию) делит работу рендера на части, останавливает и возобновляет её для избежания блокировки браузера. Это означает, что React может выполнить методы жизненного цикла из фазы рендера более, чем один раз перед фиксацией или может вызвать без фиксации совсем (по причине возникновения ошибки или более приоритетного прерывания). +Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу рендера на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в фазе рендера React может вызвать методы жизненного цикла более чем один раз перед фиксацией либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). Фаза рендера включает в себя следующие методы жизненного цикла: * `constructor` @@ -94,9 +95,9 @@ React работает в две фазы: * `render` * `setState` функции обновления (первый аргумент) -Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не содержали каких-либо побочных эффектов. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и некорректное состояние приложения. К сожалению, бывает довольно трудно обнаружить эти проблемы, поскльку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). +Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не приводили к каких-либо побочным эффектам. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и недопустимое состояние приложения. К сожалению, бывает очень трудно обнаружить эти проблемы, поскольку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). -Строгий режим не может автоматически обнаружить побочные эффекты за нас, но помогает отслеживать их, сделав более детерминированными. Достигается путём преднамеренного двойного вызова следующих методов: +Строгий режим не способен автоматически обнаруживать побочные эффекты, но помогает их отследить, сделав более детерминированными. Такое поведение достигается путём двойного вызова следующих методов: * метод `constructor` классового компонента * метод `render` @@ -110,13 +111,13 @@ React работает в две фазы: Рассмотрим следующий пример: `embed:strict-mode/side-effects-in-constructor.js` -На первый взгляд данный пример может не показаться проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз приведёт к недопустимому состоянию приложения. Такой вид ошибок может не проявляться во время разработки, или она может происходить непоследовательно и поэтому может быть проигнорирована. +На первый взгляд данный пример не кажется проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз приведёт к недопустимому состоянию приложения. Такие туднонаходимые ошибки могут никак не проявить себя во время разработки, или быть настолько редкими, что останутся незамеченными. -Решение преднамеренно производить двойной вызов таких методов, как конструктор компонента, в строгом режиме облегчает поиск ошибок такого вида. +Намеренно вызывая такие методы как конструктор компонента, и позволяет строгому режиму легко обнаружить такие проблемы. ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} -Устаревший API контекста подвержен ошибкам и будет удалён в будущей мажорной версии. Он ещё доступен во всех релизах 16.x, но в строгом режиме будет выведено следующее предупреждение: +Использование устаревшего API контекста приводило к постоянным ошибкам и поэтому он будет удалён в будущей мажорной версии. Он ещё доступен во всех релизах 16.x, но в строгом режиме будет выведено следующее предупреждение: ![](../images/blog/warn-legacy-context-in-strict-mode.png) From 44759eaf71d82cae6c7fd6cc13e50a861f07f654 Mon Sep 17 00:00:00 2001 From: Nick Tishkevich Date: Thu, 21 Feb 2019 18:30:38 +0300 Subject: [PATCH 08/20] Translate "Strict Mode" into Russian. Fix some typos. --- content/docs/strict-mode.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 3430d2fab..841bf34fb 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -45,7 +45,7 @@ React 16.3 добавил третий способ, удобный как ст > **Примечание:** > -> Колбэк-рефы продолжают поддерживатся вместе с новым `createRef` API. +> Колбэк-рефы продолжают поддерживаться вместе с новым `createRef` API. > > Вам не обязательно заменять колбэк-рефы в ваших компонентах. Их использование более гибкое, поэтому они считаются продвинутой возможностью. @@ -55,7 +55,7 @@ React 16.3 добавил третий способ, удобный как ст Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по указанному экземпляру класса. В большинстве случаев этим методом не пользуются, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` может использоваться для классовых компонентов, однако это нарушало уровни абстракции, позволяя родительскому компоненту узнавать о рендере определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить реализацию компонента, так как родительский элемент завязан на DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат на каждый вызов. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работал только когда компоненты возвращали единственный и неизменяемый DOM-узел. +`findDOMNode` может использоваться для классовых компонентов, однако это нарушало уровни абстракции, позволяя родительскому компоненту узнавать о рендере определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить реализацию компонента, так как родительский компонент завязан на DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат на каждый вызов. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работал только когда компоненты возвращали единственный и неизменяемый DOM-узел. Вместо этого, можно передать реф в компонент и перенаправить его в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). @@ -83,7 +83,7 @@ React работает в две фазы: * **Фаза рендера (render phase)** определяет какие изменения необходимо произвести, например, в DOM. В течение этой фазы React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера. * **Фаза фиксации (commit phase)** – в ней React применяет любые изменения. (В случае React DOM – это фаза, когда React вставляет, обновляет и удаляет DOM-узлы.) В течении этой фазы React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. -Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу рендера на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в фазе рендера React может вызвать методы жизненного цикла более чем один раз перед фиксацией либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). +Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу в фазе рендера на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в фазе рендера React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). Фаза рендера включает в себя следующие методы жизненного цикла: * `constructor` @@ -95,7 +95,7 @@ React работает в две фазы: * `render` * `setState` функции обновления (первый аргумент) -Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не приводили к каких-либо побочным эффектам. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и недопустимое состояние приложения. К сожалению, бывает очень трудно обнаружить эти проблемы, поскольку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). +Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не приводили к каким-либо побочным эффектам. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и недопустимое состояние приложения. К сожалению, бывает очень трудно обнаружить эти проблемы, поскольку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). Строгий режим не способен автоматически обнаруживать побочные эффекты, но помогает их отследить, сделав более детерминированными. Такое поведение достигается путём двойного вызова следующих методов: @@ -111,9 +111,9 @@ React работает в две фазы: Рассмотрим следующий пример: `embed:strict-mode/side-effects-in-constructor.js` -На первый взгляд данный пример не кажется проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз приведёт к недопустимому состоянию приложения. Такие туднонаходимые ошибки могут никак не проявить себя во время разработки, или быть настолько редкими, что останутся незамеченными. +На первый взгляд данный пример не кажется проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз приведёт к недопустимому состоянию приложения. Такие труднонаходимые ошибки могут никак не проявить себя во время разработки, или быть настолько редкими, что останутся незамеченными. -Намеренно вызывая такие методы как конструктор компонента, и позволяет строгому режиму легко обнаружить такие проблемы. +Намеренно вызывая такие методы как конструктор компонента, и позволяет строгому режиму легко обнаружить такие проблемы. ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} From 0b45a42655ae35e6186766c30aae5cd71205f9c8 Mon Sep 17 00:00:00 2001 From: ntishkevich Date: Thu, 21 Feb 2019 23:32:34 +0300 Subject: [PATCH 09/20] Translate "Strict Mode" into Russian. --- content/docs/strict-mode.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 841bf34fb..2da4d6b9e 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -45,7 +45,7 @@ React 16.3 добавил третий способ, удобный как ст > **Примечание:** > -> Колбэк-рефы продолжают поддерживаться вместе с новым `createRef` API. +> Колбэк-рефы по-прежнему поддерживаются вместе с новым `createRef` API. > > Вам не обязательно заменять колбэк-рефы в ваших компонентах. Их использование более гибкое, поэтому они считаются продвинутой возможностью. @@ -53,11 +53,11 @@ React 16.3 добавил третий способ, удобный как ст ### Предупреждение об использовании устаревшего метода findDOMNode {#warning-about-deprecated-finddomnode-usage} -Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по указанному экземпляру класса. В большинстве случаев этим методом не пользуются, так как можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). +Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по указанному экземпляру класса. В большинстве случаев этот метод не используется, поскольку можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` может использоваться для классовых компонентов, однако это нарушало уровни абстракции, позволяя родительскому компоненту узнавать о рендере определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить реализацию компонента, так как родительский компонент завязан на DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат на каждый вызов. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работал только когда компоненты возвращали единственный и неизменяемый DOM-узел. +`findDOMNode` может использоваться для классовых компонентов, однако это нарушает уровни абстракции, позволяя родительскому компоненту требовать, чтобы происходил рендер определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить детали реализации компонента, так как родитель может использовать DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат при вызове. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работает только когда компоненты возвращалют единственный и неизменяемый DOM-узел. -Вместо этого, можно передать реф в компонент и перенаправить его в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). +Вместо этого, можно передать реф в компонент и передать его далее в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). Также можно добавить компоненту DOM-узел как обёртку и прикрепить реф непосредственно к этой обёртке. @@ -83,7 +83,7 @@ React работает в две фазы: * **Фаза рендера (render phase)** определяет какие изменения необходимо произвести, например, в DOM. В течение этой фазы React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера. * **Фаза фиксации (commit phase)** – в ней React применяет любые изменения. (В случае React DOM – это фаза, когда React вставляет, обновляет и удаляет DOM-узлы.) В течении этой фазы React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. -Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу в фазе рендера на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в фазе рендера React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). +Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в фазе рендера React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). Фаза рендера включает в себя следующие методы жизненного цикла: * `constructor` @@ -106,14 +106,14 @@ React работает в две фазы: > Примечание: > -> Это применимо только в режиме разработки. _Методы жизненного цикла не вызываются дважды в продакшен режиме._ +> Это применимо только в режиме разработки. _Методы жизненного цикла не вызываются дважды в продакшен-режиме._ Рассмотрим следующий пример: `embed:strict-mode/side-effects-in-constructor.js` -На первый взгляд данный пример не кажется проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз приведёт к недопустимому состоянию приложения. Такие труднонаходимые ошибки могут никак не проявить себя во время разработки, или быть настолько редкими, что останутся незамеченными. +На первый взгляд данный пример не кажется проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз может привести к недопустимому состоянию приложения. Такие труднонаходимые ошибки могут никак не проявить себя во время разработки или быть настолько редкими, что останутся незамеченными. -Намеренно вызывая такие методы как конструктор компонента, и позволяет строгому режиму легко обнаружить такие проблемы. +Дважды вызывая такие методы как конструктор компонента позволяет строгому режиму легко обнаружить такие проблемы. ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} @@ -121,4 +121,4 @@ React работает в две фазы: ![](../images/blog/warn-legacy-context-in-strict-mode.png) -Ознакомьтесь с [документацией нового API контекста](/docs/context.html) для перехода на новую версию. +Ознакомьтесь с [документацией нового API контекста](/docs/context.html), чтобы упростить переход на новую версию. From 9921588bdf39fb8b0fa7b5d2a7eda645bd069fce Mon Sep 17 00:00:00 2001 From: ntishkevich Date: Fri, 22 Feb 2019 08:58:08 +0300 Subject: [PATCH 10/20] Fix some spots after review --- content/docs/strict-mode.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 2da4d6b9e..f12b5300d 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -8,7 +8,7 @@ permalink: docs/strict-mode.html > Примечание: > -> Проверки строгого режима работают только в режиме разработки; _они не оказывают никакого эффекта в продакшен сборке_. +> Проверки строгого режима работают только в режиме разработки; _они не оказывают никакого эффекта в продакшен-сборке_. Строгий режим может быть включён для любой части приложения. Например: `embed:strict-mode/enabling-strict-mode.js` @@ -26,7 +26,7 @@ permalink: docs/strict-mode.html ### Обнаружение небезопасных методов жизненного цикла {#identifying-unsafe-lifecycles} -[В данной статье блога](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла небезопасно использовать в асинхронных React приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование таких методов довольно тяжело. К счастью, строгий режим помогает сделать это! +[В данной статье блога](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла небезопасно использовать в асинхронных React-приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование таких методов довольно тяжело. К счастью, строгий режим помогает сделать это! Когда включён строгий режим, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким образом: @@ -55,7 +55,7 @@ React 16.3 добавил третий способ, удобный как ст Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по указанному экземпляру класса. В большинстве случаев этот метод не используется, поскольку можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` может использоваться для классовых компонентов, однако это нарушает уровни абстракции, позволяя родительскому компоненту требовать, чтобы происходил рендер определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить детали реализации компонента, так как родитель может использовать DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат при вызове. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работает только когда компоненты возвращалют единственный и неизменяемый DOM-узел. +`findDOMNode` может использоваться для классовых компонентов, однако это нарушает уровни абстракции, позволяя родительскому компоненту требовать, чтобы происходил рендер определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить детали реализации компонента, так как родитель может использовать DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат при вызове. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работает, только когда компоненты возвращалют единственный и неизменяемый DOM-узел. Вместо этого, можно передать реф в компонент и передать его далее в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). @@ -75,17 +75,17 @@ class MyComponent extends React.Component { > Примечание: > -> CSS атрибут [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может применяться для исключения узла из раскладки (layout). +> CSS-выражение [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может применяться для исключения узла из раскладки (layout). ### Обраружение неожиданных побочных эффектов {#detecting-unexpected-side-effects} -React работает в две фазы: -* **Фаза рендера (render phase)** определяет какие изменения необходимо произвести, например, в DOM. В течение этой фазы React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера. -* **Фаза фиксации (commit phase)** – в ней React применяет любые изменения. (В случае React DOM – это фаза, когда React вставляет, обновляет и удаляет DOM-узлы.) В течении этой фазы React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. +React работает в два этапа: +* **Этап рендеринга (render phase)** определяет, какие изменения необходимо произвести, например, в DOM. В течение этого этапа React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера. +* **Этап фиксации (commit phase)** – в нём React применяет любые изменения. (В случае React DOM – это этап, когда React вставляет, обновляет и удаляет DOM-узлы.) В течение этого этапа React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. -Фаза фиксации обычно не занимает много времени, что нельзя сказать про фазу рендера. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в фазе рендера React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). +Этап фиксации обычно не занимает много времени, что нельзя сказать про этап рендеринга. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в этапе рендеринга React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). -Фаза рендера включает в себя следующие методы жизненного цикла: +Этап рендеринга включает в себя следующие методы жизненного цикла: * `constructor` * `componentWillMount` * `componentWillReceiveProps` @@ -93,16 +93,16 @@ React работает в две фазы: * `getDerivedStateFromProps` * `shouldComponentUpdate` * `render` -* `setState` функции обновления (первый аргумент) +* Функции обновления `setState` (первый аргумент) Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не приводили к каким-либо побочным эффектам. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и недопустимое состояние приложения. К сожалению, бывает очень трудно обнаружить эти проблемы, поскольку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). Строгий режим не способен автоматически обнаруживать побочные эффекты, но помогает их отследить, сделав более детерминированными. Такое поведение достигается путём двойного вызова следующих методов: -* метод `constructor` классового компонента -* метод `render` -* `setState` функции обновления (первый аргумент) -* статически метод `getDerivedStateFromProps` +* Метод `constructor` классового компонента +* Метод `render` +* Функции обновления`setState` (первый аргумент) +* Статически метод `getDerivedStateFromProps` > Примечание: > @@ -113,7 +113,7 @@ React работает в две фазы: На первый взгляд данный пример не кажется проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз может привести к недопустимому состоянию приложения. Такие труднонаходимые ошибки могут никак не проявить себя во время разработки или быть настолько редкими, что останутся незамеченными. -Дважды вызывая такие методы как конструктор компонента позволяет строгому режиму легко обнаружить такие проблемы. +Дважды вызывая такие методы, как конструктор компонента, позволяет строгому режиму легко обнаружить такие проблемы. ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} From ddf096116902b4dbc3a6ced4fc9ed832457fb4ba Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Fri, 22 Feb 2019 11:55:43 +0300 Subject: [PATCH 11/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index f12b5300d..a1308cdab 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -113,7 +113,7 @@ React работает в два этапа: На первый взгляд данный пример не кажется проблемным. Но если метод `SharedApplicationState.recordEvent` не является [идемпотентным](https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BC%D0%BF%D0%BE%D1%82%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C#%D0%92_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B5), тогда создание этого компонента несколько раз может привести к недопустимому состоянию приложения. Такие труднонаходимые ошибки могут никак не проявить себя во время разработки или быть настолько редкими, что останутся незамеченными. -Дважды вызывая такие методы, как конструктор компонента, позволяет строгому режиму легко обнаружить такие проблемы. +Двойной вызов таких методов, как конструктор компонента, позволяет строгому режиму легко обнаружить подобные проблемы. ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} From cbb3b8cedf0da2300022554ae0287dab49f16818 Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Fri, 22 Feb 2019 11:55:52 +0300 Subject: [PATCH 12/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index a1308cdab..ed5638c67 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -55,7 +55,7 @@ React 16.3 добавил третий способ, удобный как ст Ранее React использовал `findDOMNode` для поиска DOM-узла в дереве по указанному экземпляру класса. В большинстве случаев этот метод не используется, поскольку можно [привязать реф непосредственно к DOM-узлу](/docs/refs-and-the-dom.html#creating-refs). -`findDOMNode` может использоваться для классовых компонентов, однако это нарушает уровни абстракции, позволяя родительскому компоненту требовать, чтобы происходил рендер определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить детали реализации компонента, так как родитель может использовать DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат при вызове. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работает, только когда компоненты возвращалют единственный и неизменяемый DOM-узел. +`findDOMNode` может использоваться для классовых компонентов, однако это нарушает уровни абстракции, позволяя родительскому компоненту требовать, чтобы происходил рендер определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить детали реализации компонента, так как родитель может использовать DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат при вызове. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работает, только когда компоненты возвращают единственный и неизменяемый DOM-узел. Вместо этого, можно передать реф в компонент и передать его далее в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). From 5f34b78010a5e035f4776ae6578e9c80ef7f33e7 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Fri, 1 Mar 2019 09:36:32 +0300 Subject: [PATCH 13/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index ed5638c67..7a3f1e922 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -19,7 +19,7 @@ permalink: docs/strict-mode.html * [Обнаружении небезопасных методов жизненного цикла](#identifying-unsafe-lifecycles) * [Предупреждении об использовании устаревшего API строковых реф](#warning-about-legacy-string-ref-api-usage) * [Предупреждении об использовании устаревшего метода findDOMNode](#warning-about-deprecated-finddomnode-usage) -* [Обраружении неожиданных побочных эффектов](#detecting-unexpected-side-effects) +* [Обнаружении неожиданных побочных эффектов](#detecting-unexpected-side-effects) * [Обнаружении устаревшего API контекста](#detecting-legacy-context-api) Дополнительные проверки будут включены в будущих релизах React. From 457c2a10c7709efaccb4caeff4fe5a82851f4c19 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Fri, 1 Mar 2019 09:36:55 +0300 Subject: [PATCH 14/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 7a3f1e922..f199b2d4f 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -83,7 +83,7 @@ React работает в два этапа: * **Этап рендеринга (render phase)** определяет, какие изменения необходимо произвести, например, в DOM. В течение этого этапа React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера. * **Этап фиксации (commit phase)** – в нём React применяет любые изменения. (В случае React DOM – это этап, когда React вставляет, обновляет и удаляет DOM-узлы.) В течение этого этапа React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. -Этап фиксации обычно не занимает много времени, что нельзя сказать про этап рендеринга. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу на части, периодически останавливает и возобновляет работу во избежании блокировки браузера. Это означает, что в этапе рендеринга React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (по причине возникновения ошибки или прерывания с большим приоритетом). +Этап фиксации обычно не занимает много времени, что нельзя сказать про этап рендеринга. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу на части, периодически останавливает и возобновляет работу, чтобы избежать блокировки браузера. Это означает, что на этапе рендеринга React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (из-за возникновения ошибки или прерывания с большим приоритетом). Этап рендеринга включает в себя следующие методы жизненного цикла: * `constructor` From 119aaa2f6fd0adb944c411b41c866eb6f28b2f86 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Fri, 1 Mar 2019 09:37:09 +0300 Subject: [PATCH 15/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index f199b2d4f..a1f71a6d4 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -41,7 +41,7 @@ permalink: docs/strict-mode.html React 16.3 добавил третий способ, удобный как строковые рефы и без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` -Поскольку объекты-рефы были добавлены как замена строковых реф, строгий режим теперь предупреждает об использовании стоковых реф. +Поскольку объекты-рефы стали заменой строковых реф, строгий режим теперь предупреждает об использовании строковых реф. > **Примечание:** > From 91ca6527d230fcee877bc38d7b9aeb42fd4a54a3 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Fri, 1 Mar 2019 09:37:23 +0300 Subject: [PATCH 16/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index a1f71a6d4..f6f0ded67 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -36,7 +36,7 @@ permalink: docs/strict-mode.html ### Предупреждение об использовании устаревшего API строковых реф {#warning-about-legacy-string-ref-api-usage} -Ранее React предоставлял два способа управления рефами: устаревшие строковые рефы и колбэк API. Хотя строковые рефы и были более удобным способом, они имели [различные недостатки](https://github.com/facebook/react/issues/1373). Поэтому мы рекомендовали [использовать колбэки вместо них](/docs/refs-and-the-dom.html#legacy-api-string-refs). +Ранее React предоставлял два способа управления рефами: устаревшие строковые рефы и колбэк API. Хотя строковые рефы и были более удобным способом, они имели [несколько недостатков](https://github.com/facebook/react/issues/1373). Поэтому мы рекомендовали [использовать колбэки вместо них](/docs/refs-and-the-dom.html#legacy-api-string-refs). React 16.3 добавил третий способ, удобный как строковые рефы и без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` From 012d88d0216ef8176f1acb323b2e2dd0dbe37fe7 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Fri, 1 Mar 2019 09:37:40 +0300 Subject: [PATCH 17/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index f6f0ded67..b279732a8 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -26,7 +26,7 @@ permalink: docs/strict-mode.html ### Обнаружение небезопасных методов жизненного цикла {#identifying-unsafe-lifecycles} -[В данной статье блога](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла небезопасно использовать в асинхронных React-приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование таких методов довольно тяжело. К счастью, строгий режим помогает сделать это! +[В этой статье](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла небезопасно использовать в асинхронных React-приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование таких методов довольно тяжело. К счастью, строгий режим помогает сделать это! Когда включён строгий режим, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким образом: From b96c62e5ba94532998507e246e30d9d55d8dab82 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Fri, 1 Mar 2019 12:22:03 +0300 Subject: [PATCH 18/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index b279732a8..7d582f503 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -95,7 +95,7 @@ React работает в два этапа: * `render` * Функции обновления `setState` (первый аргумент) -Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не приводили к каким-либо побочным эффектам. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и недопустимое состояние приложения. К сожалению, бывает очень трудно обнаружить эти проблемы, поскольку они часто могу быть [недетерминированными](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). +Поскольку вышеупомянутые методы могут быть вызваны более одного раза, важно, чтобы они не приводили к каким-либо побочным эффектам. Игнорирование этого правила может привести к множеству проблем, включая утечки памяти и недопустимое состояние приложения. К сожалению, такие проблемы тяжело обнаружить из-за их [недетерминированности](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC). Строгий режим не способен автоматически обнаруживать побочные эффекты, но помогает их отследить, сделав более детерминированными. Такое поведение достигается путём двойного вызова следующих методов: From 7981aeb1cec7deb26510d0e3338dbcf72ff746d0 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Fri, 1 Mar 2019 12:22:19 +0300 Subject: [PATCH 19/20] Update content/docs/strict-mode.md Co-Authored-By: ntishkevich --- content/docs/strict-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 7d582f503..461b54ae3 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -38,7 +38,7 @@ permalink: docs/strict-mode.html Ранее React предоставлял два способа управления рефами: устаревшие строковые рефы и колбэк API. Хотя строковые рефы и были более удобным способом, они имели [несколько недостатков](https://github.com/facebook/react/issues/1373). Поэтому мы рекомендовали [использовать колбэки вместо них](/docs/refs-and-the-dom.html#legacy-api-string-refs). -React 16.3 добавил третий способ, удобный как строковые рефы и без каких-либо недостатков: +В React 16.3 добавлен ​​третий способ, который предлагает удобство строковых рефов без каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` Поскольку объекты-рефы стали заменой строковых реф, строгий режим теперь предупреждает об использовании строковых реф. From 5073323b2f9762a2cd062d248be233ebdee69dd4 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Fri, 1 Mar 2019 14:51:04 -0800 Subject: [PATCH 20/20] Update strict-mode.md --- content/docs/strict-mode.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/docs/strict-mode.md b/content/docs/strict-mode.md index 461b54ae3..fa283cbca 100644 --- a/content/docs/strict-mode.md +++ b/content/docs/strict-mode.md @@ -26,9 +26,9 @@ permalink: docs/strict-mode.html ### Обнаружение небезопасных методов жизненного цикла {#identifying-unsafe-lifecycles} -[В этой статье](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла небезопасно использовать в асинхронных React-приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование таких методов довольно тяжело. К счастью, строгий режим помогает сделать это! +[В этой статье](/blog/2018/03/27/update-on-async-rendering.html) рассматриваются причины, почему некоторые методы жизненного цикла небезопасно использовать в асинхронных React-приложениях. Если в приложении подключены сторонние библиотеки, то отследить использование таких методов довольно тяжело. К счастью, тут может помочь строгий режим! -Когда включён строгий режим, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким образом: +Когда строгий режим включён, React составляет список всех классовых компонентов, которые используют небезопасные методы жизненного цикла, и отображает информацию о них таким образом: ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png) @@ -38,7 +38,7 @@ permalink: docs/strict-mode.html Ранее React предоставлял два способа управления рефами: устаревшие строковые рефы и колбэк API. Хотя строковые рефы и были более удобным способом, они имели [несколько недостатков](https://github.com/facebook/react/issues/1373). Поэтому мы рекомендовали [использовать колбэки вместо них](/docs/refs-and-the-dom.html#legacy-api-string-refs). -В React 16.3 добавлен ​​третий способ, который предлагает удобство строковых рефов без каких-либо недостатков: +В React 16.3 добавлен ​​третий способ, который предлагает удобство строковых рефов и лишён каких-либо недостатков: `embed:16-3-release-blog-post/create-ref-example.js` Поскольку объекты-рефы стали заменой строковых реф, строгий режим теперь предупреждает об использовании строковых реф. @@ -57,7 +57,7 @@ permalink: docs/strict-mode.html `findDOMNode` может использоваться для классовых компонентов, однако это нарушает уровни абстракции, позволяя родительскому компоненту требовать, чтобы происходил рендер определённого дочернего элемента. Это приводит к проблемам при рефакторинге, когда не удаётся изменить детали реализации компонента, так как родитель может использовать DOM-узел этого компонента. `findDOMNode` возвращает только первый дочерний элемент, но с использованием фрагментов компонент может рендерить несколько DOM-узлов. `findDOMNode` выполняет поиск только один раз. Затем метод возвращает ранее полученный результат при вызове. Если дочерний компонент рендерит другой узел, то это изменение никак не отследить. Поэтому `findDOMNode` работает, только когда компоненты возвращают единственный и неизменяемый DOM-узел. -Вместо этого, можно передать реф в компонент и передать его далее в DOM используя [перенаправление реф](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). +Вместо этого, можно передать реф в компонент и передать его далее в DOM используя [перенаправление рефов](/docs/forwarding-refs.html#forwarding-refs-to-dom-components). Также можно добавить компоненту DOM-узел как обёртку и прикрепить реф непосредственно к этой обёртке. @@ -75,13 +75,13 @@ class MyComponent extends React.Component { > Примечание: > -> CSS-выражение [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может применяться для исключения узла из раскладки (layout). +> CSS-выражение [`display: contents`](https://developer.mozilla.org/ru/docs/Web/CSS/display#display_contents) может применяться для исключения узла из макета (layout). -### Обраружение неожиданных побочных эффектов {#detecting-unexpected-side-effects} +### Обнаружение неожиданных побочных эффектов {#detecting-unexpected-side-effects} React работает в два этапа: * **Этап рендеринга (render phase)** определяет, какие изменения необходимо произвести, например, в DOM. В течение этого этапа React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера. -* **Этап фиксации (commit phase)** – в нём React применяет любые изменения. (В случае React DOM – это этап, когда React вставляет, обновляет и удаляет DOM-узлы.) В течение этого этапа React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. +* **Этап фиксации (commit phase)** – в нём React применяет любые изменения. В случае React DOM – это этап, когда React вставляет, обновляет и удаляет DOM-узлы. В течение этого этапа React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`. Этап фиксации обычно не занимает много времени, что нельзя сказать про этап рендеринга. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу на части, периодически останавливает и возобновляет работу, чтобы избежать блокировки браузера. Это означает, что на этапе рендеринга React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (из-за возникновения ошибки или прерывания с большим приоритетом). @@ -117,7 +117,7 @@ React работает в два этапа: ### Обнаружение устаревшего API контекста {#detecting-legacy-context-api} -Использование устаревшего API контекста приводило к постоянным ошибкам и поэтому он будет удалён в будущей мажорной версии. Он ещё доступен во всех релизах 16.x, но в строгом режиме будет выведено следующее предупреждение: +Использование устаревшего API контекста очень часто приводило к ошибкам и поэтому он будет удалён в будущей мажорной версии. Пока что этот API доступен во всех релизах 16.x, но в строгом режиме будет выведено следующее предупреждение: ![](../images/blog/warn-legacy-context-in-strict-mode.png)