Do we want to rename dispatch() and getState() before 1.0?

[gaearon]

Bikeshedding thread here.

As part of 1.0 we can do some breaking changes we won't be able to do after 1.0. This includes bikeshedding on names.

I wanted this library to be a functional programming trojan horse for Flux people, which I think it succeeded at. Before we reach 1.0, we are able to drop some of the Flux naming baggage and find better names for whatever it does.

We're already getting rid of dispatcher and renaming stores to reducers. Do getState and dispatch still make sense?

Traditionally dispatch was called this way because in Flux an action really is dispatched across multiple Stores. In Redux, however, functional composition means that there is only one root reducer at the top. Do we really dispatch?

I've also heard some people are confused by getState as it sounds similar to React's setState and seems to imply some connection to React. In fact, Redux has nothing to do with React.

What if instead of { getState, dispatch, subscribe } we had... { read, perform, subscribe }? Let's bikeshed.

[clearjs]

Also, append. If we consider an analogy with Event Sourcing, this would be like appending to the event log.

[emmenko]

I have a feeling this is slightly going off topic. If we take a step back and see what we have when we execute

dispatch(anAction())
// or
dispatch(anActionAsync())

The action method simply returns a plain object, or a function. It doesn't perfom anything yet. You might as well pass an object directly to dispatch. Then, what dispatch does are basically 2 things:

• calls the reducer function
• calls all the registered listeners

So it's actually just calling functions. Something like execute could also be appropriate in that sense.

So maybe we should start from that? I don't have any good names for that but maybe it will help?

[clearjs]

consume?

[ellbee]

I'd keep the existing names. I think dispatch fits more than any of the proposed replacements for it. If there is concern over getState being confused with component state then I'd probably make it more verbose, like getStoreState, rather than introducing another term like getAtom, but I don't really like either alternative.

[gaearon]

I agree. Let's keep the existing names.

[vladap]

@acdlite

(dispatch, state) => {...} Do you see how that could be confusing?

Actually, I don't. dispatch is a verb and suggests it is a complex function, probably with input parameters.

state is a noun suggesting it is a property/value/instance or getter returning a property/value/instance. It doesn't matter what it actually is if all cases are accessed uniformly.

I would expect to be able to do state.something.

It turns out that ES6 supports to access it uniformly because it provides class property getters and setters. Uniform Access Principle is embraced in FP without get/set prefixes.

Hence, instead of

class Store() {
  getState() { return this.state }
}

const s = store.getState()

it could be

class Store() {
 get state() { return this.state }

const s = store.state

if I would do const s = store.state() it doesn't compile.

I think, it might open an opportunity to have getters in store object but access them in the same way in @connect without thinking if I get a state property via a getter function from a class instance or a property from a plain object. It might be helpful to implement Lenses in store because they would behave seamlessly with getting objects properties.

[emmenko]

It's cool that we try to use all the new cool features, but we should think about browser compatibility also.

[johanneslumpe]

@emmenko that's only a problem if you strive for IE8 compat.

[emmenko]

Sure, although there are other like classes etc

https://babeljs.io/docs/advanced/caveats/

Just saying we should consider this and set a minimal target. Would be cool also to run some e2e tests against different browsers (eg: saucelabs).

[acdlite]

Actually, I don't. dispatch is a verb and suggests it is a complex function, probably with input parameters. state is a noun suggesting it is a property/value/instance or getter returning a property/value/instance. It doesn't matter what it actually is if all cases are accessed uniformly.

@vladap This is exactly what I said above. :D