-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getter methods for Stores #19
Comments
DeckStore's methods are only called internally from GameStore Methods, which can be triggered by ControlPanel Methods. How does this all fit together? The purpose of having DeckStore is to isolate Deck actions from Game Actions, but in reality this is not possible since the game state is dependent on the deck state. They can be separated nominally but they must still be coupled closely. ControlStore is more loosesly coupled with GameStore since it can interface more directly with So, if each Store is an Event Emitter, then GameStore would need to be subscribed to DeckStore and ControlStore just as Table is subscribed to GameStore. This seems wrong somehow. Instead, each GameStore should also have its own contants and actions, and Table should get its state from all of them together in |
Determine what getters to implement in gameStore
All of Table's children can still use the same props they're using now if all of Table's state is retrieved from stores, and Table can update itself every time an App Action causes a change to a variable in GameStore.
The question is: when to use App Actions and when to use GameStore methods? And how to organize the state in GameStore?
From what I understand, in flux you get state from the store only in container components, which then pass their state down to children as props. Children can then use App Actions to indirectly modify state, which cascades back down to them from the top.
Table contains everything so it is a good place to start. On mounting, Table should get its state according to the three domains I've already decided on: Game, ControlPanel, and Deck. All actions belong to one of the three domains, and ideally no action should use props from a domain to which it does not belong.
How to determine if a getter is necessary: when a container component needs to have certain state variables available from the time at it mounts, that is a good opportunity to fetch from the stores. App Actions, by contrast, are ad hoc setters and should not be implemented inside the stores themselves.
GameStore
getPlayers
getPlayer( Id )
getState
isOptionsPanelVisible
, MessageBar text & type, etc.ControlStore
getState
DeckStore
getSelected
getDrawn
getDeck
The text was updated successfully, but these errors were encountered: