Redux: Государственное управление для фронтенда

Единый store — единая правда. Redux заставляет хранить всё состояние приложения в одном объекте. Это как если бы все документы страны лежали в одной комнате: найти что-то сложно, зато никто не сможет сказать «я не знал, что это правило существует». Для enterprise-приложений с сотнями экранов такая централизация — не прихоть, а необходимость.

Иммутабельность как религия. Каждое изменение состояния в Redux — это новый объект. Никаких мутаций, только чистые функции. Если в обычном React вы могли случайно изменить пропсы, то Redux выставляет жёсткие рамки: «хочешь обновить состояние — опиши это через action».

Неизменяемая бюрократия. Action → Reducer → Store — три кита, на которых держится Redux. Action описывает «что произошло», reducer решает «как изменить состояние», а store хранит результат. Это похоже на работу госорганов: чтобы поменять что-то в системе, нужно заполнить бумаги в трёх инстанциях.

Бойлерплейт — плата за порядок. Писать action types, action creators, reducers для каждого поля формы — это как заполнять налоговую декларацию для кнопки «Отправить». Redux Toolkit немного исправил ситуацию, но миф о «слишком много кода» преследует Redux до сих пор.

Глобальное состояние — глобальные проблемы. Store в Redux живёт вне компонентов. Это значит, что любое изменение триггерит перерисовку всех подключённых компонентов, даже если они используют лишь крошечную часть состояния. useSelector и memoization помогают, но требуют ручной оптимизации.

Over-engineering для маленьких проектов. Если ваше приложение — это форма ввода и таблица, Redux будет выглядеть как танк на детской площадке. 80% случаев, когда разработчики тянут его в проект, сводятся к «потому что так делают в больших компаниях».