В чем основные преимущества серверных компонентов перед клиентскими в Next.js?

Серверные компоненты рендерятся только на сервере. Браузер не получает js код серверных компонентов, а получает только json-подобное описание необходимомого virtual dom, называемое rsc payload. За счет этого бандл становится меньше.

Второе серьезное преимущество - это поддержка streaming: сервер не дожидается, пока все дерево компонентов будет готово, а отправляет rsc payload по мере готовности, чтобы браузер мог отобразить то, что возможно, как можно скорее. На месте неготовых компонентов будут плейсхолдеры, и браузер заменит их на компоненты сразу, как получит их rsc payload с сервера.

Возможно, я кого-то удивлю, но "клиентские компоненты" в next.js рендерятся на... сервере. А затем гидратируются на клиенте, и поэтому код таких компонентов прилетает в браузер.

В отличие от них, серверные компоненты не гидратируются на клиенте, а рендерятся только на сервере.

Вчера побывала на ежегодной конференции от Яндекса «Я 💛 Фронтенд» и наконец-то смогла победить в соревновании по верстке вслепую Code in the dark! До этого два года подряд у меня было второе место :) Дали красненькую Яндекс станцию

Небольшой лайфхак.

Допустим, у вас есть проект и есть библиотека компонентов, которую вы используете в проекте. Вы делаете новый компонент в библиотеке. Для того, чтобы проверить, как он интегрируется с проектом, не обязательно релизить новую версию библиотеки - достаточно просто сбилдить библиотеку и подменить сборку библиотеки в node modules вашего проекта на только что собранную вами. Если ваш проект на next.js, то необходимо еще и удалить собранный next-ом билд проекта и пересобрать заново через next dev.

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

Сегодня хочу коснуться такой темы, как стейт менеджеры. Я с огромным удовольствием посмотрела доклад Дмитрия Бабина “Вам не нужен state менеджер “. Дмитрий сделал действительно классный анализ существующих на данный момент стейт менеджеров (упустив, однако, effector и mobx), а также сравнил их с хранением состояния средствами react. Вставлю свои пять копеек.

Дмитрий подчеркивает такую проблему стейт менеджеров, как отсутствие экосистемы (на reatom нет библиотеки работы с формой и тд), объясняя это тем, что если мы заносим в проект стейт менеджер, то мы хотим писать на нем всю бизнес логику. Я всегда относилась к стейт менеджерам иначе - в первую очередь я использовала их для хранения данных, используемых глобально (как минимум в нескольких местах приложения), а не как место для написания бизнес логики. Мои требования к стейт менеджеру следующие:

- Стейт является структурой вида “ключ-значение”.
- Содержит геттер данных по ключу.
- Содержит сеттер данных, причем для каждого поля может быть только один сеттер. Этому требованию очень удобно удовлетворяет Redux: в нем принято писать один action creator, который возвращает action, и диспатчить этот action creator из разных мест приложения; но не удовлетворяет, например, effector, потому что он допускает установку данных как в push дизайне (вызов ивента), так и в pull дизайне (подписка стора на эффект). Почему это так важно, опишу позже.
- Удобные девтулзы.

Бизнес логику я распределяла и хранила в: 1. компонентах реакт (например, вызов запроса, если он вызывается только в одном месте), 2. в ts классах (отлично подходит для кода, не требующего механизмов реактивности), 3. в redux-thunk (в небольших приложениях) или 4. в эпиках rxjs (в больших приложениях). Таким образом, я изначально проектировала свой код так, чтобы стейт менеджеру отводилась роль хранилища, поэтому с проблемой, о которой говорит Дима, я за свой профессиональный опыт так и не столкнулась.

Для чего я вообще использую стейт менеджеры? Главная проблема, которую они для меня решают, возникает вовсе не в процессе написания кода, а в процессе поддержки и эксплуатации. Хранение глобальных данных во время написания кода - это вообще не проблема. Я могу легко написать код, который хранит данные где угодно - в реакт хуках, в контексте, да хоть в объекте window. Однако потом наше приложение постепенно обрастает пользователями и фичами, и рано или поздно мы неизбежно сталкиваемся с багом: в наших глобальных данных почему-то лежит не то, что мы ожидаем. Ждем foo, а лежит bar. И дальше наша - понять, почему так получилось, и устранить проблему. Для этого, во-первых, надо понять, какие данные записаны неверно. И вот тут-то пригождаются топовые девтулзы редакса: я просто открываю девтулзы и смотрю текущий слепок данных, в котором достаточно легко нахожу неверные данные. Дальше надо понять, откуда записались неверные данные. Для этого я ставлю в соответствующем action creator брейкпойнт дебаггера и в два счета нахожу в колстеке виновника.

Таким образом, два последних пункта, про которые я пишу - удобные девтулзы и один сеттер данных, в который можно поставить дебаггер - для меня принципиальны. Поэтому я уже много лет остаюсь верной редаксу: мне не нужны суперфичи в стейт менеджере, мне нужны удобные девтулзы для поддержки и дебага приложения. Ни один другой стейт менеджер, ровно как и нативные фичи реакта (контекст, хуки) такой удобный дебаг для меня не предоставляют.