Comments 22
Прочитал статью и не совсем понял, как все это ложиться на нынешние концепции SPA? В примерах используют компонент Note, который берет данные прямо с сервера. Но как он возьмет данные когда мы поменяем id уже на клиенте, c помощью навигации? Ведь SPA не подразумевает загрузку страницы на каждый роут. Нужно ли будет загружать целые компоненты по сети? Придется ли реализовывать оба способа получения данных?
Ну и судя по ограничениям, каждый компонент на серверный не переведешь, не получится ли так на практике, что эта "оптимизация" при затраченных ресурсов не дает значимого прироста?
Ограничения есть и каждый компонент перевести не получится. К минусам также можно отнести то, что необходимо будет поднимать еще один сервер для обработки серверных компонентов, т.е. нельзя будет просто положить статику на какой-нибудь S3.
Для нынешних SPA вроде всякого рода админок новый подход не нужен, их можно писать как и раньше.
Server Components предназначены для других проектов, где React себя плохо показывал раньше, вроде онлайн-магазинов, где критичен размер загружаемого JS. В этом смысле новое API можно рассматривать как более умную версию turbolinks, где на бекенде будет работать React вместо Ruby.
Размер бандла как раз проблемой не был ни когда, наоборот — спа тут выигрывают. Проблема была в отсутствии ею нормальной индексации поисковика и, и она тут никак не решается
Проблема индексации это не та проблема которую реакт вообще должен решать
Эта проблема которую реакт вносит самим принципом своей работы. Логично, что как раз он ее и должен решать.
Фреймворк не обязан решать все проблемы на свете. Если вам нужна индексация, логичнее отказаться от реакта в этом месте.
Серверные же компоненты, о которых говорится в статье – это совсем про другое, из общего там только слово "сервер".
Фреймворк не обязан решать все проблемы на свете
Желательно было бы, чтобы он этих проблем не создавал. А он создает.
Серверные же компоненты, о которых говорится в статье – это совсем про другое, из общего там только слово "сервер".
Скорее наоборот — это ровно про то же, а из другого там только то, что состояние с сервера приходит в виде закодированного дом-дерева, а не в виде хтмл.
Требовать от реакта что бы он решал проблему обхода приложения ботами — это в целом требовать кардинальной смены подхода того как реакт и его экосистема вообще устроены. С такими предложениями вам не в комментариях на хабре нужно писать, а писать более чем обоснованные предложения команде реакта на гитхабе.
Вам стоит лучше ознакомиться со статьей и видео https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html, там подробно описано для чего, зачем, и как следует их применять.
можно получать полный доступ к окружению сервера…
Только для доступа к окружения сервера, требуются обертки для реакта...
Смущает то, что нужно использовать/писать такие обертки да ещё и в синхронном виде. То есть нельзя просто так взять и использовать Node.js API.
а) достаточно большие, чтобы на них экономить
б) не содержат при этом кода обработки действий, голый html на выходе.
Кроме приведённого примера с маркдаун, конечно.
Тут важно понимать за что именно ругали подход 10-летней давности, и что происходит сейчас. Ругали за смешивание клиентского и серверного кода в одном файле, хотя он физически исполняется в разных средах. В результате получались странные вопросы вроде такого: https://qna.habr.com/q/247194
В React Server Components у вас есть чекое разделение. Компонент либо серверный, либо клиентский. Запросы в БД возможны только в серверном коде, а пользовательские события можно обрабатывать только в клиентском коде. Технология в принципе не позволит их вам смешать в одном файле. Мухи и котлеты по-прежнему живут отдельно, хоть и пишутся на одном языке.
По большому счету, React Server Components это еще одна попытка построить фуллстек фреймворк, чтобы был один язык для сервера и для фронта. Таких проектов уже много, это и Blazor (C#), и Kotlin.js, и другие. React Server Components прекрасно ложатся в этот тренд.
Все демки обложены комментариями о том, что в одном файле это лежит только чтобы компактно показать идею. В реальном коде это можно и нужно вынести в отдельный сервисный слой. Нужно смотреть на идею в целом, а не докапываться до запятых.
React Server Components — что это?