By Justin Gordon, January 26, 2016
This document is an extension and complement to The Rails Doctrine. If you haven’t read that document, I suggest you do so first.
Besides the project objective, let’s stick with the “Rails Doctrine” and keep the following in mind.
Optimize for Programmer Happiness
The React on Rails setup provides several key components related to front-end developer happiness:
- Happiness for us is actively participating in open source, so we want to be where the action is, which is with the npm libraries on github.com.
- You can get set up on React on Rails FAST using our application generator.
- By placing all client-side development inside of the
Convention over Configuration
We’re big believers in this quote from the Rails Doctrine:
The same goes even when you understand how all the pieces go together. When there’s an obvious next step for every change, we can scoot through the many parts of an application that is the same or very similar to all the other applications that went before it. A place for everything and everything in its place. Constraints liberate even the most able minds.
The Menu Is Omakase
Here’s the chef’s selection from the React on Rails community:
- Bootstrap, loaded from bootstrap-loader. Common UI styles.
- Lodash: Swiss army knife of utilities.
- React: UI components.
- React-Router: Provider of deep links for client-side application.
- Redux: Flux implementation (aka “state container”).
- Babel: Transpiler for ES6 into ES5 and much more.
- Webpack: Generator of deployment assets and provider of hot module reloading.
By the way, we’re not omakase for standard Rails. That would be CoffeeScript. However, the Rails Doctrine makes it clear that non-standard menu choices are certainly welcome!
No One Paradigm
React on Rails fits into the “No One Paradigm” of the Rails ecosystem from the perspective that it rocks for client side development with Rails, even though it’s a totally different language than the server code written in Ruby.
Exalt Beautiful Code
ES5 was ugly. ES6 is beautiful. React is beautiful. Client side code written with React plus Redux, fully linted with the ShakaCode linters, and organized per our recommended project structure is beautiful. Don’t take our word for it. Take a look at the component sample code in the react-webpack-rails-tutorial sample code.
Value Integrated Systems
- Via React on Rails, we can seamlessly integrate React UI components with Rails.
- Tight integration allows for trivial set up of server rendering of React on top of Rails, complete with support for fragment caching of the server rendered HTML, and integration with Turbolinks.
- Tight integration allows mixing and matching Rails pages with React driven pages, even on the same page. Not every part of a UI requires the high fidelity achievable using React. Many existing apps may have hundreds of standards Rails forms. Support for mixing and matching React with Rails forms provides the best of both worlds.
Progress over Stability
React on Rails will maintain an active pace of development, to keep up with:
- Community suggestions.
- New client side tooling, libraries, and techniques.
- Updates to Rails.
Raise a Big Tent
React on Rails is definitely a part of the big tent of Rails. Plus, React on Rails provides its own big tent. A huge benefit of the React on Rails system is simple integration with Webpack and NPM, allowing integration with almost any library available on npm! The integration with Webpack also allows for other Webpack supported build tools.
Thanks for reading and being a part of the React on Rails community. Feedback on this document and anything in React on Rails is welcome. Please open an issue or a pull request. If you’d like to join our private Slack channel, please email us a request.
This is a companion discussion topic for the original entry at http://www.shakacode.com/2016/01/27/the-react-on-rails-doctrine.html