Sync with reactjs.org @ 92ad9c2 (#341)

* Update thinking-in-react.md (#2095)

Please refer to https://justsimply.dev for the thinking behind these proposed changes.

* Resolve conflicts

Author: reactjs-translation-bot

content/docs/thinking-in-react.md

@@ -37,11 +37,11 @@ prev: composition-vs-inheritance.html
 
 Но как выбрать, что является компонентом, а что нет? Это похоже на то, как вы решаете, надо ли объявить функцию или объект. Можно применить [принцип единственной ответственности](https://ru.wikipedia.org/wiki/Принцип_единственной_ответственности): каждый компонент по-хорошему должен заниматься какой-то одной задачей. Если функциональность компонента увеличивается с течением времени, его следует разбить на более мелкие подкомпоненты.
 
-Многие интерфейсы показывают модель данных JSON. Поэтому хорошо построенная модель, как правило, уже отражает пользовательский интерфейс (а значит, и структуру компонентов). Интерфейс и модели данных часто имеют похожую *информационную архитектуру*, так что разделить интерфейс на части не составляет труда. Просто разбейте его на компоненты, каждый из которых отображает часть модели данных.
+Многие интерфейсы показывают модель данных JSON. Поэтому хорошо построенная модель, как правило, уже отражает пользовательский интерфейс (а значит, и структуру компонентов). Интерфейс и модели данных часто имеют похожую *информационную архитектуру*, так что разделить интерфейс на части не составляет труда. Разбейте его на компоненты, каждый из которых отображает часть модели данных.
 
 ![Component diagram](../images/blog/thinking-in-react-components.png)
 
-Здесь мы видим, что наше простое приложение состоит из пяти различных компонентов. Курсивом выделены данные, которые эти компоненты представляют.
+Здесь мы видим, что наше приложение состоит из пяти различных компонентов. Курсивом выделены данные, которые эти компоненты представляют.
 
   1. **`FilterableProductTable` (оранжевый):** контейнер, содержащий пример целиком
   2. **`SearchBar` (синий):** поле *пользовательского ввода*
@@ -51,7 +51,7 @@ prev: composition-vs-inheritance.html
 
 Обратите внимание, что внутри `ProductTable` заголовок таблицы ("Name" и "Price") сам по себе отдельным компонентом не является. Отделять его или нет — вопрос личного предпочтения. В данном примере мы решили не придавать этому особого значения и оставить заголовок частью большего компонента `ProductTable`, так как он является всего лишь малой частью общего *списка данных*. Тем не менее, если в будущем заголовок пополнится новыми функциями (например, возможностью сортировать товар), имеет смысл извлечь его в самостоятельный компонент `ProductTableHeader`.
 
-Теперь, когда мы определили компоненты в нашем макете, давайте расположим их по порядку подчинённости. Это просто. Компоненты, которые являются частью других компонентов, в иерархии отображаются как дочерние:
+Теперь, когда мы определили компоненты в нашем макете, давайте расположим их согласно иерархии. Компоненты, которые являются частью других компонентов, в иерархии отображаются как дочерние:
 
   * `FilterableProductTable`
     * `SearchBar`
@@ -71,7 +71,7 @@ prev: composition-vs-inheritance.html
 
 Написание кода можно начать как сверху вниз (с большого `FilterableProductTable`), так и снизу вверх (с маленького `ProductRow`). Более простые приложения удобнее начать с компонентов, находящихся выше по иерархии. В более сложных приложениях удобнее в первую очередь создавать и тестировать подкомпоненты.
 
-В конце этого шага у вас на руках появится библиотека повторно используемых компонентов, отображающих вашу модель данных. Так как это статическая версия, компоненты будут иметь только методы `render()`. Компонент выше по иерархии (`FilterableProductTable`) будет передавать модель данных через пропсы. Если вы внесёте изменения в базовую модель данных и снова вызовете `ReactDOM.render()`, то увидите изменения в пользовательском интерфейсе. Ничего сложного в отслеживании изменений и обновлении интерфейса нет. Благодаря **одностороннему потоку данных** (или *односторонней привязке*), код работает быстро, но остаётся понятным. 
+В конце этого шага у вас на руках появится библиотека повторно используемых компонентов, отображающих вашу модель данных. Так как это статическая версия, компоненты будут иметь только методы `render()`. Компонент выше по иерархии (`FilterableProductTable`) будет передавать модель данных через пропсы. Если вы внесёте изменения в базовую модель данных и снова вызовете `ReactDOM.render()`, то пользовательский интерфейс отразит эти изменения. Вы можете увидеть, как обновляется интерфейс и где следует сделать очередные изменения. Благодаря **одностороннему потоку данных** (или *односторонней привязке*), код работает быстро, но остаётся понятным. 
 
 Если у вас остались вопросы по выполнению данного шага, обратитесь к [документации React](/docs/).
 
@@ -118,7 +118,7 @@ prev: composition-vs-inheritance.html
   * Определите компоненты, которые рендерят что-то исходя из состояния.
   * Найдите общий главенствующий компонент (компонент, расположенный над другими компонентами, которым нужно это состояние). 
   * Либо общий главенствующий компонент, либо любой компонент, стоящий выше по иерархии, должен содержать состояние.
-  * Если вам не удаётся найти подходящий компонент, создайте один исключительно для состояния и разместите его выше по иерархии над общим главенствующим компонентом.
+  * Если вам не удаётся найти подходящий компонент, то создайте новый исключительно для хранения состояния и разместите его выше в иерархии над общим главенствующим компонентом.
 
 Давайте применим эту стратегию на примере нашего приложения:
 
@@ -136,7 +136,7 @@ prev: composition-vs-inheritance.html
 
 Пока что наше приложение рендерится в зависимости от пропсов и состояния, передающихся вниз по иерархии. Теперь мы обеспечим поток данных в обратную сторону: наша задача сделать так, чтобы компоненты формы в самом низу иерархии обновляли состояние в `FilterableProductTable`.
 
-Поток данных в React — однонаправленный. Так проще понять, как работает приложение, но нам потребуется немного больше кода, чем в традиционной двусторонней привязке данных.
+Поток данных в React — однонаправленный. Это помогает понять, как работает приложение, но нам потребуется немного больше кода, чем с традиционной двусторонней привязкой данных.
 
 Если вы попытаетесь ввести текст в поле поиска или установить флажок в чекбоксе данной версии примера, то увидите, что React игнорирует любой ввод. Это преднамеренно, так как ранее мы приравняли значение пропа `value` в `input` к `state` в `FilterableProductTable`.
 
@@ -146,4 +146,4 @@ prev: composition-vs-inheritance.html
 
 ## Вот и всё {#and-thats-it}
 
-Надеемся, что этот пример поможет вам получить лучшее представление о том, как подойти к созданию компонентов и приложений в React. Хотя этот процесс и использует немного больше кода, помните: код читают чаще, чем пишут. А такой модульный и прямой код, как в нашем приложении, читается очень легко. Когда вы начнёте создавать большие библиотеки компонентов, вы сможете по-настоящему оценить прямолинейность и связанность React, а повторно используемые компоненты сделают ваш код намного меньше. :)
+Надеемся, что этот пример поможет вам получить лучшее представление о том, как подойти к созданию компонентов и приложений в React. Хотя этот процесс и использует немного больше кода, помните: код читают чаще, чем пишут. А модульный и прямолинейный код читается значительно легче. Когда вы начнёте создавать большие библиотеки компонентов, вы сможете по-настоящему оценить прямолинейность и связанность React, а повторно используемые компоненты сделают ваш код намного меньше. :)