From 207a1489cf7bd7b67e6c36d206af4cbae1ff3dfa Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 6 Dec 2019 18:35:26 +0200 Subject: [PATCH 01/17] first part --- content/docs/concurrent-mode-intro.md | 36 +++++++++++++++++++-------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index b2980ce3d..4e4b64f03 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -14,45 +14,59 @@ next: concurrent-mode-suspense.html
->Caution: +>Увага: > ->This page describes **experimental features that are [not yet available](/docs/concurrent-mode-adoption.html) in a stable release**. Don't rely on experimental builds of React in production apps. These features may change significantly and without a warning before they become a part of React. +>На сторінці описані **експериментальні функції, [яких ще немає](/docs/concurrent-mode-adoption.html) в стабільній версії**. Не використовуйте експериментальні збірки React в продакшн додатках. Ці функції можуть значно змінитися без попередження перед тим, як потрапити в React. > ->This documentation is aimed at early adopters and people who are curious. **If you're new to React, don't worry about these features** -- you don't need to learn them right now. - +>Ця документація орієнтована на першопрохідців та зацікавлених користувачів. **Якщо ви новачок в React, не турбуйтеся про ці функції**, не потрібно вивчати їх прямо зараз.
-This page provides a theoretical overview of Concurrent Mode. **For a more practical introduction, you might want to check out the next sections:** +На цій сторінці подано теоретичний огляд "Конкурентного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** * [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. * [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. * [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project. * [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds. -## What Is Concurrent Mode? {#what-is-concurrent-mode} +## Що таке конкурентный режим? {#what-is-concurrent-mode} -Concurrent Mode is a set of new features that help React apps stay responsive and gracefully adjust to the user's device capabilities and network speed. +Конкурентный режим - це набір нових функцій які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. +Ці особливості досі експериментальні і можуть змінюватися. Вони ще не є частиною стабільної версії React, але ви можете спробувати їх в експериментальній збірці. -These features are still experimental and are subject to change. They are not yet a part of a stable React release, but you can try them in an experimental build. -## Blocking vs Interruptible Rendering {#blocking-vs-interruptible-rendering} +## Блокування проти переривання рендерингу {#blocking-vs-interruptible-rendering} -**To explain Concurrent Mode, we'll use version control as a metaphor.** If you work on a team, you probably use a version control system like Git and work on branches. When a branch is ready, you can merge your work into master so that other people can pull it. +**Щоб пояснити конкурентний режим, ми будемо використовувати керування версіями як метафору.** +Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git і працюєте на гілках. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. Before version control existed, the development workflow was very different. There was no concept of branches. If you wanted to edit some files, you had to tell everyone not to touch those files until you've finished your work. You couldn't even start working on them concurrently with that person — you were literally *blocked* by them. +До того, як існував контроль версій, робочий процес розвитку був дуже різним. Там не було поняття гілок. Якщо ви хотіли відредагувати деякі файли, вам доводилося сказати всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з цією людиною - вас вони буквально *заблокували*. + This illustrates how UI libraries, including React, typically work today. Once they start rendering an update, including creating new DOM nodes and running the code inside components, they can't interrupt this work. We'll call this approach "blocking rendering". +Це ілюструє, як типово сьогодні працюють UI бібліотеки включаючи React. Як тільки вони починають рендерить оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". + In Concurrent Mode, rendering is not blocking. It is interruptible. This improves the user experience. It also unlocks new features that weren't possible before. Before we look at concrete examples in the [next](/docs/concurrent-mode-suspense.html) [chapters](/docs/concurrent-mode-patterns.html), we'll do a high-level overview of new features. -### Interruptible Rendering {#interruptible-rendering} +У конкурентному режимі рендеринг не блокується. Він переривається. Це покращує зручність в користуванні. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [главах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. + + +### Interruptible Rendering {#interruptible-rendering} Переривання рендерингу Consider a filterable product list. Have you ever typed into a list filter and felt that it stutters on every key press? Some of the work to update the product list might be unavoidable, such as creating new DOM nodes or the browser performing layout. However, *when* and *how* we perform that work plays a big role. +Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він заїкається при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або "веб-переглядача, що виконує макет". Однак * коли * і * як * ми виконуємо цю роботу, грає велику роль. + A common way to work around the stutter is to "debounce" the input. When debouncing, we only update the list *after* the user stops typing. However, it can be frustrating that the UI doesn't update while we're typing. As an alternative, we could "throttle" the input, and update the list with a certain maximum frequency. But then on lower-powered devices we'd still end up with stutter. Both debouncing and throttling create a suboptimal user experience. +Поширений спосіб обійти заїкання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б "throttle" введення та оновити список з певною максимальною частотою. Але потім на пристроях з меншою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг створюють неоптимальну зручність для користувача. + The reason for the stutter is simple: once rendering begins, it can't be interrupted. So the browser can't update the text input right after the key press. No matter how good a UI library (such as React) might look on a benchmark, if it uses blocking rendering, a certain amount of work in your components will always cause stutter. And, often, there is no easy fix. +Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіші. Незалежно від того, наскільки добре може виглядати бібліотека користувальницького інтерфейсу (наприклад, React) на еталоні, якщо він використовує блокування візуалізації, певна кількість роботи у ваших компонентах завжди призведе до заїкання + + **Concurrent Mode fixes this fundamental limitation by making rendering interruptible.** This means when the user presses another key, React doesn't need to block the browser from updating the text input. Instead, it can let the browser paint an update to the input, and then continue rendering the updated list *in memory*. When the rendering is finished, React updates the DOM, and changes are reflected on the screen. Conceptually, you can think of this as React preparing every update "on a branch". Just like you can abandon work in branches or switch between them, React in Concurrent Mode can interrupt an ongoing update to do something more important, and then come back to what it was doing earlier. This technique might also remind you of [double buffering](https://wiki.osdev.org/Double_Buffering) in video games. From 11e4ad5a192545ad0de4e928d3bf8327cd88bb9e Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Thu, 9 Jan 2020 10:41:51 +0200 Subject: [PATCH 02/17] finish translate concurrent mode intro --- content/docs/concurrent-mode-intro.md | 71 ++++++++++++--------------- content/docs/nav.yml | 2 +- 2 files changed, 33 insertions(+), 40 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 4e4b64f03..5d741f2a1 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -1,6 +1,6 @@ --- id: concurrent-mode-intro -title: Introducing Concurrent Mode (Experimental) +title: Знайомство з паралельним режимом (Експериментальний) permalink: docs/concurrent-mode-intro.html next: concurrent-mode-suspense.html --- @@ -21,92 +21,85 @@ next: concurrent-mode-suspense.html >Ця документація орієнтована на першопрохідців та зацікавлених користувачів. **Якщо ви новачок в React, не турбуйтеся про ці функції**, не потрібно вивчати їх прямо зараз. -На цій сторінці подано теоретичний огляд "Конкурентного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** +На цій сторінці подано теоретичний огляд "Паралельного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** * [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. * [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. * [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project. * [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds. -## Що таке конкурентный режим? {#what-is-concurrent-mode} +## Що таке паралельний режим? {#what-is-concurrent-mode} -Конкурентный режим - це набір нових функцій які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. +Паралельний режим - це набір нових функцій які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. Ці особливості досі експериментальні і можуть змінюватися. Вони ще не є частиною стабільної версії React, але ви можете спробувати їх в експериментальній збірці. ## Блокування проти переривання рендерингу {#blocking-vs-interruptible-rendering} -**Щоб пояснити конкурентний режим, ми будемо використовувати керування версіями як метафору.** +**Щоб пояснити паралельний режим, ми будемо використовувати керування версіями як метафору.** Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git і працюєте на гілках. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. -Before version control existed, the development workflow was very different. There was no concept of branches. If you wanted to edit some files, you had to tell everyone not to touch those files until you've finished your work. You couldn't even start working on them concurrently with that person — you were literally *blocked* by them. - До того, як існував контроль версій, робочий процес розвитку був дуже різним. Там не було поняття гілок. Якщо ви хотіли відредагувати деякі файли, вам доводилося сказати всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з цією людиною - вас вони буквально *заблокували*. -This illustrates how UI libraries, including React, typically work today. Once they start rendering an update, including creating new DOM nodes and running the code inside components, they can't interrupt this work. We'll call this approach "blocking rendering". - Це ілюструє, як типово сьогодні працюють UI бібліотеки включаючи React. Як тільки вони починають рендерить оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". -In Concurrent Mode, rendering is not blocking. It is interruptible. This improves the user experience. It also unlocks new features that weren't possible before. Before we look at concrete examples in the [next](/docs/concurrent-mode-suspense.html) [chapters](/docs/concurrent-mode-patterns.html), we'll do a high-level overview of new features. +У Паралельному режимі рендеринг не блокується. Він переривається. Це покращує зручність в користуванні. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [главах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. -У конкурентному режимі рендеринг не блокується. Він переривається. Це покращує зручність в користуванні. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [главах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. +### Переривання рендерингу -### Interruptible Rendering {#interruptible-rendering} Переривання рендерингу +Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він затиняїться при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або "веб-переглядача, що виконує макет". Однак * коли * і * як * ми виконуємо цю роботу, грає велику роль. -Consider a filterable product list. Have you ever typed into a list filter and felt that it stutters on every key press? Some of the work to update the product list might be unavoidable, such as creating new DOM nodes or the browser performing layout. However, *when* and *how* we perform that work plays a big role. +Поширений спосіб обійти запинання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б "throttle" введення та оновити список з певною максимальною частотою. Але потім на пристроях з меншою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг створюють неоптимальну зручність для користувача. -Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він заїкається при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або "веб-переглядача, що виконує макет". Однак * коли * і * як * ми виконуємо цю роботу, грає велику роль. +Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіші. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, легко не виправити. -A common way to work around the stutter is to "debounce" the input. When debouncing, we only update the list *after* the user stops typing. However, it can be frustrating that the UI doesn't update while we're typing. As an alternative, we could "throttle" the input, and update the list with a certain maximum frequency. But then on lower-powered devices we'd still end up with stutter. Both debouncing and throttling create a suboptimal user experience. -Поширений спосіб обійти заїкання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б "throttle" введення та оновити список з певною максимальною частотою. Але потім на пристроях з меншою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг створюють неоптимальну зручність для користувача. +**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг переривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру намалювати оновлення на вхід, а потім продовжити надання оновленого списку *у пам'яті*. Коли рендеринг закінчен, React оновлює DOM, а зміни відображаються на екрані. -The reason for the stutter is simple: once rendering begins, it can't be interrupted. So the browser can't update the text input right after the key press. No matter how good a UI library (such as React) might look on a benchmark, if it uses blocking rendering, a certain amount of work in your components will always cause stutter. And, often, there is no easy fix. +Концептуально ви можете подумати про це як React, що готує кожне оновлення "на гілці". Так само, як ви можете відмовитися від роботи у гілках або перемикатися між ними, React у паралельному режимі може перервати постійне оновлення, щоб зробити щось важливіше, а потім повернутися до того, що він робив раніше. Ця методика може також нагадувати вам про [подвійне буферування](https://wiki.osdev.org/Double_Buffering) у відеоіграх. -Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіші. Незалежно від того, наскільки добре може виглядати бібліотека користувальницького інтерфейсу (наприклад, React) на еталоні, якщо він використовує блокування візуалізації, певна кількість роботи у ваших компонентах завжди призведе до заїкання +Методи паралельного режиму зменшують потребу в дебаунсингу та тротлингу в інтерфейсі користувача. Оскільки рендеринг переривається, React не потрібно штучно *затримувати* рендеринг, щоб уникнути затинання. Він може почати рендеринг відразу, але перервати цю роботу, коли це необхідно, щоб додаток завжди був в змозі реагувати на запити. +### Навмисні послідовності завантаження {#intentional-loading-sequences} -**Concurrent Mode fixes this fundamental limitation by making rendering interruptible.** This means when the user presses another key, React doesn't need to block the browser from updating the text input. Instead, it can let the browser paint an update to the input, and then continue rendering the updated list *in memory*. When the rendering is finished, React updates the DOM, and changes are reflected on the screen. +Ми вже говорили, що паралельний режим - це як React працює "на гілці". Гілки корисні не тільки для короткочасних виправлень, але і для довготривалих змін. Іноді ви можете працювати над функцією, але може пройти кілька тижнів, перш ніж вона виявиться в «досить хорошому стані», щоб злитися з майстром. Ця сторона нашої метафори управління версіями стосується і рендерингу. -Conceptually, you can think of this as React preparing every update "on a branch". Just like you can abandon work in branches or switch between them, React in Concurrent Mode can interrupt an ongoing update to do something more important, and then come back to what it was doing earlier. This technique might also remind you of [double buffering](https://wiki.osdev.org/Double_Buffering) in video games. +Уявіть, що ми пересуваємося між двома екранами в додатку. Іноді у нас може не вистачати завантаженого коду і даних, щоб показати користувачеві «досить добре» стан завантаження на новому екрані. Перехід на порожній екран або на великий спінер може бути неприємним досвідом. Однак також звичайно, що необхідний код та дані не потребують занадто багато часу для отримання. **Чи не було б приємніше, якби React міг залишитися на старому екрані трохи довше і "пропустити" "поганий стан завантаження" перед тим, як показати новий екран?** -Concurrent Mode techniques reduce the need for debouncing and throttling in UI. Because rendering is interruptible, React doesn't need to artificially *delay* work to avoid stutter. It can start rendering right away, but interrupt this work when needed to keep the app responsive. +While this is possible today, it can be difficult to orchestrate. In Concurrent Mode, this feature is built-in. React starts preparing the new screen in memory first — or, as our metaphor goes, "on a different branch". So React can wait before updating the DOM so that more content can load. In Concurrent Mode, we can tell React to keep showing the old screen, fully interactive, with an inline loading indicator. And when the new screen is ready, React can take us to it. -### Intentional Loading Sequences {#intentional-loading-sequences} +Незважаючи на те, що це можливо сьогодні, це може бути важко організувати. У паралельному режимі ця функція вбудована. React спочатку починає готувати новий екран в пам'яті - або, як йдеться у нашій метафорі, "на іншій гілці". Тож React може зачекати, перш ніж оновити DOM, щоб завантажувати більше контенту. У паралельному режимі ми можемо сказати React продовжувати показувати старий екран, повністю інтерактивний, із вбудованим індикатором завантаження. І коли новий екран буде готовий, React може перевести нас до нього. -We've said before that Concurrent Mode is like React working "on a branch". Branches are useful not only for short-term fixes, but also for long-running features. Sometimes you might work on a feature, but it could take weeks before it's in a "good enough state" to merge into master. This side of our version control metaphor applies to rendering too. -Imagine we're navigating between two screens in an app. Sometimes, we might not have enough code and data loaded to show a "good enough" loading state to the user on the new screen. Transitioning to an empty screen or a large spinner can be a jarring experience. However, it's also common that the necessary code and data doesn't take too long to fetch. **Wouldn't it be nicer if React could stay on the old screen for a little longer, and "skip" the "bad loading state" before showing the new screen?** +### Паралельність {#concurrency} -While this is possible today, it can be difficult to orchestrate. In Concurrent Mode, this feature is built-in. React starts preparing the new screen in memory first — or, as our metaphor goes, "on a different branch". So React can wait before updating the DOM so that more content can load. In Concurrent Mode, we can tell React to keep showing the old screen, fully interactive, with an inline loading indicator. And when the new screen is ready, React can take us to it. +Давайте резюмуємо два приклади, наведені вище, і подивимося, як паралельний режим об'єднує їх: **У паралельнjve режимі React може працювати над кількома оновленнями стану *паралельно*** - так само, як гілки дозволяють різним членам команди працювати самостійно: -### Concurrency {#concurrency} +* Для CPU-пов'язаних оновлень (наприклад, створення вузлів DOM та запуску компонентного коду) паралельність означає, що більш термінове оновлення може «перервати» рендеринг, що вже розпочався. -Let's recap the two examples above and see how Concurrent Mode unifies them. **In Concurrent Mode, React can work on several state updates *concurrently*** — just like branches let different team members work independently: +* Для IO-пов'язаних оновлень (таких як отримання кода або даних з мережі), паралельність означає, що React може почати візуалізацію в пам'яті ще до того, як всі дані надійдуть, і пропустити показ порожніх станів завантаження. -* For CPU-bound updates (such as creating DOM nodes and running component code), concurrency means that a more urgent update can "interrupt" rendering that has already started. -* For IO-bound updates (such as fetching code or data from the network), concurrency means that React can start rendering in memory even before all the data arrives, and skip showing jarring empty loading states. +Важливо, те, що ви *використовуєте* React так само. Поняття, такі як компоненти, реквізити та стан, принципово працюють однаково. Коли ви хочете оновити екран, ви встановлюєте стан. -Importantly, the way you *use* React is the same. Concepts like components, props, and state fundamentally work the same way. When you want to update the screen, you set the state. +React використовує евристику, щоб вирішити, наскільки "терміновим" є оновлення, і дозволяє вам налаштувати його за допомогою декількох рядків коду, щоб ви могли досягти бажаного досвіду користувача для кожної взаємодії. -React uses a heuristic to decide how "urgent" an update is, and lets you adjust it with a few lines of code so that you can achieve the desired user experience for every interaction. +## Введення досліджень у продакшн {#putting-research-into-production} -## Putting Research into Production {#putting-research-into-production} -There is a common theme around Concurrent Mode features. **Its mission is to help integrate the findings from the Human-Computer Interaction research into real UIs.** +Існує загальна тема навколо функцій паралельного режиму. **Його місія полягає в тому, щоб допомогти інтегрувати результати від дослідження взаємодії людини і комп'ютера в реальному UIs.** -For example, research shows that displaying too many intermediate loading states when transitioning between screens makes a transition feel *slower*. This is why Concurrent Mode shows new loading states on a fixed "schedule" to avoid jarring and too frequent updates. +Наприклад, дослідження показують, що відображення занадто багатьох станів проміжного завантаження при переході між екранами робить відчуття перехіду *повільніше*. Ось чому паралельний режим показує нові стани завантаження за фіксованим "графіком", щоб уникнути нестабільності та занадто частого оновлення. -Similarly, we know from research that interactions like hover and text input need to be handled within a very short period of time, while clicks and page transitions can wait a little longer without feeling laggy. The different "priorities" that Concurrent Mode uses internally roughly correspond to the interaction categories in the human perception research. +Аналогічно, з досліджень ми знаємо, що з такими взаємодіями, як наведення курсора та введення тексту, потрібно оброблятись за дуже короткий проміжок часу, тоді як кліки та переходи сторінок можуть зачекати трохи довше, не відчуваючи лага. Різні "пріоритети", які використовує паралельний режим внутрішньо, приблизно відповідають категоріям взаємодії в дослідженні людського сприйняття. -Teams with a strong focus on user experience sometimes solve similar problems with one-off solutions. However, those solutions rarely survive for a long time, as they're hard to maintain. With Concurrent Mode, our goal is to bake the UI research findings into the abstraction itself, and provide idiomatic ways to use them. As a UI library, React is well-positioned to do that. +Команди з сильним фокусом на досвіді користувачів іноді вирішують подібні проблеми одноразовими рішеннями. Однак ці рішення рідко виживають довгий час, оскільки їх важко підтримувати. У паралельному режимі наша мета полягає в тому, щоб визначити результати досліджень інтерфейсу в самій абстракції та надати ідіоматичні способи їх використання. Як UI бібліотека, React чудово підходить для цього. -## Next Steps {#next-steps} +## Наступні кроки {#next-steps} -Now you know what Concurrent Mode is all about! +Тепер ви знаєте, що таке паралельний режим! -On the next pages, you'll learn more details about specific topics: +На наступних сторінках ви дізнаєтесь більше деталей щодо конкретних тем: * [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. * [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. diff --git a/content/docs/nav.yml b/content/docs/nav.yml index cf8000724..64cb74abe 100644 --- a/content/docs/nav.yml +++ b/content/docs/nav.yml @@ -137,7 +137,7 @@ isOrdered: true items: - id: concurrent-mode-intro - title: Introducing Concurrent Mode + title: Знайомство з паралельним режимом - id: concurrent-mode-suspense title: Suspense for Data Fetching - id: concurrent-mode-patterns From e68ab6e4f6c1c74f3e10845f1d15be5249c4f72f Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Sat, 11 Jan 2020 17:54:36 +0200 Subject: [PATCH 03/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Sergey DIniovskiy --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 5d741f2a1..05689eb09 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -16,7 +16,7 @@ next: concurrent-mode-suspense.html >Увага: > ->На сторінці описані **експериментальні функції, [яких ще немає](/docs/concurrent-mode-adoption.html) в стабільній версії**. Не використовуйте експериментальні збірки React в продакшн додатках. Ці функції можуть значно змінитися без попередження перед тим, як потрапити в React. +>На сторінці описані **експериментальні функції, [яких ще немає](/docs/concurrent-mode-adoption.html) в стабільній версії**. Не використовуйте експериментальні збірки React в продакшн додатках. Ці функції можуть суттєво змінитися та без попередження потрапити в React. > >Ця документація орієнтована на першопрохідців та зацікавлених користувачів. **Якщо ви новачок в React, не турбуйтеся про ці функції**, не потрібно вивчати їх прямо зараз. From 60d595abeb203adbf06bf70f68813fb460c08e3f Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Sat, 11 Jan 2020 18:04:10 +0200 Subject: [PATCH 04/17] Apply suggestions from code review Co-Authored-By: Sergey DIniovskiy --- content/docs/concurrent-mode-intro.md | 40 +++++++++++++-------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 05689eb09..cbdba34ad 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -18,10 +18,10 @@ next: concurrent-mode-suspense.html > >На сторінці описані **експериментальні функції, [яких ще немає](/docs/concurrent-mode-adoption.html) в стабільній версії**. Не використовуйте експериментальні збірки React в продакшн додатках. Ці функції можуть суттєво змінитися та без попередження потрапити в React. > ->Ця документація орієнтована на першопрохідців та зацікавлених користувачів. **Якщо ви новачок в React, не турбуйтеся про ці функції**, не потрібно вивчати їх прямо зараз. +>Ця документація орієнтована на першопрохідців та зацікавлених користувачів. **Якщо ви новачок в React, не турбуйтеся про ці функції**, немає необхідності вивчати їх прямо зараз. -На цій сторінці подано теоретичний огляд "Паралельного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** +На цій сторінці представлений теоретичний огляд "Паралельного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** * [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. * [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. @@ -36,45 +36,45 @@ next: concurrent-mode-suspense.html ## Блокування проти переривання рендерингу {#blocking-vs-interruptible-rendering} -**Щоб пояснити паралельний режим, ми будемо використовувати керування версіями як метафору.** -Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git і працюєте на гілках. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. +**Щоб пояснити паралельний режим, ми будемо використовувати контроль версій як метафору.** +Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git і працюєте з гілками. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. -До того, як існував контроль версій, робочий процес розвитку був дуже різним. Там не було поняття гілок. Якщо ви хотіли відредагувати деякі файли, вам доводилося сказати всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з цією людиною - вас вони буквально *заблокували*. +До того, як створили контроль версій, робочий процес девелопменту дуже відрізнявся. Там не було поняття гілок. Якщо ви хотіли відредагувати якісь файли, вам доводилося говорити всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з іншою людиною - ви були буквально *заблокувані*. -Це ілюструє, як типово сьогодні працюють UI бібліотеки включаючи React. Як тільки вони починають рендерить оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". +Це ілюструє, як типово сьогодні працюють UI бібліотеки включаючи React. Як тільки вони починають рендерити оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". -У Паралельному режимі рендеринг не блокується. Він переривається. Це покращує зручність в користуванні. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [главах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. +У Паралельному режимі рендеринг не блокується. Він переривається. Це робить користування додатком зручнішим. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [главах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. ### Переривання рендерингу -Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він затиняїться при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або "веб-переглядача, що виконує макет". Однак * коли * і * як * ми виконуємо цю роботу, грає велику роль. +Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він затиняїться при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або будування макета браузером. Однак *коли* і *як* ми виконуємо цю роботу, грає велику роль. -Поширений спосіб обійти запинання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б "throttle" введення та оновити список з певною максимальною частотою. Але потім на пристроях з меншою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг створюють неоптимальну зручність для користувача. +Поширений спосіб обійти запинання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б використати "throttle" введення та оновлювати список з певною максимальною частотою. Але потім на пристроях з меньшою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг погіршують зручність користування вашим додатком. -Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіші. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, легко не виправити. +Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, це легко не виправити. -**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг переривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру намалювати оновлення на вхід, а потім продовжити надання оновленого списку *у пам'яті*. Коли рендеринг закінчен, React оновлює DOM, а зміни відображаються на екрані. +**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг переривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчен, React оновлює DOM, а зміни відображаються на екрані. -Концептуально ви можете подумати про це як React, що готує кожне оновлення "на гілці". Так само, як ви можете відмовитися від роботи у гілках або перемикатися між ними, React у паралельному режимі може перервати постійне оновлення, щоб зробити щось важливіше, а потім повернутися до того, що він робив раніше. Ця методика може також нагадувати вам про [подвійне буферування](https://wiki.osdev.org/Double_Buffering) у відеоіграх. +Концептуально ви можете думати про це так, що React готує кожне оновлення "на гілці". Так само, як ви можете відмовитися від роботи у гілках або перемикатися між ними, React у паралельному режимі може перервати постійне оновлення, щоб зробити щось важливіше, а потім повернутися до того, що він робив раніше. Ця методика може також нагадувати вам про [подвійну буферизацію](https://wiki.osdev.org/Double_Buffering) у відеоіграх. -Методи паралельного режиму зменшують потребу в дебаунсингу та тротлингу в інтерфейсі користувача. Оскільки рендеринг переривається, React не потрібно штучно *затримувати* рендеринг, щоб уникнути затинання. Він може почати рендеринг відразу, але перервати цю роботу, коли це необхідно, щоб додаток завжди був в змозі реагувати на запити. +Паралельний режим зменьшує потребу в дебаунсингу та тротлінгу в інтерфейсі користувача. Оскільки рендеринг переривається, React не потрібно штучно *затримувати* рендеринг, щоб уникнути затинання. Він може почати рендеринг відразу, але перервати цю роботу, коли це необхідно, щоб додаток завжди був в змозі реагувати на запити. ### Навмисні послідовності завантаження {#intentional-loading-sequences} -Ми вже говорили, що паралельний режим - це як React працює "на гілці". Гілки корисні не тільки для короткочасних виправлень, але і для довготривалих змін. Іноді ви можете працювати над функцією, але може пройти кілька тижнів, перш ніж вона виявиться в «досить хорошому стані», щоб злитися з майстром. Ця сторона нашої метафори управління версіями стосується і рендерингу. +Ми вже говорили, що паралельний режим у React - це ніби працювання "на гілці". Гілки корисні не тільки для короткочасних виправлень, але і для довготривалих змін. Іноді ви можете працювати над функцією, але може пройти кілька тижнів, перш ніж вона виявиться в «досить хорошому стані», щоб злитися з master. Цей аспект метафори про управління версіями стосується і рендерингу. -Уявіть, що ми пересуваємося між двома екранами в додатку. Іноді у нас може не вистачати завантаженого коду і даних, щоб показати користувачеві «досить добре» стан завантаження на новому екрані. Перехід на порожній екран або на великий спінер може бути неприємним досвідом. Однак також звичайно, що необхідний код та дані не потребують занадто багато часу для отримання. **Чи не було б приємніше, якби React міг залишитися на старому екрані трохи довше і "пропустити" "поганий стан завантаження" перед тим, як показати новий екран?** +Уявіть, що ми пересуваємося між двома екранами в додатку. Іноді у нас може не вистачати завантаженого коду і даних, щоб показати користувачеві «досить добрий» стан завантаження на новому екрані. Перехід на порожній екран або на великий спінер може бути неприємним досвідом. Однак, те, що необхідний код та дані не потребують занадто багато часу для отримання, це також поширена практика. **Чи не було б приємніше, якби React міг залишитися на старому екрані трохи довше і "пропустити" "поганий стан завантаження" перед тим, як показати новий екран?** While this is possible today, it can be difficult to orchestrate. In Concurrent Mode, this feature is built-in. React starts preparing the new screen in memory first — or, as our metaphor goes, "on a different branch". So React can wait before updating the DOM so that more content can load. In Concurrent Mode, we can tell React to keep showing the old screen, fully interactive, with an inline loading indicator. And when the new screen is ready, React can take us to it. -Незважаючи на те, що це можливо сьогодні, це може бути важко організувати. У паралельному режимі ця функція вбудована. React спочатку починає готувати новий екран в пам'яті - або, як йдеться у нашій метафорі, "на іншій гілці". Тож React може зачекати, перш ніж оновити DOM, щоб завантажувати більше контенту. У паралельному режимі ми можемо сказати React продовжувати показувати старий екран, повністю інтерактивний, із вбудованим індикатором завантаження. І коли новий екран буде готовий, React може перевести нас до нього. +Незважаючи на те, що це можно робити і сьогодні, це може бути важко організувати. У паралельному режимі ця функція вбудована. React спочатку починає готувати новий екран в пам'яті - або, як йдеться у нашій метафорі, "на іншій гілці". Тож React може зачекати, перш ніж оновити DOM, щоб завантажувати більше контенту. У паралельному режимі ми можемо сказати React продовжувати показувати старий екран, повністю інтерактивний, із вбудованим індикатором завантаження. І коли новий екран буде готовий, React може перевести нас до нього. ### Паралельність {#concurrency} -Давайте резюмуємо два приклади, наведені вище, і подивимося, як паралельний режим об'єднує їх: **У паралельнjve режимі React може працювати над кількома оновленнями стану *паралельно*** - так само, як гілки дозволяють різним членам команди працювати самостійно: +Давайте резюмуємо два приклади, наведені вище, і подивимося, як паралельний режим об'єднує їх: **У паралельному режимі React може працювати над кількома оновленнями стану *паралельно*** - так само, як гілки дозволяють різним членам команди працювати самостійно: * Для CPU-пов'язаних оновлень (наприклад, створення вузлів DOM та запуску компонентного коду) паралельність означає, що більш термінове оновлення може «перервати» рендеринг, що вже розпочався. @@ -84,14 +84,14 @@ While this is possible today, it can be difficult to orchestrate. In Concurrent React використовує евристику, щоб вирішити, наскільки "терміновим" є оновлення, і дозволяє вам налаштувати його за допомогою декількох рядків коду, щоб ви могли досягти бажаного досвіду користувача для кожної взаємодії. -## Введення досліджень у продакшн {#putting-research-into-production} +## Додавання дослідженя до продакшену {#putting-research-into-production} -Існує загальна тема навколо функцій паралельного режиму. **Його місія полягає в тому, щоб допомогти інтегрувати результати від дослідження взаємодії людини і комп'ютера в реальному UIs.** +Існує загальна тема щодо можливості паралельного режиму. **Його місія полягає в тому, щоб допомогти інтегрувати результати від дослідження взаємодії людини і комп'ютера в реальному UIs.** Наприклад, дослідження показують, що відображення занадто багатьох станів проміжного завантаження при переході між екранами робить відчуття перехіду *повільніше*. Ось чому паралельний режим показує нові стани завантаження за фіксованим "графіком", щоб уникнути нестабільності та занадто частого оновлення. -Аналогічно, з досліджень ми знаємо, що з такими взаємодіями, як наведення курсора та введення тексту, потрібно оброблятись за дуже короткий проміжок часу, тоді як кліки та переходи сторінок можуть зачекати трохи довше, не відчуваючи лага. Різні "пріоритети", які використовує паралельний режим внутрішньо, приблизно відповідають категоріям взаємодії в дослідженні людського сприйняття. +Аналогічно, з досліджень ми знаємо, що з такі взаємодії, як наведення курсора та введення тексту, потрібно обробляти за дуже короткий проміжок часу, тоді як кліки та переходи сторінок можуть зачекати трохи довше, не відчуваючи лага. Різні "пріоритети", які використовує паралельний режим, приблизно відповідають категоріям взаємодії в дослідженні людського сприйняття. Команди з сильним фокусом на досвіді користувачів іноді вирішують подібні проблеми одноразовими рішеннями. Однак ці рішення рідко виживають довгий час, оскільки їх важко підтримувати. У паралельному режимі наша мета полягає в тому, щоб визначити результати досліджень інтерфейсу в самій абстракції та надати ідіоматичні способи їх використання. Як UI бібліотека, React чудово підходить для цього. From 4d0901901fa7bdddad0d6bc6864b1303b1c26bf9 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Sat, 11 Jan 2020 18:25:27 +0200 Subject: [PATCH 05/17] minor fix --- content/docs/concurrent-mode-intro.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index cbdba34ad..235d9f2cc 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -31,6 +31,7 @@ next: concurrent-mode-suspense.html ## Що таке паралельний режим? {#what-is-concurrent-mode} Паралельний режим - це набір нових функцій які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. + Ці особливості досі експериментальні і можуть змінюватися. Вони ще не є частиною стабільної версії React, але ви можете спробувати їх в експериментальній збірці. @@ -67,8 +68,6 @@ next: concurrent-mode-suspense.html Уявіть, що ми пересуваємося між двома екранами в додатку. Іноді у нас може не вистачати завантаженого коду і даних, щоб показати користувачеві «досить добрий» стан завантаження на новому екрані. Перехід на порожній екран або на великий спінер може бути неприємним досвідом. Однак, те, що необхідний код та дані не потребують занадто багато часу для отримання, це також поширена практика. **Чи не було б приємніше, якби React міг залишитися на старому екрані трохи довше і "пропустити" "поганий стан завантаження" перед тим, як показати новий екран?** -While this is possible today, it can be difficult to orchestrate. In Concurrent Mode, this feature is built-in. React starts preparing the new screen in memory first — or, as our metaphor goes, "on a different branch". So React can wait before updating the DOM so that more content can load. In Concurrent Mode, we can tell React to keep showing the old screen, fully interactive, with an inline loading indicator. And when the new screen is ready, React can take us to it. - Незважаючи на те, що це можно робити і сьогодні, це може бути важко організувати. У паралельному режимі ця функція вбудована. React спочатку починає готувати новий екран в пам'яті - або, як йдеться у нашій метафорі, "на іншій гілці". Тож React може зачекати, перш ніж оновити DOM, щоб завантажувати більше контенту. У паралельному режимі ми можемо сказати React продовжувати показувати старий екран, повністю інтерактивний, із вбудованим індикатором завантаження. І коли новий екран буде готовий, React може перевести нас до нього. @@ -77,7 +76,6 @@ While this is possible today, it can be difficult to orchestrate. In Concurrent Давайте резюмуємо два приклади, наведені вище, і подивимося, як паралельний режим об'єднує їх: **У паралельному режимі React може працювати над кількома оновленнями стану *паралельно*** - так само, як гілки дозволяють різним членам команди працювати самостійно: * Для CPU-пов'язаних оновлень (наприклад, створення вузлів DOM та запуску компонентного коду) паралельність означає, що більш термінове оновлення може «перервати» рендеринг, що вже розпочався. - * Для IO-пов'язаних оновлень (таких як отримання кода або даних з мережі), паралельність означає, що React може почати візуалізацію в пам'яті ще до того, як всі дані надійдуть, і пропустити показ порожніх станів завантаження. Важливо, те, що ви *використовуєте* React так само. Поняття, такі як компоненти, реквізити та стан, принципово працюють однаково. Коли ви хочете оновити екран, ви встановлюєте стан. From 7363c2d9ebc5cd86b8fefdc8c4af70dfccbe47cf Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 17 Jan 2020 18:27:56 +0200 Subject: [PATCH 06/17] fix --- content/docs/concurrent-mode-intro.md | 14 +++++++------- content/docs/nav.yml | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 235d9f2cc..991ee306a 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -30,19 +30,19 @@ next: concurrent-mode-suspense.html ## Що таке паралельний режим? {#what-is-concurrent-mode} -Паралельний режим - це набір нових функцій які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. +Паралельний режим - набір нових функцій, які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. -Ці особливості досі експериментальні і можуть змінюватися. Вони ще не є частиною стабільної версії React, але ви можете спробувати їх в експериментальній збірці. +Ці особливості досі експериментальні й можуть змінюватися. Вони ще не є частиною стабільної версії React, але ви можете спробувати їх в експериментальній збірці. ## Блокування проти переривання рендерингу {#blocking-vs-interruptible-rendering} **Щоб пояснити паралельний режим, ми будемо використовувати контроль версій як метафору.** -Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git і працюєте з гілками. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. +Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git й працюєте з гілками. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. -До того, як створили контроль версій, робочий процес девелопменту дуже відрізнявся. Там не було поняття гілок. Якщо ви хотіли відредагувати якісь файли, вам доводилося говорити всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з іншою людиною - ви були буквально *заблокувані*. +До того, як створили контроль версій, робочий процес девелопменту дуже відрізнявся. Там не було поняття гілок. Якщо ви хотіли відредагувати якісь файли, вам доводилося говорити всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з іншою людиною - ви були буквально *заблоковані*. -Це ілюструє, як типово сьогодні працюють UI бібліотеки включаючи React. Як тільки вони починають рендерити оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". +Це ілюструє як типово сьогодні працюють UI бібліотеки, включаючи React. Як тільки вони починають рендерити оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". У Паралельному режимі рендеринг не блокується. Він переривається. Це робить користування додатком зручнішим. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [главах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. @@ -51,12 +51,12 @@ next: concurrent-mode-suspense.html Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він затиняїться при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або будування макета браузером. Однак *коли* і *як* ми виконуємо цю роботу, грає велику роль. -Поширений спосіб обійти запинання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б використати "throttle" введення та оновлювати список з певною максимальною частотою. Але потім на пристроях з меньшою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг погіршують зручність користування вашим додатком. +Поширений спосіб обійти запинання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак, може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б використати "throttle" введення та оновлювати список з певною максимальною частотою. Але потім на пристроях з меньшою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг погіршують зручність користування вашим додатком. Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, це легко не виправити. -**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг переривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчен, React оновлює DOM, а зміни відображаються на екрані. +**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг преривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчен, React оновлює DOM, а зміни відображаються на екрані. Концептуально ви можете думати про це так, що React готує кожне оновлення "на гілці". Так само, як ви можете відмовитися від роботи у гілках або перемикатися між ними, React у паралельному режимі може перервати постійне оновлення, щоб зробити щось важливіше, а потім повернутися до того, що він робив раніше. Ця методика може також нагадувати вам про [подвійну буферизацію](https://wiki.osdev.org/Double_Buffering) у відеоіграх. diff --git a/content/docs/nav.yml b/content/docs/nav.yml index 64cb74abe..0466db5b5 100644 --- a/content/docs/nav.yml +++ b/content/docs/nav.yml @@ -133,7 +133,7 @@ title: Рецепти тестування - id: testing-environments title: Середовища тестування -- title: Concurrent Mode (Experimental) +- title: Паралельний режим (Експериментальний) isOrdered: true items: - id: concurrent-mode-intro From 81512acdefb2a13b0324e3e84f52e7dc45103af1 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Mon, 10 Feb 2020 17:50:47 +0200 Subject: [PATCH 07/17] minor fix --- content/docs/concurrent-mode-intro.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 991ee306a..fa9c6c5c3 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -30,7 +30,7 @@ next: concurrent-mode-suspense.html ## Що таке паралельний режим? {#what-is-concurrent-mode} -Паралельний режим - набір нових функцій, які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. +Паралельний режим — набір нових функцій, які допомагають React додаткам залишатися чутливими та плавно підлаштовується під можливості пристрою користувача та швидкість мережі. Ці особливості досі експериментальні й можуть змінюватися. Вони ще не є частиною стабільної версії React, але ви можете спробувати їх в експериментальній збірці. @@ -44,14 +44,14 @@ next: concurrent-mode-suspense.html Це ілюструє як типово сьогодні працюють UI бібліотеки, включаючи React. Як тільки вони починають рендерити оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". -У Паралельному режимі рендеринг не блокується. Він переривається. Це робить користування додатком зручнішим. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [главах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. +У Паралельному режимі рендеринг не блокується. Він переривається. Це робить користування додатком зручнішим. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [розділах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. ### Переривання рендерингу Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він затиняїться при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або будування макета браузером. Однак *коли* і *як* ми виконуємо цю роботу, грає велику роль. -Поширений спосіб обійти запинання - "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак, може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б використати "throttle" введення та оновлювати список з певною максимальною частотою. Але потім на пристроях з меньшою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг погіршують зручність користування вашим додатком. +Поширений спосіб обійти запинання — "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак, може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б використати "throttle" введення та оновлювати список з певною максимальною частотою. Але потім на пристроях з меньшою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг погіршують зручність користування вашим додатком. Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, це легко не виправити. @@ -64,7 +64,7 @@ next: concurrent-mode-suspense.html ### Навмисні послідовності завантаження {#intentional-loading-sequences} -Ми вже говорили, що паралельний режим у React - це ніби працювання "на гілці". Гілки корисні не тільки для короткочасних виправлень, але і для довготривалих змін. Іноді ви можете працювати над функцією, але може пройти кілька тижнів, перш ніж вона виявиться в «досить хорошому стані», щоб злитися з master. Цей аспект метафори про управління версіями стосується і рендерингу. +Ми вже говорили, що паралельний режим у React — це ніби працювання "на гілці". Гілки корисні не тільки для короткочасних виправлень, але і для довготривалих змін. Іноді ви можете працювати над функцією, але може пройти кілька тижнів, перш ніж вона виявиться в «досить хорошому стані», щоб злитися з master. Цей аспект метафори про управління версіями стосується і рендерингу. Уявіть, що ми пересуваємося між двома екранами в додатку. Іноді у нас може не вистачати завантаженого коду і даних, щоб показати користувачеві «досить добрий» стан завантаження на новому екрані. Перехід на порожній екран або на великий спінер може бути неприємним досвідом. Однак, те, що необхідний код та дані не потребують занадто багато часу для отримання, це також поширена практика. **Чи не було б приємніше, якби React міг залишитися на старому екрані трохи довше і "пропустити" "поганий стан завантаження" перед тим, як показати новий екран?** From 56e8dc15e6ea03b1a5310be7645f4a4ed7f641c1 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Tue, 3 Mar 2020 15:22:09 +0200 Subject: [PATCH 08/17] replace text --- content/docs/concurrent-mode-intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index fa9c6c5c3..44fcf5cd0 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -53,10 +53,10 @@ next: concurrent-mode-suspense.html Поширений спосіб обійти запинання — "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак, може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б використати "throttle" введення та оновлювати список з певною максимальною частотою. Але потім на пристроях з меньшою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг погіршують зручність користування вашим додатком. -Причина затинання проста: після початку рендеринга, він не може бути перерван. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, це легко не виправити. +Причина затинання проста: після початку рендеринга, він не може бути перерваний. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, немає простого способу виправити це. -**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг преривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчен, React оновлює DOM, а зміни відображаються на екрані. +**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг преривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчений, React оновлює DOM, а зміни відображаються на екрані. Концептуально ви можете думати про це так, що React готує кожне оновлення "на гілці". Так само, як ви можете відмовитися від роботи у гілках або перемикатися між ними, React у паралельному режимі може перервати постійне оновлення, щоб зробити щось важливіше, а потім повернутися до того, що він робив раніше. Ця методика може також нагадувати вам про [подвійну буферизацію](https://wiki.osdev.org/Double_Buffering) у відеоіграх. From 534ad3f627d85e1235362b29978df76d8161d2ba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80=20?= =?UTF-8?q?=D0=A2=D0=B2=D0=BE=D1=80=D0=BE=D0=B3=D0=BE=D0=B2?= Date: Fri, 24 Apr 2020 12:49:15 +0300 Subject: [PATCH 09/17] fix commet, translate text --- content/docs/concurrent-mode-intro.md | 49 ++++++++++++--------------- 1 file changed, 22 insertions(+), 27 deletions(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 44fcf5cd0..34ec44cdd 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -19,14 +19,15 @@ next: concurrent-mode-suspense.html >На сторінці описані **експериментальні функції, [яких ще немає](/docs/concurrent-mode-adoption.html) в стабільній версії**. Не використовуйте експериментальні збірки React в продакшн додатках. Ці функції можуть суттєво змінитися та без попередження потрапити в React. > >Ця документація орієнтована на першопрохідців та зацікавлених користувачів. **Якщо ви новачок в React, не турбуйтеся про ці функції**, немає необхідності вивчати їх прямо зараз. + На цій сторінці представлений теоретичний огляд "Паралельного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** -* [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. -* [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. -* [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project. -* [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds. +* [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних в React-компонентах. +* [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, які стали можливими завдяки паралельному режиму та затримці. +* [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим в своєму проекті. +* [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. ## Що таке паралельний режим? {#what-is-concurrent-mode} @@ -34,27 +35,23 @@ next: concurrent-mode-suspense.html Ці особливості досі експериментальні й можуть змінюватися. Вони ще не є частиною стабільної версії React, але ви можете спробувати їх в експериментальній збірці. - ## Блокування проти переривання рендерингу {#blocking-vs-interruptible-rendering} -**Щоб пояснити паралельний режим, ми будемо використовувати контроль версій як метафору.** -Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git й працюєте з гілками. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. - -До того, як створили контроль версій, робочий процес девелопменту дуже відрізнявся. Там не було поняття гілок. Якщо ви хотіли відредагувати якісь файли, вам доводилося говорити всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з іншою людиною - ви були буквально *заблоковані*. +**Щоб пояснити паралельний режим, ми будемо використовувати контроль версій як метафору.** Якщо ви працюєте в команді, ви, ймовірно, використовуєте систему контролю версій на зразок Git й працюєте з гілками. Коли гілка готова, ви можете злити свою роботу в master, щоб інші люди могли її витягнути. -Це ілюструє як типово сьогодні працюють UI бібліотеки, включаючи React. Як тільки вони починають рендерити оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". +До того, як створили контроль версій, робочий процес розробки дуже відрізнявся. Там не було поняття гілок. Якщо ви хотіли відредагувати якісь файли, вам доводилося говорити всім не торкатися цих файлів, поки ви не закінчите роботу. Ви навіть не могли почати працювати над ними одночасно з іншою людиною - ви були буквально *заблоковані*. -У Паралельному режимі рендеринг не блокується. Він переривається. Це робить користування додатком зручнішим. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [розділах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. +Це ілюструє як типово сьогодні працюють UI-бібліотеки, включаючи React. Як тільки вони починають рендерити оновлення, включаючи створення нових вузлів DOM та запуск коду всередині компонентів, вони не можуть перервати цю роботу. Цей підхід ми будемо називати "блокуванням рендеренгу". +У паралельному режимі рендеринг не блокується. Він переривається. Це робить користування додатком зручнішим. Він також розблоковує нові функції, які раніше були неможливі. Перш ніж ми розглянемо конкретні приклади в [наступних](/docs/concurrent-mode-suspense.html) [розділах](/docs/concurrent-mode-patterns.html), ми зробимо загальний огляд нових функцій. ### Переривання рендерингу Розглянемо список продуктів, що фільтруються. Ви коли-небудь фільтрували список та відчували, що він затиняїться при кожному натисканні клавіш? Деяка робота над оновленням списку продуктів може бути неминучою, наприклад, створення нових вузлів DOM або будування макета браузером. Однак *коли* і *як* ми виконуємо цю роботу, грає велику роль. -Поширений спосіб обійти запинання — "debounce" введення. Під час дебаунсингу ми лише оновлюємо список *після* того як користувач перестає друкувати. Однак, може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б використати "throttle" введення та оновлювати список з певною максимальною частотою. Але потім на пристроях з меньшою потужністю ми все-таки почнемо затинатися. Як дебаунсинг, так і тротлинг погіршують зручність користування вашим додатком. - -Причина затинання проста: після початку рендеринга, він не може бути перерваний. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI бібліотека (наприклад, React) в порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І, найчастіше, немає простого способу виправити це. +Поширений спосіб обійти запинання — не обробляти вхідні дані при кожній зміні (debounce). У такому разі ми оновлюємо список лише *після* того, як користувач перестає друкувати. Однак, може бути неприємно, що інтерфейс користувача не оновлюється під час введення тексту. Як альтернатива, ми могли б "гальмувати" (throttle) введення даних та оновлювати список з певною максимальною частотою. Але потім на пристроях з меншою потужністю ми все-таки почнемо затинатися. Обидва підходи створюють неоптимальний UI. +Причина затинання проста: після початку рендеринга, він не може бути перерваний. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI-бібліотека (наприклад, React) у порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І найчастіше це не так просто виправити. **Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг преривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчений, React оновлює DOM, а зміни відображаються на екрані. @@ -66,32 +63,30 @@ next: concurrent-mode-suspense.html Ми вже говорили, що паралельний режим у React — це ніби працювання "на гілці". Гілки корисні не тільки для короткочасних виправлень, але і для довготривалих змін. Іноді ви можете працювати над функцією, але може пройти кілька тижнів, перш ніж вона виявиться в «досить хорошому стані», щоб злитися з master. Цей аспект метафори про управління версіями стосується і рендерингу. -Уявіть, що ми пересуваємося між двома екранами в додатку. Іноді у нас може не вистачати завантаженого коду і даних, щоб показати користувачеві «досить добрий» стан завантаження на новому екрані. Перехід на порожній екран або на великий спінер може бути неприємним досвідом. Однак, те, що необхідний код та дані не потребують занадто багато часу для отримання, це також поширена практика. **Чи не було б приємніше, якби React міг залишитися на старому екрані трохи довше і "пропустити" "поганий стан завантаження" перед тим, як показати новий екран?** - -Незважаючи на те, що це можно робити і сьогодні, це може бути важко організувати. У паралельному режимі ця функція вбудована. React спочатку починає готувати новий екран в пам'яті - або, як йдеться у нашій метафорі, "на іншій гілці". Тож React може зачекати, перш ніж оновити DOM, щоб завантажувати більше контенту. У паралельному режимі ми можемо сказати React продовжувати показувати старий екран, повністю інтерактивний, із вбудованим індикатором завантаження. І коли новий екран буде готовий, React може перевести нас до нього. +Уявіть, що ми пересуваємося між двома екранами в додатку. Іноді у нас може не вистачати завантаженого коду і даних, щоб показати користувачеві «досить добрий» стан завантаження на новому екрані. Перехід на порожній екран або на великий спінер може бути неприємним досвідом. Проте найчастіше, щоб отримати необхідний код та дані непотрібно занадто багато часу. **Чи не було б приємніше, якби React міг залишитися на старому екрані трохи довше і "пропустити" "поганий стан завантаження" перед тим, як показати новий екран?** +Незважаючи на те, що це можно робити і сьогодні, це важко організувати. У паралельному режимі ця функція вбудована. React спочатку починає готувати новий екран в пам'яті - або, як йдеться у нашій метафорі, "на іншій гілці". Тож React може зачекати, перш ніж оновити DOM, щоб завантажувати більше контенту. У паралельному режимі ми можемо сказати React продовжувати показувати старий екран, повністю інтерактивний, із вбудованим індикатором завантаження. І коли новий екран буде готовий, React може перевести нас до нього. ### Паралельність {#concurrency} Давайте резюмуємо два приклади, наведені вище, і подивимося, як паралельний режим об'єднує їх: **У паралельному режимі React може працювати над кількома оновленнями стану *паралельно*** - так само, як гілки дозволяють різним членам команди працювати самостійно: -* Для CPU-пов'язаних оновлень (наприклад, створення вузлів DOM та запуску компонентного коду) паралельність означає, що більш термінове оновлення може «перервати» рендеринг, що вже розпочався. -* Для IO-пов'язаних оновлень (таких як отримання кода або даних з мережі), паралельність означає, що React може почати візуалізацію в пам'яті ще до того, як всі дані надійдуть, і пропустити показ порожніх станів завантаження. +* Для оновлень пов'язаних до ЦП (наприклад, створення вузлів DOM та запуску коду компонента) паралельність означає, що більш термінове оновлення може «перервати» рендеринг, що вже розпочався. +* Для оновлень пов'язаних до вводу-виводу (таких як отримання кода або даних з мережі), паралельність означає, що React може почати візуалізацію в пам'яті ще до того, як всі дані надійдуть, і пропустити показ порожніх станів завантаження. Важливо, те, що ви *використовуєте* React так само. Поняття, такі як компоненти, реквізити та стан, принципово працюють однаково. Коли ви хочете оновити екран, ви встановлюєте стан. React використовує евристику, щоб вирішити, наскільки "терміновим" є оновлення, і дозволяє вам налаштувати його за допомогою декількох рядків коду, щоб ви могли досягти бажаного досвіду користувача для кожної взаємодії. -## Додавання дослідженя до продакшену {#putting-research-into-production} - +## Досвід впровадження у продакшн {#putting-research-into-production} -Існує загальна тема щодо можливості паралельного режиму. **Його місія полягає в тому, щоб допомогти інтегрувати результати від дослідження взаємодії людини і комп'ютера в реальному UIs.** +Існує загальна тема щодо можливості паралельного режиму. **Його місія полягає в тому, щоб допомогти інтегрувати результати від дослідження взаємодії людини і комп'ютера в реальному UI.** Наприклад, дослідження показують, що відображення занадто багатьох станів проміжного завантаження при переході між екранами робить відчуття перехіду *повільніше*. Ось чому паралельний режим показує нові стани завантаження за фіксованим "графіком", щоб уникнути нестабільності та занадто частого оновлення. Аналогічно, з досліджень ми знаємо, що з такі взаємодії, як наведення курсора та введення тексту, потрібно обробляти за дуже короткий проміжок часу, тоді як кліки та переходи сторінок можуть зачекати трохи довше, не відчуваючи лага. Різні "пріоритети", які використовує паралельний режим, приблизно відповідають категоріям взаємодії в дослідженні людського сприйняття. -Команди з сильним фокусом на досвіді користувачів іноді вирішують подібні проблеми одноразовими рішеннями. Однак ці рішення рідко виживають довгий час, оскільки їх важко підтримувати. У паралельному режимі наша мета полягає в тому, щоб визначити результати досліджень інтерфейсу в самій абстракції та надати ідіоматичні способи їх використання. Як UI бібліотека, React чудово підходить для цього. +Команди з сильним фокусом на досвіді користувачів іноді вирішують подібні проблеми одноразовими рішеннями. Однак ці рішення рідко виживають довгий час, оскільки їх важко підтримувати. У паралельному режимі наша мета полягає в тому, щоб визначити результати досліджень інтерфейсу в самій абстракції та надати ідіоматичні способи їх використання. Як UI-бібліотека, React чудово підходить для цього. ## Наступні кроки {#next-steps} @@ -99,7 +94,7 @@ React використовує евристику, щоб вирішити, на На наступних сторінках ви дізнаєтесь більше деталей щодо конкретних тем: -* [Suspense for Data Fetching](/docs/concurrent-mode-suspense.html) describes a new mechanism for fetching data in React components. -* [Concurrent UI Patterns](/docs/concurrent-mode-patterns.html) shows some UI patterns made possible by Concurrent Mode and Suspense. -* [Adopting Concurrent Mode](/docs/concurrent-mode-adoption.html) explains how you can try Concurrent Mode in your project. -* [Concurrent Mode API Reference](/docs/concurrent-mode-reference.html) documents the new APIs available in experimental builds. +* [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних в React-компонентах. +* [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, що стали можливими завдяки паралельному режиму та затримки. +* [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим в своєму проекті. +* [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. From 96f8c14ed0f675ca70532f3ca0ae8e630e7da1d7 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 19:21:02 +0300 Subject: [PATCH 10/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 34ec44cdd..e7c84039f 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -96,5 +96,5 @@ React використовує евристику, щоб вирішити, на * [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних в React-компонентах. * [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, що стали можливими завдяки паралельному режиму та затримки. -* [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим в своєму проекті. +* [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим у своєму проекті. * [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. From 34e1ea5de4928acc1f9f7e3c36a64b8beb3b57e7 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 19:21:13 +0300 Subject: [PATCH 11/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index e7c84039f..e6ad0283a 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -94,7 +94,7 @@ React використовує евристику, щоб вирішити, на На наступних сторінках ви дізнаєтесь більше деталей щодо конкретних тем: -* [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних в React-компонентах. +* [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних у React-компонентах. * [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, що стали можливими завдяки паралельному режиму та затримки. * [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим у своєму проекті. * [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. From 1d788184f57c2bd6d58f004ed2010781c877ba63 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 19:21:38 +0300 Subject: [PATCH 12/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index e6ad0283a..b97c35d24 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -95,6 +95,6 @@ React використовує евристику, щоб вирішити, на На наступних сторінках ви дізнаєтесь більше деталей щодо конкретних тем: * [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних у React-компонентах. -* [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, що стали можливими завдяки паралельному режиму та затримки. +* [Патерни паралельного UI](/docs/concurrent-mode-patterns.html) показує деякі патерни UI, які стали можливими завдяки паралельному режиму та затримці. * [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим у своєму проекті. * [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. From 0c501424de60e2b1e74916eb48cdf5ce0e776572 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 19:21:55 +0300 Subject: [PATCH 13/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index b97c35d24..40a8cc219 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -24,7 +24,7 @@ next: concurrent-mode-suspense.html На цій сторінці представлений теоретичний огляд "Паралельного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** -* [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних в React-компонентах. +* [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних у React-компонентах. * [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, які стали можливими завдяки паралельному режиму та затримці. * [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим в своєму проекті. * [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. From 77d2965564f5f987201dc23e6b0993c653282152 Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 19:22:05 +0300 Subject: [PATCH 14/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 40a8cc219..a89bcc309 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -26,7 +26,7 @@ next: concurrent-mode-suspense.html * [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних у React-компонентах. * [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, які стали можливими завдяки паралельному режиму та затримці. -* [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим в своєму проекті. +* [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим у своєму проекті. * [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. ## Що таке паралельний режим? {#what-is-concurrent-mode} From a5e039d097dfb8c322133e801fc68a88f7704cca Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 19:22:17 +0300 Subject: [PATCH 15/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index a89bcc309..0caddd736 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -25,7 +25,7 @@ next: concurrent-mode-suspense.html На цій сторінці представлений теоретичний огляд "Паралельного Режиму". **Для більш практичного застосування ви можете ознайомитись з наступними розділами:** * [Затримка при запиті даних](/docs/concurrent-mode-suspense.html) описує новий механізм запиту даних у React-компонентах. -* [Паралельний режим UI шаблони](/docs/concurrent-mode-patterns.html) показують деякі UI шаблони, які стали можливими завдяки паралельному режиму та затримці. +* [Патерни паралельного UI](/docs/concurrent-mode-patterns.html) показує деякі патерни UI, які стали можливими завдяки паралельному режиму та затримці. * [Використання паралельного режиму](/docs/concurrent-mode-adoption.html) пояснює, як ви можете спробувати паралельний режим у своєму проекті. * [Довідник API паралельного режиму](/docs/concurrent-mode-reference.html) документує нові API, доступні в експериментальних версіях. From b1fa6197bf337ff6206b9683f0cbe1ff72eccb4e Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 22:27:43 +0300 Subject: [PATCH 16/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index 0caddd736..cdd0444ac 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -53,7 +53,7 @@ next: concurrent-mode-suspense.html Причина затинання проста: після початку рендеринга, він не може бути перерваний. Тому браузер не може оновити введення тексту відразу після натискання клавіши. Незалежно від того, наскільки добре може виглядати UI-бібліотека (наприклад, React) у порівнянні з іншими, якщо він використовує блокування рендерингу, певна кількість роботи у ваших компонентах завжди призведе до затинання. І найчастіше це не так просто виправити. -**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг преривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчений, React оновлює DOM, а зміни відображаються на екрані. +**Паралельний режим усуває це фундаментальне обмеження, роблячи рендеринг переривчастим.** Це означає, що коли користувач натискає іншу клавішу, React-у не потрібно блокувати браузер для оновлення введення тексту. Натомість він може дозволити браузеру відобразити оновлення вводу, а потім продовжити оновлювати список *у пам'яті*. Коли рендеринг закінчений, React оновлює DOM, а зміни відображаються на екрані. Концептуально ви можете думати про це так, що React готує кожне оновлення "на гілці". Так само, як ви можете відмовитися від роботи у гілках або перемикатися між ними, React у паралельному режимі може перервати постійне оновлення, щоб зробити щось важливіше, а потім повернутися до того, що він робив раніше. Ця методика може також нагадувати вам про [подвійну буферизацію](https://wiki.osdev.org/Double_Buffering) у відеоіграх. From 5194bbd9af5cfafff6c6b5705b2cbb11895e7fdc Mon Sep 17 00:00:00 2001 From: HLOkeksandr Date: Fri, 24 Apr 2020 22:27:57 +0300 Subject: [PATCH 17/17] Update content/docs/concurrent-mode-intro.md Co-Authored-By: Volodymyr Klymenko --- content/docs/concurrent-mode-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/concurrent-mode-intro.md b/content/docs/concurrent-mode-intro.md index cdd0444ac..45dbeca7b 100644 --- a/content/docs/concurrent-mode-intro.md +++ b/content/docs/concurrent-mode-intro.md @@ -57,7 +57,7 @@ next: concurrent-mode-suspense.html Концептуально ви можете думати про це так, що React готує кожне оновлення "на гілці". Так само, як ви можете відмовитися від роботи у гілках або перемикатися між ними, React у паралельному режимі може перервати постійне оновлення, щоб зробити щось важливіше, а потім повернутися до того, що він робив раніше. Ця методика може також нагадувати вам про [подвійну буферизацію](https://wiki.osdev.org/Double_Buffering) у відеоіграх. -Паралельний режим зменьшує потребу в дебаунсингу та тротлінгу в інтерфейсі користувача. Оскільки рендеринг переривається, React не потрібно штучно *затримувати* рендеринг, щоб уникнути затинання. Він може почати рендеринг відразу, але перервати цю роботу, коли це необхідно, щоб додаток завжди був в змозі реагувати на запити. +Паралельний режим зменьшує потребу в очікуванні (debouncing) та гальмуванні (throttling) в інтерфейсі користувача. Оскільки рендеринг переривається, React не потрібно штучно *затримувати* рендеринг, щоб уникнути затинання. Він може почати рендеринг відразу, але перервати цю роботу, коли це необхідно, щоб додаток завжди був в змозі реагувати на запити. ### Навмисні послідовності завантаження {#intentional-loading-sequences}