Мы пытаемся реализовать архитектуру потока и сталкивались с несколькими трудностями: следует ли несколько представлений получать данные из одного и того же хранилища? Я не имею в виду тривиальные методы выборки модели, такие как getUser, я имею в виду состояние представления (isActive, выбранные поля и т. Д.) Использование того же хранилища для обработки состояния обоих представлений выглядит как избыточная связь по моему мнению.Flux Архитектура и связь между компонентами
Например, рассмотрите торговое приложение, имеющее страницу запаса. переход от фондовой страницы на новую страницу заказа и используя ту же currentStock собственности в StocksStore, вызывает у нас много смешных ошибок при навигации вперед и назад между страницами;)
Так я пришел к выводу, что если два вида используют один и тот же магазин для сохранения состояния просмотра, тогда это хорошая возможность разделить хранилище на два подкатегории (StockStore, NewOrderStore).
Это приводит к созданию архитектуры хранилища для каждого компонента, что обеспечивает лучшую сегрегацию компонентов для модулей для упрощения обслуживания.
Вы согласны с моими заключениями? Вы столкнулись с подобными проблемами?
Erik.
Я не уверен, что понимаю, что вы подразумеваете под 'currentStock'-' newOrderPage' не сразу поражает меня как требующего свойства currentStock. Не могли бы вы уточнить? – citelao
Это может быть скорее основано на мнениях по поводу вопроса StackOverflow, но на самом деле нет никакого * правильного * способа сделать это. Это компромисс, который будет зависеть от многих аспектов вашего приложения и других вариантов дизайна. Конечно, нет ничего, что помешало бы вам использовать один магазин для нескольких компонентов, на самом деле я бы сказал, что это очень распространено. На странице Flux Facebook: «Больше, чем просто управление коллекцией объектов в стиле ORM, магазины управляют состоянием приложения для определенного домена в приложении» –