Stores not "composing"?

[levibotelho]

I'm having a bit of a hard time understanding the example provided on the main page in regards to stores.

I have two stores defined, each of which consists of a single function that returns an object. When creating my redux instance, I do the following:

var stores = {
    authenticationStore: require("../stores/authentication-store"),
    signUpStore: require("../stores/sign-up-store")
};

var dispatcher = Redux.createDispatcher(
  Redux.composeStores(stores),
  function (getState) {
    return [promiseMiddleware(getState), thunkMiddleware(getState)];
  }
);

So far so good, as far as I can tell.

My problem is that in the select method on one of my components, I attempt to read the store values as follows

function selectSignUpFormProps(state) {
  // signUpStore returns an object containing signedUpUser and signUpError properties.
  return {
    user: state.signedUpUser,
    error: state.signUpError
  };
}

However instead of containing signedUpUser and signUpError properties as I would expect, state contains authenticationStore and signUpStore properties which contain the return values of their respective functions.

By looking at the demo on the main page of the repo, I was under the impression that the results of my store functions would be composed into a single state object, and not subdivided by store. Am I doing something incorrectly, or is my understanding of stores/state flawed?

[dariocravero]

@levibotelho that behaviour is expected. What's going on behind the scenes is that each store's state is essentially held in a "big object" that holds every other state in redux. When you "slice" them through a selector you're gaining access to that object and your selection process starts from there. () I guess that the examples are still too shallow as to show the pattern at its full extent. For example, the todomvc container gets all todos, it so happens that the store is called *todos and that its reducer returns an array so it's very simple.
This explanation by @gaearon might help shed some light anyway.

I think we need larger examples to show this. I'll make sure to publish back our new code as it happens these days as it might be useful to a larger crowd :)

EDIT: (*) Mixing every property of your stores in a huge bag of "things" mixed by your stores' results wouldn't be very handy as you would very quickly have clashes.

[taylorhakes]

As @dariocravero said, the stores are subdivided by the name of the store. It prevents conflicts in naming and allows you to know which store you are accessing. If you take a look at this https://github.com/gaearon/redux#smart-components , it shows the counter store property being accessed on the state.

I definitely agree more documentation around selecting state is needed.

[dariocravero]

ref #140

[levibotelho]

@dariocravero @taylorhakes Thank you both for the explanation. I agree that it makes total sense to split up the stores -- I was caught off guard by the todo project which indeed is so simple that it made me think I was missing something. Thanks again!

[dariocravero]

:)

[gaearon]

Closing as not an issue.
We'll provide better docs!