Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have it figured out. A long-winded explanation:

Honestly I hate the react-rails gem. Whoever was maintaining it kept doing things at the whims of issue requestors. I remember one instance where they broke our apps with an upgrade because someone decided it would be a good idea to shim a definition for `window` into server prerenders. All because an issue creator who didn't really know what they were doing supposedly "needed" that to get browserify-rails working.

So we made this: https://github.com/revelrylabs/execjs-rails. That handles the server-side rendering for us. We only use react-rails for its assets, never for its helpers.

And here's our own (always-evolving) layer on top of execjs-rails: http://toolkit.revelry.co/pages/core.

Examples are written in dusty JavaScript, but we've successfully used revelry_core with sprockets-es6 several times now.

EDIT: Still no modules yet. It doesn't help that Josh Peek deleted the old sprockets-es6 repo and all its issues before passing off maintenance to someone else.)



Wow! Thanks for this. I've been wrestling with getting ES6, React, and Rails to play nicely for some time. How stable is execjs-rails?


Very, actually. It's about time I add more tests, maybe remove its opinion about what view context to dump to JavaScript (leave that to the end dev), and version it as 1.0. I think it's had one significant bug in almost a year and no problem issues in the past 6 months.


Ha, so mere days after I told you it's stable I had to ship a fix to make sure that it was serving precompiled assets when they are available. We had never noticed because our server-side assets had never gotten large enough to go over Heroku's 60-second boot time limit. So anyway, if you're trying this out, please upgrade execjs-rails now. We cut our app's production boot time by roughly 80% by doing so.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: