Hacker News Reader

Comment by jamie_ca | Hacker News Reader

Because Rails has 10+ years of development on backend tooling that shouldn't be nixed or reinvented on account of a reorganization of files?

Yes, it replaces view rendering completely with Cells, but routing, dispatch, request serialization, activerecord, asset pipeline, rails-provided view helpers and more are all used basically as-is.

View on HN

The view rendering doesn't need to be done by Rails. I've been using React and Webpack to build the clientside of my Rails apps and have been very happy with that approach. There is nothing that this architecture does that a clientside framework like React cannot do better.

How do you store/version/deploy that, by the way? Do you build your Rails project purely as an API, and a separate project/repo for the React client?

It doesn't make sense to replace Rails views completely in my view. There are parts of the app that are still being served by Rails views because they are not mission critical or have a great solution already in-place. Where React comes handy is when you have an interactive one-page app with a lot of moving parts. I have 2-3 React apps in this current project. Webpack is a great solution for packaging your css, js and other assets in logical units. I think it's much better than Sprockets, but it requires some configuration.

I've played with Weboack for toy projects. Do you have one Webpack project that builds and watches all your React apps, or do you treat each separately? I have a larger project on my todo list, and I'm considering doing a Rails API and a single React app for everything on the client (including URL routing).

Do you use Flux as well? Do you use a router system or still let Rails do most of the routing?

Yeah, I do use Flux, and I love it. I use a mixture of both Rails and a clientside routers, but Rails does most of the work for sure.

Reply on news.ycombinator.com