is a library for managing states that follow the principles of the . We won't go too deep in technical details, but we'll cover the basic principles that you'll need to understand this framework. Redux is an independent framework, but for the sake of brevity, we'll assume that we are using it with React. Redux flux architecture Global state (store) Unlike React’s standard architecture, the components state isn’t stored in its component class (with exception to specific cases). All data from the view or received by API’s, databases or any other endpoint is stored in a single global object called the store (is also common to name it the state). The goal of the store is to link each component property to one of its properties. This way, every time that a property data is updated, the component its rendered again using the new data instead. Following this concept, let's assume we have an app that requires user authentication and todo-list features. In this case, our store would look something like this: { : { : , : }, : [ , , ], } auth username 'admin' name 'John Doe' todos 'Brew coffee' 'Read Redux article' 'Watch AI documentary' See that we stored data about two different features in a single object. Actions "Actions are payloads of information that send data from your application to your store. They are the only source of information for the store." - redux.js.org That means that every time that you need to change a property data in the store, you need to dispatch an action. In a more technical description, actions are objects that contain a type property (responsible for informing the store about what kind of action it is supposed to execute) and the payload (the actual data to be altered). { : , : { : , : }, } // Action example type 'LOGIN' payload username 'admin' password '123456' It is good practice to maintain all data (except the type) inside a single property called payload. Still thinking about the auth feature, we could implement three actions: , and . LOGIN_REQUEST LOGIN_SUCCESS LOGIN_ERROR The first one would be dispatched directly by the user, while the other two would be dispatched by the app is based on the response of the auth API. To dispatch an action in our app, we need to make it the returned object of a pure function (action creator). This function will be made available for every component of the app. authUser = ({ : , : { username, password } }); const ( ) => username, password type 'LOGIN_REQUEST' payload Reducers Although actions can listen to events triggered by the user or by the app, they can't change the state of our store. To make any change in the store, we need to use our middlemen, reducers. Every reducer listens to every action dispatched by the app. It is up to us to define which of these actions it needs to take into account and do something about. For the auth feature, we would have a reducer to deal with the auth data of the user: authenticated = { (action.type) { : ; ; : state; } } const ( ) => state = , action false switch case 'LOGIN_SUCCESS' return true case 'LOGOUT' return false default return The first argument received by the reducer should always be the current state and we must give it the appropriate default value (in this case, false). The second argument is our action object that holds the type and payload data. Is common practice to use a switch statement to assess the action type and return a value accordingly. This is what makes sure that our reducer only changes the state of the store with specific actions and return the default value for the other ones, preserving the state integrity. Every reducer controls a single property of the store's state. Nonetheless, the property's value can be yet another object too. This gives us more possibilities for our app, for instance, separating the state in "modules": { : { : , }, : { : , : }, : , } // State representation auth authenticated true user username 'admin' name 'John Doe' token 'somecooltoken' // ... other properties Reducers have the edge to be super powerful and change more than one data in the state as long as they are encapsulated in the same object/module that the reducer is responsible for. In conclusion, these are the basics you need to understand to work with Redux, but as your app grows in complexity, you can make use of even more advanced features like middlewares I hope this was a helpful introduction to Redux and that you feel more motivated to use Redux to its full extend from now on. Previously published at https://medium.com/@mrcsmedeiros/3-basic-principles-you-must-know-before-using-redux-fc32917577ab
