Все вокруг пишут про RSC как про серебряную пулю, но никто не говорит о том, как это ломает привычный кэш на клиенте. Я перевел свой pet-проект на Next.js App Router, и первые две недели был в восторге, пока не начал замечать, что данные в UI иногда живут своей жизнью. Серверные компоненты отлично работают, когда ты контролируешь каждый fetch, но как только добавляешь сторонние библиотеки или легаси-код, который делает запросы напрямую, начинается хаос с ревалидацией.
Я потратил выходные, разбираясь в кэш-слоях Next.js, и в итоге пришлось извращаться с `unstable_noStore` и ручной инвалидацией. При этом в документации все выглядит гладко, а на практике — пара подводных камней, о которых молчат. Кто-то тоже сталкивался с тем, что RSC ломает optimistic updates? Или у меня руки кривые и я просто не понял философию? Давайте обсудим, как вы решаете проблему синхронизации серверного и клиентского состояния в реальных проектах.
👎 1💡 1
Ох, вы прямо в больное место тыкнули! 😅 Я как раз недавно на проекте с App Router ловила такой же баг: серверный компонент отдавал данные, клиентский — свои, а UI в итоге показывал «кашу» из двух состояний. И да, optimistic updates с RSC — это отдельный цирк. Проблема не в самой философии, а в том, что она предполагает идеальный мир, где каждый fetch — через серверный компонент и каждый кэш — под контролем. А в реальности у нас легаси-библиотеки, которые сами лезут в fetch, и вот тут начинается ад с ревалидацией.
Я в итоге для себя выработала такой костыль: все критичные данные, которые должны жить на клиенте и обновляться оптимистично, выношу в отдельные клиентские компоненты с явным `useQuery` и кастомным ключом, а серверные компоненты оставляю только для статики и SEO-контента. Плюс, да, `unstable_noStore` — это наш друг, но мне до сих пор неудобно, что в доках это подается как «экзотика», хотя без него половина проектов просто разваливается. Так что вы не одиноки с кривыми руками — просто архитектура RSC пока не дозрела до продакшена с нетривиальным кэшированием.
