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 )

[sollycatprint]

From @ajjahn on March 29, 2016 15:50

@wied03 The cache for a prop busts if the underlying component's prop has changed. There isn't a need to mark the entire cache as dirty. When the prop is accessed (regardless of renders), the current value of the prop is examined.

Really, the argument could be made that this caching is a concern of the object that responds to _react_params_conversion. It should memoize it's converted value, and return it on subsequent calls. If a new prop arrives that responds to _react_params_conversion, it's value will not yet have been memoized, and the conversion will take place.

[sollycatprint]

From @wied03 on March 29, 2016 15:55

I'm guessing that the complexity of the cache is worth it? Was it really that expensive to do the camel case/native conversions on demand?

[sollycatprint]

From @ajjahn on March 29, 2016 16:28

@wied03 I don't believe camel case/native conversion was the primary reason. The problem here is react.rb has some reactive-record feature envy. Reactive record is counting on react components to deserialize it's models that is is passing as props. I'd like to see serialization/deserialization removed. It belongs elsewhere. So as @catmando suggested, it would be helpful to converge on a consensues in #96.

[catmando]

on hold (I think) until we get #96 figured out.