Is there a way to check if a loader is currently open?
I’m using a boolean value to store the current state which I update on each change. I cant find anything on the Loader that I can use to check this.
present() returns a Promise that resolves once it is open.
1 Like
To add more info to what @rapropos said, you need to make a loop with if and then conditions. The loading / loader widget will close once all conditions are matched.
No, and this makes no sense. What I was trying to tease out of @baadier1 is that they were popping loaders in one place and attempting to dismiss them somewhere else. I consider that an antipattern. Loaders should only be lexically scoped and controlled in a single place.
To add more context to the original question.
We have a network conditions provider that monitors whether we have a usable network or not.
When the app boots up a initial boolean value is set by checking whether the internet is available or not.
We then display a network loader that blocks input and requests that the user turns on a network.
We also then set up subscriptions on the network connect and disconnect observables.
The issue we having is that it seems that the observable is firing multiple times which results in the loader being shown again so we end up with multiple loaders overlaid on each other. One solution was to have dismissAll() on the dismiss function but it seems a anti-pattern to gloss over a bigger problem.
What I’m trying to achieve is a check to see if the loader is currently open and then not to display another.
The promise doesnt help as I’m not concerned with when it finishes opening and more with is it currently open.
I was in the process of setting a bool when I open the loader so I can manage state like that but thought there must be a simpler way. I couldnt find anything on that Loader object though.
Is it safe to say that the best choice would be managing the loader state in the provider as a bool?
I created an intermediary loading service. Async calls ask the service to post a loading spinner. The service only posts a spinner if there isn’t one already posted. You could also send a fingerprint with each request that would match with a dismiss, so you could ensure there is a loading spinner showing as long as there is an open request. (Counting up and back down to 0 would probably be fine too, though I wouldn’t do it that way because it would be harder to debug.) I don’t need that because of how I structured my database calls. But if you’re doing more (or doing it more chaotically…) then it might be a good safety mechanism.
1 Like
So we have a general purpose loader that we use for run of the mill stuff like async calls that works in this way.
Then we have one or two specialized ones that operate differently like the network-conditions-loader where we operate it seperately. It probably makes more sense to just manage it like this if the Loader component doenst have a check to see if its open.
How are you doing the fingerprint?
const UPLOAD_PHOTO_TO_STORAGE_FINGERPRINT = 'iA44B'; // unique random string
The purpose of the call is opaque when the JS is uglified, but a search on the fingerprint in the source takes you to the self-documenting const name.
Also, I store the fingerprints in a Set, not an Array, just in case there are any duplicate requests due to backoff.
Sweet thanks! Cool idea. I’ll share with some of my team mates.
In response to the very first question. simply check if(loading.instance).
2 Likes
For modals, popovers, loading overlays, toast etc, you can check existence by calling getTop() on the controller:
loadingCtrl.getTop().then(v => v ? loadingCtrl.dismiss() : null);
If getTop() returns a value, you can do some work on it, else return null.
3 Likes
const loadingExist = document.getElementsByTagName('ion-loading')[0];
if (!loading) {
await this.presentLoading();
}
I dislike direct DOM access in app code unless there is absolutely no other alternative. Also, every time you rely on undocumented framework internals, especially when using strings like this that are completely opaque to static code analysis tools that can warn you, you create another potential point of failure when framework updates come out.
Does here any alternatives ? Other samples don’t works in my cases.
I’m curious why you would need to do this at all, but I would probably go with what @AaronSterling suggested, and manage it myself.