Identifying in flight effects?

[imfractured]

Hey Folks,

My team is looking to integrate some hardware input devices into our TCA app and I'm curious to know if there's a way to identify in flight effects that are async in order to guard against initiating that same action / effect flow again until the first async is completed.

Basically we have a piece of hardware that emits an action that kicks off an API request. Previously we only used software input such as keyboard or camera which we could limit input by throwing up a spinner overtop the UI so the user couldn't create multiple instances of that action. The problem comes from the user hammering on the hardware device that essentially will start multiple instances of that async request which can have an undesiered effect on the API and user experience.

We can't cancel a cancellable in this case because we actually need to get the response back before we want to allow the user to create a new action / input that would kick off the same loop again.

Since we can cancel inflight effects with the cancellable and they take an ID, I was wondering if there's a way to identify any in flight cancellable events possibly in order to block the action before we kick off the async request from the reducer level in a more structured way. ie. check for inflight effect id: x, and if it exists return .none instead of moving forward.

I could approach this by having a Bool for example every time that action creates the effect with something like isLoading = true and once the async completes kicking off the secondary action it could set isLoading = false but that would add a lot of extra cruft across the reducers that I would prefer to avoid if possible.

Any ideas would be greatly appreciated!

[mbrandonw]

Hi @imfractured, without making changes to TCA I think you only have two options. The boolean state like you mentioned, or possibly tracking that boolean state in the dependency itself so that you can ask the dependency if the work is still running. At least that way you do not need to keep booleans in your state to track that, but it does mean your mock dependencies need to do the extra work to also track that booleans correctly so that you can trust your tests.

Currently there is no way to ask the library if an effect with a specific ID is currently running. That is actually something we do want to add to the library, and it will be possible with some upcoming changes we want to make. But we just don't have everything in place for that yet.