-
Notifications
You must be signed in to change notification settings - Fork 8.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
Reset chrome fields while switching an app #73064
Reset chrome fields while switching an app #73064
Conversation
@elasticmachine merge upstream |
@@ -157,6 +157,11 @@ export class ChromeService { | |||
const recentlyAccessed = await this.recentlyAccessed.start({ http }); | |||
const docTitle = this.docTitle.start({ document: window.document }); | |||
|
|||
// erase the help menu extension from previous app while switching to a next app | |||
application.currentAppId$.subscribe(() => { | |||
helpExtension$.next(undefined); |
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.
- Shouldn't we reset all the Chrome fields then? Badge, Breadcrumbs, etc.
- It implicitly enforces calling order for
navigation
andsetHelpExtension
. @joshdover should we make this logic explicit? For example, we can move some Chrome params into theApplication
interface?
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.
- Shouldn't we reset all the Chrome fields then? Badge, Breadcrumbs, etc.
- It implicitly enforces calling order for
navigation
andsetHelpExtension
. @joshdover should we make this logic explicit? For example, we can move some Chrome params into theApplication
interface?
- Good point, I would also do this on switching an app.
Especially since I still see couple of places when a pagetitle
is not changed after navigating to any app, or such a PR's like Add doc titles to ES UI apps #71045 , wherechrome.docTitle.reset()
is manually called on application destroy.
So doing it once after switching to any app would close other issues. - I was also under assumption to set default chrome params explicitly in
navigateToApp
, but discovered thatchrome
service depends onapplication
one.
So, the other implementation way would cause significant code changes.
I'm excited to receive @joshdover opinion! 🙂
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.
- Yes, let's go ahead and do those for the chrome items that make sense.
- I agree this would be much better. I think it would be best to split that change into two phases where we first introduce the new API, separately migrate each usage of the existing imperative APIs, and then remove the imperative APIs. This could be done as a different issue / PR.
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.
@joshdover Should I expand this PR with other chrome items reset, or close it in favor of new API ?
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.
Should I expand this PR with other chrome items reset, or close it in favor of new API ?
We can fix it here quickly and refactor chrome service after. Another complain: #72671
but let's wait for @joshdover opinion
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.
Yes I agree, let's go ahead and do the quick fix now in this PR and refactor later.
@elasticmachine merge upstream |
…a into fix/erase_help_extension
@elasticmachine merge upstream |
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.
Can we add a test about that behavior in src/core/public/chrome/chrome_service.test.ts
?
Apart from that, LGTM
Sure! Done! |
💚 Build SucceededBuild metricsasync chunks size
page load bundle size
History
To update your PR or re-run it, just comment with: |
* Reset chrome help extension while switching an app * Reset other chrome fields * Set docTitle in saved objects app * Add unit tests Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Summary
Fixes #72896
Fixes #72671
Initial issue description:
Help menu not resetting on navigating to Kibana home for some apps
Actually, the problem is also related to switching the apps, which don't have its own chrome fields (e.x. help menu extension, badge, breadcrumbs, etc), so there is a previous one always appear. (e.x. go from
Visualize
toDev Tools
, or fromDashboard
toStack Management
).So I put the subscription on
application.currentAppId$
to erase the previous chrome fieldsChecklist
Delete any items that are not applicable to this PR.
For maintainers