Then, we call dispatch(), and pass in something, whether it be a plain action object, a function, or some other value that a middleware can look for. Just like with a normal action, we first need to handle a user event in the application, such as a click on a button. So how do middleware and async logic affect the overall data flow of a Redux app? One possibility is writing a middleware that looks for specific action types, and runs async logic when it sees those actions, like these examples:Īgain, notice that this "async function middleware" let us pass a function to dispatch! Inside that function, we were able to write some async logic (an HTTP request), then dispatch a normal action object when the request completed. Let's look at a couple examples of how middleware can enable us to write some kind of async logic that interacts with the Redux store. That means you could write some async logic in a middleware, and still have the ability to interact with the Redux store by dispatching actions. Middleware also have access to dispatch and getState. Also, since middleware form a pipeline around the real store.dispatch function, this also means that we could actually pass something that isn't a plain action object to dispatch, as long as a middleware intercepts that value and doesn't let it reach the reducers.
Redux middleware were designed to enable writing logic that has side effects.Īs we said in Part 4, a Redux middleware can do anything when it sees a dispatched action: log something, modify the action, delay the action, make an async call, and more. So, if we can't put side effects in reducers, where can we put them?
However, any real app will need to do these kinds of things somewhere. Generating random numbers or unique random IDs (such as Math.random() or Date.now()).Modifying some state that exists outside of a function, or mutating arguments to a function.Some common kinds of side effects are things like: A "side effect" is any change to state or behavior that can be seen outside of returning a value from a function. Any asynchronicity has to happen outside the store.Įarlier, we said that Redux reducers must never contain "side effects".
Redux dispatch how to#
It only knows how to synchronously dispatch actions, update the state by calling the root reducer function, and notify the UI that something has changed. Redux Middleware and Side Effects īy itself, a Redux store doesn't know anything about async logic. We'll use the client object to make HTTP calls to our in-memory fake REST API for this section. The project also includes a small HTTP API client object that exposes client.get() and client.post() methods, similar to popular HTTP libraries like axios. The API uses /fakeApi as the base URL for the endpoints, and supports the typical GET/POST/PUT/DELETE HTTP methods for /fakeApi/todos. To keep the example project isolated but realistic, the initial project setup already included a fake in-memory REST API for our data (configured using the Mirage.js mock API tool). In this section, we'll update our todo app to fetch the todos from an API, and add new todos by saving them to the API. However, most real applications need to work with data from a server, by making HTTP API calls to fetch and save items.
So far, all the data we've worked with has been directly inside of our React+Redux client application. In Part 5: UI and React, we saw how to use the React-Redux library to let our React components interact with a Redux store, including calling useSelector to read Redux state, calling useDispatch to give us access to the dispatch function, and wrapping our app in a component to give those hooks access to the store.
0 kommentar(er)
