Add context support

[wied03]

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

[ajjahn]

@wied03 Please do!

[catmando]

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.

[wied03]

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.

[wied03]

@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 ?

[wied03]

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?

[catmando]

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

[catmando]

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.

[wied03]

What about the caching question?

[catmando]

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].

[wied03]

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

[catmando]

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...

[wied03]

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.

[ajjahn]

@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.

[wied03]

@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?

[catmando]

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