Обновлено содержание reconcilation.md.

Применены изменения @revidovich. Слегка перефразированы некоторые предложения.

Author: ntishkevich

content/docs/reconciliation.md

@@ -8,24 +8,24 @@ React предоставляет декларативный API, который
 
 ## Мотивация {#motivation}
 
-При работе с React вы можете понимать `render()` как функцию, которая создаёт дерево React-элементов в какой-то момент времени. При последующем обновлении состояния или пропсов функция `render()` вернёт новое дерево React-элементов. Теперь React должен понять, как эффективно обновить UI, чтобы он совпадал с новейшим из деревьев.
+При работе с React вы понимаете `render()` как функцию, которая создаёт дерево React-элементов в какой-то момент времени. При следующем обновлении состояния или пропсов функция `render()` возвращает новое дерево React-элементов. Во время выполнения этой функции React должен выяснить как наиболее эффективно обновить пользовательский интерфейс для соответствия новому дереву.
 
-Существует несколько общих решений алгоритмической проблемы трансформации одного дерева в другое за минимальное количество операций. Тем не менее, [передовые алгоритмы](http://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf) имеют сложность порядка O(n<sup>3</sup>), где n — это число элементов в дереве.
+Существует несколько общих решений алгоритмической проблемы трансформации одного дерева в другое за минимальное количество операций. Тем не менее, даже [передовые алгоритмы](http://grfia.dlsi.ua.es/ml/algorithms/references/editsurvey_bille.pdf) имеют сложность порядка O(n<sup>3</sup>), где n — это число элементов в дереве.
 
-Если бы мы использовали это в React, отображение 1000 элементов потребовало бы порядка миллиарда сравнений. Это слишком дорого. Взамен, React реализует эвристический алгоритм O(n), который основывается на двух предположениях:
+Если бы мы использовали это в React, отображение 1000 элементов потребовало бы порядка миллиарда сравнений. Это слишком дорого. Взамен, React реализует эвристический алгоритм O(n), который основывается на двух утверждениях:
 
 1. Два элемента с разными типами произведут разные деревья.
-2. Разработчик может указать, какие дочерние элементы могут оставаться стабильными между разными рендерами с помощью пропа `key`.
+2. Разработчик может указать какие дочерние элементы останутся стабильными между рендерами с помощью пропа `key`.
 
-На практике эти предположения верны почти во всех случаях.
+На практике эти утверждения верны почти во всех случаях.
 
 ## Алгоритм сравнения {#the-diffing-algorithm}
 
-При сравнении двух деревьев первым делом React сравнивает два корневых элемента. Поведение различается в зависимости от типов корневых элементов.
+React сравнивает деревья начиная с их корневых элементов и направляется вниз. Сравниваются типы (теги) корневых элементов.
 
 ### Элементы различных типов {#elements-of-different-types}
 
-Всякий раз, когда корневые элементы имеют различные типы, React уничтожает старое дерево и строит новое с нуля. Переходы от `<a>` к `<img>`, или от `<Article>` к `<Comment>`, или от `<Button>` к `<div>` приведут к полному перестроению.
+сякий раз, когда корневые элементы имеют различные типы, React уничтожает старое дерево и строит новое с нуля. Трансформация из `<a>` в `<img>`, или из `<Article>` в `<Comment>`, или из `<Button>` в `<div>` приведут к полному перестроению вложенных элементов.
 
 При уничтожении дерева старые DOM-узлы удаляются. Экземпляры компонента получают `componentWillUnmount()`. При построении нового дерева, новые DOM-узлы вставляются в DOM. Экземпляры компонента получают `UNSAFE_componentWillMount()`, а затем `componentDidMount()`. Любое состояние, связанное со старым деревом, теряется.
 
@@ -41,7 +41,7 @@ React предоставляет декларативный API, который
 </span>
 ```
 
-При этом старый `Counter` уничтожится, а новый — смонтируется.
+При этом старый `Counter` уничтожится и смонтируется новый.
 
 >Примечание:
 >
@@ -59,7 +59,7 @@ React предоставляет декларативный API, который
 <div className="after" title="stuff" />
 ```
 
-Сравнивая эти элементы, React знает, что нужно модифицировать только `className` у лежащего в основе DOM-узла.
+Сравнивая эти элементы, React знает, что нужно модифицировать только `className` у DOM-узла.
 
 Обновляя `style`, React также знает, что нужно обновлять только изменившиеся свойства. Например: 
 
@@ -69,9 +69,9 @@ React предоставляет декларативный API, который
 <div style={{color: 'green', fontWeight: 'bold'}} />
 ```
 
-При конвертации между этими элементами, React знает, что нужно модифицировать только стиль `color`, а `fontWeight` сохранить.
+При конвертации между этими элементами, React знает, что нужно модифицировать только стиль `color`, не затронув `fontWeight`.
 
-После обработки DOM-узла React рекурсивно проходится по дочерним элементам.
+После обработки DOM-узла React рекурсивно проходит по дочерним элементам.
 
 ### Компоненты одного типа {#component-elements-of-the-same-type}
 
@@ -88,7 +88,7 @@ React предоставляет декларативный API, который
 
 ### Рекурсия по дочерним элементам {#recursing-on-children}
 
-По умолчанию при рекурсивном обходе дочерних элементов DOM-узла React проходит по обоим спискам потомков одновременно и создаёт мутацию, когда находит отличие.
+По умолчанию при рекурсивном обходе дочерних элементов DOM-узла React одновременно проходит по обоим спискам потомков и создаёт мутацию, когда находит отличие.
 
 Например, при добавлении элемента в конец дочерних элементов, преобразование между этими деревьями работает отлично: 
 
@@ -121,11 +121,11 @@ React сравнит два дерева `<li>первый</li>`, сравнит
   <li>Москва</li>
 </ul>
 ```
-React будет мутировать каждого потомка, вместо того чтобы оставить `<li>Санкт-Петербург</li>`  и `<li>Москва</li>` нетронутыми. Эта неэффективность может стать проблемой.
+React, вместо того чтобы оставить `<li>Санкт-Петербург</li>`  и `<li>Москва</li>` нетронутыми, будет мутировать каждого потомка. Эта неэффективность может стать проблемой.
 
 ### Ключи {#keys}
 
-Для решения этой проблемы React поддерживает атрибут `key`. Когда у дочерних элементов есть ключи, React использует их, чтобы сопоставить потомков исходного дерева с потомками последующего дерева. Например, если добавить `key` к неэффективному примеру выше, преобразование дерева станет эффективным:
+Для решения этой проблемы React поддерживает атрибут `key`. Когда у дочерних элементов есть ключи, React воспользуется ими, чтобы сопоставить потомков исходного дерева с потомками последующего дерева. Например, если добавить `key` к неэффективному примеру выше, преобразование дерева станет эффективнее:
 
 ```html
 <ul>
@@ -140,7 +140,7 @@ React будет мутировать каждого потомка, вмест
 </ul>
 ```
 
-Теперь React знает, что элемент с ключом `'2014'` — новый, а элементы с ключами `'2015'` и `'2016'` только что переместились.
+Теперь React знает, что элемент с ключом `'2014'` — новый, а элементы с ключами `'2015'` и `'2016'` переместились.
 
 На практике найти ключ обычно несложно. Элемент, который вы хотите отобразить, уже может иметь уникальный идентификатор, и ключ может быть взят из ваших данных:
 
@@ -152,18 +152,18 @@ React будет мутировать каждого потомка, вмест
 
 В крайнем случае вы можете передать индекс элемента массива в качестве ключа. Это работает хорошо в случае, если элементы никогда не меняют порядок. Перестановки элементов вызывают замедление.
 
-При использовании ключей перестановки так же могут вызывать проблемы с состоянием компонента. Экземпляры компонента обновляются и повторно используются на основе их ключей. Перемещение элемента изменяет его, если ключ является индексом. В результате состояние компонента для таких вещей, как неуправляемые `<input>`, может смешаться и обновиться неожиданным образом.
+Вдобавок перестановки элементов могут вызвать проблемы с состоянием компонента, когда в качестве ключей используются индексы. Экземпляры компонента обновляются и повторно используются на основе своих ключей. Если ключ является индексом, то перемещение элемента изменяет его. В результате состояние компонента для таких элементов , как неуправляемые `<input>`, может смешаться и обновиться неожиданным образом.
 
 На CodePen [есть примеры проблем, которые могут быть вызваны использованием индексов в качестве ключей](codepen://reconciliation/index-used-as-key), а также есть [обновлённая версия того же примера, которая показывает как решаются проблемы с перестановкой, сортировкой и вставкой элементов в начало, если не использовать индексы как ключи](codepen://reconciliation/no-index-used-as-key).
 
 ## Компромиссы {#tradeoffs}
 
-Важно помнить, что алгоритм согласования — это деталь реализации. React может повторно рендерить всё приложение на каждое действие, конечный результат будет тем же. Для ясности, повторный рендер в этом контексте означает вызов функции `render` для всех компонентов, но это не означает, что React размонтирует и смонтирует их заново. Он применит различия только следуя правилам, которые были обозначены в предыдущих разделах.
+Важно помнить, что алгоритм согласования — это деталь реализации. React может повторно рендерить всё приложение на каждое действие, конечный результат будет тем же. Для ясности, повторный рендер в этом контексте означает вызов функции `render` для всех компонентов, но это не означает, что React размонтирует и смонтирует их заново. Он лишь применит различия следуя правилам, которые были обозначены выше.
 
-Мы регулярно совершенствуем эвристику, чтобы ускорить часто встречающиеся варианты использования. В текущей реализации вы можете выразить факт того, что поддерево сдвинулось среди его соседей, но вы не можете сказать, что оно сдвинулось куда-то в другое место. Алгоритм повторно отрендерит всё поддерево.
+    Мы регулярно совершенствуем эвристику, чтобы повысить производительность. В текущей реализации вы можете выразить факт того, что поддерево было перемещено среди своих соседей, но вы не можете сказать, что оно переместилось куда-то в другое место. Алгоритм повторно рендерит всё поддерево.
 
-React полагается на эвристику, следовательно, если предположения, на которых она основана, не соблюдены, пострадает производительность. 
+React полагается на эвристику, следовательно, если утверждения, на которых она основана, не соблюдены, то пострадает производительность. 
 
-1. Алгоритм не будет пытаться сопоставить поддеревья компонентов разных типов. Если вы заметите за собой, что пытаетесь чередовать компоненты разных типов с очень схожим выводом, то желательно сделать их компонентами одного типа. На практике мы не выявили с этим проблем.
+1. Алгоритм не будет пытаться сравнивать поддеревья компонентов разных типов. Если вы заметите за собой, что пытаетесь использовать компоненты разных типов с очень схожим выводом, то, вероятно, стоит их сделать компонентами одного типа. На практике мы не выявили с этим проблем.
 
 2. Ключи должны быть стабильными, предсказуемыми и уникальными. Нестабильные ключи (например, произведённые с помощью `Math.random()`) вызовут необязательное пересоздание многих экземпляров компонента и DOM-узлов, что может вызывать ухудшение производительности и потерю состояния у дочерних компонентов.