Apply suggestions from code review

Co-Authored-By: Oleg Shilov <[email protected]>

Author: gcor

content/docs/concurrent-mode-patterns.md

@@ -26,7 +26,7 @@ next: concurrent-mode-adoption.html
 Обновляя состояние, мы обычно ожидаем сразу же увидеть изменения на экране. В этом есть смысл, ведь мы хотим, чтобы наше приложение было отзывчивым к действиям пользователя. Тем не менее, существуют сценарии, при которых предпочтительно **отложить появление обновления на экране**.
 
 Например, если мы переходим с одной страницы на другую, и часть кода или данных для следующего экрана ещё не загружена, может быть странным сразу увидеть пустую страницу с индикатором загрузки.
-Скорее всего мы захотим задержаться на предыдущем экране. Реализация такого паттерна всегда была достаточно сложной в React. Конкурентный режим предоставляет новый набор интсрументов для решения таких задач.
+Скорее всего мы захотим задержаться на предыдущем экране. Реализация такого паттерна всегда была достаточно сложной в React. Конкурентный режим предоставляет новый набор инструментов для решения таких задач.
 
 - [Переходы](#transitions)
   - [Wrapping setState in a Transition](#wrapping-setstate-in-a-transition)
@@ -52,13 +52,13 @@ next: concurrent-mode-adoption.html
 
 Давайте вернёмся к [примеру](https://codesandbox.io/s/infallible-feather-xjtbu) с предыдущей страницы про [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html).
 
-Когда мы нажимаем на кнопку "Next", чтобы переключить активный профиль, данные текущей страницы моментально пропадают и мы видим индикатор загрузки для всей страницы снова. Мы можем сказать, что это "нежелательное" состояние загрузки. **Было бы хорошо, если бы мы могли "пропустить" его и подождать пока загрузится конент перед переходом на новый экран**
+Когда мы нажимаем на кнопку "Next", чтобы переключить активный профиль, данные текущей страницы моментально пропадают и мы видим индикатор загрузки для всей страницы снова. Мы можем сказать, что это "нежелательное" состояние загрузки. **Было бы хорошо, если бы мы могли "пропустить" его и подождать пока загрузится контент перед переходом на новый экран**
 
 React предлагает новый встроенный хук `useTransition()`, чтобы решить эту задачу.
 
 Чтобы его использовать, нам нужно выполнить три шага.
 
-Во-первых, мы убедимся, что мы включили конкурентный режим. Мы поговорим подбробнее о [внедрении конекурентного режима](/docs/concurrent-mode-adoption.html) позже, но пока отметим, что необходимо использовать `ReactDOM.createRoot()` вместо `ReactDOM.render()` для того, чтобы воспользоваться этим решением:
+Во-первых, мы убедимся, что мы включили конкурентный режим. Мы поговорим подробнее о [внедрении конкурентного режима](/docs/concurrent-mode-adoption.html) позже, но пока отметим, что необходимо использовать `ReactDOM.createRoot()` вместо `ReactDOM.render()` для того, чтобы воспользоваться этим решением:
 
 ```js
 const rootElement = document.getElementById("root");
@@ -83,16 +83,16 @@ function App() {
   // ...
 ```
 
-**Сам по себе, этот код пока ничего не делает.** Для того чтобы настроить переходы состояния, нам нужно использовать возращаемое значение данного хука. Результатом вызова `useTransition` будут два значения:
+**Сам по себе, этот код пока ничего не делает.** Для того чтобы настроить переходы состояния, нам нужно использовать возвращаемое значение данного хука. Результатом вызова `useTransition` будут два значения:
 
-* `startTransition` является функцией. Мы будем использовать её для того чтобы сказать React *какое* обновление состояения мы хотим отложить.
+* `startTransition` является функцией. Мы будем использовать её для того чтобы сказать React *какое* обновление состояния мы хотим отложить.
 * `isPending` представляет собой булево значение. Через него React сообщает нам происходит переход в данный момент или нет.
 
 **By itself, this code doesn't do anything yet.** We will need to use this Hook's return values to set up our state transition. There are two values returned from `useTransition`:
 
 Мы будем использовать их в примере ниже.
 
-Заметьте, мы передали в `useTransition` объект с конфигурацией. Это свойство `timeoutMs`, которое определяет **как долго мы готовы подождить пока переход закончится**. Передавая `{timeoutMs: 3000}`, мы говорим "Если следующий профиль будет загружаться более 3 секунд, покажи большой спиннер -- но до истечения этого таймаута можно показывать предыдущий экран".
+Заметьте, мы передали в `useTransition` объект с конфигурацией. Это свойство `timeoutMs`, которое определяет **как долго мы готовы ждать завершения перехода**. Передавая `{timeoutMs: 3000}`, мы говорим "Если следующий профиль будет загружаться более 3 секунд, покажи большой спиннер -- но до истечения этого таймаута можно показывать предыдущий экран".
 
 ### Оборачивание setState в Переход {#wrapping-setstate-in-a-transition}
 
@@ -107,7 +107,7 @@ function App() {
 >
 ```
 
- Мы обернём обновление состояния в метод `startTransition`. Таким образом, React поймёт, что **мы не против того, чтобы React отложил это обновление состояния** если оно приведёт к нежелательному состояинию ожидания загрузки:
+ Мы обернём обновление состояния в метод `startTransition`. Таким образом, React поймёт, что **мы не против того, чтобы React отложил это обновление состояния** если оно приведёт к нежелательному состоянию ожидания загрузки:
 
 ```js{3,6}
 <button
@@ -201,29 +201,29 @@ function App() {
 * Мы обернули обновление состояния в `startTransition`, чтобы React знал, что его можно отложить.
 * Мы используем `isPending`, чтобы сообщить пользователю статус перехода и отключить кнопку.
 
-В результате, нажатие на "Next" не приводит к немедленному переходу на нежелательный экран загрузки, а оставляет нас на предыдущем экране с возможностью отоброжать прогресс по загрузке.
+В результате, нажатие на "Next" не приводит к немедленному переходу на нежелательный экран загрузки, а оставляет нас на предыдущем экране с возможностью отображать прогресс загрузки.
 
 ### Где происходит обновление? {#where-does-the-update-happen}
 
-Имплементация была не очень сложной. Однако, если начать размышлять о том, как бы это могло бы быть реализовано, всё может показаться гараздо более запутанным. Если мы обновляем состояние, почему мы не показываем результат сразу же? *Где* рендерится следующая версия `<ProfilePage>`?
+Имплементация была не очень сложной. Однако, если начать размышлять о том, как бы это могло бы быть реализовано, всё может показаться гораздо более запутанным. Если мы обновляем состояние, почему мы не показываем результат сразу же? *Где* рендерится следующая версия `<ProfilePage>`?
 
-Очевидно, обе "версии" `<ProfilePage>` существуют одновременно. Мы знаем, что старая версия существует, потому что видим её на экране и даже показывает идикатор прогресса. Также мы знаем, что и новая версия *где-то* существует, потому что как раз её мы и ожидаем!
+Очевидно, обе "версии" `<ProfilePage>` существуют одновременно. Мы знаем, что старая версия существует, потому что видим её на экране и даже показывает индикатор прогресса. Также мы знаем, что и новая версия *где-то* существует, потому что как раз её мы и ожидаем!
 
 **Но как две верси одного компонента могут существовать одновременно?**
 
-Таким образом мы подходим к основной сути Конкурентного Режима. [Ранее мы говорили](/docs/concurrent-mode-intro.html#intentional-loading-sequences), что можно представить как будто React работает над новым состоянием в "отдельной ветке". Другой подход, представить что оборачивая обновление состояния в `startTransition` мы начинем рендерить его *"в параллельной вселенной"*, почти как в фантастическом фильме. Мы не "видим" это вселенную явно -- но мы можем получить сигнал от неё, который говорит нам о том, что какой-то процес запущен (`isPending`). Когда обновление будет готово, наши "вселенные" объединятся в одну, и мы увидим результат на экране!
+Таким образом мы подходим к основной сути Конкурентного Режима. [Ранее мы говорили](/docs/concurrent-mode-intro.html#intentional-loading-sequences), что можно представить как будто React работает над новым состоянием в "отдельной ветке". Другой подход, представить что оборачивая обновление состояния в `startTransition` мы начинем рендерить его *"в параллельной вселенной"*, почти как в фантастическом фильме. Мы не "видим" это вселенную явно -- но мы можем получить сигнал от неё, который говорит нам о том, что какой-то процесс запущен (`isPending`). Когда обновление будет готово, наши "вселенные" объединятся в одну, и мы увидим результат на экране!
 
 Поиграйте с [примером](https://codesandbox.io/s/jovial-lalande-26yep), и представьте, что так и происходит.
 
-Конечно, рендеринг двух версий *в одно и то же время* - это илюзия, ровно как и идея о том, что все программы на вашем компьютере исполняются в один и тот же момент. Операционная система перекулючается между приложениями очень быстро. Аналогично, React может переключаться между версией, которую мы видим на экране и версией "готовящейся" к показу.
+Конечно, рендеринг двух версий *в одно и то же время* - это иллюзия, ровно как и идея о том, что все программы на вашем компьютере исполняются в один и тот же момент. Операционная система переключается между приложениями очень быстро. Аналогично, React может переключаться между версией, которую мы видим на экране и версией "готовящейся" к показу.
 
 Использование API `useTransition` позволяет сфокусироваться на желаемом результате и не думать о тонкостях имплементации. Тем не менее, полезно представлять, что обновления обёрнутые в `startTransition` происходят "в ветке" или "в другом мире".
 
 ### Переходы повсюду {#transitions-are-everywhere}
 
-Как мы поняли из [разобра Задержки](/docs/concurrent-mode-suspense.html), любой компонент может "задерживатсья" на любое время, если данные, которые ему необходимы ещё не готовы. Мы можем подумать над стратегий расположения границ `<Suspense>` в разных частях дерева, но не всегда этого будет достаточно.
+Как мы поняли из [разбора Задержки](/docs/concurrent-mode-suspense.html), любой компонент может "задерживаться" на любое время, если данные, которые ему необходимы ещё не готовы. Мы можем подумать над стратегий расположения границ `<Suspense>` в разных частях дерева, но не всегда этого будет достаточно.
 
-Давайте вернёмся к нашему [первому примеру Задержки](https://codesandbox.io/s/frosty-hermann-bztrp), когда у нас был только один профиль. Сейчас занные запрашиваются только однажды. Добавим кнопку "Refresh", чтобы проверять обновления с сервера.
+Давайте вернёмся к нашему [первому примеру Задержки](https://codesandbox.io/s/frosty-hermann-bztrp), когда у нас был только один профиль. Сейчас данные запрашиваются только однажды. Добавим кнопку "Refresh", чтобы проверять обновления с сервера.
 
 Наша попытка может выглядеть следующим образом: