getter methods for Stores

[codegard1]

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
  • returns an array of all Player records
• getPlayer( Id )
  • returns a single player record
• getState
  • returns an object containing state variables such as isOptionsPanelVisible, MessageBar text & type, etc.

ControlStore

• getState
  • returns a collection of state variables such as deck visibility

DeckStore

• getSelected
  • returns an array of selected cards from the store
• getDrawn
  • returns an array of drawn cards from the store
• getDeck
  • returns a fresh deck from Shuffle

[codegard1]

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 onChange. That way, whenever anything changes in any of the Stores, it will be passed to Table, which in turn will stay up to date.