Time to Learn React!
Web Guild Week at Strava
jQuery, Backbone, and CoffeeScript — oh my!
We developed a simple rubric for evaluating our options and then selected some engineers to split off into teams and develop a proof of concept login view using each of the technologies we were evaluating. We then came together at the end of the experiment, discussed our findings, and, as you may have guessed, ended up choosing React on ES6.
At the time of this decision there were only a handful of web engineers that conceptually understood React and we hadn’t made many of our most important technical and best practice decisions yet. How were we going to test our code? Would we be using Redux? Were we going to use CSS modules? How would we integrate with existing code and our existing Rails application? How would we go about migrating our old CoffeeScript code over to React? How would a new engineer at Strava become proficient in React and its associated technologies?
Over the next few weeks a group of Strava engineers, dubbed “The React Working Group”, integrated React into our Strava Local Rails app. This app is independent of our monolith and was a good candidate for continuing to develop our ideas and understanding of this new set of tools. During that time we answered some of the most basic questions and developed some initial best practices. We were going to use Jest for testing, we were not going to use Redux yet, CSS modules were a go, and we would upgrade our apps to Rails 4.2 in order to use the Webpacker Gem for easy integration with webpack.
The complicating factor was that our main Rails application (www.strava.com) was running Rails 3.2 so we needed to make a very concerted effort to speed up our upgrade plans. I can write a whole other blog post series on upgrading our Rails application, but we’ll stick with React for this post. The summary is that we did it. The Rails 4.0 upgrade was by far the most difficult part and took over a month to complete. The 4.1 and 4.2 upgrades each took about two weeks and included backwards-compatible development work and deployment. We did not have to roll-back any deploys so we considered this a massive success.
Establishing a Permanent Colony
At this point we felt that we had a sufficient starting base from which we could begin adopting React as our primary frontend framework. The problem, of course, was that we had a lot of engineers that knew very little about ES6, React, Jest, Webpack, and CSS modules — let alone how all of these new tools would interact with our existing Rails app.
We spent the first few days of the week working through the Web Bos React for Beginners course. This got everyone up to speed with basic ES6, JSX, and React. We then spent the rest of the week writing actual code, comparing results, and learning some more advanced concepts. There was no pressure to produce production level code. If it took one engineer longer to work through the basic React course than another engineer, that was completely okay.
Throughout the week we also organized some hour-long presentations from the React Working Group members. These sessions were recorded so that future employees could follow along and get caught up. For example, we organized one session on Jest/Testing and another on CSS Modules.
When we actually dove into code we constrained ourselves to a set list of some smaller views/projects and purposefully duplicated each others work. We wanted to be able to compare implementations so that we could learn and develop consistent practices going forward.
Are We There Yet?
React week was a great success. The team benefited greatly from being able to take a full week off regular work and just learn. Ultimately this dedicated learning time will result in long term productivity, reliability, and confidence gains. Even if all of us don’t immediately go off and start writing React components, we will be able to more confidently review code and assess technical tradeoffs as we continue to build out our tooling and infrastructure.
There are some things we could have done better. We should have done more to plan and organize our learning sessions and we should have done a better job of setting up some of the basic tooling and integrations with our web app ahead of time. Part of the reason we weren’t as prepared is that we had just finished our Rails 4.2 upgrade and had not had time to do as much setup as we would have liked.