Alternative to require() ?

[remyyounes]

According to these discussions #33 #64, "supporting additional gems like maccman/sprockets-commonjs is outside the scope [...]."
So, I have been trying to look for an alternative way to load copyProperties other than using require with commonJS.
This is how i would normally get it:
var copyProperties = require('react/lib/copyProperties');

Of course, I could just provide my own copyProperties or just not use it at all. But it would be nice to have those utilities.
I've been searching but haven't found a workaround. What would you suggest ?

[lcmen]

+1 I have the same issue.

Right now the only solution I came up with includes copyProperties file in my project.

[remyyounes]

I ended up dropping sprockets.
For now, we're packaging all our React stuff with NPM and we import the output bundle from our main application.js file.

[richsoni]

@remyyounes are you handling isomorphism with this solution? I already have a similar stack, but have not solved that yet.

[jtmalinowski]

If I remember correctly - we would have to prepare a different build of React to expose require, but this might have changed. Do we have a way to do it now (i.e. implement #33) ?

[mczepiel]

I think I've stumbled into this same problem myself trying to use CommonJS modules.

I pulled my react app out of the asset pipeline and am browserifying and reactifying it on the side. I now include the resulting bundle.js alone inside the application.js manifest and rely on react-rails for the view helper and react_ujs alone*

application.js

//= require bundle
//= require react_ujs

As a wrinkle/legacy solution I have kept react_ujs in place and modified it to look for React and MyComponent, not within window, but within a configurable namespace so I can:

browserify index.js --standalone MyApp -o app/assets/javascripts/bundle.js

module.exports.React = require('react');
module.exports.FooApp = require('./components/foo/App.react');
module.exports.BarApp = require('./components/bar/App.react');

and find MyApp.React and MyApp.FooApp from react_ujs.js after the bundle has loaded:

(function(document, window, namespace) {
  ...
  var React = namespace.React;
  ...
  var constructor = namespace[className] || eval.call(namespace, className);
  ...
})(document, window, <%= Rails.application.config.react[:standalone_namespace] || 'window' %>);

I'm not sure if this is doing more harm than good at the moment though, I could just code each top level App I have to look for its own DOM node and skip react_ujs but I figured not including that would help me with server side rendering.

*Pre-rendering was the main reason I pulled the react app out of the asset pipeline; I couldn't figure out how to get the exejc or commonjs.rb runtimes working within the existing prerenderer without hacking up execjs itself to pass along the require.

I'm tempted to patch react-rails's prerendering to optionally use an external service
Does a nodejs react-component-rendering project exist already?
Does any of this sound like a worthwhile direction? I'm just getting back into rails and am new to react.

[lcmen]

Using Browserify outside of Assets Pipeline sounds good but how you debug your application then? Do you generate a source map alongside that bundle?

[mczepiel]

To be honest I've invested more time in getting this all working than building an app worth debugging :-/

But yes, I have my watchify task generating sourcemaps with the --debug flag.

There are certainly more moving parts this way but I don't know enough of about the ecosystem to understand how commonjs support will arrive.

FWIW I think I also had rails-browserify working at one point which I think was fine for the client side but didn't change the situation on prerendering at all.

[mczepiel]

Oh and hmm found this and it does indeed work, with some tailoring:
http://stackoverflow.com/questions/26048771/render-react-components-from-php

I might just put this in place myself locally and keep an eye out for any more polished solutions.

EDIT: Well that works fine just added node-jsx and replaced the prendering with an HTTP call to the node server and I have server side rendering and with the aforementioned mess I've made above I have it working in the client side as well. Not sure this was worth it though…

[jtmalinowski]

Aside from modifying react_ujs, I guess it would be dead simple to just fork this repo, change our code in https://github.com/reactjs/react-rails/blob/master/lib/react/renderer.rb, maybe make require global if necessary, you would have it working in ~30 minutes - if I understand what you want to achieve.

[mczepiel]

Yep, actually cleared up much of the customization of react_ujs by having browserify --require react and then just var React = require('react') works as expected.

The call to the node service is a couple lines of code in the renderer. So far, so good; I am now requiring react and not including it via a script tag and server side rendering works fine. I can do work to make it available to others if anybody is interested, but it's a little hacky customized right now.

[superplussed]

Can anyone speak to whether @JakubMal's suggestion or something similar is on the roadmap? I love the integration with Rails but this is an issue I keep running into.

[rmosolgo]

I don't plan to add commonjs require support to this gem, but I'm certainly open to it if someone else wants to add it. If Sprockets adopts a new dependency management strategy, I'll keep up with that!