Sweetalert2: good way to see if there is already a modal open?

[kenvernaillenvub]

[limonte]

I added swal.isVisible() global function to check if swal2 modal is visible to v4.1.9

Thanks for the nice request @kenvernaillenvub !

[kenvernaillenvub]

My current problem is that some modals, that shouldn't be closed (only by confirming) are closing when opening a new modal.
Maybe by a variable like "allowOverwrite".
When in modal1 "allowOverwrite":false and modal1 is open, when modal2 is opening, it should be pushed into the queue of modal1.

[blazeworx]

I also have the situation where I have a modal open currently that should only be closed by clicking the the modal's button and if another modal is opened (by a background ajax call or whatever). it closes the original one and pops up.. instead of queuing up as the next modal to show after the current one is closed. Not sure how I am going to get around this yet..

[limonte]

@simo9000 you are the most skillful here in swal2 queues :) do you have any idea how to handle the case mentioned by @blazeworx?

[birjolaxew]

We currently do not have a way to handle more than one alert being "open" at a time. We should probably implement an internal array, which tracks alerts that were hidden by opening another, and some logic to reopen them once the active one is dismissed/closed.

[simo9000]

@blazeworx PR #241 will allow you to do exactly what you are trying to do. You'll have to implement your swal as a state machine. Then during the ajax call, assuming you make the ajax call as part of one of the swal callbacks (i.e. preConfirm, inputValidator etc) you'll be able to edit the swal queue and insert a new alert to follow the current one when closed normally.

I am just doing testing and docs now on the PR and should have it ready to go this weekend. I've been swamped with work and other stuff until just recently.

As far as implementing a way to have multiple alerts open at once, i am not sure what benefit that has over advancing the queuing features. Won't that require adding more swal modals to the DOM? All of the testing functions are using class selectors which would break if we allow more than one swal modal to exist in the DOM. It's also more memory intensive to do it that way.

Just my two cents...

[limonte]

I'm reopening this issue, it becomes interesting :)

[birjolaxew]

@simo9000 Nah, it wouldn't require multiple DOM instances. We'd simply have an array of JS instances (either by saving the input to swal(), or ideally by rewriting the lib to use classes and then save an instance of that) which we then push/pop as alerts are opened/closed.

It _would_ require some rewriting, but it would make sure users don't have to implement the queue themselves.

[simo9000]

@birjolaxew ok i can only see that as working with classes. We could make every call to swal use a global queue behind the scenes and then appending a new alert in a callback could be done with a single function call in a callback.

It would definitely be simpler for the lib users but would be a lot more lib rewrite than what i'm doing with PR #241. The state machine can achieve the same function but puts more work on the lib user for sure but I was OK with that since i was intending it to be an advanced feature. I also didn't want to commit to that much work rewriting the lib. in the end, the two ideas are not mutually exclusive...

[birjolaxew]

@simo9000 Oh, definitely. The state machine is completely independent of this.

I'll probably end up rewriting the lib to use classes at some point either way, but I'm a bit low on free time currently, so it might not be right around the corner.

[simo9000]

Regarding the use of classes, won't that require another polyfill to keep back compatibility with I.E.?

[birjolaxew]

ES6 Classes are simply another syntax for prototypes, which have been in the language since forever. We probably won't use the class syntax anyway, since we don't use an ES6 transpired, but we should be able to use prototypes without an issue.

[limonte]

@simo9000

I just released v4.2.4 with your PR merged.

Could you please make a jsfiddle with the simple implementation of use-case mentioned by @blazeworx . Thank you once again for your contribution! :+1:

[simo9000]

Alright sorry for the delay. I made a fiddle that shows the state machine doing an ajax call and then inserting an alert into the queue. I'll say again, the State Machine only provides access to modify the swal queue as part of a swal callback. I hope this is sufficient for what @blazeworx is looking for.

[limonte]

nice! I just added showLoaderOnConfirm: true to your fiddle: https://jsfiddle.net/r5ssrjhu/4/

[limonte]

@blazeworx let us know if this works for you

[blazeworx]

@limonte @simo9000 👍 sweet! works for me! might be a good idea to put that fiddle in the examples/docs.

[limonte]

Thanks for the feedback @blazeworx ! I'm happy we succeed to help you with your task. I'm closing this task and opening another one about the documentation https://github.com/limonte/sweetalert2/issues/270

[kenvernaillenvub]

My current problem is that some modals, that shouldn't be closed (only by confirming) are closing when opening a new modal.

Does this work now? And how?

If I open a swal-popup and another process opens another swal-popup, it still just removes the first one. Why aren't new swal-popups automatically added to a queue?

Fiddle: https://jsfiddle.net/kenvernaillen/7sfr1gLh/

[limonte]

@kenvernaillenvub

If I open a swal-popup and another process opens another swal-popup, it still just removes the first one. Why aren't new swal-popups automatically added to a queue?

For adding a new modal to a queue, instead of swal({}) use swal.insertQueueStep({}).
See the example: https://sweetalert2.github.io/#dynamic-queue