Comments 24
Уже давно использую React исключительно как шаблонизатор. Как шаблонизатор он идеален, на мой взгляд. А состояние храню в MobX.
Я сомневаюсь, что у MobX есть шансы заработать в серверных компонентах. Соответственно вы как раз попадает в группу кандидатов на то, чтобы переехать на кучу альтернатив React'у, благо что MobX на них тоже иногда есть (тот же Preact). И даже серверный рендеринг там есть, когда он нужен.
Вроде есть какие-то решения, но сам, честно говоря, еще не смотрел.
https://github.com/vinhnguyen1211/react-mobx-ssr
Так это для нормального SSR с рендерингом и на сервере и клиенте, который в Реакте был последние лет восемь и который до последнего момента был в NextJS. Конечно он будет работать. Ему и оберток особых не нужно. Вопрос в схеме когда у вас вместо половины компонентов не то HTML, не то хрен пойми что.
MobX прекрасно работает с SSR Nextjs 12/13.
У нас есть несколько проектов с Nextjs 12 + MobX в продакшене, и в данный момент почти ушел в продакшен проект на Nextjs 13 + MobX с использованием директории app
Оно точно внутри серверных компонентов работает или просто внутри директории app?
В серверных компонентах вы лишь получаете/обрабатываете/кешируете сырые данные, которые потом передаются в клиентские компоненты(клиентские компоненты также рендерятся на сервере с помощью SSR).
Мы используем и глобальные сторы(например AppStore/UserStore) и локальные сторы одновременно.
Внутри клиентских компонентов вы уже инициализируете и заполняете обсерваблы, или закидываете данные в глобальный стор(они у нас наполняются из layout.tsx).
Для локального стора, выглядит примерно так:
export const Client = observer(({ catalogProduct }: PropsType) => {
const store = useObservable({
tab: 'description',
catalogProduct: new CatalogProductModel(catalogProduct)
});А серверные компоненты при этом зачем?
Генерировать SEO, в клиентских компонентах нельзя задать SEO.
Ну и мы еще кешируем результаты некоторых запросов в Redis.
А в чем проблема с SEO в клиентских компонентах? При условии их рендеринга на сервере, конечно.
В этом: "The metadata object and generateMetadata function exports are only supported in Server Components"
https://nextjs.org/docs/app/api-reference/functions/generate-metadata
И чем это отличается от Head кроме синтаксиса? Просто другой способ задания содержимого <head> в папке app?
Я пишу на Vue, и релиз Nuxt 3 также больно отразился на текущем проекте, все сырое, какие-то экспериментальные фичи, большинство пакетов непонятно как адаптировать. У нас на проекте использовался Nuxt 2, как решение для SSR, сейчас все проекты приводим к Vue 3, и обновляться до Nuxt 3 ради Vue 3 - это просто какая-то жесть. По сути новая версия Nuxt - это уже какой-то другой фреймворк. Мы отказались от Nuxt, и SSR реализовали с помощью vite-plugin-ssr (вместе с переходом на vue 3 также переходили с webpack на vite). Т.е. от использования полноценного фреймворка пришли к использованию доп. либы, которую можно контролировать и в которой гораздо меньше магии и непонятных релизов.
Как серверные компоненты помогут в SEO? Они ведь возвращают не верстку, а данные
Если кратко, то первый ответ сервера - вёрстка, а дальше вместо SPA качаются метаданные для их рендеринга, а клиентские компоненты только на клиенте рендерятся
клиентские компоненты также рендерятся на сервере, разница в том, что серверные компоненты не попадают в js bundle.
https://nextjs.org/docs/getting-started/react-essentials#client-components
Client Components enable you to add client-side interactivity to your application. In Next.js, they are pre-rendered on the server
Вот почему я как java разработчик не буду учить UI ещё лет 5 как минимум. Наблюдаю уже лет 10 как эволюционирует UI и каждый раз натыкается на одни и те же грабли и возвращается к серверному рендерингу. Всё началось с Гугла и его GWT, который стал педалить и взрывать браузеры, потом продолжилось angularjs с тем же результатом, потом angular и реакт, и всё равно всё возвращается к серверному рендерингу...
Вот тоже такие мысли, если уж отказались от сервеного рендеринга, то уж с концами
Там есть ещё денежный нюанс - можно покупать меньше серверов если часть логики будет исполняться на клиенте, а только бизнес-важная - на сервере. Классика выбора толстый/тонкий клиент. Плюс быстрее отклик когда не надо каждый чих на сервере гонять, ну и трафика меньше когда только данные - опять же и деньги и время.
Но есть нюанс - сео-оптимизация. И там либо классическая статика была, либо пререндеры первичные, решающие проблему, но только если сам контент не динамичен, а теперь решили миксануть ещё одним способом.
Но толстые клиенты не исчезнут, по причинам с деньгами и скоростью отзывчивости выше, просто добавился ещё один вариант в градиенте от чистой серверной генерации до толстого клиента с сухими данными.
Полностью с вами согласен. Единственный момент я бы вибирал толстый клиент при условии если система действительно высоконагруженная, типа соцсетей. Даже один разработчик на реакт/ангуляр это от 4к долларов для компании. Поэтому думаю на эту сумму можно закупить достаточно серверных мощностей для серверного рендеринга от нескольких сотен до миллион пользователей(зависит от технологии на сервере), как пример сайт stack overflow.
Может это и полезно, но если там участвовали разработчики Next, то я не хотел бы таким пользоваться. Мне не нравятся их решения, в частности диктат на файловую структуру.
Я склоняюсь к такому мнению, что для множества людей React останется как UI часть, а вот серверные компоненты, как новый подход (именно подход), никак не сочитается с заголовком данной статьи.
Не наступил ли у React момент переписывания Angular.js на Angular?