<b>React Server Actions ломают привычную границу между UI и сервером — и это надо спроектировать заранее</b>

<b>React Server Actions ломают привычную границу между UI и сервером — и это надо спроектировать заранее</b>

За неделю в репах видно одну и ту же ошибку: action используют как “магический fetch”, а потом тащат туда валидацию, авторизацию и бизнес-логику без границ. В итоге компонент начинает знать слишком много, а тестировать становится нечего.

Рабочая схема проще:
— action принимает только примитивные данные и FormData;
— на входе делает жёсткую проверку и нормализацию;
— внутри вызывает отдельный service/use-case, а не живёт сам по себе;
— наружу возвращает либо строго типизированный success, либо список ошибок, без сырых исключений. ⚙️

Для коммерческого проекта особенно важно не смешивать side effects: запись в БД, отправку писем, инвалидацию кэша и редирект лучше держать раздельно. Тогда action остаётся тонким адаптером, который легко переиспользовать и заменить на API route, если понадобится.

Есть наблюдение которое стоит проверить: чем меньше логики в action, тем проще миграция между Server Components, form actions и обычными запросами. Не привязывайте домен к UI-слою — action должен быть входной дверью, а не местом, где живёт весь продукт.