When people hear React, they think of a focused library used for efficiently rendering user interfaces. When people hear framework, they think of a large system that might have a few useful tools within it but is otherwise a bloated mess. They're correct about frameworks for the most part, but saying that React isn't a framework is a little misleading.
If you take React out of the box and try to do any meaningful development with it, you'll promptly hit a wall. This is because instead of being distributed as a monolithic framework, React is better described as a core library surrounded by an ecosystem of tools.
The advantage of a framework is that you can install the core library along with the supported tooling in one shot. The downside is that every project is different and you can't be sure what tools you need versus those that you won't. Another advantage to having an ecosystem of tools is that they can evolve independently from one another; you don't have to wait for a new release of the entire framework to get an enhancement for one of the tools that your project uses.
The aim of this book is to show you how to best utilize the tooling ecosystem surrounding React. In this chapter, you'll be introduced to the concept of React tooling by learning the following:
- React without tooling
- Introduction to tooling
- The tools covered in this book
- Deciding which tools are needed for your project
Before we dive into tooling discussions, let's make sure that we're on the same page about what React is, and what actually comes with the package when you install it. There are two core React packages required for running React web applications. We'll take a look at these now to provide you with some context for thinking about React tooling.
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
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.
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
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.
Tooling isn't unique to React. Every project has its own set of tools that handle tasks related to the core technology so that you don't have to. With frameworks, tooling is baked into the project for the most part. With libraries like React, you get to choose the tools you need versus those that don't play a role in your project.
Now that you know what the React core is, what makes up the rest of the React ecosystem?
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:
- It's easier to deploy apps that depend on a simple library instead of a framework where all batteries are included
- It's easier to think about application development when you have tools that stay out of the way for the most part
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.
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.
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.
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:
If the tooling in the preceding section seemed like a bit much for a single project, don't sweat it. Trying to leverage every possible React tool at the same time is always a mistake. Address one problem at a time, starting with the essentials. As your project moves forward, add in the optional tools to expand your toolset.
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.
This chapter introduced you to the concept of tooling in the React ecosystem. You learned that React, at its core, is a simple library and that it depends on the use of several tools to be of any value in the real world. Frameworks try to provide all of the tooling that you'll ever need for your project. While convenient, the needs of the framework users are difficult to predict and can be a distraction from core functionality.
Next, you learned that tooling in React can be a challenge because as a React developer, you're responsible for choosing the right tools and managing their configuration. You then got an overview of the tooling that you'll learn about in more detail throughout the remainder of this book. Lastly, you learned that some tools are critical for React development and you'll need to get them set up right away. Others are optional, and you might not start using them till there's an actual need later on in the life of the project.
In the next chapter, you'll use the Create React App tool to bootstrap a React project.