How Airtable uses React

In early 2015, Airtable had just launched publicly and released its iOS app. After a long product sprint in preparation for the launch and release, our engineering team finally had the opportunity to take a step back and try out new frameworks and tools as a foundation for our next phases of work.

As part of that effort, that summer I decided to explore the possibility of using React in Airtable’s web client. I had experience using React both during my time as an engineer at Facebook and in a few personal projects. This experience gave me familiarity with the design philosophies behind React, and empowered me to advocate for it at Airtable.

Initial considerations

  1. Reduced boilerplate: We could write simpler UI code when working with a virtual DOM. While using React, an Airtable engineer could write a render() function for each component that would provide a mapping from state to DOM markup or child components, and React's virtual DOM system would determine what actual DOM mutations to perform when a component was mounted or when its state changed. Our existing code before React had to manually describe the specific DOM mutations required by numerous different state changes. The switch to React would obviate the need to write this tedious code and eliminate all the potential bugs that might result, by letting us write code at a higher level of abstraction.
  2. Decomposition: We could more effectively organize and decompose our UI code. Prior to React, each of our components needed a .js file to describe DOM mutations and event handling, and a separate HTML-like .ejs template file to describe its initial DOM element structure. With JSX, React allows you to combine these both into a single file, and in turn it becomes easier to break code into smaller, reusable components with well-defined interfaces. Transitioning away from HTML files isn't always the right move for all companies or teams, but as a small team of engineers all of whom were comfortable writing JavaScript, it wasn't a concern for us.
  3. Security: We could write code that was more secure by default. React’s JSX markup cleanly distinguishes HTML tags from other strings and escapes the latter automatically. In our previous framework, some types of DOM mutations could introduce XSS vulnerabilities if we weren’t careful to escape user-supplied strings.

With the above considerations in mind, I went ahead with a pilot project. I rewrote our view configuration menus in React, which include our filtering and sorting menus. After those changes were written, tested, and shipped, and we saw the above benefits, we decided to adopt React more widely across our codebase.

Prioritizing what to rewrite in React

  • We prioritized rewriting code that would greatly benefit from React’s convention of one-way data flow. Our field configuration menu was a good candidate, as it has to maintain its own temporary state to store any unsaved field configuration, rather than relying on a model class for storage. Its state had been spread out across many different component files over time, and was increasingly difficult to understand. The use of one-way data flow guided us to re-architect this menu in way that we found more readable and decomposable.
  • We prioritized rewriting parts of our product where lots of new features were planned. Rather than adding features to the pre-React version of a component, we usually preferred to first rewrite the component in React and then add new features on top of the React rewrite. We found that the latter approach has been easier to code review and easier to maintain in the long run, making it worthwhile even taking into account the one-time cost of the rewrite.
  • We prioritized creating a library of small, reusable components that show up across our product, like buttons, menus, and icons. Centralizing this code into library components ensures a consistent look-and-feel across our product and makes it easy to update for site-wide design refreshes. It also provides a useful set of building blocks to streamline future feature work.

We avoided rewriting features just for the sake of rewriting them, if they didn’t fall into any of the above categories. In particular, we kept around some Grid View components that were highly optimized for rendering performance and unlikely to work as performantly in React without duplicating a lot of effort.

Managing mixed React & non-React code

Looking back one year later

Airtable engineer & digital artist. Loves building tools for creativity, exploration, and abstraction.

Airtable engineer & digital artist. Loves building tools for creativity, exploration, and abstraction.