Some of that may live inside components, but some may need to live outside the UI layer. Redux reducers must not contain side effects, but real applications require logic that has side effects. This logic can include side effects, such as async requests or generating random values, as well as logic that requires dispatching multiple actions or access to the Redux store state.
Thunks allow us to write additional Redux-related logic separate from a UI layer. Instead, they are passed to store.dispatch(): Thunk functions are not directly called by application code. Writing Thunks Ī thunk function is a function that accepts two arguments: the Redux store dispatch method, and the Redux store getState method. However, they can be used for a variety of tasks, and can contain both synchronous and asynchronous logic. Thunks are a standard approach for writing async logic in Redux apps, and are commonly used for data fetching. Using thunks requires the redux-thunk middleware to be added to the Redux store as part of its configuration.
#Redux middleware code#
Rather than execute some logic now, we can write a function body or code that can be used to perform the work later.įor Redux specifically, "thunks" are a pattern of writing functions with logic inside that can interact with a Redux store's dispatch and getState methods. The word "thunk" is a programming term that means "a piece of code that does some delayed work". Techniques for writing sync and async logic in thunks.
What "thunks" are, and why they're used for writing Redux logic.The last middleware in the chain will receive the real store's dispatch method as the next parameter, thus ending the chain. That function will be given the next middleware's dispatch method, and is expected to return a function of action calling next(action) with a potentially different argument, or at a different time, or maybe not calling it at all. Each middleware receives Store's dispatch and getState functions as named arguments, and returns a function. middleware ( arguments): Functions that conform to the Redux middleware API. This way, there is a single standard way to extend dispatch in the ecosystem, and different middleware may compete in expressiveness and utility. Middleware is not baked into createStore and is not a fundamental part of the Redux architecture, but we consider it useful enough to be supported right in the core. It lets you dispatch a Promise async action, and dispatches a normal action when the Promise resolves. Another example of middleware is redux-promise. They would receive dispatch as an argument and may call it asynchronously. It does so by letting you dispatch async actions in addition to normal actions.įor example, redux-thunk lets the action creators invert control by dispatching functions. The most common use case for middleware is to support asynchronous actions without much boilerplate code or a dependency on a library like Rx. Multiple middleware can be combined together, where each middleware requires no knowledge of what comes before or after it in the chain. The key feature of middleware is that it is composable. Middleware lets you wrap the store's dispatch method for fun and profit. Middleware is the suggested way to extend Redux with custom functionality.
0 kommentar(er)
