RSC в Next 15 это шаг назад, или я чего то не понял

[maitee92]

Не понимаю восторга вокруг RSC в Next 15, по ощущениям сложность выросла, а профита ноль для обычного дашборда. Сижу второй проект на app router, и каждый раз спотыкаюсь об одно и то же: где-то нужен use client, где-то нельзя передать функцию через границу сервер-клиент, контекст не работает как привык, а ошибки гидрации ловлю по три штуки в день. У нас типичная админка, формы, таблицы, фильтры. Где тут выигрыш от server components, который оправдывает этот геморрой. Может я просто готовлю неправильно, тогда ткните носом.

[Version]

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

[duel]

+1 к посту выше. мы на app router но половина приложения это одна жирная use client секция, по сути тот же спа просто внутри некста. и норм работает

[juniorredteam]

ошибки гидрации это почти всегда дата которая на сервере и клиенте разная. Date.now, random, localStorage в рендере. покажи код, угадаю с первого раза

[Manuelriere]

ошибки гидрации это почти всегда дата которая на сервере и клиенте разная

не только. у меня гидрация падала из-за того что одна либа графиков лезла в window на этапе рендера, никакого рандома. suppressHydrationWarning это затыкание симптома, а корень в том что RSC заставляет тебя думать о двух средах одновременно там где раньше была одна. вот эта когнитивная нагрузка и есть та цена про которую спрашивал ОП

[debian91]

@duel, честно, RSC сырой до сих пор. кеширование в next переписывали уже три раза, в 15 опять поменяли дефолты fetch, то что кешировалось само теперь нет. документация отстает от реальности. я не говорю что идея плохая, идея норм, реализация в некст местами боль

[fpga_lord]

попробуй remix кстати, там та же серверная философия но без этого деления компонентов на два сорта. loader на сервер, компонент один. многим заходит после некста именно из-за того что в голове не надо держать границу

[kiwash]

@debian91, давайте по делу, где конкретный профит RSC которым можно оправдать переход для реального проекта.

коротко: ты не тащишь на клиент код который нужен только для рендера. пример из жизни, у нас была страница каталога, тянула markdown-парсер, подсветку кода и либу форматирования дат, суммарно под 240 кб в бандле. перевели рендер этого в server component, на клиент уехало 0 кб из этого, парсинг и форматирование остались на сервере, в браузер прилетел готовый html. бандл страницы похудел с 410 до 170 кб, LCP на 4g упал примерно на 600 мс по нашим RUM-метрикам. вот ради такого RSC и нужен. а для админки за авторизацией где бандл всем пофиг и сео не нужно, ты реально страдаешь без выгоды, и тут ОП прав на сто процентов. инструмент под задачу, а не везде подряд.

[sergey123]

вот этот ответ выше надо в шапку. а то развели холивар а суть в одном абзаце