Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Concurrent Mode». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Concurrent Mode** - це старий експериментальний режим React, який намагався зробити рендеринг асинхронним на рівні ядра, дозволяючи призупиняти, скасовувати й відновлювати рендер частин UI. **Ключове:** його перейменували на "Concurrent Features", бо "режим" вимагав вмикання/вимикання й ламав сумісність зі старими бібліотеками, тоді як з React 18 ці можливості (Transitions, Suspense, Streaming SSR тощо) вмикаються вибірково поверх одного concurrent-рушія через `createRoot()`.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## 1. Що таке "Concurrent Mode" (історично) До React 18 команда React експериментувала з новим рендеринг-рушієм - **Concurrent Mode**. Це був *експериментальний режим*, який повністю змінював те, **як React рендерить дерево компонентів**. > Мета Concurrent Mode: > зробити React **асинхронним**, щоб він міг **призупиняти**, **відновлювати** і **скасовувати** рендеринг частин UI, > не блокуючи головний потік JavaScript. ### Простіше кажучи: React хотів "думати наперед", рендерити частини інтерфейсу у фоні й показувати їх, коли вони готові. Це відкривало шлях до: - плавних переходів між екранами, - завантаження даних без "смикання" UI, - кращої чутливості під навантаженням. --- ## 2. Проблема старого підходу У React 17 і нижче: - рендеринг був **синхронним** - якщо React почав перемальовування, він мав завершити його **повністю**; - UI міг "фризитися", поки React рендерить великі списки чи важкі компоненти; - не можна було гнучко керувати пріоритетами (наприклад, розрізняти "термінові" й "фонове оновлення"). Concurrent Mode мав це вирішити. --- ## 3. Що вмів Concurrent Mode Коли він з'явився (у React 16.8-17, в експериментальних білдах), увімкнення режиму виглядало приблизно так: ```javascript ReactDOM.createRoot(rootElement, { concurrent: true }); ``` Це активувало новий "асинхронний" рушій рендерингу, де React міг: - призупиняти рендер (pause), - скасовувати проміжний результат (cancel), - відновлювати (resume), - показувати *частково готовий UI* (partial hydration, streaming SSR). --- ## 4. Чому від "Concurrent Mode" відмовилися Команда React зрозуміла: "режим" передбачає, що його можна **увімкнути чи вимкнути**, а це **розриває екосистему** - бібліотеки мають знати, в якому режимі вони працюють. Багато розробників боялися вмикати "Concurrent Mode", бо він **ламав сумісність** зі старими бібліотеками, які не були розраховані на переривний рендер. > Цитата з React Blog: > *"Concurrent Rendering is not a new mode that you turn on - it's a set of features that you can use when you need them."* --- ## 5. Перехід до "Concurrent Features" З виходом **React 18 (березень 2022)**, команда React змінила філософію: > Більше **жодного окремого режиму**. > Натомість - **набір можливостей (features)**, які вмикаються **за потреби**. Тепер усе працює **в межах одного рушія** - нового concurrent-rendering-core. А конкурентні можливості активуються автоматично, якщо ти використовуєш сучасний API. --- ## 6. Що тепер входить у "Concurrent Features" Ось основні **фічі**, засновані на Concurrent Rendering: | Feature | Що робить | |---|---| | **Automatic Batching** | React об'єднує кілька `setState` в один рендер, навіть в асинхронних контекстах | | **Transitions** (`useTransition`, `startTransition`) | Дозволяють відкладати низькопріоритетні оновлення (наприклад, фільтрацію, пошук) | | **Suspense for Data Fetching** | Дозволяє React "чекати" дані (Promise) і показувати fallback-UI | | **Streaming SSR** (`renderToPipeableStream`) | Сервер може віддавати HTML потоками, без очікування всієї сторінки | | **Selective Hydration** | Клієнт гідрує лише ті частини сторінки, які вже видно / потрібні | | **useDeferredValue** | Дозволяє "відкласти" обчислення неважливих даних, щоб не блокувати рендер | Усі ці фічі **працюють поверх одного concurrent-рушія**, але **вмикаються вибірково**, коли ти використовуєш відповідні API. --- ## 7. Як це вмикається тепер Раніше - через "режим": ```javascript ReactDOM.render(<App />, root); // звичайний ReactDOM.createRoot(root, { concurrent: true }); // Concurrent Mode (старе) ``` Тепер - просто через новий API: ```javascript import { createRoot } from 'react-dom/client'; const root = createRoot(document.getElementById('root')); root.render(<App />); ``` Все: тепер React використовує concurrent-renderer за замовчуванням. Жодних "режимів", "прапорців" чи "breaking changes". --- ## 8. Головна відмінність у філософії | Було (Concurrent Mode) | Стало (Concurrent Features) | |---|---| | Режим (вмикається/вимикається) | Набір можливостей (вмикаються автоматично) | | Вимагав повної адаптації бібліотеки | Сумісний зі старими бібліотеками | | Міг ламати поведінку | Безпечний і поступовий | | Експериментальний | Стабільний і готовий до продакшену | | Активувався вручну | Працює через `createRoot()` | --- ## 9. Підсумок > **Concurrent Mode** - це ранній експеримент, > де React намагався зробити рендеринг "асинхронним" на рівні ядра. > > **Concurrent Features** - це сучасна, стабільна реалізація тих самих ідей, > але у вигляді **гнучких API**, які можна вмикати за потреби. --- ### Коротко: | Термін | Що означає | Статус | |---|---|---| | **Concurrent Mode** | Старий експериментальний режим, повністю конкурентний рендеринг | Видалено, не використовується | | **Concurrent Features** | Сучасні стабільні можливості (Transitions, Suspense, Streaming SSR та ін.) | Використовується з React 18+ | | **Concurrent Rendering** | Внутрішній механізм, що лежить в основі всіх цих можливостей | Працює завжди при `createRoot()` |Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.