Chapter 8. React Design Patterns

In the last chapter, we looked at React on the server. We created a simple HTTP server followed by multiple endpoints and web sockets.

In this chapter, we will take a step back and consider the component architecture we have built so far. We'll look at a couple of popular React design patterns and how we can make subtle improvements to our architecture.

Where we are

Let's take a look at the things we have created so far and how they interact with each other. If you've been following closely, this may all be familiar to you; but stick with it.

We will talk about how these interactions are failing us and how we can improve them. From the moment our interface begins to render, we start to see the following things happen:

1. We begin by creating a backend object. We use this as a store for the pages in our application. This has methods such as add, edit, delete, and all. It also acts as an event emitter, notifying listeners whenever pages change.

2. We create a PageAdmin React component and pass the Backend object to it. The PageAdmin component uses the Backend object as a data source for other page components, all of which are created within the PageAdmin render method. The PageAdmin component listens for changes in Backend as soon as it is mounted. It stops listening after it is unmounted.

3. The PageAdmin component has a few callbacks, which it passes...

Flux

At this stage, we encounter the first design pattern (and the improvements we can make). Flux is a pattern proposed by Facebook that defines the flow of data in an interface.

Note

Flux is not a library, but Facebook has released a few tools that help implement the design pattern. You don't have to use those tools to implement Flux. To install it, run npm install --save flux in addition to the previous dependencies.

We implemented something very close to Flux, but our implementation is at a slight disadvantage. Our Backend class does too much. We call it directly to add and fetch pages. It emits events when new pages are added. It's tightly coupled with the components that use it.

So, we'd have a hard time replacing it with a new Backend class (unless the methods, events and return values were in the exact same format). We'd have a hard time using multiple data backends. We don't even really have unidirectional flow of data because we send and receive data from Backend.

Flux differs here...

Redux

Flux leads us to separate our Backend class into a dispatcher and a store as a means of decoupling from a single state store and implementation. This leads to quite a bit of boilerplate, and we still have some coupling (to global dispatcher and store objects). It's great to have some terminology to work with, but it doesn't feel like the best solution.

What if we could decouple actions and storage and remove the global objects? This is what Redux seeks to do along with reducing boilerplate code and bringing about better standards overall.

Note

You can download the Redux tools by running npm install --save redux react-redux in addition to the previous dependences. Redux is also just a pattern, but the tools in these libraries will help greatly in setting things up.

Redux can be a lot to take in at first, but there are some simple underlying things which bind it all together. For a start, there's the idea that all state is held in immutable objects. This state should only be transformed...

Summary

In this chapter, you learned about modern architectural design patterns that we can use to build better React applications. We began with the Flux pattern and moved on to Redux.

In the next chapter, we will look at how to create plugin-based components to allow our interfaces to be extended by others.