State should be able to be an array

[timwis]

I have a "tables" model that's a collection of tables. I would expect to be able to set my state property to an array within the tables namespace and the resulting global state look like: { app: {}, tables: [] } as it would in redux. Instead, if you set the state to an empty array, it's not included in the global state. If you set it to an array with a value, it gets set to {tables: {0: 'that value'}}.

Not a big deal, just thought I'd point it out. At first glance I imagine it could be an issue with apply or xtend.

[yoshuawuyts]

Hmm, I think this ties further into whether or not non-objects should be supported at the top level. If you're not using namespaces it should diff just fine. We could probably detect if an obj

Just to verify, what you're trying to achieve is:

app.model({
  namespace: 'tables',
  state: [],
  reducers: { /* things go here */}
})

Given the approach I'm proposing, this should be possible too:

app.model({
  namespace: 'something',
  state: 'foobar',
  reducers: {
    update: (state, action) => state + 'bar'  // 'foobarbar'
  }
})

does this make sense?

edit: fixed typo as per comment below

[timwis]

That's right. Of course state is the property name rather than model but yes

[yoshuawuyts]

hah, you're right - derp. Fixed!

[yoshuawuyts]

I reckon this should land in 3.1 not 3.0; wanna narrow down the scope a lil and have barracks at 100% coverage before adding big changes to the merging algorithm

[yoshuawuyts]

Hmmm, I think arrays should perhaps be the only ones that can exist in the top level scope too; adding all other types throws us down JS type equality hell, which def isn't where we want to be.

[yoshuawuyts]

yeah feel like this might be the solution to models troubles (: - well, if we add some docs and patterns too - selectors feel like v. useful - probs if we add plugins too we could do some amaze things C:

[yoshuawuyts]

Closing because choo@5 will introduce a new API. See #425 for the merged PR. Thanks!