-
Notifications
You must be signed in to change notification settings - Fork 13
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
Events emitted when modal is opened and closed #16
base: main
Are you sure you want to change the base?
Conversation
Hey @ibanjo, thanks for your pull request! Just thinking, wouldn't these features potentially be better suited in user land? These events could be implemented on consumer level with the |
Interesting enough, actually. I introspected the
following your idea of managing the actual
This actually does not leverage your As a compromise, we may think about proxying the native
thus allowing the user to simply bind them to the
Shall I try this? |
this would be useful for my use case also |
this.dialog.hide() | ||
} | ||
}, | ||
|
||
watch: { | ||
'dialog.shown' (val) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is dialog.shown
coming from exactly?
Also, since this is Vue 3, we should leverage import { ref, watch } from 'vue'
idiom and stick it inside the setup
(I'd actually like to convert the props to use defineProps
as well but didn't quite know about that at the time when I helped with the Vue 3 port).
https://vuejs.org/guide/essentials/watchers.html#basic-example
Another question is how do we deal with when lower-level a11y-dialog
opens/closes based off the data attributes not instance?
|
||
methods: { | ||
open () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do/will these play with the case when the consumer asks for the dialog-ref
instance? Wouldn't this neuter or create a double callback situation? I suppose both would be handled by the consumer so I suppose they would be silly to both utilize the instance and also listen for the callback. But maybe there's a case where consumer wants to control opening/closing via the instance, but still listen for these events? Also, can the consumer not just do this themselves via the instance 🤔
Thank you for the wrapper, it made my day! I just added a couple (possibly) useful events, fired when the modal is opening/closing and after the show/hide methods have been called on the A11yDialog instance.