[proposal] allow initialState to be set in store's config

[fvgoto]

Instead of having

getInitialState(){ // same as React!
      return {
        text: 'Use Cartiv!',
      }
},

in the store definition (second arg to createStore), it would be nice if we could just do

  initialState: {
    text: 'Use cool Cartiv!',
  },

in the store config (first arg to createStore).

PRO:

• If getInitialState is mandatory or virtually always used, it's better placed in store config, I think.
• We can save typing the function stuff and the return (most of the times initial state will be a kind of primitive object (nothing to be evaluated)).
• Avoids mixing up this "special" method with all the reducer-like methods, which store definition part has been designed for.

CON:

• It would not fully comply to the same as React! thought any more...
• If ever we need the initial state to be calculated and it depends on other methods defined in the store definition section (that is using this context), we've got a little problem. Solution would be to accept also a function for the initialState, in which case Cartiv would need to invoke it at the moment when initial state is effectively setup/requested. Thus initialState should/could probably accept a plain object, as well as a function. (Thinking of _.result...)

What about storeDidUpdate?

• If you "move" also that one to the store options (as an optional), the store definition would have left only the custom "reducer-like" methods (and that would play well with #2) - nice, isn't it?
• BTW: Are there other such "magic" (or special) methods?

Maybe you could/would allow both ways:

• allow it in the store definition (legacy, backward compatibility) and
• allow it in the store config (this proposal).

[yonatanmn]

The con of not being like React is crucial to my opinion.
The pro of amount of code is not that important, so I won't change naming of getInitialState.

I understand your concern about mixing "reducer-like" methods with rest of store methods.
In React you have some lifecycle methods, some normal methods and some event-driven ones (onChange). They all live in the same place and it became 'normal'. In Cartiv it's a bit different because you need to explicitly say which are the event-driven methods, but apart from that, it's quite the same.
In your solution - I'd still need to name\filter all api methods, if I don't want the expose all store-definition methods (like __someInternalComputation).
Also, if you seperate it to other object, you won't be able to do: this.getInitialState()
So I'm not sure yet about that, but I tend to leave it as is.
Allowing both ways sounds like a source for a lot of confusion.

Store lifecycle methods - getInitialState, storeDidUpdate, shouldStoreUpdate (documentation needed).
Not implemented yet: storeWillUpdate

[fvgoto]

ACK to confusion if allowing two ways for initial state.
Right about mixity in React also, thus no issue...
Thanks for lifecycle method list.

Many thanks for the discussion! - I'm closing this one.