Chapter 2: Why Rematch over Redux? An Introduction to Rematch Architecture

In this chapter, we'll briefly analyze the reasons why Rematch was created. We'll also see how Rematch works internally and how it's possible to reduce Redux boilerplate with Rematch. We'll learn how Rematch, despite being less than 2 kilobytes in size, can reduce the code that we need to set up Redux by 90%.

This chapter is important for understanding the key concepts of Rematch that we'll be looking at in the next few chapters.

In this chapter, we will cover the following topics:

• Why Rematch?
• How does Rematch work?

By the end of this chapter, you will be able to understand any Rematch concept as well as understand why Rematch was created and how the developer experience gets improved by using the latest JavaScript features.

Technical requirements

To follow along with this chapter, all you will need is a basic knowledge of ES6 JavaScript.

Why Rematch?

Rematch was created in 2017 by Shawn McKay and Blair Bodnar, a pair of Canadian programmers who thought that Redux should be simpler and easier to use.

As McKay said in several publications, Rematch is a wrapper around Redux that provides a simpler API, without losing any of the configurability that Redux offers.

We saw in the previous chapter that Redux has a steep learning curve compared to a simple component local state because it includes so much new terminology and so many features that don't exist in other development suites.

As regards Redux, we can use this formula to easily understand why an abstraction layer is necessary:

Figure 2.1 – Formula to calculate the quality of our API for managing state

time_saved represents the time you may have spent developing your own state management solution, while time_invested is the hours invested in reading documentation, watching tutorials, and researching unfamiliar terminologies...

How does Rematch work?

Internally, Rematch is pretty simple. That's why calling it a framework isn't quite correct; it's just a higher layer without the Redux boilerplate.

Let's analyze Rematch in depth. In Figure 2.4, we introduce the Rematch model:

Figure 2.4 – Rematch architecture

Rematch models are among the most important parts of your store because they allow you to define the initial state of the model, the reducers, and the effects.

Any model is built on the basis of these properties:

Name

Models can contain a name that will become a key in the Redux store – this means that you will be able to access the state of a model or dispatch actions from a model using its name. Now, a name is not mandatory – if you don't provide a name, Rematch will use the object keys provided to the init() function instead.

The init() function returns a Rematch store, which is essentially a Redux store with...

Summary

In this chapter, we have learned about the main concepts that are required to start a simple application with Rematch. We also learned why Redux needs an abstraction layer and how Rematch entered the game to solve that problem.

Now that we've covered all these concepts, we can safely face the creation of our first application. We will learn how to create a simple Redux to-do application with vanilla JavaScript, for a future migration to Rematch.