Skip to content

Parent component now sets the keys used to close the modal #757

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: next
Choose a base branch
from

Conversation

gtiersma
Copy link

@gtiersma gtiersma commented Mar 3, 2022

The parent component provides the keysToClose prop with an array of strings specifying which keys should be able to close the modal (Example: ["Escape", "Enter", " "])

I found an edge-case where if the dialog is opened by the parent component by a certain key and the modal is configured to close with that same key, it will immediately close after opening. For example, the parent decides to open the modal when the enter key is pressed down. If the modal is configured to close with the enter key, it will immediately close once that same key that was used to open it is released.
To fix this, I added a boolean to track if a key that is used to close the modal has been pressed down. This boolean is then checked before closing the modal from a key press. This makes it so the modal will not close unless the key configured to close it is pressed down and then released.

One controversial change worth mentioning is backwards compatibility. Any previous usages of this modal that had clickToClose set to false will now close when the Esc key is pressed (unless the parent is changed to pass an empty array to the keysToClose prop).
My justification for this change is to allow for the capability for the dialog to not be closable by clicking, yet still be closable by the keys specified in the parent.
If we wish to have this commit perfectly backwards compatible, adding back the "if clickToClose" statement surrounding the add/remove listener lines will do the trick, but it won't be possible to have the dialog not closable by clicking, yet closable by pressing a key.

One last point to mention is that if we wish for Dialog.vue to also allow the parent to set the keys to close it, it will need a simple change to take the keysToClose prop in-and-out.

The parent component provides the keysToClose prop with an array of strings specifying which keys should be able to close the modal (Example: ["Escape", "Enter", " "])

I found an edge-case where if the dialog is opened by the parent component by a certain key and the modal is configured to close with that same key, it will immediately close after opening. For example, the parent decides to open the modal when the enter key is pressed down. If the modal is configured to close with the enter key, it will immediately close once that same key that was used to open it is released.
To fix this, I added a boolean to track if a key that is used to close the modal has been pressed down. This boolean is then checked before closing the modal from a key press. This makes it so the modal will not close unless the key configured to close it is pressed down and then released.

One controversial change worth mentioning is backwards compatibility. Any previous usages of this modal that had clickToClose set to false will now close when the Esc key is pressed (unless the parent is changed to pass an empty array to the keysToClose prop).
My justification for this change is to allow for the capability for the dialog to not be closable by clicking, yet still be closable by the keys specified in the parent.
If we wish to have this commit perfectly backwards compatible, adding back the "if clickToClose" statement surrounding the add/remove listener lines will do the trick, but it won't be possible to have the dialog not closable by clicking, yet closable by pressing a key.

One last point to mention is that if we wish for Dialog.vue to also allow the parent to set the keys to close it, it will need a simple change to take the keysToClose prop in-and-out.
@sonarqubecloud
Copy link

sonarqubecloud bot commented Mar 3, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant