-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Simplify dialog navigation to fix back button #23220
Conversation
Still have some work to do on alerts. The back button should work on them as well I guess |
Alright, I think it's in a pretty good state now. Ideally the |
if ("dialog" in ev.state) { | ||
// coming to a dialog | ||
// in practice the dialog stack is empty when navigating forward, so this is a no-op | ||
showDialogFromHistory(ev.state.dialog); |
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.
It is not really a no-op, as it will trigger a history.back
(causing the forward button to be enabled again) that will then trigger a closeLastDialog
which will no-op
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.
Yeah, I meant to say nothing will happen from a user perspective but no-op was shorter :D
* Simplify dialog navigation to fix back btn * add back comment * manage dialog stack in the manager instead of history * handle dialogs that refuse to close
Proposed change
Removed
replaceDialog
and all related logic as it is not used anywhere. @bramkragten correct me if this is wrong but I couldn't find anything using it.This allowed me to simplify the history management logic for dialogs and fix back button issues.
Multiple modals on top of each other work well now.
Esc
closes all dialogs but this is managed by the dialogs themselves via theescapeKeyAction
attribute. An example of this is a siren with advanced options in themore-info
dialog.Browser history was too limiting to do what we wanted. Only access to current state, no callbacks in the state, etc. So the dialog states are now managed in a stack inside
make-dialog-manager.ts
and only a single state is pushed to the browser history.Going forward in history will not open a dialog anymore as it made no sense in most cases.
Type of change
Example configuration
Additional information
Checklist
If user exposed functionality or configuration variables are added/changed: