React 16 Tooling: Master essential cutting-edge tools, such as create-react-app, Jest, and Flow

The first part of the React core is the package called react. This package is what we interface with directly when writing React components. It's a small API—the only time we really use it is when we're creating components with state and we need to extend the Component class.

There's a lot going on under the hood with the react package. This is where the render tree resides and is responsible for efficiently rendering UI elements. Another name for the render tree is the virtual DOM. The idea is that you only have to write JSX markup that describe the UI elements that you want to render while the render tree takes care of everything else:

What you see in this diagram are the components that your code directly interfaces with, and the render tree that takes care of handling presentational changes that result from components that change state. The render tree and everything that it does for you is the key value proposition of React.

The second part of the React core is the Document Object Model (DOM) itself. In fact, the name virtual DOM is rooted in the idea that React is creating DOM representations in JavaScript before it actually talks to the DOM APIs. However, the render tree is a better name because React is creating an AST (short for Abstract Syntax Tree) based on the React components and their states. This is why the same React library is able to work with projects like React Native.

The react-dom package is used to actually translate the render tree into DOM elements in the browser by directly communicating with the browser DOM APIs. Here's what the previous diagram looks like with react-dom included:

This is a nice architecture—it means that you can substitute react-dom for another render target with little effort. As you can see, the core layer of React is minimal. No wonder it's so popular—we can create user interfaces with declarative code that are easy to maintain and are efficient with little effort on our part. With this in mind, let's shift our focus over to the tooling that makes all of this possible.

Framework bloat is a major turn-off for a lot of people. The reason it feels like bloat is because they have a lot of features that you'll likely never use. React handles this well because it has a clear distinction between the core library and anything else, including things that are essential for React development.

There are two observations I've made about React and the way it's positioned within its surrounding ecosystem:

In other words, you don't have to use the majority of React tools, but some of them are incredibly helpful.

Any given tool is external to the library you're working with; it's essential to remember this. Tools exist to automate something that would otherwise suck more development time out of our lives. Life is too short to manually do things that can be done for us. I repeat, life is too short for tasks that software can perform better than us. If you're a React developer, take comfort in the fact that there are tools out there for all of the important things that you need to do but don't have time to do.

Perhaps, the ultimate motivator for taking tooling seriously is thinking about what life would be like without the tools that we depend on as professionals. The construction industry is more mature than software and serves as a great example.

Imagine that you are part of a team that's responsible for building a house—an immensely complex undertaking with many moving parts. Now, think about everything that you have to work with. Let's start with the materials themselves. Anything that doesn't have to be assembled on site, isn't. When you're building a house, many components show up partially assembled. For example, sections of roof framing or mixed cement shows up when it's needed.

Then there are actual tools that builders use when putting the house together—simple screwdrivers, hammers, and measuring tapes are taken for granted. What would construction life be like without the ability to create components offsite or the availability of tools to work with everyday construction materials? Would it make the construction of a house impossible? No. Would the process of building it become some unbearably expensive and slow that it'd likely be cancelled before completed? Yes.

Unfortunately, in the software world, we're only beginning to understand how important tooling is. It doesn't matter that we have all the materials and knowledge to build the house of the future. If we don't have the right tooling, it might never be built.

React uses a special syntax that resembles HTML to declare components. This markup, called JSX, is embedded in the component JavaScript and needs to be compiled to JavaScript before it's usable by the browser.

The most common approach is to use Babel—a JavaScript compiler—along with a JSX plugin:

The trick is finding a way to make this compilation step as seamless as possible. As a developer, you shouldn't need to concern yourself with the JavaScript output produced by Babel.

Similar to compiling JSX to JavaScript, newer JavaScript language features need to be compiled into versions that are widely supported by browsers everywhere. In fact, once you figure out how to compile JSX to JavaScript, the same process is used to transpile between different versions of JavaScript:

You shouldn't have to worry about the transformed output of your JSX or JavaScript compilation. These are activities better suited for tools to handle, so that you can focus on application development.

Something that's unique to web application development is that it's mostly static content that's loaded into the browser. The browser loads the HTML, followed by any scripts which are then run to completion. There's a long-running process that continuously refreshes the page based on the state of the application—everything is over a network.

As you can imagine, this is especially annoying during development when you want the see the results of your code changes as they're introduced. You don't want to have to manually refresh the page every time you do something. This is where hot module replacement comes into play. Essentially, HMR is a tool that listens for code changes, and when it detects one, it sends a new version of the module to the browser:

Even with a tool like Webpack and its HMR component, it's time-consuming and error-prone to get this setup working correctly, even for simple React projects. Thankfully, there's tooling that hides these setup details from developers today.

You know that you need to write tests for your components. It's not that you don't want to write the actual tests; it's that setting them up so that they're able to run can be a pain. The Jest unit test tool simplifies this because it knows where tests can be found and can run them:

With Jest, we have a place where all of our unit tests go, and each depend on the component that they're testing. This tool knows where to find these tests and how to run them. The result is that we get nice unit test and code coverage output when we need it. There is no overhead beyond actually writing the tests.

JavaScript isn't a type-safe language. Type safety can vastly improve the quality of applications by eliminating the possibility of runtime errors. Once again, we can use tooling to make type-safe React applications. The Flow tool can examine your code, look for type annotations, and notify you when errors are found.

It's one thing to have an application that works; it's another to have an application that works and has maintainable code that doesn't make people's eyes bleed. The best way to achieve measurable code quality is to adopt a standard, like Airbnb's (https://github.com/airbnb/javascript). The best way to enforce coding standards is to use a linter. With React applications, the preferred linting tool is ESLint (https://eslint.org/).

Perhaps the most overlooked tool of React developers is Storybook, which is used for isolated component development. You don't realize it until you're developing your component, but the application can get in the way. Sometimes, you just want to see how the component looks and behaves all on its own:

With a tool like Storybook, it's trivial to provide an isolated context for your component, free of distractions from other components.

Sometimes, looking at unit test output and source code isn't enough to figure out a problem that you're experiencing. Instead, you need to see what's going on as you interact with the application itself. In the browser, you install React tooling that makes it easy to inspect React components as they are related to rendered HTML content.

React also has some built-in performance monitoring capabilities that extend the abilities of the browser developer tools. You can use them to examine and profile your components at a low level.

When you're ready to deploy your React application, it isn't as simple as producing a build and distributing it. In fact, you might not even distribute it at all if you're building a hosted service. Regardless of what the end use case of your application is, there are likely going to be several moving parts in addition to the React frontend. Increasingly, containerizing the main processes that make up your application stack is the preferred approach:

In order to create and deploy React application stacks like this, you'll rely on tools like Docker, especially when it comes time to automate the various deployment scenarios of your project.

There are some React tools that you simply can't live without. For example, browsers don't understand JSX syntax, so this needs to be compiled to JavaScript. As you write code, you'll want to lint it to make sure that basic mistakes aren't missed, and you'll want to run your unit tests. If you try hard enough, you might be able to get by without these tools. But that's the thing—you would spend more effort not using a given tool than to simply embrace it.

As a starting point, find the minimal set of React tools that allow you to make progress. Once your progress noticeably slows, it's time to consider introducing additional tools.

Optional tools are things that you might not get any real value from. For example, you probably won't reap enormous benefits from using Flow to check for type safety or Storybook to isolate component development at the very beginning of a project.

The key thing to remember is that any React tool is optional, and no decisions are permanent. You can always bring in Flow later on, and you can always ditch Storybook if isolated component development isn't your thing.