Request management made easy with @zup-next libraries for react: Part 2.
Este artigo também está disponível em português.
Hey there! We are very happy to see you again. We hope you went through the first part of this series. If not, please check it out Part 1, then come back. Also, you can see our full demo which is the basis for this article.
So what about that third screen?
It’s a little bit more complex, so we left it for last.
In Payment container, we need to load some resources and create an order. To start, we can use the same strategy as before:
The components Loading, LoadingError, OrderProgress, OrderSuccess, and PaymentMethod, in the codes above, are not important for understanding the behavior of the library. But if you want to check them out, they can be found here.
Just to remember, we use isCreating, hasCreateError and hasCreateSuccess to verify the status of the create operation. These are some helper functions available in the library and you can find a list of all of them here.
In the Summary component, we call createOrder that dispatches the action to start the operation create of the resource order. Note that here we pass to createOrder the order we want to create.
Great! If you execute the code now, almost everything will work as expected, but there are two problems we need to fix.
First problem: we need to reset the state of our resource
Once we order something, “order.create.status” will remain the same in our redux state, either success or error. Then, if we go back to the home page and try to buy a movie again we won’t be able to, because when we reach the payment page, we’ll be faced with a success or an error message, depending on the result of the last order.
To fix it, we need to reset the state for creating an order before unmounting the component (or every time we mount it). To accomplish that, we can use the action creator resetOrderStatus. That’s easy!
Note: You can find an extensive list of all action creators available in a resource by checking our documentation.
Now, if you try to order a new movie, it will work properly! But, there’s still one other problem to solve…
Second problem: shouldn’t we update the balance value in the redux state?
If you’ve paid attention to the success message of the order, you might’ve noticed that there’s something wrong there. The text says “Thank you for buying with us. Your current balance is x” and look at it, the value of x still the same. Also, the value in the header didn’t update either. Not good, we can’t let users order things forever.
The way we defined our resources only tell them what to do when an action is dispatched, and they will deal with their own data. But, we can find some situations when an action should also impact another resource. This is one of them. When an order is paid, in other words, when a resource order is created, the value of the balance might have changed. For that reason, we also need to update the resource wallet. To achieve this, we can use one of the following approaches:
- Update the redux state manually, subtracting the movie’s price from wallet.balance.
- Reload the resource wallet.
We chose the second approach to fix the problem. We’ll set that after every successful order, the wallet resource must be reloaded. This is pretty simple to do.
When declaring our resources, we can pass a third parameter, which are generator functions to run just after the operations succeed. Note that they must be generator functions because they will be integrated as part of the saga. See in the code below how we can change the definition of the resource order to implement this feature.
Done! Now, every time we order something, the action to load the wallet is dispatched, which updates the balance value everywhere in our application.
The update and remove actions, available in our resources, works similar to the create. You can check the full resources documentation and see it for yourself.
To implement our first suggested approach (update the balance value without making a request), we’d need to use the first parameter passed to the success callback. For more information, please, check our documentation.
Final words
That’s it for now! The demo application is implemented and we deal with all requests in a very fast and organised way. Thank you for following us until this very moment. We’d love to hear your opinions on this, and if you have any ideas, feel free to contribute to our repository!
In the third part of this series, we talk about something very interesting and useful. How to use @zup-next/redux-action-cache to avoid unnecessary requests in our applications. Please, check it out, I’ll see you there.
Great thank's the co-authors Tiago Peres França and Isac
