Why you need no Redux Saga
A very common requirement when writing single page applications is making an asynchronous HTTP request to some kind of an API. You might want to fetch some data from the server. Or you might want to perform some action on the server (think RPC).
Either way, it is an asynchronous action. And if you are just starting with Redux and/or front-end development, you google how other developers across the internet do these async things. And you come across redux-observable, redux-saga, redux-thunk, or some other “side-effects” library for Redux.
Redux-observable uses reactive programming, redux-saga uses generators. Both are extremely fascinating and useful concepts. But do you need to learn either of these to do that API request?
In a word, no.
To make my point, let us briefly get to the very essence of what we use Redux for.
I love Redux, because it allows me to abstract from the visual UI and lets me represent the state of my application in a simple (JavaScript) object. The UI is then for the most part just a visual projection of this object. It is as simple as that.
So, need to perform an asynchronous request? Ask yourself this question first: Does the request even affect the global state of the application at all?
- No it doesn’t. This is a perfectly valid use case. Forget about Redux and just call that axios (or the HTTP client of your choosing).
- Yes it does. Then why not just update the state yourself? One dispatch before the request and one dispatch after the request.
Anyone with even basic knowledge of Javascript and Redux will understand how the code above works. Don’t put a middleman in there until you see that it will bring you more than it costs you.
Another beauty of this “JavaScript 101” approach is that you get a Promise back (or an Observable if you wish)! Ever wanted to show a spinning wheel after clicking a button without a neck-breaking loop through dispatcher, reducer, selector, connect and props? Well now you can! :)
By the way, if you are a more seasoned Redux user, you might notice that this is not very different from redux-thunk at all. The main difference is dependency injection. Redux-thunk injects dispatch and getState for you — but since you have to pass the action to a dispatch first anyway, it saves you almost no keystrokes. On the other hand, it makes things a little less transparent and even changes the signature of the dispatch method to return a Promise (try explaining this to TypeScript).
Wrap up
My personal struggle with these side effects libraries was that they were adding a lot of complexity to something that, by itself, does not need to be complex at all.
I didn’t realize that what makes Redux really valuable for me, are not conventions or “using modern web technologies”. It is the fact that I can reason about the application without the burden of UI. And that I can easily write tests which do not have to rely on some crazy framework mocks.
So at the end of the day, my end goal is that I want to be able to update the state whenever I need to, to whatever state I need to. If a 3rd party library can help me with this, great! If not, why bother with it?
Whether this model works for you is entirely up to you to decide. But it has for me so far.
