hypens swapped with quotes

Author: shdq

content/docs/concurrent-mode-suspense.md

@@ -43,9 +43,9 @@ const ProfilePage = React.lazy(() => import('./ProfilePage')); // Ленивая
   - [Что если я не использую Relay?](#what-if-i-dont-use-relay)
   - [Для авторов библиотек](#for-library-authors)
 - [Классические подходы против Задержки](#traditional-approaches-vs-suspense)
-  - [Подход 1: Получаем-после-рендера (задержка не используется)](#approach-1-fetch-on-render-not-using-suspense)
-  - [Подход 2: Получаем-потом-рендерим (задержка не используется)](#approach-2-fetch-then-render-not-using-suspense)
-  - [Подход 3: Рендерим-во-время-получения-данных (используем Задержку)](#approach-3-render-as-you-fetch-using-suspense)
+  - [Подход 1: «Получаем после рендера»‎ (задержка не используется)](#approach-1-fetch-on-render-not-using-suspense)
+  - [Подход 2: «Получаем потом рендерим»‎ (задержка не используется)](#approach-2-fetch-then-render-not-using-suspense)
+  - [Подход 3: «Рендерим во время получения данных»‎ (используем Задержку)](#approach-3-render-as-you-fetch-using-suspense)
 - [Начинаем получать данные рано](#start-fetching-early)
   - [Мы все ещё в этом разбираемся](#were-still-figuring-this-out)
 - [Задержка и состояние гонки](#suspense-and-race-conditions)
@@ -149,17 +149,17 @@ function ProfileTimeline() {
 
 Наоборот, мы взглянем на Задержку, как на следующий логический шаг в перечне подходов:
 
-* **Получаем-после-рендера (например, `fetch` в `useEffect`):** Начинаем рендерить компоненты. Каждый из этих компонентов может вызвать получение данных в своих «эффектах» и методах жизненного цикла. Этот подход обычно ведёт к «водопадам».
-* **Получаем-потом-рендерим (например, Relay без Задержки):** Начинаем получать все данные для следующего экрана как можно раньше. Когда данные готовы – рендерим новый экран. Мы ничего не можем делать пока не получим все данные.
-* **Рендерим-во-время-получения-данных (например, Relay с Задержкой):** Начинаем получать все требуемые данные для следующего экрана как можно раньше и начинаем рендерить новый экран *немедленно — до того, как получим ответ от сети*. По мере поступления данных, React повторяет рендер компонентов, которым всё ещё нужны данные, до тех пор, пока они не будут готовы.
+* **«Получаем после рендера»‎ (например, `fetch` в `useEffect`):** Начинаем рендерить компоненты. Каждый из этих компонентов может вызвать получение данных в своих «эффектах» и методах жизненного цикла. Этот подход обычно ведёт к «водопадам».
+* **«Получаем потом рендерим»‎ (например, Relay без Задержки):** Начинаем получать все данные для следующего экрана как можно раньше. Когда данные готовы – рендерим новый экран. Мы ничего не можем делать пока не получим все данные.
+* **«Рендерим во время получения данных»‎ (например, Relay с Задержкой):** Начинаем получать все требуемые данные для следующего экрана как можно раньше и начинаем рендерить новый экран *немедленно — до того, как получим ответ от сети*. По мере поступления данных, React повторяет рендер компонентов, которым всё ещё нужны данные, до тех пор, пока они не будут готовы.
 
 >Примечание
 >
 >Это немного упрощено и на практике требуется использование нескольких подходов. Тем не менее, мы будем рассматривать их отдельно, чтобы лучше отразить компромиссы, которые они требуют.
 
 Для сравнения подходов мы реализуем страницу с профилем пользователя используя каждый из них.
 
-### Подход 1: Получаем-после-рендера (задержка не используется) {#approach-1-fetch-on-render-not-using-suspense}
+### Подход 1: «Получаем после рендера»‎ (задержка не используется) {#approach-1-fetch-on-render-not-using-suspense}
 
 Распространённый сегодня способ получения данных в React с использованием эффекта:
 
@@ -175,7 +175,7 @@ componentDidMount() {
 }
 ```
 
-Мы зовем этот подход «получаем-после-рендера» потому что получение данных начинается *после* рендера компонента на экране. Это приводит к проблеме, известной как «водопад».
+Мы зовем этот подход «получаем после рендера» потому что получение данных начинается *после* рендера компонента на экране. Это приводит к проблеме, известной как «водопад».
 
 Взгляните на компоненты `<ProfilePage>` и `<ProfileTimeline>`:
 
@@ -233,7 +233,7 @@ function ProfileTimeline() {
 
 Водопады  распространены в коде который получает данные после рендера. Их можно устранить, но по мере роста продукта, многие люди предпочитают использовать решение, которое защищает от этой проблемы.
 
-### Подход 2: Получаем-потом-рендерим (задержка не используется) {#approach-2-fetch-then-render-not-using-suspense}
+### Подход 2: «Получаем потом рендерим»‎ (задержка не используется) {#approach-2-fetch-then-render-not-using-suspense}
 
 Библиотеки могут предотвратить появление водопадов предлагая более централизованный способ получения данных. Например, Relay решает эту проблему перемещением информации о данных, которые нужны компоненту в статически анализируемые *фрагменты*, которые позже собираются в единый запрос.
 
@@ -307,7 +307,7 @@ function ProfileTimeline({ posts }) {
 
 Конечно, это можно исправить в данном примере. Мы можем убрать вызов `Promise.all()` и ждать оба промиса отдельно. Однако этот подход прогрессивно усложняется с увеличением количества данных и ростом дерева компонентов. Сложно писать надежные компоненты когда произвольные части дерева данных могут исчезать или устаревать. Поэтому рендер *после* получения всех данных для нового экрана часто является более практичным вариантом.
 
-### Подход 3: Рендерим-во-время-получения-данных (используем Задержку) {#approach-3-render-as-you-fetch-using-suspense}
+### Подход 3: «Рендерим во время получения данных»‎ (используем Задержку) {#approach-3-render-as-you-fetch-using-suspense}
 
 В предыдущем подходе мы получали данные перед вызовом `setState`:
 
@@ -371,13 +371,13 @@ function ProfileTimeline() {
 
 **Чем больше потоков данных поступает, React будет пробовать рендерить и каждый раз он сможет продвигаться «глубже».** Когда данные `resource.user` получены, компонент `<ProfileDetails>` успешно отрендерится и нам больше не потребуется заглушка `<h1>Loading profile...</h1>`. В итоге мы получим все данные и заглушек больше не будет на экране.
 
-Здесь есть интересный момент. Даже если мы используем клиент GraphQL, который собирает все требования к данным в единый запрос, *потоковая передача ответа позволяет нам быстрее показать больше контента*. Так как мы рендерим *во время получения* (в отличии от *после* получения) и если `user` появится в ответе раньше, чем `posts`, мы сможем «убрать» внешнюю заглушку `<Suspense>` до окончания ответа. Мы могли упустить это ранее, но даже при подходе получаем-потом-рендерим решение содержит водопад: между получением и рендером. Задержка не страдает от этого водопада и библиотеки, такие как Relay пользуются этим.
+Здесь есть интересный момент. Даже если мы используем клиент GraphQL, который собирает все требования к данным в единый запрос, *потоковая передача ответа позволяет нам быстрее показать больше контента*. Так как мы рендерим *во время получения* (в отличии от *после* получения) и если `user` появится в ответе раньше, чем `posts`, мы сможем «убрать» внешнюю заглушку `<Suspense>` до окончания ответа. Мы могли упустить это ранее, но даже при подходе «получаем потом рендерим»‎ решение содержит водопад: между получением и рендером. Задержка не страдает от этого водопада и библиотеки, такие как Relay пользуются этим.
 
 Обратите внимание, как мы избавились от проверок `if (...)` «идет загрузка» в наших компонентах. Это не только убирает шаблонный код, но и упрощает быстрые изменения в дизайне. Например, если мы хотим, чтобы информация о пользователе и его сообщения всегда появлялись вместе, мы можем удалить разделение `<Suspense>` между ними. Или мы можем сделать их независимыми от друг друга, предоставив каждому *собственный* `<Suspense>`. Задержка позволяет нам изменить степень раздробленности наших состояний загрузки и управлять их последовательностью без больших изменений в коде.
 
 ## Начинаем получать данные рано {#start-fetching-early}
 
-Если вы работает над библиотекой получения данных, есть важный аспект в подходе Рендерим-во-время-получения-данных, который не стоит упускать. **Мы запускаем получение данных _перед_ рендером.** Посмотрите внимательно на этот пример:
+Если вы работает над библиотекой получения данных, есть важный аспект в подходе «рендерим во время получения данных»‎, который не стоит упускать. **Мы запускаем получение данных _перед_ рендером.** Посмотрите внимательно на этот пример:
 
 ```js
 // Начинаем получать данные рано!