Section 1: Rematch Essentials
On completion of this part, you will be able to understand why and how Redux was created. You'll learn what the motivations were for creating Rematch and how it works internally. Also, you'll learn how to create a simple to-do app with Vanilla JavaScript with Redux, and to close the section, you'll migrate that application to Rematch.
In this section, we include the following chapters:
- Chapter 1, Why Redux? An Introduction to Redux Architecture
- Chapter 2, Why Rematch over Redux? An Introduction to Rematch Architecture
- Chapter 3, Redux First Steps – Creating a Simple To-Do App
- Chapter 4, From Redux to Rematch – Migrating a To-Do App to Rematch
Chapter 1: Why Redux? An Introduction to Redux Architecture
Redux is a consolidated state management solution used by millions of websites, downloaded 3 million times per week. Overall, it's a great solution for a complex problem, but it was created with some limitations that Rematch aims to solve with best practices.
In this book, we'll analyze the weakest points of Redux and how Rematch solves them with a small wrapper in less than 2 KB. We'll move from the most basic example of a to-do task application to an Amazon clone website built with React and latest web technologies trends. We'll also create a mobile application with React Native and Rematch, introduce testing coverage, and, of course, explore TypeScript and Rematch plugins. By the end of this book, you'll be able to create any application or migrate an existing one to Rematch.
In this chapter, we'll learn why Redux was created and what problem it is designed to solve. Also, we'll learn how it works internally, and we'll get acquainted with some Redux terminology.
In this chapter, we will cover the following topics:
- Why Redux?
- What was there before Redux?
- How does Redux work?
By the end of this chapter, you will know the story behind Redux, how it works internally, and what was the cause of its creation. Of course, you will also learn practically all the most important terminology of Redux and use it in the next chapters.
Technical requirements
To follow along with this chapter, all you will need is a basic knowledge of ES6 JavaScript.
Why Redux?
To get started with this book, it's interesting to know what Redux does and what problem it's designed to solve.
In 2015, Redux was created by Dan Abramov, who began writing the first Redux implementation while preparing for a conference talk at React Europe, and Andrew Clark. Redux is a predictable state container for JavaScript applications; in other words, it is a utility tool to manage global states, which means data that is reachable across many parts of your application.
Where I used to work, we always asked the same question before starting a project: do we really need Redux? The problem we found is that when your application gets more complex, with more components that need to pass props down from a parent component to child components, the more complex the project becomes to read and improve. In short, it becomes unmaintainable.
This is an example of a common architecture of a basic application that passes down props from a parent component to child components:
Figure 1.1 – React architecture without Redux
That's where Redux joins the game. Redux eases these complexities, providing patterns and tools that make it easier to understand when, where, why, and how the state will be updated, and how your application logic will behave when those changes occur.
Redux will help when we need to do the following tasks:
- Manage large amounts of application state that are needed in many places.
- Manage business logic that is complex to update.
- Create an app that will be maintained by many people.
A year after releasing React, Facebook published the Flux architecture on social media. Flux is more of a pattern than a framework; it eschews Model-View-Controller (MVC) in favor of a unidirectional data flow. When a user interacts with the user interface, the user interface propagates an action through a singleton dispatcher to many stores that hold the application's data, which updates all of the user interfaces that are affected. Flux architecture became really popular, and so many implementations appeared, too, but the most popular was Redux; the adoption of Redux was quickly adopted by the React community, and it soon became common to teach the use of React and Redux together.
Now that we know why Redux is interesting for our projects and why it was created, we should look at what frontend technologies for state management existed before Redux entered the game.
What was there before Redux?
In 2011, Facebook had a big issue with its notification system; the problem was called Zombie Notifications. Users received chat notifications, but when they clicked on them, there would be no new messages waiting for them. The Facebook team was getting a lot of complaints about this issue, and after a lot of research, they found the problem: the entire architecture was weak and had been since its creation.
Facebook was using the MVC architecture at the time, which became increasingly unstable as the application grew more and more complex. Here's an example of a common MVC architecture:
Figure 1.2 – MVC architecture
Basically, the number of models, controllers, and views that shaped Facebook became unmanageable to maintain. That's why newer frameworks appeared in the frontend ecosystem, one of which was Backbone.js...
