Add context support

[sollycatprint]

From @wied03 on March 25, 2016 21:15

In react-opal, you can use the React context feature, like this. I can probably do a PR for this.

class ParentComponent
  include React::Component

  # Simply supply the Ruby/Opal type that :foo will be and react-opal will map that to a React PropType automatically
  provide_context(:foo, Fixnum) { params[:foo_value] }

  def render
    present ChildComponent
  end
end

class ChildComponent
  include React::Component

  consume_context(:foo, Fixnum)

  def render
    # will render the :foo_value prop passed into ParentComponent
    div { "foo is #{self.context[:foo]}" } 
  end
end

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

[sollycatprint]

From @ajjahn on March 28, 2016 14:29

@wied03 Please do!

[sollycatprint]

From @catmando on March 28, 2016 15:14

I would request that we keep the syntax consistent with params and state:

params.foo
state.foo
context.foo

Also I am not clear on what the type is for, does it have the same purpose as the optional typing of params? If so again I would want to see consistent syntax.

[sollycatprint]

From @wied03 on March 28, 2016 15:16

You are required to give React a proptype for context. My code converts the Ruby type into a proptype. You could just give it an Object type for everything but I figured I would try and play nice.

[sollycatprint]

From @wied03 on March 28, 2016 15:18

@catmando - As to context.foo vs. context[:foo], I guess you guys changed react.rb after my fork to return a method missing type class instead of a Hash for params to allow params.foo ?

[sollycatprint]

From @wied03 on March 28, 2016 15:20

It looks like PropsWrapper is being used for that. Why do the cache? To avoid camel_casing, etc. again? How are you marking the cache dirty when a re-render happens?

[sollycatprint]

From @catmando on March 28, 2016 15:33

context.foo vs. context[:foo] is just syntax sugar right? it can do the same thing under the hood.

Interesting that React requires a proptype. So do we want to be consistent and make it optional (and if not provided we will just use Object as you suggest.)

So syntax would be consistent with params

provide_context :foo, type: Bar or provide_context :foo # equivilent to adding, type: Object

[sollycatprint]

From @catmando on March 28, 2016 15:35

I realized I don't have the initializer in the above, but again would like to make it all consistent with param for ease of learning.

[sollycatprint]

From @wied03 on March 28, 2016 15:37

What about the caching question?

[sollycatprint]

From @catmando on March 28, 2016 15:43

I'm leaving that to @ajjahn. I'm just going from the standpoint that there is no reason why we can't make context.foo work the same as context[:foo]. In fact it should be easier if we wanted to work on it to make context.foo slightly faster than context[:foo].

[sollycatprint]

From @wied03 on March 28, 2016 15:44

@catmando - I agree there, my mind moved on to the internals of PropsWrapper

[sollycatprint]

From @catmando on March 28, 2016 15:55

right... so we want to redo the PropsWrapper (and validation too) so that it works for props, and context, plus it work for class level props, and special param types (like observables) without adding burden to the base function if you don't use those features...

[sollycatprint]

From @wied03 on March 28, 2016 15:56

And I'm cool with doing a PR for this since I already wrote it in react-opal. I'm mainly curious about the cache question now.

[sollycatprint]

From @ajjahn on March 29, 2016 2:56

@wied03 That cache was added to address #124 and #125.

@catmando You implemented a fix for the 0.7.x branch (in a different way). When I pulled it into master things had changed, so I brought the spec you wrote along and made it pass.

Those issues are only issues because of the _react_params_conversion, which I feel is a code smell anyway, and not a responsibility of react.

@wied03 We've had discussions on the state and props wrappers. I believe they both could use some TLC. Especially the implementation of state and observables. Too many objects know too much about each other.

[sollycatprint]

From @wied03 on March 29, 2016 3:24

@ajjahn - I'm not really as curious about why the cache is there as much as how you know when to clean it out. If you have a re-render of a component, doesn't the cache as is stick around?

[sollycatprint]

From @catmando on March 29, 2016 15:31

okay so if part of the confusion is being caused by _react_params_conversion, then lets wrap up that discussion. ( #96 )