Является ли хорошей практикой использовать setState в redux?
Доброго дня.
Сам я никогда не считал это допустимым, однако разработчики некоторых компонентов (и в целом, некоторые разработчики) смешивают setState и глобальный store state. Это удобно, т.к. можно хранить в setState внутренние, служебные свойства и информацию, но не нарушает ли это сам принцип архитектуры redux?
По-хорошему в redux выносят только то, что используется в разных частях приложения, а так же данные полученные с сервера. Для остального предпочтительней использовать state компонента. В подавляющем большинстве случаев, lifting state up будет предпочтительней использования redux.
Ответ Дэна Абрабомова на похожий вопрос How to choose between Redux's store and React's state.
Спасибо за ответ, не ожидал такого, тем паче, от автора Redux.
Ведь тогда получается, что поток данных перестает быть однонаправленным. Это на 100% допустимо для сторонних компонентов, которые должны быть черными ящиками, но для приложения в целом?.. в редаксе ведь центральный принцип "весь state приложения в одном месте". Т.е. использование только store - это, прежде всего, дань архитектуре, методологии, что не всегда может быть продиктовано реальной необходимостью.
Алексей Николаев, для всего приложения. Не забывайте, что redux это не архитектура ради архитектуры, а инструмент для решения определенных задач. Если есть задача использовать какое-то общее состояние в разных частях приложения, хранить его и иметь возможность его изменять, то redux тут подойдет как нельзя лучше. Если же подобной задачи не стоит, то всегда предпочтительней state компонента. Меньше кода, меньше операций, проще анализ и рефакторинг. В случае изменения требований локальное состояние переносится в хранилище redux за считанные минуты.
в редаксе ведь центральный принцип "весь state приложения в одном месте".
Верно. Но единственная выгода, которую вы при этом получите это путешествия во времени, которые мало когда нужны, при целой куче недостатков вроде просевшей производительности, раздутой кодовой базы и усложненного рефакторинга, казалось бы, простых вещей.
Относитесь к этому правилу как к Есть только одно глобальное хранилище. При этом локальных может быть неограниченное количество.
Так же обратите внимание на Context API, многие вещи удобно передавать через контекст.
