Time to Learn React!
Web Guild Week at Strava
The web guild at Strava is responsible for maintaining and improving the Ruby/Rails/JavaScript/CSS platform, processes, and culture. We believe that an up-to-date, modern web platform is not only more secure and faster, but also makes our engineers more productive and happier. As part of a company wide Guild Week, during the week of April 2nd all of our web engineers took time off from their regularly scheduled product work to focus solely on learning React.
jQuery, Backbone, and CoffeeScript — oh my!
Strava’s main monolithic Rails application began its life over 9 years ago. At that time functional and immutable JavaScript was not in vogue, libraries like React and Redux did not exist, and CSS modules were not a thing. In the early days of Strava we used jQuery and over time, as our application grew, we adopted CoffeeScript and Backbone. Since then, our JavaScript stack has fallen behind the times. Compared to new versions of the Javascript language and new front-end application paradigms, our Javascript stack is brittle and difficult to work with or feel excited about. Near the end of last year we decided to experiment with a few of the newest front-end languages and libraries in order to select a set of tools that would allow us to continue to meet our product goals and stay nimble and reactive to the latest advancements in front-end development.
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?
Exploring React-land
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.
Enter guild week. Guild week was a perfect opportunity to spend 100% of our time focused entirely on learning these new tools, continuing to develop our best practices, and building a knowledge base so that future employees would be able to learn to use React at Strava quickly. The goal at the end of this week was not to have some percentage of our main Rails app rewritten in React. Instead, we wanted every engineer in the web guild to understand React code and concepts and feel comfortable reviewing ES6 and JSX. The ideal outcome was that going forward the entire guild would agree that all new JavaScript code would be written in React and that over time we would refactor existing backbone views and models into React.
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.
In the following weeks we have made additional progress. We have a full “Getting Started in JavaScript” guide which summarizes each of the tools and best practices we have adopted — along with links to the recorded guild week presentations. We have fully integrated linting and testing of JavaScript and CSS into our CI pipeline. And we continue to make improvements to our deployment and development pipelines: for example by de-duping and better organizing our production JavaScript assets.
We’re excited for the future of JavaScript at Strava! And we’re really looking forward to the next Guild week. If you’re interested in joining the web guild and getting to participate in the next two web guild weeks we’ll have this year, we are always hiring web engineers. Check out our open positions here or reach out to me directly @panthomakos.
