I'm trying to learn how to use react in my rails 5 app.
I've just finished following Kenny Hibino's you tube series for his medium clone. He used react-rails gem, but then realised he wanted to use the react router.
The alternative gem is react-on-rails. There is a lot of commentary on this gem that concludes it is heavy.
A further alternative is not to use either of these gems and have a react front end app with a separate rails back end app. I've just finished the udemy course by Stephen Grider on getting started with react (Modern React with Redux). It gives a very clear overview of react and JSX.
Has anyone had any experience with this third option? I'd like to learn how to use the separate app concept before I decide to invest time in learning how to use react-on-rails, especially if that gem isnt a solid solution (I see the advice on the gem page is not to use server side rendering as a default). I cant find an intro course to using rails with react (apart from Kenny's video tutorials, which he has realised don't get him to where he wants to be re the router). I've read several medium posts about choosing one gem or the other, but I'm now looking for an option without a gem.
I just found the pluralsight course. I'll give that a try & come back to let anyone else that's interested whether learning Flux looks like a good option.
At work, we created a webapp that used React for its front end. The back end was a separate app acting as a web service. We didn't use Rails though, we used Koa (a Node.js web framework).
If you need React routing, I feel like it would be difficult to mix Rails routing and server-generated views with React routing and how React does views. I would design your app so that React had complete dominion over the front end and use Rails as a separate back end app.
Given that you've completed Grider's course on React with Redux, you probably have a pretty good understanding of React by now and you may end up being really happy with what you can do with an SPA design pattern.
Having your front end and back end decoupled like that is also great in that you can upgrade to future versions of Rails or switch to different frameworks entirely for your back end app and it will still be compatible with your front end app as long as you stick to the API you created between them.
@Melanie, I'm definitely interested to hear your thoughts on the Pluralsight course. Thanks!
Great question Melanie!
Hey Matthew do you have any resources that you would recoment that follows the same principal of having front end and back end decoupled?
That's a good question. Truth is there are lots of resources out there. I've used books, Coursera courses, this site, random documentation... lots of sources as I've learned web development.
Any resources that preach an "API first" approach and show you how to use Rails in
--api mode will demonstrate that loose coupling well.
If you're into books, one I can recommend is Rails, Angular, Postgres, and Bootstrap from Pragmatic Programmers:
It's about combining Rails with Angular. The first edition of the book uses AngularJS, and the second edition of the book (which is not yet published) uses Angular. They both use Postgres as the database and include styling with Bootstrap. It's very comprehensive.
One note is that it doesn't do the 100% separated back end and front end approach. It's not completely loosely-coupled. The author argues that the book fills a niche of helping Rails devs add Angular to their apps. I still found it nice to read to help me get going with Angular. By having it a little bit coupled together, you save some effort since Rails can do a lot for you.
If you do decide to go the completely loosely coupled way (no views in your Rails app, no ERB, --api mode, non-devise auth), then the JWT and "let's make an API" series Chris did on this site will help you out big time. Your goal at that point is to design a Rails app that connects to the database and serves up JSON data from its endpoints, and a front end app that doesn't care where it gets its data from, and glue them together with your knowledge of how HTTP works.
I'll check out the book. And I'll start looking for a good read on resful rails development. :D
I will also check out the GoRails episodes on APIs.
@Melanie, I think you also have the option of using React with Rails without using either of those gems (react_on_rails and react_rails).
I believe Rails 5.1 will include webpacker that will allow for React to be added to your Rails app with:
rails webpacker:install:react # Install everything needed for react
I've yet to try this myself but am just letting you know that it might be an option.
Some articles that touch on this:
Feedback on the pluralsight course. I didnt get much from it. It uses react-rails on the front end but rails still runs the application. I was trying to learn how to let react control the frontend, so for me it wasnt what I was looking for.
Thanks Mark Radford for the links. Some of the feedback I've found on using webpack is that it makes the front end smooth, but there will still be duplication in the back end if it's seved by a rails api - as opposed to a node mongoDB stack.
I dont want to get too caught up in this because I think it might come down to preference. Reading the materials Mark shared, I'm keen to use the process that Stephen Grider's course has shared and skip the gem in favour of setting things up directly.
Do you know of any links to examples of react on rails applications that have been created using the webpacker gem instead of other gems such as react-rails?
It's probably too new to see many examples of this implemented. But Chris's latest episode as of right now is about using Webpacker, so that might be a nice place to start. :)
Hi Gabriella, I'm using webpack on the client side (its one of my node modules), so I dont think I have use for the gem.
I ran into a similar problem with an old client. They wanted a React frontend with a Rails backend and the routing mixed with React-Router was a nightmare. So I rewrote the backend to be 100% API driven and the frontend is served up and is 100% react which makes HTTP requests to the API backend.
If you need any help with this, feel free to reach out in Slack
Great - thanks nynhex. I'm trying to figure this out now. Most of the courses I'm finding are node backend API - makes me think its time to learn node. i'd love to know your general configuration. I'm struggling to make initial architecture decisions
Node.js is pretty nice. I use it a lot at work. It's designed for non-blocking operations from the ground up, so where in Rails you'd have to use threads or concurrency libraries to speed things up, in Node.js that's just how it is.
I think it's worth knowing more than one technology stack, and I'd recommend learning Node.js when you can. If you're interested in web frameworks for it, there's Express but there's also its successor, Koa, which is designed very modular (opposite of Rails, throwing in everything).