Hitting ESC should close prompts and confirms about vex HOT 8 CLOSED

I agree, except the prompt should close without confirming.

from vex.

We definitely would like to add this feature as an option (similar to how showCloseButton is an option). However, the behavior gets complicated when multiple dialogs are opened. For example:

1. User opens Dialog A with the default setting (can close with ESC).
2. Dialog A launches Dialog B with the escapeToClose: false passed.
3. User presses escape.

Do we either:

• Close Dialog A?, or
• Do nothing.

Currently, Vex doesn't really know that Dialog B is on top of A (or hierarchically first). We could assume this by using the Vex ID order though. (This would assume that people never launch dialogs behind other dialogs, which might be fair.)

Another option entirely is to make this a global setting which cannot be overridden by individual dialogs. That kind of thing goes against one of the main philosophies of Vex which is that you control just about everything. But it might be worth simplifying in this case.

That being said, we'd like to solve this problem. So, please send us your thoughts and we'll start a PR.

from vex.

We decided to go with the assumption. When you hit ESC we use the options of currently opened vex with the highest vex ID to determine if we can close.

from vex.

@gregsabo I didn't mean that a prompt should be confirmed when hitting esc. I meant that the prompts and the confirm dialogs should be cancelable with hitting ESC ;)

@adamschwartz I would (don't know if you have already) add the option to open a dialog modally. This would mean that it is topmost (would also display a cover to block access to everything "below" the dialog).
Also, the only dialog that you can open when a modal dialog is currently displayed, is another modal dialog. "Normal" dialogs would get displayed below the modal ones.

So by default, alerts, prompts and confirms should be modal dialogs. That would be as closest to the "native counterparts" in the browser as possible.
Ideally, alerts, prompts and confirms would halt the script execution, but sadly thats not possible right now :)

from vex.

Thanks @Paratron for your additions.

Remember that Vex is a very generic library, so it's very hard to predict the way people will use it. It's true that a user couldn't click something below an overlay to launch a dialog behind another, but a developer could programmatically in an app. For example, the way the Vex homepage works is that when you click "Demo", 5 vex dialogs get launched at once. It's pretty neat.

Vex.dialog is great for alerts, confirms, and prompts, as you note. But that's a specific use case and not everyone will use generic vex.open in that way. For example, at HubSpot, we use Vex with crazy nested dialogs situations like these (notice how dark the overlays get as they stack):

That being said, we did ultimately add the functionality you suggested, so enjoy!

from vex.

Well, you could prevent the "darkening" by only having one masking element and moving it beneath the modal dialog thats currently focused. I had such a case as well (I am creating a bigger UI Library right now), and ended up moving the mask elements z-index.

I noticed that you added a backdrop/mask now when opening an alert/prompt/confirm, BUT! :)

Its a very bad idea to close the modal when the user clicks on the backdrop. While this behaviour might be okay for a dialog with a simply informing nature (as the alert box is), closing the informative dialog with an accidentially click on the background might be desasterous when the user cannot simply re-open the important message again.

The same goes for prompts and confirms where a accidentially cancel action could cause frustration.
Again: this might be a desired behaviour in some use cases (e.g. a "lightbox" that displays an image or detail text), so I would add an option for this.

Hell, I really made up my mind about popups/dialogs so far. I think we could talk all night long about this :)

from vex.

Well, you could prevent the "darkening" by only having one masking element and moving it beneath the modal dialog thats currently focused.

Unfortunately, this wouldn't work in Vex because appendLocation can be different for each Vex on the page, so managing z-indexes for the overlays and dialogs would be impossible without any knowledge of the user's markup. That being said, a similar affect could be achieved with CSS, by only applying a background color to the last Vex's overlay:

.vex-overlay
    background: rgba(0, 0, 0, .4)
    position: fixed
    top: 0
    right: 0
    bottom: 0
    left: 0

.vex:not(:last-child) .vex-overlay
    background: transparent

We definitely may consider changing this to be the default styling.

Its a very bad idea to close the modal when the user clicks on the backdrop.

The setting overlayClosesOnClick can be set to false if desired.

from vex.

Not mentioned above but escapeButtonCloses: false can disable the default ESC key functionality per instance.

from vex.