The react ecosystem

The path to learning about React is more complicated than it might first appear. What makes learning about React difficult isn't React itself, as React is just a UI library. Instead, the confusion comes from trying to put all the pieces of the React ecosystem together for the first time.

To even get a normal React app up and running you need the right combination of NPM, Babel, and Webpack. What about routing? Well, React doesn't come with a router so you'll need to add one. Wait, what about styling? Also, where does Redux fit into all of it? In this post, we'll answer all these questions, and you'll get a high level overview of how the most popular pieces of the React ecosystem fit together.

There's no better place to start a post about the React ecosystem than with React itself.

As I mentioned earlier, React itself is just a library for building user interfaces, nothing more. If that's all it is, then why is the setup for building a React application so complicated? The reality is you can build React apps with just an index.html if you wanted.

Is that the best idea long term? Probably not, but it's important to know that it is entirely possible.

Now that that's out of the way, eventually you'll want a more "production ready" build setup, which leads us back to the same question, why is the setup for building a React application so complicated? There are a few different reasons for that and the best way to see why is with some code. Here's a typical React file (don't worry too much about the specifics, we'll dive much deeper into it all of it later on).

If we were to give this file to a modern web browser as is, one of two things would happen, either the browser would throw an error because we have what appears to be HTML located inside of our JavaScript file, or it would throw an error due to our import/export syntax. Both are important for building a modern React application and both shed light on why the setup is so complicated.

First, let's tackle the weird HTML in JavaScript syntax, this brings us to our first explanation of why the setup is so complicated, Babel.

Technically Babel is a JavaScript compiler. The way I like to think about it is Babel is a code transformer. You put your code into one end of the Babel machine, and out the other end comes new code after it's been transformed to your liking. Remember that weird HTML syntax inside of our JavaScript that you saw earlier? It's called JSX. It's React's way to allow you to describe UI inside of your components. Your gut reaction might be to hate it, that's fine because by the end of this course you'll love it. We're going to learn about the why of JSX in a later section, but for now, know that browsers (obviously) don't support JSX natively. Before we ever give our React code (with JSX) to a browser, we first need to transform it into regular old JavaScript that the browser can understand, this sounds like the perfect scenario for our Babel machine. We'll put our React code with JSX in one end of the machine, and out the other, we'll get browser compatible JavaScript.

What's also cool about Babel is it's not limited to just making JSX -> JS transformations. In fact, you can make any transformation. The most common use case is using it to convert ECMAScript 2015+ code into a backward compatible version of JavaScript that current and older browsers or environments can understand.

Now that we know that we can use Babel to solve our JSX issue, the next issue we still have to face is the import/export syntax. This is where Webpack comes into play.

If you're not familiar with JavaScript modules, read From IIFEs to CommonJS to ES6 Modules before continuing.

Webpack is a module bundler. What it does is it examines your codebase, looks at all the imports and exports, then intelligently bundles all of your modules together into a single file that the browser can understand. What that means is instead of including all the scripts in your index.html file as we did above, you include the single bundle.js file the bundler creates for you.

How can that help us in our scenario? At this point, it should be pretty obvious. The output that Webpack gives us won't include any import/export statements. This way the browser won't choke on it.

We'll dive into the implementation details of both Babel and Webpack in a later section. For now, you should understand at a high level why they exist and how they benefit us.

It may be surprising, but React itself doesn't come with a router. The reason for that, again, is React is just a UI library. The benefit of this is you're able to pick which router works best for you. The most popular Router for React is React Router.

We'll dive much deeper into React Router later on, but for now, know that React Router's whole job is to render specific components based on the current URL path of the user.

When a user navigates to the home page (**/**), React Router will render the **Home**component. When they navigate to **/about**, React Router will render **About**. Finally, as you can probably guess, when they navigate to **/topics**, React Router will render the **Topics** component.

What's interesting about React Router is you'll notice the entire API is just components, this aligns nicely with React itself.

Styling in React is, for some reason, the most controversial part of the React ecosystem. There are typically two schools of thought, let's call them Traditional and Untraditional (for the sake of remaining free of bias, for now).

Traditionally, you style your React applications just like you would any other application. You have an **index.css** file where all your styles go. You have classes and cascading. You could even use SASS or any other CSS pre-processor, but at the end of the day, there's nothing inherently different about styling your React app than any other app you've built. All the benefits and downsides of standard CSS still apply.

In an untraditional way, you embrace React's component model. If you're already encapsulating the logic and UI in the component, why not include the styles as well? The term typically used is "CSS in JS." With CSS in JS, you avoid all the typical properties of standard CSS. No more cascade, no more global namespace, instead, all of your styles for a component live in the component itself.

Revisiting our simple **User** component from earlier, CSS in JS may look like this.

The most popular CSS in JS library in the React ecosystem is Styled Components. They take it one step further and allow you to define components which specify styling.

Redux markets itself as a "Predictable state container for JavaScript." I like to think about it as an ecosystem for making state changes in your applications more predictable. Often Redux gets coupled with React, but that coupling is artificial. You can use Redux with any other view library, not just React.

Comparing the principles for how React manages state and how Redux manages state leads to some interesting insights about the two libraries. The whole philosophy of React is that you build individual components that can each manage their own state as well as describe their UI. You then compose those components together to get your app.

The philosophy of Redux is pretty different. Instead of having state spread out in different places, with Redux you stick all of your state in a single location called a Store. You then establish strict rules for how the state of your Store can change.

If Redux is the right tool for the job, it's fantastic. If it's the wrong tool for the job, it's overkill. For some reason, over the last few years, the hype around Redux surmounted all rationality. With that hype came many misconceptions around the use of Redux and React together. Here's my attempt to clear up those misconceptions before you get any further into the course. First, if you're new to React, ignore Redux entirely until you feel comfortable with React. If you start mixing the two, you'll get confused as to what's React and what's Redux. If someone says otherwise, they're wrong. Second, there's a good chance that you may never need Redux. There was a time before Redux existed where we all built complex React applications, and we were just fine. Third, no new features of React are making Redux obsolete. Again, I think of Redux as more of an ecosystem than anything else. New features to React can replace parts of that ecosystem, but I don't believe it'll ever replace the whole thing.