Apply suggestions from code review by @another-guy

Co-Authored-By: agoldis <[email protected]>

Author: another-guy

content/docs/higher-order-components.md

@@ -163,9 +163,9 @@ function withSubscription(WrappedComponent, selectData) {
 }
 ```
 
-Заметьте, что HOC ничего не меняет и не наследует поведение оборачиваемого компонента, вместо этого HOC *оборачивает* оригинальный компонент в контейнер посредством *композиции*. HOC является чистой функцией без посторонних эффектов.
+Заметьте, что HOC ничего не меняет и не наследует поведение оборачиваемого компонента, вместо этого HOC *оборачивает* оригинальный компонент в контейнер посредством *композиции*. HOC является чистой функцией без побочных эффектов.
 
-Вот и всё! Оборачиваемый компонент получает все пропсы, переданные контейнеру, а также проп `data`. Для HOC не важно как будут использоваться данные, а оборачиваемому компоненту не важно откуда они берутся.
+Вот и всё! Оборачиваемый компонент получает все пропсы, переданные контейнеру, а также проп `data`. Для HOC не важно, как будут использоваться данные, а оборачиваемому компоненту не важно, откуда они берутся.
 
 Так как `withSubscription` -- это обычная функция, то мы можем убрать или добавить любое количество аргументов. Например, мы могли бы сделать конфигурируемым название пропа `data` и ещё больше изолировать HOC от оборачиваемого компонента. Также мы можем добавить аргумент для конфигурации `shouldComponentUpdate` или источника данных. Всё это возможно, потому что HOC полностью контролирует процесс создания компонента.
 
@@ -189,7 +189,7 @@ function logProps(InputComponent) {
 const EnhancedComponent = logProps(InputComponent);
 ```
 
-В приведённом выше примере мы не можем повторно использовать `InputComponent` отдельно от `EnhancedComponent`. Важнее то, что если мы захотим обернуть `EnhancedComponent` в другой HOC, который *тоже* меняет `componentWillReceiveProps`, то мы сотрем функциональность заданную первым HOC! Более того, `EnhancedComponent` не работает с функциональными компонентами потому, что у них отсутствуют методы жизненного цикла.
+В приведённом выше примере мы не можем повторно использовать `InputComponent` отдельно от `EnhancedComponent`. Важнее то, что если мы захотим обернуть `EnhancedComponent` в другой HOC, который *тоже* меняет `componentWillReceiveProps`, то мы сотрём функциональность заданную первым HOC! Более того, `EnhancedComponent` не работает с функциональными компонентами, потому что у них отсутствуют методы жизненного цикла.
 
 Мутирующие HOC являются хрупкой абстракцией, они конфликтуют с другими HOC, мы не сможем просто применять их без того, чтобы знать что именно они меняют.
 
@@ -218,7 +218,7 @@ function logProps(WrappedComponent) {
 
 HOC добавляют компонентам функциональность, но они не должны менять их оригинальное предназначение. Ожидается, что интерфейс компонента, который вы возвращаете из HOC, будет похож на интерфейс оборачиваемого компонента.
 
-Пропсы, которые напрямую не связаны с функциональностью HOC, должны передаваться оборачиваемогу компоненту. Рендер-метод большинства HOC похож на следующий:
+Пропсы, которые напрямую не связаны с функциональностью HOC, должны передаваться без изменений оборачиваемогу компоненту. Рендер-метод большинства HOC похож на следующий:
 
 ```js
 render() {
@@ -238,7 +238,7 @@ render() {
 }
 ```
 
-Такое соглашение помогает создавать гибкие и многоразовые компоненты.
+Такое соглашение помогает создавать гибкие повторно используемые компоненты.
 
 ## Соглашение: Максимизируем композитивность {#convention-maximizing-composability}
 
@@ -288,7 +288,7 @@ const enhance = compose(
 const EnhancedComponent = enhance(WrappedComponent)
 ```
 
-(Поэтому мы можем использовать `connect`, и другие расширяющие функциональность HOC, в качестве экспериментальных JavaScript декораторов.)
+(Поэтому мы можем использовать `connect` и другие расширяющие функциональность HOC в качестве экспериментальных JavaScript декораторов.)
 
 Вы можете найти вспомогательную функцию `compose` во многих сторонних библиотеках, включая lodash (под названием [`lodash.flowRight`](https://lodash.com/docs/#flowRight)), [Redux](http://redux.js.org/docs/api/compose.html), и [Ramda](http://ramdajs.com/docs/#compose).
 
@@ -316,7 +316,7 @@ function getDisplayName(WrappedComponent) {
 
 ### Не используйте HOC внутри рендер-метода {#dont-use-hocs-inside-the-render-method}
 
-Алгоритм сравнения React (или согласование (reconciliation)) использует тождественность компонентов чтобы определить нужно ли обновить существующее поддерево, или убрать и монтировать вместо него новое. Если компонент, полученный из `render`, идентичен (`===`) компоненту из предыдущего рендера, то React рекурсивно продолжит сравнивать поддерево. Если компоненты не равны, React полностью удалит и заменит старое поддерево.
+Алгоритм сравнения React (известный как согласование или reconciliation) использует тождественность компонентов чтобы определить нужно ли обновить существующее поддерево, или убрать и монтировать вместо него новое. Если компонент, полученный из `render`, идентичен (`===`) компоненту из предыдущего рендера, то React рекурсивно продолжит сравнивать поддерево. Если компоненты не равны, React полностью удалит и заменит старое поддерево.
 
 Обычно нас это не беспокоит. Однако, важно учитывать что мы не можем применять компоненты высшего порядка внутри рендер-метода компонента: