Привет!

Интересный кейс, про подходы мета-фреймворков для загрузки данных, и немного мыслей по теме.

В Next.js улучшают поддержку SEO, если надо будет формировать мета данные динамически - для этого будет отдельная функция - загрузчик.

При этом, в нексте уже есть возможность загрузки данных в самих компонентах, благодаря Server Components (серверные компоненты могут быть async, клиентские могут использовать экспериментальный хук use) и подходу render-as-you-fetch.

Это обсудили в твиттере, что делать если нужны данные из одного и того же запроса в компоненте и загрузчике SEO данных.
Решение - экспериментальное cache апи реакта - https://twitter.com/leeerob/status/1619812802453188608?t=W_QqKVZeKSFPTeORs8XBlg&s=19

Remix кстати эту проблему решает по другому, прокидывая данные из загрузчика для страницы в meta функцию.

Этот cache под капотом дедуплицирует вызов функции по аргументам.

И для render-as-you-fetch с server components это наверное нормальное решение что бы избежать дубликатов и водопадов запросов, хотя и решаемое на уровне http клиентов (например tinkoff-request https://tinkoff.github.io/tinkoff-request/docs/plugins/cache-deduplicate.html)

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

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

Гораздо лучше все эти проблемы решают стейт-менеджеры, с готовыми механизмами для сайд-эффектов, основной минус что их всё-таки надо интегрировать поверх мета-фреймворка, и можно опять же упереться в его гибкость.

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

Если говорить про кейс с SEO, благодаря DI, в трамвайных экшенах можно менять мету вручную, используя созданный для этого сервис (привет хорошим практикам из Angular) - то есть гибче просто уже некуда.

По итогу, не могу сделать какие-то полезные выводы - все делают по разному, и все эти механизмы сделаны не просто так, имеют и плюсы и минусы.

Очень интересно как вы решаете сложные кейсы бизнес-логики в приложениях написанных на мета-фреймворках.