Observer free code path for state

[sollycatprint]

From @wied03 on March 25, 2016 21:17

For those of us that use the GrandCentral/Redux approach and keep most state outside the component, we don't want to hit any Observable code for any incidental state calls. I'm assuming that any Observable code remains light to keep file sizes down.

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

[sollycatprint]

From @ajjahn on March 29, 2016 15:54

@wied03 I agree that observable state shouldn't be required. This could be addressed in the state definition by passing an option. Not sure if it should be opt in or opt out, but I like declaring it for the purpose of having self documenting components.

[catmando]

@wied03 okay I've assigned this to myself to wrap my head around it...

[zetachang]

Haven't actually got a chance to try out Observable state provided, but other than redux, reactjs community is also using MobX which provide observable state management by a different way. It actually wrap either class / property / collection as observable and you could just fire the mutation using the plain old property writing syntax without worry about subscription since its automatically done by a single observer call at the top.

const TodoView = observer(({todo}) =>
    <li>
        <input
            type="checkbox"
            checked={todo.finished}
            onClick={() => todo.finished = !todo.finished}
        />{todo.title}
    </li>
)

[catmando]

@zetachang - the above is what reactrb State does.

The problem is as @wied03 points out is its too wrapped up in the base react code.

I think the base reactrb-dsl (or whatever it gets called) has none of this enhanced semantics, except some minimal code hooks necessary to support it (i.e. React::RenderingContext)

To get the advanced flux/redux like mechanism we have another gem reactrb-flux-state or some such.

This adds the ability to create flux/redux like states that are separate from a specific component.

including the reactrb-flux-state gem gets you the current reactrb class level state semantics.

There is also the notion of "observables" ... I think we can deprecate these.

[zetachang]

I am planing to work on a version of State which is decoupled with this.state managed by ReactJS.

This may give a better chance for us to extract this out as separate library or at least let user decide what kind of state management approach they want to use.