Skip to content

pass context to the ruby racer #298

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
catmando opened this issue Jun 15, 2015 · 8 comments
Closed

pass context to the ruby racer #298

catmando opened this issue Jun 15, 2015 · 8 comments

Comments

@catmando
Copy link

We need to pass some ruby context to the ruby racer engine during the server side rendering process. This is a very powerful capability which allows us to access server models during pre-rendering.

I propose the following solution:

  1. in the prerendering options allow this:
    prerender: {context: {some_context: some_object, other_context: some_other_object}, static: true}

  2. each of the context values is sent to therubyracer(v8) engine using the context key.

Of course it requires therubyracer.

I have the following code in a branch that implements this and would be happy to do a PR:

module React
  module ServerRendering
    class SprocketsRenderer

...

      def render(component_name, props, prerender_options)
        if prerender_options.is_a? Hash
          if ExecJS.runtime.name == "(V8)" and prerender_options[:context]
            raise PrerenderError.new(component_name, props, "you must use 'therubyracer' with the prerender[:context] option") unless ExecJS.runtime.name == "(V8)"
          else
            prerender_options[:context].each { |key, value| @context.instance_variable_get("@v8_context")[key] = value }
            prerender_options = prerender_options[:static] ? :static : true
          end
        end
...
@rmosolgo
Copy link
Member

Wow, that's a really cool idea!

I'm hoping to enable this kind of creativity by the React::ServerRendering.renderer = API. This allows you to implement a server renderer and hook into the rest of react-rails.

A renderer should implement:

  • #initialize(options) which receives react.config.server_renderer_options
  • #render(component_name, props, prerender_options) which returns rendered markup to put into the document.

Do you think this kind of feature could work with that extension API? I want clean up SprocketsRenderer a bit too, see #299

@catmando
Copy link
Author

Yes I am great with that approach... All that the code above is doing is a little preprocessing of the incoming hash, plus it does need to get access to the underlying evaluator. If the API could present the base render function, and access to the evaluator then no PR is needed.

Is that API available today?

@rmosolgo
Copy link
Member

also if you get something like this together, I'd love to add a wiki page or something and link to it! There aren't any other contrib-type projects yet but I think that would be great.

@mchristen
Copy link

👍

Currently our approach to setting React context data on a top level component is to set some properties that are used as 'initial data' for a component that are transferred into the context object.

Having this means we could forgo that convention and be able to specify the React context in much the same way we would specify properties, with the benefit of not having to mix data with properties/state.

@catmando
Copy link
Author

Okay! Probably get back to cleaning this up in a couple of weeks (I've got this working good enough for us for now) looking forward to it!

@rmosolgo
Copy link
Member

rmosolgo commented Sep 3, 2015

somewhat relevant to this thread is my PR to re-implement the view helper to be request-aware. You get one instance of the helper per request. #346

(sorry, wrong button!)

@rmosolgo rmosolgo closed this as completed Sep 3, 2015
@rmosolgo rmosolgo reopened this Sep 3, 2015
@rmosolgo
Copy link
Member

rmosolgo commented Dec 9, 2016

Seems like this was addressed, but I forgot to close it!

@rmosolgo rmosolgo closed this as completed Dec 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants