flux multiple store instances

Question

In a flux application where data is divided into buckets by owner id, should we use one store which internally separates the data into buckets, or one store instance per bucket?

For instance, we have an application user who is a coach for multiple athletes. Each coached athlete has zero or more workouts, and the coach can view one or more athletes' workouts at the same time.

We could have one workout store for all athletes; the store has to ensure that all data is separated into athlete buckets, and every store method requires an athleteId parameter.

Or, we could have one store instance per athlete id. This simplifies the store logic and method signatures, but then we have to manage more store instances.

Does anybody have any experience with this approach? Any pros or cons of doing it one way or the other? Or, which way is 'the flux way', and why?

Eucharist

Answer 1

The Flux way is to create singleton stores. They are not models as we are used to thinking about models in an ORM-style MVC pattern. Stores are instantiated only at the moment of the application's initialization. They manage a "domain" of logic and data.

These singleton stores register a callback with the dispatcher. The callback is the only way data gets into the stores. Stores also provide getter methods as a public API -- the only way data gets out. There are no setters. Stores are a universe of their own, completely in control of their data and behavior.

In your case, it sounds like the logical domains are Athlete and Workout, so I would create an AthleteStore and a WorkoutStore, and maintain collections of those two things within their respective stores. I'd imagine you'll have getters like getWorkoutsByAthleteID(), for example.

Acrosstheboard

thanks - this is the pattern we started with, but then there are many places in the app where it would be simpler to have one store instance per athlete. However, the more I thought about it I do see cases where we'd lose some of the benefits of the singleton stores – Eucharist

With singleton stores, how do you prevent all components listening to a certain store from re-rendering when only one of them has updated? – Krypton

@dforevdg: you can check within shouldComponentUpdate – Ardene