ruby-hyperloop / hyper-react

The project has moved to Hyperstack!!
https://hyperstack.org/
MIT License
285 stars 14 forks source link

implicit state declaration #87

Open sollycatprint opened 8 years ago

sollycatprint commented 8 years ago

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 commented 7 years ago

Vote: :-1: for explicit state :foo # at class level :+1: for implicit state.foo # everywhere

adamcreekroad commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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.