Proposal: make exported store name insignificant

[gaearon]

When specifying Container or @container, the name under which the store is exported is insignificant. You just assign it a string key:

@container({
  stores: { counter: counterStore }
})

and it appears as counter.

There is now a single place where it's still significant: the action creator callback form.

export function incrementIfOdd() {
  return (dispatch, state) => {
    if (state.counterStore % 2 === 0) { // reading from counterStore state here
      return;
    }

    dispatch(increment());
  };
}

It's not obvious that it's called counterStore because of export { default as counterStore } from './counterStore inside stores/index.js passed to the @root.

An alternative is to let state be ES6 map with Store functions as keys. Then you'd do

import counterStore from './stores/counterStore';

export function incrementIfOdd() {
  return (dispatch, state) => {
    if (state.get(counterStore) % 2 === 0) { // get state for the store
      return;
    }

    dispatch(increment());
  };
}

This code won't break if you rename the export, and also makes the dependency clear.
Thoughts?

[emmenko]

Sounds like a good solution!

[hugooliveirad]

Looks good for me too. I like the ideia of passing the store to get it's state. Passing a string to do that is something that I dislike in e.g. Flummox.

ES6 Map api is simple enough too.

👍

[gaearon]

Maybe shouldn't even pass an ES6 Map and instead pass just the read function. This reinforces that the state is meant to be read-only, doesn't introduce a dependency on a specific type and also forbids weird things like enumeration.

export function incrementIfOdd() {
  return (dispatch, read) => {
    if (read(counterStore) % 2 === 0) {
      return;
    }

    dispatch(increment());
  };
}

[emmenko]

👍

[gaearon]

If somebody wants to PR this, I'll take it.

[gaearon]

If you do decide to PR this, note that internally we still need to use string keys for storage. This is because functions are hot-swapped on every file save, and their identities change. This is why we have an { key: string -> state: object } object for state, and a { store: function -> key: string } ES6 Map for mapping Store functions to state keys.

[gaearon]

Fixed via ac1be83, thanks!