18 реакт умеет и отдавать разметку в потоке, и гидрировать ее на клиенте по мере поступления, вместо одной тяжелой задачи по гидрации.
Границами
Suspense определяется, какие компонеты будут отрендерены сразу (app shell), для каких фаллбэк (индикатор загрузки), а какие будут отрендерены после резолва Suspense компонентов.Этот механизм подробно описан в посте New Suspense SSR Architecture in React 18.
Официально для нас разработчиков есть только один API, который поддерживает
Suspense как асинхронное действие - это React.lazy.Но Next.js, Relay и ряд других инструментов уже давно используют подкапотный механизм для своих апишек для загрузки данных, по сути все сводится к тому, что обернутый в Suspense механизм должен выкинуть Promise, и пока он не зарезолвлен, будет отрендерен пропс fallback.
Кастомную реализацию можно посмотреть тут - https://blog.logrocket.com/data-fetching-react-suspense/
Для SSR приложений, важный нюанс - этот Promise должен быть в одном и том же состоянии и на клиенте, и на сервере:
- Отрендерили app shell на сервере с pending промисом для Suspense компонента
- Отдали эту разметку на клиент, запустили гидрацию
- Этот Suspense компонент уже в клиентском коде на момент гидрации должен получить промис в таком же pending статусе
- Затем на сервере промис переходит в resolved, мы телепортируем его на клиент
- Клиентский Suspense видит что промис зарезолвлен и рендерит вложенный компонент
Интересный нюанс, когда renderToPipeableStream отдает app shell с фаллбэками, он добавляет пустые
template теги и небольшой скрипт $RC в котором вроде как подменяется fallback на разметку из темплейта, а после резолва suspended компонентов для них также отправляются на клиент скрипты с использованием этого $RC метода - очень похоже что это логика именно для React Server Components, интересно разобраться почему оно вообще добавляется в нашем случае, когда никаких RSC нет.