Является ли хорошей практикой использовать setState в redux?

Question

[Алексей Николаев]

Доброго дня.
Сам я никогда не считал это допустимым, однако разработчики некоторых компонентов (и в целом, некоторые разработчики) смешивают setState и глобальный store state. Это удобно, т.к. можно хранить в setState внутренние, служебные свойства и информацию, но не нарушает ли это сам принцип архитектуры redux?

Answer 1

[Антон Спирин]

По-хорошему в redux выносят только то, что используется в разных частях приложения, а так же данные полученные с сервера. Для остального предпочтительней использовать state компонента. В подавляющем большинстве случаев, lifting state up будет предпочтительней использования redux.

Ответ Дэна Абрабомова на похожий вопрос How to choose between Redux's store and React's state.

Comments

[Алексей Николаев]

Спасибо за ответ, не ожидал такого, тем паче, от автора Redux.

Ведь тогда получается, что поток данных перестает быть однонаправленным. Это на 100% допустимо для сторонних компонентов, которые должны быть черными ящиками, но для приложения в целом?.. в редаксе ведь центральный принцип "весь state приложения в одном месте". Т.е. использование только store - это, прежде всего, дань архитектуре, методологии, что не всегда может быть продиктовано реальной необходимостью.

[Антон Спирин]

Алексей Николаев, для всего приложения. Не забывайте, что redux это не архитектура ради архитектуры, а инструмент для решения определенных задач. Если есть задача использовать какое-то общее состояние в разных частях приложения, хранить его и иметь возможность его изменять, то redux тут подойдет как нельзя лучше. Если же подобной задачи не стоит, то всегда предпочтительней state компонента. Меньше кода, меньше операций, проще анализ и рефакторинг. В случае изменения требований локальное состояние переносится в хранилище redux за считанные минуты.

в редаксе ведь центральный принцип "весь state приложения в одном месте".

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

Так же обратите внимание на Context API, многие вещи удобно передавать через контекст.