Redux Action Dismisses Modal and Makes It Appear Again

May 19, 2022 Post a Comment

Redux-Observable volition solve your state problems.

Solving Common Async Land Issues

Anybody using Redux will eventually find themselves in demand of a way to handle async actions. At that place are quite a few options out at that place with the biggest name being Redux-Thunk followed by Redux-Saga and Redux-Observable.

Redux-Observable is an amazingly powerful middleware for Redux using RxJS. Using Redux-Observable requires knowing or learning RxJS which is itself a major pain in the butt. When I first started using these tools, it took quite a bit of time and a lot of experimentation to effigy out a good process.

Instead of forcing anybody else to become through the same thing, I've created a bunch of helpful starter epics you might use in your project. While these are going to be simpler examples (relative argument), you lot should be able to figure out the basics of RxJS and how it ties into Redux-Observable for your ain uses.

What is Redux-Observable

Redux-Observable abstracts out connecting to the Redux shop and handles subscriptions for you so you don't have to worry about listening for actions or dispatching them yourself.

At a very basic level, it's calling Redux's acceleration role when it subscribes to all your epics (appreciable pipelines) at the same time like then:

          allYourObservablesTogether
.subscribe(store.acceleration)

Because Redux-Appreciable just dispatches actions, it might not be obvious how to work with side-effects.

Side-Effects

Allow'southward get-go with side-furnishings. Sometimes you need to hook into 3rd party libraries like a chat customer, a logging platform, or an analytics service. To exercise then, you're virtually always going to be calling into their non-Redux libraries. Since Redux, by default, only calls actions that affect state through reducers, you might be wondering how you lot're supposed to necktie in third party libraries with Redux. That's where Redux-Observable and its epics come up in.

For this case, I'll be communicating with a tertiary party service and telling it to start logging but after I've stored the user'southward information; for instance, later a successful sign-in.

We start past piping off the activity$ observable given to our ballsy by Redux-Observable. We want to check if the action coming in has a matching type using ofType.

Under the hood, ofType is really:

          filter(({ type }) => (
            type === 'USER::UPDATE_USER_INFO'
))

ofType is just like checking for action.type in a land reducer. Any action that occurs volition go through this ofType check and either proceed or stay.

Considering a logging service requires our user's data formatted in a certain way, we'll map information technology to a new object, so laissez passer that over to the logging service using tap.

tap is used when you want to do side-effects such every bit a console.log or claw into a 3rd party tool similar updateLoggingService. It's exactly the aforementioned every bit a Promise's .then() except it doesn't mutate the land of the pipeline.

This is the Promise equivalent of a tap:

          Hope
.resolve(value)
.and then(value => {
            updateLoggingService(value)                return value
})

tap is also bang-up when you wanna debug your pipeline. It's invaluable when working on a new ballsy.

Since all epics must emit an action and we're not doing that, we end our pipeline with ignoreElements. We've placed ignoreElements right at the finish of our observable so it'll stop the pipeline every bit soon as information technology gets past tap. No action is ever emitted.

Execute Once

Along with side-effects, sometimes you'll desire to execute an action simply once. In this example, it'southward going to be when y'all want to beginning your on-site conversation.

This ballsy looks very similar to what we had before except it starts the conversation client only once using have(ane). This means, no matter how many times that action is called, it merely executed that starting time time.

There might be a separate action to update the conversation customer with user info like we had in the previous instance, but this epic is only concerned with starting the chat client. Since we're calling a function on a 3rd party service, we actually only want to call this the one time. Calling it once more would upshot in an mistake from that 3rd party library.

Immediately Executing Actions

When your app starts, y'all might want to immediately execute an activity instead of waiting for an action to come up in. Information technology's most-probable a bad idea to tightly couple an ballsy with Redux-Observable's initialization, but information technology removes the need to call a an action to execute your epic.

A simple instance is to log the app's current version to the console and then yous can be certain the deployed version of your app matches up with the version you expected to be out in that location.

I've provided 3 dissever examples, but you'll probably only want to use ane in your application.

Observe that we're not using ofType. There are no Redux actions being emitted to trigger the app version logging. While this may seem similar a practiced thought at first, information technology also ways we have no control over its execution. I'd recommend against using immediate deportment like this unless yous really take a demand. Either way, we tin can use this case to acquire some more than RxJS patterns.

Redux-Observable, prior to version 1, did not handle immediate execution properly and required using timer(0). The timer part takes a time and waits until that time has passed earlier emitting a 0 through the pipeline just once. To be clear, it passes 0 through the pipeline no matter what y'all've passed into the timer function.

Under the hood, it looks something like this:

In the other two examples, I use of and EMPTY. of volition emit annihilation it's given. If you pass information technology more parameters, each 1 of those will be emitted separate one after the other. In this instance, we don't intendance what nosotros emit, so long as we emit something. We could fifty-fifty emit cipher, but nosotros're choosing to emit appVersion to make our code a scrap cleaner.

EMPTY is a abiding observable which completes immediately when subscribed. This is why we can use defaultIfEmpty. What happens is EMPTY calls observer.complete() and then the value in defaultIfEmpty gets passed downward the pipeline then long as it's in your pipeline. That'southward why we're not calling console.info(appVersion) directly.

Updating Land

Probably the nigh basic example of Redux-Appreciable y'all'll run into is updating the state. It's non entirely obvious, but updating Redux'southward state with an epic requires listening for an activity and executing some other activity.

In this case, we have an authentication platform dispatching an UPDATE_USER_INFO action when a user signs in. There are a few ways nosotros could handle this such equally doing all the conversions directly in our reducer, but we can let our epic handle it instead.

Commencement, we map (transform) our data to match how we're going to store it, then nosotros map to the action that our reducer listens to for storage.

Now, our userInfoReducer can be a simple as this:

Because you can practice a lot more with an appreciable pipeline in your epics than your reducers, information technology's a great process to take super uncomplicated, reusable reducers and utilize epics for all your data transformations and business organisation logic. That fashion, yous can concentrate on circuitous logic in Redux-Observable instead of complicating your reducers.

Utilizing the Store with Actions

A lot of the time, y'all'll want to employ something in state to execute other actions. This is where we become to the real ability of Redux-Observable. It'southward i thing to listen to actions, it's another to bring together the entirety of your application'southward state in 1 identify and use it to execute other actions.

I've had quite a few situations where I actually desire something out of the state, but peradventure it'due south non at that place notwithstanding. Maybe I'd like to wait until something's in the store before my ballsy continues. There are a few ways of going nigh this. I'm going to go over a few simpler examples and explain why yous'd employ them, merely I'll leave the complicated one for the end of this commodity.

In this first example, nosotros wait for the UPDATE_AUTH_INFO action to dispatch before doing anything. Our terminate goal is to dispatch the closeModal action once we're authenticated.

Like our other observables, nosotros're listening for an action, and then mapping. In this instance, we don't even care what UPDATE_AUTH_INFO has as a payload because we're mapping to the closed-over land$.value. The .value prop doesn't exist on most observables, but state$ is a BehaviorSubject which ways you tin can grab the current value off at any time.

Next, we grab the electric current authInfo object from our country and pluck the isAuthenticated prop off it. It's the same as doing:

          map(authInfo => (
            authInfo
            .isAuthenticated
))

Next is a trick I utilise to filter truthy values with a lot less code. By passing the Boolean constructor function to filter, only values that are truthy will proceed. Be aware 0 and '' are falsey.

Once we know for sure the user'due south authenticated from our country, we can execute a new operator: mapTo. This is just like a map, merely it stores the value it receives at runtime instead of executing a function in the pipeline like map.

From hither, nosotros continue as usual, mapping our pipeline value to an action which will become dispatched by Redux-Observable.

Listening to Country Updates Directly

Sometimes you'll want to listen to state$ direct. This can be very efficient and decouples your epics needing to know which actions update which parts of the state.

In this instance, nosotros're relying on the immutability of the Redux store through the distinctUntilChanged operator. This operator holds onto the previous land and compares that with the current value in the pipeline. If they lucifer, information technology stops the pipeline right there. If the value has inverse, continue through the pipeline.

JavaScript Events

Sometimes you need to hook into JavaScript events like listening for changes to localStorage, communication from an iframe, or interacting with a tertiary party library. This comes up a lot since third parties well-nigh never use observables.

We're going to listen for changes to our window size because we're going to be creating a custom implementation of an @media query.

We create a fromEvent observable using window, and the type of event we're listening to: resize. This is the aforementioned as doing a window.addEventListener except it's wrapped up nicely into an observable.

You tin can fifty-fifty listen to other kinds of events such equally on:

          someThirdPartyLibrary
.on('set', () => {})

When using fromEvent, it looks like this:

          fromEvent(
            someThirdPartyLibrary,
            'ready',
)
.pipe(
            // This is your callback pipeline
)

One time those responses come in from our resize events, we're going to limit them to 60 frames a 2nd. This means resize notifications will only come in so long every bit they're within this 60 frames-per-2d time slot. That also means we're merely going to have a maximum of lx resize events come through per second.

As description, we should really be using the requestAnimationFrame scheduler in RxJS, but we rolled our own for this example because it's much simpler to explicate.

AJAX Calls

If you're hooking into API endpoints straight instead of through a GraphQL server, you'll probably want to go through Redux-Appreciable to manage state updates from AJAX calls.

This is where dependencies come in. Instead of pulling in ajax straight, it's all-time to inject information technology into your epic through the middleware function.

This allows for easier debugging. If you return server-side also like I practice, you'll desire to know the ajax function from RxJS only works when you have a DOM because information technology's doing an XMLHttpRequest under the hood. You lot could always swap this out for something like axios or fetch equally well.

At that place's an operator in RxJS which volition piece of work in-tandem with ajax and that's switchMap. When using switchMap, information technology completes the previous ajax observable which cancels the request. This is smashing for async deportment because it ways you lot tin easily minimize race conditions.

Information technology looks a little something like this:

Dependencies come up in every bit the 3rd statement of our ballsy creator. Your access token or id token should have the permissions stored in it; although, you might need to check with the associated API what your user'south capable of doing to ensure the UI doesn't permit them more than power than usual. In this instance, we're request the API for all user permissions.

With this ballsy, there's a lot more than going on. Before we can fifty-fifty make an AJAX telephone call, we need to take hold of the accessToken from the store using land$.value.

Now we're seeing a new operator: switchMap. This, and a few others like it, are by-far the about-important operators since they allow you to chain observables together in a single pipeline. In our case, when y'all call the ajax function, it will return an appreciable.

Normally, we could render immediately after calling ajax and add our operators to the master pipeline. Instead, we're going to pipe off of ajax directly. While it doesn't brand sense in this instance, information technology has to do with how nosotros'll eventually handle errors.

After our successful AJAX call, we pluck the response holding containing our permissions list then map to the storePermissions activity.

`Cancelling AJAX Calls When Using mergeMap`

When pulling all permissions at in one case, yous tin probably get away with a single ballsy. Based on your architecture, you might be using React and each component might know which permission(due south) information technology requires. In this instance, especially if your app has a ton of permissions, you lot might fetch a single permission when you lot need it rather than pulling in the whole list.

Yous don't want to create a split epic for every possible permission. Instead, you'll want to create a generic epic which utilizes mergeMap. To avoid race conditions in these situations, you lot'll need the takeUntil operator.

Let'due south outset from the top. I've added a helper function to filter out permission actions based on a given permissionType. This is going to come in handy later in the ballsy.

Much of this epic is the aforementioned except we're now passing in a permissionType with our activeness and demand to combine it with a value off the state. I'm using an observable from earlier: of which takes the value passed and pipes information technology through. In this way, we can pipage off the of observable, grab the access token, and switchMap to ajax similar before.

When yous utilize mergeMap instead of switchMap, it will create a new observable and also subscribe to it. This operator can single-handedly create memory leaks if y'all're not careful. Thankfully, ajax merely fires once and completes later, but if y'all want the same cancellation behavior we had before with switchMap, we'll want to use takeUntil.

takeUntil is given an observable and never pushes anything through the pipeline. When the given observable emits, it completes the current observable in the same way take would.

In our takeUntil, we're listening for another FETCH_PERMISSION action that has a matching permissionType. If so, we'll complete the observable which cancels the AJAX call. This allows another 1 to begin without incurring a possible race status.

Delaying AJAX Requests

You might want to limit the amount of AJAX requests that go out at a fourth dimension. For example, yous might be uploading files and desire to exercise them in pairs of 2 instead of 10 files all at once.

Using mergeMap, it will most-certainly transport all 10 files at once. On the other manus, using concatMap will limit it to i item at a time. If you want to limit it to two items at a fourth dimension, use mergeMap with a 2nd argument of two. This tin can exist actually difficult to take hold of if yous keep everything in the aforementioned epic though.

A better way would be to use map and mergeAll like so:

This example is pretty complex, and it'south got a lot of concepts nosotros haven't seen yet. For instance, wrapping permissionTypes in from actually pipes each permissionType through as a separate value in the pipeline. We're mapping those into a whole new appreciable which nosotros mergeAll(2) to keep information technology down to two items beingness merge-mapped at a time. This restricts the load we're putting on the API and ensures our application can handle larger and larger batches of permissions with ease. Other than those changes, it'southward by and large the aforementioned epic equally before.

The one major divergence is how nosotros handle the takeUntil. When FETCH_PERMISSIONS is executed, we now need to loop through each permissionType and see if any lucifer upward with our activity telephone call before cancelling.

Waiting for Merge-Mapped Observables

At present, what if you lot wanted to wait until all these merge-mapped observables consummate merely at the same time fire off the storePermission action? For that, we'll use toArray and multicast.

I've really used this functionality in a existent application for an epic that controlled file uploads so it does accept its uses.

The multicast solution is pretty amazing, just also difficult to sympathize. You lot actually need to exist aware what this is doing if yous wanna change the behavior of it, but I'one thousand only going to comprehend the current implementation at a high-level in this article.

Subject has some special sauce where information technology's both an observable and an observer. Because of this, we're creating a split up Subject observable that is going to receive the same output at this point in the pipeline and is connected to the source observable (in this case from(permissionTypes)). Nosotros are going to merge the source observable with itself and pipe off the merged observable.

Nosotros've placed this multicast operator immediately after the mergeAll, and so it will receive each permissionType response every bit they emit. One time all permission types take passed this area of the pipeline, toArray volition emit an assortment of AJAX responses it gathered. Since we don't intendance about those responses as we already handled them individually, we then map to the finishedStoringPermissions action.

Here's a much much simpler example that you could re-create-paste into just almost whatsoever JavaScript playground:

Note: range(one, 4) is the same as from([i, ii, 3, 4]).

Catching AJAX Errors

How exercise nosotros handle errors in Redux-Observable? The aforementioned mode we do with RxJS… Kinda.

We use catchError to catch any unsuccessful AJAX responses. If not, they would be swallowed by Redux-Observable, and you'd never know. RxJS v6 solves the fault swallowing, but information technology's possible you desire to handle that error anyway.

In this example, we open the error modal and pass it the error along with a stack trace. Note the use of the of observable again. catchError takes a office that returns an appreciable. Failing to do so results in some other fault entirely and then if yous're using catchError, be sure you're going to fire off an action.

We too take to put catchError on the ajax observable specifically because information technology wouldn't be caught otherwise. This is why we pipe off ajax straight, because the action returned by catchError still goes through the pipeline every bit if catchError was never called.

Generic Error Catching

Similar AJAX errors, you volition want to put catchError on quite a few of your epics. In this example, we'll transport them over to our logging software by calling an fault activeness. This style, those errors are as well available in the Redux Devtools. Nosotros can also create an epic somewhere else in the codebase that but listens for this error action and handles integrating with the 3rd political party logging service using a side-effect.

If this instance is executed server-side, window is undefined; thus, you'll normally break your app, but with Redux-Appreciable, you'll only striking the catchError and continue on as if nothing happened.

We're purposefully making sure to yet telephone call storeCurrentUrl in this example, but since we don't have window, we'll laissez passer a zero cord instead.

Not but that, but we're also calling logError to notify our logging service at the aforementioned fourth dimension considering of the helpful observable merge. As you've probably gathered, merge allows u.s. to execute multiple actions at the same time when nosotros laissez passer them in as carve up arguments.

Because information technology's going to come up, you should be enlightened in that location's also a merge operator. I would say you could probably avoid using the operator version birthday, but because of a deficiency in how RxJS'southward finalize operator works with Redux-Observable, you'll eventually come to demand it.

I briefly went over merge in the generic catchError example, merely there are far more uses for it. Typically, before making AJAX calls, I'll showtime a loading indicator. Later on the AJAX call is complete, I'll fire more actions such equally storing that data and stopping the loading indicator.

Our examples are getting a lot more than complicated so we're keeping information technology to this aforementioned permissions ballsy.

Using merge, we're able to start the loading indicator correct before the AJAX call and finish it immediately later on. Sadly, at that place's no real way to heed for both successful and unsuccessful with Redux-Observable. This is because the finalize method in RxJS is like tap. It calls an action when the appreciable either completes or errors, it does non actually execute anything. Then y'all tin can utilise it when you need a side-effect, but not when you want to call an activity in scenario i or 2.

To get around this outcome, I've added the operator version of merge which I'm going to alias as mergeOperator so it'south clear:

In this example, mergeOperator works similar to a finalize function, and we don't accept to duplicate our loaded action.

Listening to 2 Observables

Our app has an error notification that automatically removes itself afterwards x seconds, just also allows the user to hide the fault manually before the timer runs out. Somehow, we have to observe a manner to listen to ii observables at the same time and have them race to see which 1 happens first.

We're using the aforementioned concepts equally earlier, but now there's a new appreciable in boondocks: race. This observable emits the first value betwixt the two observables.

Something to be weary, race doesn't just terminate as presently as a race occurred. While similar to Promise.race(), it actually keeps listening. When one observable emits, information technology lets that appreciable's emission go through and waits until the other one emits as well. Once that one emits, it goes dorsum to listening and seeing which of the two volition win the side by side race. This continues as long as the race is withal agile.

To mitigate the infinite wait issue, I've placed have(1) on the HIDE_ERROR_NOTIFICATION action listener. timer(10000) completes afterwards it emits so I don't take to take(i) on it.

The last part that ends up being pretty weird is the filter. This is there to ensure we only call the hideErrorNotification action once. If the timer runs out start, hideErrorNotification will be called. Since it'south in a race, information technology won't emit anything. But if the user hides the notification him or herself, and then hideErrorNotification has already been called, and we don't desire to call it a second time. This is why information technology'due south existence filtered out.

Race to the State

If we're loading components which dispatch actions requiring an accessToken, it's quite possible those components will load prior to an access token beingness available in state. In this particular example, we don't want to make an AJAX call without an accessToken.

Here'southward the error-prone example:

This particular appreciable might make the AJAX telephone call with undefined as the accessToken. You might be thinking we could utilize race to solve this issue; and we tin, but it'southward unnecessary.

To ensure you lot have an accessToken in your country, you need to listen to country$ :

By listening to state$ and checking for a truthy value from our accessTokenSelector, we're ensuring that we just make this AJAX telephone call in one case we have an accessToken.

This only works considering country$ is a special kind of observable chosen a BehaviorSubject which means state$ always has a value whereas activity$ is stateless and can merely listen for actions. This is why state$.value exists, and besides why listening to state$ gives y'all the latest value.

In another situation, you might not want to wait for the accessToken to exist available. Instead, y'all could write some logic later on your accessTokenSelector to display an error if you don't accept an accessToken available.

Conclusion

I hope y'all've gained something from reading this article. I see it as an extension of the Redux-Observable documentation and an aggregating of most 9 months of my ain experience with Redux-Appreciable and RxJS in production applications.

All of my applications using Redux-Appreciable have been congenital using these very aforementioned edifice blocks. At that place are enough more solutions I've implemented with Redux-Observable, but these few should exist plenty to get started!

Moore Hatemaked