How Airtable uses React

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.

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.

Managing mixed React & non-React code

Looking back one year later

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store