DEV Community

sunflowerseed
sunflowerseed

Posted on • Updated on

I can't understand Redux's `store.dispatch()`. Is it `store.takeAction()`?

Sometimes I have a hard time understanding the "verbs" or method names of OOP these days.

Note the following is just to use Redux alone, without the mechanism of hooking it up with React.

For example, in Redux, if you use the most basic form:

store = createStore(reducer);
store.dispatch(action);
store.getState();
store.subscribe(fn);
Enter fullscreen mode Exit fullscreen mode

For quite some time, I didn't quite get it what dispatch() means? The store "dispatch" something, like the store is sending out something?

So later on, I found that the method names are from the "I" perspective:

  1. Store, I want to dispatch an action to you
  2. Store, I want to get state from you
  3. Store, I want to subscribe to you with an observer (or listener)

If we use the Smalltalk way of naming, which is one of the earliest object oriented programming languages, it is:

store.takeAction()
store.giveState()          // or store.state()
store.addEventListener()
Enter fullscreen mode Exit fullscreen mode

It goes naturally:

  1. Store, take this action
  2. Store, give state to me
  3. Store, add an event listener

You can see window.addEventListener() is using such naming too.

Did I misunderstand something? Not that I want to nitpick... but it is the use of some terms that can make me confused for quite a while, and then I found out, "oh... the name... it actually is from the perspective of the user of the object, instead of a verb or message to send to the object." (for a long time, I thought the store is to dispatch or send out some action to some where).

Discussion (2)

Collapse
zeke profile image
Zeke Hernandez

Hey jianlin,

Interesting, I never took the time to think about this much.
But I think that "dispatch" refers not the programmer dispatching the action to the store, but rather the store dispatching the action to its reducer.

Collapse
sunflower profile image
sunflowerseed Author

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() 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:

  1. We create the store by providing it a "rule book" (the reducer)
  2. We send actions to it
  3. We get its state sometimes
  4. We want to be notified for change of state instead of always checking up on it.

so it translates to

  1. store = createStore(reducer)
  2. store.takeAction()
  3. store.state()
  4. store.addObserver()

But I guess it is one way to look at it.