First, we’ll skip to “state”. In terms of programming and apps, a state represents everything combined to keep an application running.
Next, we add the term “predictable”, which then gives us a state that is consistent, no matter the environment it is run in.
Now we can layer on “container”, which is a fully-encapsulated app that includes everything necessary to run.
Consider this: You use Application X on your smartphone, do some things with that app, and then switch to Application Y and do different things. While using Application Y, you realize you forgot to do something with Application X, so you go back to the first app. When you reopen that original app, it’s in the same state it was when you last left it.
That’s state. But wait, there’s more.
There are three principles to consider for state:
That’s mostly basic stuff. Redux is much more than that.
Redux started when Facebook began having problems with the Model-View-Controller structure, which is a software design pattern that separates an application into three components: Model (data-related logic), View (UI logic for an application), and Controller (interface between Model and View). When Facebook needed to do massive scaling, the MVC structure began to fail them.
At that point, Facebook released Flux, which is a unidirectional method of updating the View component and handling user-based actions.
In June 2015, Dan Abramov created Redux, which is based on Facebook’s Flux and the Elm programming language. The big changes Abramov made in Redux was that he only used a single store and removed the dispatcher.
A store is a way to persistently store and manage collections of data. Flux used multiple stores, Redux only one. So if you have numerous components in an application, there is only one store that manages the state of the components. That store can relay any given state to any given component, making it an incredibly effective and efficient model.
The dispatcher is a special program that communicates with a scheduler and takes a process to the desired state.
In short, no. Instead of being a traditional library or framework, Redux is an application data-flow architecture. To use Redux it’s recommended that you work with the Redux toolkit, but the fundamental building blocks of Redux are:
Redux is also commonly used with libraries such as React and Angular. With these combinations, it’s possible to develop user interfaces that depend on a desired state.
And although you could write a complete application using a framework, once that application begins to become more and more complex, using a framework to manage the ever-growing list of components and states in that app can become very tricky, if not impossible.
That’s not the case with Redux.
In terms of programming, you would use Redux for applications where data is shared among components. For example, you have an app that uses a login component. The data from the login component is shared with the status component. Most apps that use Redux are mobile apps (with exceptions of course). Some examples of apps using Redux are:
Less obvious uses for Redux are:
More impressive, however, is the list of companies that currently use Redux. That list includes the likes of:
Before we answer that question, let’s define frontend and backend in simple terms.
With that out of the way, is Redux used on the frontend or backend? The easy answer is “both.” Redux can be used for any application that places a high priority on the ability to predictably store states.
One good example of using Redux on the backend is with multiplayer games that run within a browser and need to store their state on the server to ensure all players have the same view of the game. In this instance, the server holds the state and is seen as the “single source of truth.”
Let’s Make Your Idea a Reality with React Native Development React Native is one of
This content is blocked. Accept cookies to view the content.