| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Name | Name | Last commit date | ||
|---|---|---|---|---|
parent directory.. | ||||
This means that all data in an application follows the same lifecycle pattern, making the logic of your app more predictable and easier to understand. It also encourages data normalization, so that you don't end up with multiple, independent copies of the same data that are unaware of one another.
(Containers are a gateway between State and Components. They take a piece of State from the Store and pass it into a Component as props using the mapStateToProps() method. The mapStateToProps() method accepts the state and returns only the relevant bits of state we need.)
Basically in React the setState() method is the initial and final step for changing the state and re-rendering the component. But with Redux this state changing will have to go through 5 / 6 different steps before state change can happen.
All these because in Redux all the application's state lives in one immutable state-tree called store. That store is at the fundamental level is a simple javascript object. And the reason its called immutable is because one does not simply modify the state tree. What we do is, we distribute action. State is read-only: The state cannot be changed directly by the view or any other process (maybe as a result of network callback or some other event). In order to change the state, you must express your intent by emitting an action. An action is a plain object describing your intent, and it contains a type property and some other data. Actions can be logged and later replayed which makes it good for debugging and testing purpose.
Object goes to the reducer, which in turn is just a function that takes an object. And what comes out of it is also just an object.
https://medium.com/@holtkam2/react-redux-understanding-the-data-flow-fd700b6bd56f
| Back | FazBrowse Home | New Git URL |