Answer the question
In order to leave comments, you need to log in
What is Redux in simple words?
I've been using jQuery for 10 years and I'm having a hard time understanding the React architecture I'm trying to figure out.
For example, I have a lot of independent blocks on the page, I create them as widgets in yii, while one widget can be nested in another, and so on, you can call them components. It happens that an action in one component affects another component, for example, in one component the "Save" button is pressed, and the other component must be updated (redrawn). I do this: clicked the button, I send ajax, on successful response, I trigger the event of this component $(document).trigger('widget_user#save'); And in other components that should respond, I listen to this event $(document).on('widget_user#save', function(){...}); Thus, my components become independent, and anyone who is interested can subscribe to its events.
Does Redux do something similar? Please explain in simple terms. And what is a state?
Answer the question
In order to leave comments, you need to log in
Best explanation of Redux I've seen.
getinstance.info/articles/react/learning-react-redux
To understand how Redux works, you need to be familiar with React.
At least in order not to be afraid of props.
Do you have React. These are all just JS objects. - this allows you to write a jsx engine that React uses it.
Since the structure is component based, you have to think about how to update the components in the other part of the page.
The principle is this: a component is usually updated when new properties are received - props or when its state object changes - state.
In order for you to update components that are far apart from each other - you need to think about what and where the properties come from - to forward a function that will cause a redraw.
What Redux does:
It doesn't call for abandoning state.
But there is a common data container. And when the data changes, the components that display exactly this data also change.
When you need to change something - you call dispatch - a special reducer function reacts to this - and changes the data as you need. When the data is replaced - the Propvider component - calls the render from its child component (the one that wraps the Provider).
For example:
<Provider>
<MyComponent />//Вот сюда Provider пробросит (запишет) новые props.
</Provider>
{
chunkStore: {},
some: {}
}
{store: store.chunkStore}
In this case, different thinking (design).
In your case:
The logic comes from the components. Suppose there is a label online/offline
on the user's page
Where to get the value if you need to block the chat window at the moment when the user is offline ?
What if there is not one such action, but let's say 10 pieces?
What if there is more than one such action, but let's say 10 pieces and more on different pages?
Where to put the function that will check the status of the user?
How to name it so that there is no name conflict?
Redux is the first approach for me .
1. State is projected (front database)
{user:{online:false}}
2. checkUserStatus action (ajax/socket)
3. as many components as you like (which do not know anything about each other and have any behavior, depending on the status of the user)
components may not be able to do anything other than render this status (label), or may be more complex and have logic + handlers ( buttons, etc.)
jQuery "sees" the entire DOM. And it manipulates the DOM that the browser provides access to. But it is possible in another way.
Let's consider such an architecture in which all components are interconnected in a tree-like manner. That is, a single component can communicate with its children and with its parent. If it is necessary that two components communicate with each other in different branches, then in the end their communication occurs through a common ancestor. This approach is quite consistent with the tree structure of HTML.
Then we separate state from behavior and presentation. The state can be described by a static data structure, JSON, for example. And behavior is a pure function, from the previous state and some event (action) making the next state. The view "knows" how to render the state. This principle can be reproduced from the smallest components (having no children) in our tree to the root. Then the entire life cycle of the application can be depicted as a chain of states from some initial state to the current one, driven by events (actions).
In order to display all this, it is not necessary to immediately manipulate the DOM during the calculation of the next state (or view). You can build a DOM fragment from the state and its representation, how it should turn out. And then calculate the diff between this constructed fragment (virtual DOM) and the real browser one. And apply this diff to the real DOM. Once. Get it quickly.
As far as I know (correct me if I'm wrong), Redux is borrowed from Elm. Elm is an ecosystem and functional language compiled to JS, designed to make front-end development convenient, fast and without runtime errors. Syntax is an adaptation of Haskell. The key element of Elm is just this very architecture. I advise you to read more in the original source. https://guide.elm-lang.org/architecture/
In addition to the mentioned features, this architecture also allows you to perform the so-called time-travelling debugging. Since each state and each event along the path from the initial to the current one can be pledged and reproduced (after all, we have a clean function that calculates the next state).
From the point of view of functional programming, with this approach, the current state is the result of the leftFold function applied to the initial state, a sequence of events (actions) leading to the current state, and a function that can calculate the next state.
jQuery is the principle of DOM events and modification, and saving states is a secondary matter
Typical mechanism: something happened (click / scroll) -> change something in the DOM, maybe remember something in JS
React is the principle of states, and changing the DOM or an event is a secondary matter
An event may have occurred -> update a special object (called the model)
Something has changed in the model -> it is possible to update the DOM if the model is somehow related to HTML
Redux assumes that all the state of your application is stored in one place (store), and the only way to change this state is to map the old state to the new one using a special function - the reducer. This function has the signature (action, old_state) => new_state, where action can be understood as a "recipe" for your action, for example "add user to database".
The component rendering engine in react does not explicitly know about redux, it only cares that a state change has occurred in one way or another, to which it must respond by updating the components in accordance with internal logic.
Redux is a state manager that all components see. In fact, you can make a bunch of isolated states and, accordingly, to them - according to an independent type of changes (mutations). Next, we register actions to states and mutations and apply these actions in components depending on the events.
For me, this is something like an mvc model in the frontend. The model is the state, the controller is the actions, and the views are the calls to the actions in the component template.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question