Are there reasons not to use this in production?

[abitdodgy]

I'm considering React for an app due in three months. I realise this is not yet stable, but is there a reason not to start using it for some basic components?

[rmosolgo]

No reason not to use it in production! I'm using all over PCO Check-ins with no problem. Only caveats:

• You have to use some tricks if you're using commonjs requires (react-rails incompatible with browserify workflow #129 (comment))
• For best results, use the latest turbolinks version (react_component not rendering on browser back navigation #159)

[danott]

I work side-by-side with @rmosolgo, and it's definitely usable in a team environment. The minimal surface area of the react_component helper and react_ujs for mounting is easy to wrap your head around.

Let us know if you run into any pain points along the way!

[abitdodgy]

@rmosolgo @danott thanks guys. That gives me a lot of confidence. Would you be kind enough to elucidate:

1. When to use server side rendering versus browser rendering?
2. How do you wire up your restful Rails routes and pass them to the component?

I have a mental gap of how to bridge the Rails app with something that is meant to handle the view layer only.

[bowd]

@abitdodgy another vote of confidence from us at Anyroad, we recently deployed this in production (we've been using React standalone for Anyguide for a while now).

My take on your questions is:

1. We opted for react-rails for server side rendering because we want to facilitate search engine indexing and other crawlers on this part of our product. Which means that right now we pre-render everything, and it's really fast. But I can imagine you could turn it off on some components if you don't care wether they get indexed or not.

As a side note we also realised that top level components (the ones you render in rails) are pure functions of props (or at least should be IMO), which makes them great for fragment caching, as you can use a serialised version of the props (or an MD5 of it) as a cache key for components, which works pretty well (but won't shave off that much if you don't have complex component hierarchies).

1. The way we structured things we basically have normal templates for our actions but these templates just render a few top level components. If you go to our landing page on Anyroad you can imagine that all vertically divided sections are top level components.
   In order to render these components we need props for them, and that's the main job of the controller actions now. We have these sorta decorator/presenters that can be turned into a hash of props for each component, and they can reuse each other. For example the 3 cards on the landing page are setup as props inside of a presenter for that section, but the actual props for each card are built by a separate presenter that is build to be used with the card component.

As a side note we also have these kind of presenters for stores, that render our initial state that gets injected into our Flux stores when the app boots on the client. And this will be synced to the props that our top level components get (ones rendered server side), and as a convention we consider all the props that we pass in on the server to be part of the initial state (because it's not like those components can receive other props). This way the components get booted up with the correct initial state and they are wired up to receive changes from the stores that are also booted up with a synced initial state. This makes it really nice to reuse logic and build apps that can be both single page or not.
This works great for our search page. The state you can get to by filtering is exactly the state you would get if you refresh from the server with the filters in the url, because when you actually filter client-side, the api request comes back with the same store presenter that was uses server side, so that just gets swapped into the store and all components update.

Ok I went a bit overboard without explaining a lot of things but I hope this at least gets you excited :)

[abitdodgy]

Thanks everyone and @bogdan-dumitru for chipping in. I think sometimes it's best to take the plunge and see what happens. At this point I'm not concerned about react-rails. I'm more concerned about my ability to be productive doing SAP. Only one way to find out.

[rmosolgo]

FWIW I don't actually use it to go full-SPA. I just use React components like I used to use complicated jQuery-powered bits -- just complicated, dynamic UI elements. It's like a more maintainable alternative to mutating the page with random jQuery.

Seems like that's how FB uses it too: https://twitter.com/floydophone/status/557348616080076800 (at least for that part of the app)

[abitdodgy]

@rmosolgo yes, I figured that might be the use case, and I intend to use it the same way. I'm just worried about taking the plunge without enough guidance and info out there on integrating it with Rails. I feel like I'm always ready to just fallback to jQuery because I already overcame the learning curve and I can do it quickly. But I also despise the lack of maintainability of spaghetti jQuery.

[oguzbilgic]

I would suggest you to install React Developer tools for Chrome [0] and just go explore how other people structured their components such as anyroad.com or even facebook.com :)

[0] : https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en