implicit state declaration

[sollycatprint]

From @catmando on November 25, 2015 21:40

why even declare states?

state :foo

is completely redundant, and is at odds with the rest of ruby. executing state.foo should just create foo if it does not yet exist. Typically this will happen in the before_mount macro. This also solves confusion that several people have had because the state macro runs at the class level (not in the instance) but yet it is creating instance level objects.

I vote we allow state variables to (just like instance variables) be created as they are referenced. (method_missing to the rescue)

Why not params: because params do need to be explicitly declared in ruby, so it is again consistent

Copied from original issue: zetachang/react.rb#87

[MichaelSp]

Vote:
👎 for explicit state :foo # at class level
👍 for implicit state.foo # everywhere

[adamcreekroad]

I do like explicitly defining all the states. It allows me to quickly see all/any states at first glance without having to look through a possibly large file, and have a chance of missing one. To me there is a point where there is too much magic, but it really comes down to personal preference. I think both ways should be allowed.

[fkchang]

If I read it right, state at the class level is sort of the corresponding call to getInitialState(). This can work for primitive types, but you can't access params and other instance functionality because it's at the state level, so it only looks like it's parallel but isn't. I'd say keep it at the class level only if we can have it give access to the instance level functionality. Otherwise it can be confusing

[janbiedermann]

using state foo: 12 at class level from lap20 onwards sets state synchronously nicely without causing a second render.
using implicit state at instance level may cause a second render unless used in callbacks that allow for a synchronous setState() call

[catmando]

The issue here is whether states MUST be declared before use (like Params)

The answer currently is NO for instance states, yes for class states

The only thing is some folks (i.e. @adamcreekroad) like to declare states for readability. I think we should leave this problem open, and in the future implement a config variable state_declaration_required that defaults to false, but if set to true, will throw errors if states are used and not declared. This will make mr. @adamcreekroad and his ilk happy.