MapDispatchToProps Flow / The importance of Thunk
If you’re coming across this article, you’re probably learning the difference between the two functions that are called by the connect function.
mapDispatchToProps is the second function passed into connect. It is the dispatching of actions as props to the store, giving us access to the dispatch function. Down in my code below, I’ve specified under componentDidMount the callback props that the WishlistContainer component will then have that will use dispatch to send actions to the reducer.
I’ve destructured my mapDispatchToProps function by naming it ‘fetchLists’. If a component only needs the mapDispatchToProps function, it still has be named the second argument of connect. Indicate so by calling on ‘null’ as the first argument to say ‘this component does not need props from the state and there is no need to call on mapStateToProps.’
My mapDispatchToProps function, fetchLists, will retrun an object, as that is what mapDispatchtToProps does. The key of the object becomes the name of the component’s props and the value is a function that will call on dispatch with an action. Here I am assigning props to the component and invoking a dispatch. The value of fetchLists returns a function that will call dispatch with an action. (For disclaimer purposes to explain my code below, I’ve kept the name of the function being returned as ‘dispatch’. We can name the function anything we like).
After the second .then, the dispatch calls the reducer with the action. Calling on dispatch invokes the reducer, ‘FETCH_LISTS’ in this case with the code above. Invoking the reducer results on a newly updated state of the wishlist.
The switch case statement in the reducer determines how to change the state and return the a new state. Now that component has been updated. The component connected knows to re-render when the Redux state changes, and the component displays the new state.
With apps performing all types of functions and having to maintain a render to the user all the while keeping itself from crashing as it multitasks, these asynchronous acts would not be possible without middleware — the most popularly used to handle data being thunk.
The App makes a request to the API to retrieve data. Clicking on a button triggers the action creator - here it would be fetchLists or addList. The process of fetch and .then has to occur first and dispatch cannot be called yet until the promise from the process of fetch and .then has been resolved. Once we have access to the data we need (response.json()), then dispatch will be called to send the actions to the reducer. We want to keep the app from returning an action before the data is retrieved. Thunk makes it possible for an action creator (fetchLists, addList) to return a function (named ‘dispatch’ here) instead of a Javascript object.
To bring Thunk into your redux store and give the entire app access to it, it becomes an argument of the store enhancer applyMiddleware. With thunk tucked inside applyMiddleware, and together with the reducer, they are packed into the createStore function. We then declare a variable, commonly named store and make it equal to the createStore function that takes its arguments. Now, we have our redux store in the variable of store.
You want store to be declared globally. It then gets passed in as a prop to Provider to be able to wrap around the root component of your app, App component here, and this makes the App component and all the children components it holds accessible to the redux store.
