Would we think of a store to be an object, that "has" a reducer (which is a function, not an object), which is a "rule book" that says how the state should change according to the action.
The getState() and subscribe() part are easier to understand.
If we consider all method names as an interface, it is like, it is between the object and the outside world. So dispatch sounds somewhat imperative and it is the internal working of the store. The outside world may not care about how the action is dispatched to the reducer. All the outside world cares is, I tell the store the action, and now change the state according to the rule book. From the standpoint of the outside world, it is:
We create the store by providing it a "rule book" (the reducer)
We send actions to it
We get its state sometimes
We want to be notified for change of state instead of always checking up on it.
so it translates to
store = createStore(reducer)
store.takeAction()
store.state()
store.addObserver()
But I guess it is one way to look at it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I guess that can make sense...
Would we think of a store to be an object, that "has" a reducer (which is a function, not an object), which is a "rule book" that says how the state should change according to the action.
The
getState()andsubscribe()part are easier to understand.If we consider all method names as an interface, it is like, it is between the object and the outside world. So
dispatchsounds somewhat imperative and it is the internal working of the store. The outside world may not care about how the action is dispatched to the reducer. All the outside world cares is, I tell the store the action, and now change the state according to the rule book. From the standpoint of the outside world, it is:so it translates to
But I guess it is one way to look at it.