Как стать автором
Обновить

Комментарии 22

Прочитал статью и не совсем понял, как все это ложиться на нынешние концепции SPA? В примерах используют компонент Note, который берет данные прямо с сервера. Но как он возьмет данные когда мы поменяем id уже на клиенте, c помощью навигации? Ведь SPA не подразумевает загрузку страницы на каждый роут. Нужно ли будет загружать целые компоненты по сети? Придется ли реализовывать оба способа получения данных?


Ну и судя по ограничениям, каждый компонент на серверный не переведешь, не получится ли так на практике, что эта "оптимизация" при затраченных ресурсов не дает значимого прироста?

На все ваши вопросы есть ответы, но только в дополнительных источниках)
Нет, при смене роута, будут запрошены и переданы по сети только props, необходимые для отрисовки серверного компонента на клиенте. Оба способа реализовывать не нужно (вообще может быть кейс что вы достаете данные напрямую из бд).
Ограничения есть и каждый компонент перевести не получится. К минусам также можно отнести то, что необходимо будет поднимать еще один сервер для обработки серверных компонентов, т.е. нельзя будет просто положить статику на какой-нибудь S3.

Для нынешних SPA вроде всякого рода админок новый подход не нужен, их можно писать как и раньше.


Server Components предназначены для других проектов, где React себя плохо показывал раньше, вроде онлайн-магазинов, где критичен размер загружаемого JS. В этом смысле новое API можно рассматривать как более умную версию turbolinks, где на бекенде будет работать React вместо Ruby.

Размер бандла как раз проблемой не был ни когда, наоборот — спа тут выигрывают. Проблема была в отсутствии ею нормальной индексации поисковика и, и она тут никак не решается

Хорошо что многие годы существует Puppeteer который решает все проблемы с индексацией поисковиками, и с отдачей целого HTML пользователю если этого прям так хочется. И ему пофигу реакт не реакт.
Хорошо что многие годы существует Puppeteer который решает все проблемы с индексацией поисковиками

Вообще ни как не решает.

Попробуйте prerender.io

Проблема индексации это не та проблема которую реакт вообще должен решать. Если нужна «классическая» индексация поисковиками — юзайте next, gatsby и тд.
Проблема индексации это не та проблема которую реакт вообще должен решать

Эта проблема которую реакт вносит самим принципом своей работы. Логично, что как раз он ее и должен решать.

Фреймворк не обязан решать все проблемы на свете. Если вам нужна индексация, логичнее отказаться от реакта в этом месте.


Серверные же компоненты, о которых говорится в статье – это совсем про другое, из общего там только слово "сервер".

Фреймворк не обязан решать все проблемы на свете

Желательно было бы, чтобы он этих проблем не создавал. А он создает.


Серверные же компоненты, о которых говорится в статье – это совсем про другое, из общего там только слово "сервер".

Скорее наоборот — это ровно про то же, а из другого там только то, что состояние с сервера приходит в виде закодированного дом-дерева, а не в виде хтмл.

Реакт это библиотека для разработки интерфейса. Это не фреймворк, это не генератор сайтов, на одном реакте даже PWA не сделать — нужен хотя бы react-dom, хотя если посмотреть на зависимости create-react-app — там еще куча всего для того что бы сделать веб приложение (это при том что в cra даже нет роутера).

Требовать от реакта что бы он решал проблему обхода приложения ботами — это в целом требовать кардинальной смены подхода того как реакт и его экосистема вообще устроены. С такими предложениями вам не в комментариях на хабре нужно писать, а писать более чем обоснованные предложения команде реакта на гитхабе.
можно получать полный доступ к окружению сервера…
Только для доступа к окружения сервера, требуются обертки для реакта...

Смущает то, что нужно использовать/писать такие обертки да ещё и в синхронном виде. То есть нельзя просто так взять и использовать Node.js API.

А могут ли серверные компоненты содержать кроме html завернутого в JSX, завернутого в JSON ещё и какой-то код для обработки поведения этого html? Если нет, то реальных применений будет мало, т.к. я сходу и не вспомню примеров компонентов которые будут одновременно:
а) достаточно большие, чтобы на них экономить
б) не содержат при этом кода обработки действий, голый html на выходе.
Кроме приведённого примера с маркдаун, конечно.
Это же PHP десятилетней давности — запрос к БД и отрисовка HTML в одном файле. Только PHP уже тогда за это ругали и рекомендовали разделять ответственности, а в мире реакта это оказывается ново, модно и удобно.

Тут важно понимать за что именно ругали подход 10-летней давности, и что происходит сейчас. Ругали за смешивание клиентского и серверного кода в одном файле, хотя он физически исполняется в разных средах. В результате получались странные вопросы вроде такого: https://qna.habr.com/q/247194


В React Server Components у вас есть чекое разделение. Компонент либо серверный, либо клиентский. Запросы в БД возможны только в серверном коде, а пользовательские события можно обрабатывать только в клиентском коде. Технология в принципе не позволит их вам смешать в одном файле. Мухи и котлеты по-прежнему живут отдельно, хоть и пишутся на одном языке.


По большому счету, React Server Components это еще одна попытка построить фуллстек фреймворк, чтобы был один язык для сервера и для фронта. Таких проектов уже много, это и Blazor (C#), и Kotlin.js, и другие. React Server Components прекрасно ложатся в этот тренд.

Ругали за смешивание клиентского и серверного кода в одном файле,

А какая разница — в одном или нескольких? Для меня как программиста — это не важно, я никогда даже не замечу, в одном оно файле или в разных. Для пользователя — тем более без разницы, он тоже не заметит.

В примерах и презентации увидел код за который руки по локоть отрывать надо. Там запрос на бэк и запрос к постгресу внутри UI компонента прям(JS + SQL + HTML в одном файле — пхп нервно курит в стороне). Facebook прям в примерах смешивает презентационный слой и слой доступа к данным. В этой чудо фиче можно будет как-то норм архитектуру со слоями и DI дизайнить типо MVVM || Clean Architecture?

Все демки обложены комментариями о том, что в одном файле это лежит только чтобы компактно показать идею. В реальном коде это можно и нужно вынести в отдельный сервисный слой. Нужно смотреть на идею в целом, а не докапываться до запятых.

Я бы ещё добавил, что это все эксперименты и не production ready.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации