Missing part of Redux Saga Experience

Redux saga is a middleware between an application and redux store, that is handled by redux actions. This means, it can listen to actions, intercept actions it is interested in and replace them with other actions. This may be useful for plenty of things. In particular, using sagas you can keep your components as simple as possible and move all the logic to sagas. When you start working with Redux saga, it seems quite natural to write sagas that describe behavior of a single component or a single page. And it works fine in simple applications that have two or three pages and everything is loaded synchronously. But when a project grows, this may lead you to a mess in sagas department, where sagas don’t have clear purposes and duplicate each other in many ways. It will be difficult to manage, debug and make even small changes. The thing is that sagas’ work should be coordinated. After some time of struggling with this mess and finally reading the documentation we in DashBouquet came up with a new approach, which has always been there. Describe a full flow in a saga. This is what the documentation implies, you should just read carefully. Let’s see, what it looks like. It looks like a flow, isn’t it? Sure, describing full flow in saga doesn’t mean that there should be only one saga. The point is that everything is handled from one place. Now, let’s take a look at an actual example. Say, in our app a user is able to fill up a job application and send it to the server for further processing. We want to create a saga that will describe full flow of this process. Everything starts on route when a user clicks an “Apply for a job” button and is redirected to the application form. /create_application_page {take, call, put, select, fork, cancel, race} 'redux-saga/effects'; { , } 'react-router-redux'; {takeEvery} "redux-saga"; * api './api'; import from import LOCATION_CHANGE push from import from import as from createApplication(data) { put( (`/application_form`)); function* yield push { saveApplication } = yield race({saveApplication: take(SAVE_APPLICATION),cancelApplication: take(CANCEL_APPLICATION),}); const (saveApplication) { { data } = saveApplication; api.saveApplication(data); put( (`/application_saved`));} else {yield put( (`/application_cancaled`));}} watchCreateApplication() { createApplicationTask = takeEvery(CREATE_APPLICATION, createApplication); if const yield yield push push function* const { {payload: {pathname}} = yield take( ); (pathname.search(/^\/create_application_page\/?$/) !== -1) { cancel(createApplicationTask); }}} while (true) const LOCATION_CHANGE if yield break; Here is an action dispatched when a user clicks “Apply for a job”. Then he is redirected to another page with a form. After the user fills up the form and clicks Submit or Cancel, he is redirected further depending on which action was dispatched. And data is sent to the server only if the user clicks Submit. CREATE_APPLICATION Also the user may 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 where the saga is injected asynchronously, it will be injected one more time, and the data on the server will be created twice, while the user intended to do it only once. We certainly don’t want that, so we need to cancel the task on LOCATION_CHANGE dispatched by redux-router, hence checking the pathname in . /create_application_page watchCreateApplication And just to make things a bit more complicated, we assume, that in the middle of filling up the form, the user can call a dialog with another form, in which he can choose, say, a country and a city he is applying from and submit this data to the server. We can do this by simply forking another saga that would be quite similar to saga: createApplication chooseLocation() { put(showDialog()); { saveLocation } = yield race({saveLocation: take(SAVE_LOCATION),cancelLocation: take(CANCEL_LOCATION),}); (saveLocation) { { data } = saveLocation; api.saveLocation(data);} put(closeDialog());} function* yield const if const yield yield createApplication() { put( (`/application_form`)); createLocationTask = takeEvery(CREATE_LOCATION, createLocation) function* yield push const ... cancel(createLocationTask); yield } Here we handle the dialog with and 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. In more detail it is a subject for another article. showDialog closeDialog It is important not to 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. It is a quite simple example. A flow may be much more complicated, with any amount of subflows (though it might be a bad idea from UX point of view). But anyway, what this approach gives 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, but no matter, how many forks your flow has, you never get lost in it. _After applying few simple manipulations to the result of Normalizr’s work we get data that we can keep in store_hackernoon.com Using Normalizr to organize data in stores — practical guide _Why reselect is so good_hackernoon.com Usage of Reselect in a React-Redux Application _The second part of the article about how to use Normalizr to organize data in stores._hackernoon.com Using Normalizr to organize data in store. Part 2 _Javascript has two major ways of dealing with asynchronous tasks — callbacks and Promises. In general Promises are…_hackernoon.com How to Stop Using Callbacks and Start Living Written by Ilya Bohaslauchyk