<b>React Server Actions ломают архитектуру, если смешать их с клиентским состоянием</b>

<b>React Server Actions ломают архитектуру, если смешать их с клиентским состоянием</b>

За неделю в репах чаще всего виден один и тот же перекос: action вызывают как «умный fetch», а потом тащат в неё валидацию, мутирующий UI и бизнес-логику одним комом. В итоге граница между сервером и клиентом исчезает, а отладка превращается в поиск побочного эффекта.

Держите простое правило:
— action должна принимать данные формы, проверять их и менять серверное состояние;
— всё, что влияет на интерфейс до ответа, оставляйте в клиенте;
— результат action возвращайте в компактном виде: успех, ошибка, новый id, а не целый экран данных.

Есть наблюдение которое стоит проверить: чем меньше логики в action, тем проще переживать повторные вызовы, отмены, прогревы и деградацию сети. Особенно это заметно в SaaS, где одна форма может работать в десятке сценариев, а не в одном happy path. Здесь server action — не место для «магии», а узкий вход в доменную операцию.

Если action начала читать cookies, трогать внешние API и менять несколько таблиц, проверьте: не пора ли вынести orchestration в отдельный service-слой, а action оставить тонкой обёрткой. Так код переживает и рост продукта, и замену UI без переписывания половины формы.