Hacks & TricksStudent CornerTutorial

How we describe full flow by using redux-saga

How we describe full flow by using redux-saga

What is redux saga?

Redux saga is somewhat between an app and a redux store, handled with the help of redux actions. By that I mean it is able to listen to actions and intercept the ones it’s interested in. As well it can replace the actions. Redux saga is normally used for a variety of things. One of its main applications is keeping the components as simple as possible and moving all logic to sagas.

Upon starting a work with Redux saga you will notice that it feels right to write sagas, which describe a behavior of either a single component or a page. The workflow is smooth with condition that your application is simple, has 2-3 pages and everything is loaded at one time. However, when the project expands, it often leads to chaos in sagas department and results in sagas that do not have the clear purpose and duplicate one another in numerous ways. Obviously, it will make your work much more difficult and you may have problems with debugging and making even slightest changes.

It should be clear by now that sagas work has to be coordinated. At DashBouquet it took us some time to finally come up with a solution which we did not even have to invent as it already existed. How about describing full flow in a saga? This is exactly what your documentation suggests if you pay enough attention to it. Below I will show you what it looks like.

Image shows full flow in saga

It looks like a flow indeed. And describing full flow in saga does not imply that there must be one saga only. The point is: handle everything from one place.

Also, check: Trust Joomla CMS for Powerful Websites and Online Applications

Creating a saga

To make it more clear we will have a look at an example. Imagine an app where a user fills up a job application and sends it right to the server. So we have to create a saga for describing a full flow of the process.

Start with /create_application_page route. When a user clicks an “Apply for a job” button he is redirected to the application form.

Image shows create application page route

CREATE_APPLICATION is an action dispatched when a user clicks “Apply for a job”. After that, the user is redirected to another page with a form. After filling up the form and clicking Submit or Cancel, the user will be redirected further, depending on the action. Note that the data is sent to the server only after clicking Submit.

Remember that the user can change his mind in the middle of filling up the form and just go by another link without clicking “Cancel”. In this case, if he later comes back to /create_application_page where the saga is injected asynchronously, it will be injected one more time. Moreover, the data on the server will be created twice, while the user intended to do it only once. It’s not something that we want to happen, so we need to cancel the task on LOCATION_CHANGE dispatched by redux-router, hence checking the pathname in watchCreateApplication.

Add some functions

And now I’m going to complicate things a bit more. Assume that in the middle of filling up the form the user can call a dialog with another form. Here he can choose, say, a country and a city he is applying from. And finally submit this data to the server. We can do this by simply forking another saga that would be quite similar to createApplication saga:

Image shows showDialog saga

Image shows closeDialog saga

Here we handle the dialog with showDialog and closeDialog sagas. In two words, they should set some value in the store to tell a page if the dialog has to be shown or hidden at the moment. It can be a topic for another article.

Do not forget to cancel the forked tasks. If at some point you find an avalanche of requests going to the server when it was supposed to be only one or two, you probably missed this somewhere.

This was a relatively simple example. A flow may be more complicated, with any amount of sub flows. Though it might be a bad idea from UX point of view. Nevertheless, the advantage of this approach is that you can build your flow step by step. You can make changes later quite easily and they will not lead to unexpected behavior from other sagas. You can make it more complicated if you need to. No matter how many forks your flow has, you never get lost in it.

If you have any doubts check my GitHub.

 

Comment here

This site uses Akismet to reduce spam. Learn how your comment data is processed.