React + Redux + … Rails?
Bionexo is a Brazilian company that creates digital solutions for the healthcare supply chains. We are the leading company on this market in Brazil and responsible for most of the innovations on this niche.
In the ending of 2016 we decided that we were going to re-imagine one of the core modules of our platform, maybe the most problematic and complex of them all. The biggest challenge on this task was to provide a good experience for the users through a very interactive user interface.
The first thing we had to do is learn; none of us had ever used Redux or even React. Our team also didn’t have much experience with funcional programming, so that was one more challenge for us.
After some time spent alone learning by ourselves, we decided to work in the form of what we call coding dojos: We got together in a meeting room (about 5 or 6 of us) with a laptop and a projector to develop really small features using React + Redux, with only one person (the pilot) typing and others watching and making suggestions about the code. Every 1 hour or so the pilot rotates so everybody has a chance to write some code.
We worked like this for about one week, 4 hours a day (we were intercalating our learning time with other features/issues so we could keep delivering value for our users). In addition, we were still learning by ourselves, for instance I watched a lot of egghead courses.
After most of us were comfortable with React and Redux we got back to our workstations and started coding for real the features, most of the times doing pair programming. After 2 to 3 months of development, QA phases, bug solving and deployment, we delivered the first version of the new interface to our users.
Ok, but what about Rails?
Yeah, our platform is built using Rails, so we were between two approaches for solving this problem: building a standalone interface with node.js (or something similar), and that interface would communicate with a Rails API, or building it inside Rails. We went with a somewhat in between approach.
If you search for react gems, you will find two main gems: react-rails and react_on_rails. With the first one, react-rails, you develop your components inside rails. The asset pipeline will be responsible to transform your jsx and stitch everything up. React_on_rails instead will do a lot of stuff outside rails, keeping everything very separated from your app.
Foreman will be responsible to run your rails server and the webpack watch on the development environment. If in the future you want to separate your code, it’s as easy as moving one folder to your new app and configuring your build, run and test tasks.
In the beginning we had a lot of problems to configure webpack, babel and rubyracer. This is something that we can talk about in another post, but after we solved that, everything worked perfectly. :)
And was it worth it?
After all that, was it worth it? Definitely! We learned React and Redux, and the good thing about react and redux is that you end up learning a lot about functional programming, which is quite useful in a lot of other problems.
Our front-end also became a lot more organized, which makes its maintenance and improvement much easier.
On the other side, when other teams have to develop new code or solve any bugs on this module, they will have to learn about React and Redux before they start coding. To decrease this knowledge gap, we have already done one Tech Talk (which cover the entirety of this post plus the basics about react and redux) and we plan on doing more on-demand trainings.
tldr: we decided to use react, redux and rails, and you should also do so!