-
Notifications
You must be signed in to change notification settings - Fork 4.1k
chore(Portal): Listen for Escape keypress using addEventListener instead of event-stack #4504
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
base: master
Are you sure you want to change the base?
Conversation
…ead of event-stack
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Btw there is some behaviour change in the "Multiple Modals" example. Prod: when I click "Open first Modal", then "Proceed", then hit This PR: Still both modals close with 1 Escape hit, however second opening of second modal works. I believe that the production behaviour is a bug tho. |
Test error is |
Yeah, that's something that is ugly about |
@layershifter I've been exploring behaviour of the fluentui Popover and I've noticed that the nested popover closes on Escape only when something inside the Popover has focus because there is the contains condition Is that intentional? At first I thought that the escape closing one by one somehow starts working with the virtual parents but as I see it now, these are 2 different things. If it is intentional and I am right that escape has nothing to do with Virtual Parents (there is nothing about escape in the VP PR) implementation of VP and escape handling should be 2 separate PRs IMO. |
It is only one removed EventStack instance from Portal. I wanna go step by step with it just to know that I am not going some wrong direction.
There are few decisions I would like to explain:
PortalInner
. It seems to me like the right place as PortalInner is only mounted when Portal is open (-> listeners only added when portal is open as well as with EventStack component).onClose
andcloseOnEscape
required inPortalInner
because it seems to me that PortalInner is and should only be used inside the Portal itself. Therefor there should not be option for SUIR developer to forget prop drill it.Overall, I looked into it a bit and I think that most of the listeners should be in the
PortalInner
as it has access to the ref which will be needed for other handlers. I should even makePortal
itself a bit lightweight when closed.I hope that it makes sense and does not disrespect some SUIR architecture.