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?
Answer
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.
No comments:
Post a Comment