Flux на самом деле больше касается управления состоянием приложения, а вовсе не деталей того, какие компоненты отображаются в представлении. Это домен React. Flux просто предполагает, что у вас есть какой-то слой реактивного представления — обычно это React.
Состояние приложения не совпадает с состоянием компонента. Состояние приложения — это то, что необходимо знать в нескольких компонентах. Для состояния компонента React вполне подходит this.state
. Компонент ввода — хороший пример того, что может понадобиться.
Так что в вашем случае, если только одному компоненту нужно знать положение прокрутки, может быть не очень хорошо перемещать это состояние в хранилище Flux. Но как только это должно быть известно в нескольких компонентах — особенно компонентах в разных ветвях дерева — вы, вероятно, захотите управлять этим состоянием в Store.
Другая проблема, которую поднимает ваш вопрос, — это роль Flux Actions. Приложение Flux всегда использует действия в качестве источника потока данных. Для этого есть много веских причин: стабильное состояние приложения, обеспечение устойчивости приложения к новым функциям, упрощение анализа, история отмен, восстановление состояния приложения, компоненты представления без состояния и т. д.
Иногда люди хотят написать как можно меньше кода и используют обратный вызов, передаваемый между компонентами, для изменения this.state
в родительском компоненте вместо отправки нового действия для прохождения через поток данных Flux. Я считаю, что это смешивает уровни управления представлением и состоянием приложения, и хотя это целесообразно, это может привести к большой головной боли. В долгосрочной перспективе это не очень гибко, потому что теперь состояние связано с этими несколькими компонентами. Создание потока данных Flux с самого начала намного проще в долгосрочной перспективе и гораздо более устойчиво к новым функциям. Тем не менее, это также требует дополнительных вложений в код.
person
fisherwebdev
schedule
27.06.2015