set method creates keys on store itself

[tommoor]

Using the set method to set keys that are in the scheme it seems as though the data is set on the store object itself, wouldn't it make more sense to have some sort of data object within the store so that these properties aren't mixed in with other methods?

Maybe I'm missing something...

[darcyadams]

I agree. Been hoping to get around to this for awhile, but haven't made it happen yet. If you want to take a stab, go for it.
I must say, it is handy to have them as top level attributes when you need to do data manipulation as opposed to setting, but I agree that the potential for accidental conflicts outweighs that minor benefit.

[tommoor]

Okay, glad I'm not going crazy - I also expected there to be some sort of default getState method implemented and I ended up just having to do:

getState: function() {
  return this;
}

which isn't great.

[darcyadams]

Well, the benefit of using scheme is that the scheme attributes are automatically applied as state in the views with the flux mixin. If you don't use scheme, yes you have to manually define a getState method.

[darcyadams]

... Actually the need to define the getStae method is what led to the initial idea for the scheme enhancement.

[tommoor]

Got it, this is useful.

I guess the problem is that only a few of our stores are treated like models (one for app state for example). The majority of stores are used as the flux architecture expects - more like a collection of models. This is why I ended up implementing a getState method so that there was a consistent way to access the data across these different types of stores.

Ideally the scheme methodology would work with a collection/array as well and implement a standard method to get as well as set the data imo.

[darcyadams]

closing as this is now corrected in master