Most developers agree that automated software testing is an important practice. It proves that code is correct now and that it stays correct in the future as the code evolves. However, despite this widely-held opinion, there are still lots of developers who aren't testing their software.
Not knowing what nor how to test are big barriers to getting started -- and that's just with regular code. The barrier feels even bigger for redux-saga code because generator functions can't be tested in the same way as regular functions.
This could become a big problem for teams who are increasingly relying on putting complex business logic in sagas without tests.
I am going to walk you through some saga unit tests written using a library called redux-saga-test-plan.
We wrote some sagas in the previous article (Part 4) for a mock RPG. Now let's test them!
Does your web app use Redux-Saga and the Fetch API to make a lot of repeated or lengthy calls to a particular server?
You've probably noticed that Chrome limits concurrent connections to any given host.
This can be a big problem if one part of your app ends up blocking another part due to pending API requests.
Obviously, you should try to reduce the number of calls you make, where possible. Consolidating requests and using debounce or throttle techniques can help sometimes.
But sometimes you don't control the server or requirements dictate that you need to make those API calls regardless. Sometimes you're at the mercy of a slow database, slow network connection, or an impatient user.
I'm going to show you how you can "fire and forget" all your API calls through Redux-Saga with true request cancellation built into the system via the AbortController API.
Whether you're working on the back end in Node.js or on the front end with React, learning TypeScript is the number one thing you can do to level up your ability to produce solid code.
(Okay, well maybe that and learning how to apply automated testing effectively... but we're here to talk about TypeScript).
But what about the mountain of build tooling? It's so complicated. "I don't want to learn webpack and gulp and npm and babel and and and..." you say.
I understand completely. You want to start experimenting with TypeScript without having all the baggage. Undoubtedly, learning is easiest when there is no friction.
Here are some easy ways to get your toes wet with TypeScript before you dive in completely.
There are thousands of libraries you can add to your project. Actually... hundreds of thousands.
NPM reports having over 650,000 public packages available!
On one hand, this is great because you have so much selection... you can do whatever you want.
On the other hand, this can feel paralyzing because determining which libraries you need can be a long, painful process. Choose poorly and soon you'll face the horrible decision of fighting against a library you hate versus spending time-you-don't-have to rewrite your code.
This paralysis is compounded by the difficulty of discovering what libraries even exist. There could be a library that solves your exact needs but how would you know? Or you found a library that you think will work for you but how do you know if there isn't a better one out there?
You could read blogs and forums; follow high-profile developers on social media; read through open source projects to see what other developers are using.
But it all takes a long time and you're starting a project and need to know NOW.
To shortcut the process, I'm going to show you the libraries I use and recommend for React + TypeScript projects.