There are literally hundreds of React tools in existence today. The aim of this book, however, is to cover the essential tools for React development. Even with the curated list of tools that you'll learn about in this book, you probably won't use every single one in any given project. Let's take a brief look at the tooling that we'll be looking at throughout the remainder of this book.
React tooling covered in this book
JSX needs to be compiled to JavaScript
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.
Newer JavaScript language features need to be transpiled
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.
Hot module loading to enable 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.
Running unit tests automatically
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.
Thinking about type safety
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.
Linting for code quality
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/).
Isolating component development environments
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.
Providing a browser-based debugging environment
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.
Deploying React applications
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.
