Making the helper for server side rendering work with JS created by Webpack

[justin808]

I want to enable the system of externally packaged js code (via Webpack) work with the server rendering library here: https://github.com/justin808/react-webpack-rails-tutorial

While I can and probably should make a separate project, I was wondering if it might make sense to submit a PR to this project. In a nutshell, the webpack system creates one JS file that the server side rendering would use.

So there's just a tiny part of this project that's relevant which is mostly the view helpers.

[chrisvfritz]

👍 I also prefer using Webpack to manage my JS, so tighter integration would be helpful for me as well.

[rmosolgo]

Yeah, I think think this would be good fit! We have a problem with Sprockets in production, too: although sprockets might create a big, compiled file, it's not used by react-rails server rendering (#212 & #288).

How about this solution:

• You could implement CompiledFileRenderer (your call on the name :P) which builds on ExecJSRenderer
• CompiledFileRenderer accepts a path to file which should be a compiled asset including everything needed for server rendering: React.js, components and any dependencies

For Webpack users, they could use this renderer in dev & production, just pointing it at their bundle. For Sprockets users, they could use this in production and point it at the compiled asset.

One more consideration: Since Sprockets files often have a big hash in them which we can't predict, the path argument for this renderer should be suitable for Dir.glob (or something similar). That way Sprockets users won't have to worry about different hashes on different builds.

What do you think about that? It would be a big win for react-rails I think!

[chrisvfritz]

One minor addition I'd make is the ability to pass an array of file paths. I personally prefer to bundle my vendor assets separately from my application assets, resulting in two files. The reason is my vendor assets rarely change, but are (typically) the largest contributor to file size, while my (again, typically) smaller application code might update on production several times per day. For mobile users, having to redownload a much smaller file can make a noticeable performance difference.

[justin808]

We should probably have a skype to do some dual code reading. I don't know enough about Sprockets. However, I read the view helper code carefully. The thing about my webpack strategy is that all the configuration for the JS code is in the webpack config file, and ALL the js assets are underneath a /client directory so you can open up the JS code in a JS editor, like WebStorm. Based on reading some react-rails code, it seems like the trick is to make whatever react components global for running execjs. When webpack gets done with it's thing, it just creates one honking es-5 JS file that's got everything neatly bundled. That file is excluded from source code control.

Let's talk more on skype or slack.

[mchristen]

I would be careful using a glob to find the pre-compiled assets. sprockets-rails makes no guarantee that there won't be more than one version of the asset file. It specifically keeps around older copies on a rolling basis that is configurable.

See the documentation here for the specifics.

My workaround for that was to use a new ActionView::Base instance to call asset_path on, like so

ActionView::Base.new.asset_path('components.js')

[justin808]

The key question is whether it makes sense to have a separate gem that just has the helper methods, and then this gem could depend on the gem with the helpers.

I think this gem includes the react source and has close integration with sprockets.

My solution just requires including one specified JS file that is prepared by webpack either by a watch process during development (using foreman to start, for example), or pre-compiled.

The technique is explained here:
http://www.railsonmaui.com/blog/2014/10/03/integrating-webpack-and-the-es6-transpiler-into-an-existing-rails-project/

[rmosolgo]

@mchristen I guess you're right about possibly multiple compiled assets. I wonder if you could use the asset_path approach in the config, eg

if Rails.env.production?
  react.config.server_renderer = React::Rails::ServerRendering::StaticFilesRenderer
  react.config.server_renderer_options = {
    files: [ActionView::Base.new.asset_path("components.js")]
  }
else 
  # SprocketsRenderer etc
end

That would keep the renderer very "dumb" -- still just takes a list of files

[nikhilbaradwaj]

How about the following - When you run the installation script for react-rails gem, it creates a file called components.js and a directory called 'components' under 'javascripts'.

1. remove the components folder
2. components.js will require everything under the components folder. Remove this reference and just add a reference to the webpack pre-compiled js file (rails-bundle.js in the case of justin808's application).

Adding <%= react_component('ReactComponentName', {name: 'Something'}, {prerender: true or false}) %>
to the erb/html file should then work for both server side and client side rendering assuming that 'ReactComponentName' react component is globally accessible in the compiled js.

[justin808]

I'll create a fork and throw up a PR for us to play with. It will be really fun to get this working. I'll post a message once this is somewhat working. If anybody wants to work with me on this, please email me: justin@railsonmaui.com.

[justin808]

I published an alpha version here: https://rubygems.org/gems/react_on_rails.

It relies heavily on webpack. I'd be interested in possibly merging this code, but I'm not sure it makes sense since the approach is a bit different.

The API is a little bit different to support redux. You create a function that takes props and returns a React component rather than just rendering a react component.

Here's the source:
https://github.com/shakacode/react_on_rails/

[taylorbrooks]

Like @nikhilbaradwaj, I really only want to use react-rails for the view helpers and webpack for compilation and dependencies.

It would be awesome to have a bundled file (generated by webpack) like components.js -- which would include all the things.

And whenever I used the view helper <%= react_component("ComponentThing" ..... %> it would be smart enough to find that component in my bundled js file.

[justin808]

@taylorbrooks What are we missing in the gem https://github.com/shakacode/react_on_rails/ (BTW -- just about to merge a very important PR).