поток нескольких экземпляров магазина

В Flux-приложении, где данные разделены на сегменты по идентификатору владельца, должны ли мы использовать одно хранилище, которое внутренне разделяет данные на сегменты, или один экземпляр хранилища для каждого сегмента?

Например, у нас есть пользователь приложения, который является тренером нескольких спортсменов. У каждого тренируемого спортсмена нет или более тренировок, и тренер может просматривать тренировки одного или нескольких спортсменов одновременно.

У нас мог бы быть один магазин тренировок для всех спортсменов; хранилище должно гарантировать, что все данные разделены на сегменты спортсменов, и для каждого метода хранилища требуется параметр спортсмена.

Или у нас может быть один экземпляр магазина для каждого идентификатора спортсмена. Это упрощает логику хранилища и сигнатуры методов, но тогда нам приходится управлять большим количеством экземпляров хранилища.

Есть ли у кого-нибудь опыт работы с этим подходом? Есть ли плюсы или минусы того или иного способа? Или какой путь является «путем потока» и почему?


reactjs reactjs-flux
person Micah Condon    schedule 27.10.2014    source источник

Ответы (1)


arrow_upward
9
arrow_downward

Путь Flux заключается в создании одноэлементных хранилищ. Они не являются моделями, поскольку мы привыкли думать о моделях в шаблоне MVC в стиле ORM. Хранилища создаются только в момент инициализации приложения. Они управляют «областью» логики и данных.

Эти одноэлементные хранилища регистрируют обратный вызов в диспетчере. Обратный вызов — единственный способ, которым данные попадают в хранилища. Магазины также предоставляют методы получения в качестве общедоступного API — единственный способ получить данные. Сеттеров нет. Магазины — это отдельная вселенная, полностью контролирующая свои данные и поведение.

В вашем случае кажется, что логическими доменами являются Athlete и Workout, поэтому я бы создал AthleteStore и WorkoutStore и поддерживал коллекции этих двух вещей в соответствующих магазинах. Я полагаю, у вас будут, например, геттеры, такие как getWorkoutsByAthleteID().

person fisherwebdev    schedule 28.10.2014
comment
спасибо - это шаблон, с которого мы начали, но есть много мест в приложении, где было бы проще иметь один экземпляр магазина для каждого спортсмена. Однако, чем больше я думал об этом, тем больше я видел случаи, когда мы теряли некоторые преимущества одноэлементных хранилищ. - person Micah Condon; 28.10.2014
comment
Как в случае одноэлементных хранилищ предотвратить повторный рендеринг всех компонентов, прослушивающих определенное хранилище, когда обновился только один из них? - person dx_over_dt; 15.05.2015
comment
@dforevdg: вы можете проверить в течение shouldComponentUpdate - person sled; 06.10.2015