Migrate ui/doc_title to New platform#48121
Conversation
|
Pinging @elastic/kibana-platform (Team:Platform) |
There was a problem hiding this comment.
We don't have any other services with that kind of legacy API, however this was needed to keep the old docTitle karma test working, as they were using 'private' APIs to manually change to baseTitle of the old module. Please tell me if these is a better approach
There was a problem hiding this comment.
What I've been doing with the legacy tests is just making them dumb unit tests that ensure the NP API was called by using a mock. That way we don't have to do things like this, which should save us time when we start removing the legacy code.
There was a problem hiding this comment.
I think this is a good way to bridge the old tests.
There was a problem hiding this comment.
@joshdover issue I had here is with the tests in src/legacy/ui/public/doc_title/__tests__/doc_title.js that were basically injected in the old docTitle module a different base name. Could find another way than than to keep the test. Do you see another approach ? Or maybe should I just remove the legacy test as we now got that covered in the NP module tests instead ?
There was a problem hiding this comment.
I'm fine with removing this test completely.
There was a problem hiding this comment.
This is only a nice to have, but it felt like this could ease the developer way to call the API. If we prefer something more rigid, we can stick to ChromeDocTitleEntry instead
There was a problem hiding this comment.
There's currently only one plugin that uses excludeBase=true, although we want to keep BWC in most cases in my opinion we should remove this flag and make it consistent across Kibana. I've asked the ingest team for feedback if they rely on this behaviour.
kibana/x-pack/legacy/plugins/monitoring/public/services/title.js
Lines 18 to 22 in 7ac8e4d
There was a problem hiding this comment.
Now that I think more about this... this service does just two things, if you give it parts it joins them with - and it adds the baseTitle. It's so small it's almost annoying :-P but the value it provides is consistency for all of Kibana. If a plugin really needs to break this consistency it feels like they might as well just use document.title = .
There was a problem hiding this comment.
The ingest team is happy for us to drop the true flag in this PR so that monitoring also uses the baseTitle.
There was a problem hiding this comment.
@rudolf ok great. then I guess I will change the type to export type ChromeDocTitleChange = string | string[]
There was a problem hiding this comment.
But yes, the dual logic between displaying the title and the join(' - ') is quite annoying :)
There was a problem hiding this comment.
This is what I'm referring to in previous comment.
There was a problem hiding this comment.
render seems to be an unused export, so removing it was avoiding another method bridging.
💔 Build Failed
|
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
…odule in tests with no usages Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
122b7d5 to
08f20ad
Compare
💚 Build Succeeded |
joshdover
left a comment
There was a problem hiding this comment.
Can you go ahead and a entry in the migration guide table as part of this PR?
| * @param newTitle The new title to set, either a string, string array or {@link ChromeDocTitleEntry} | ||
| * @param [apply=true] If false, will not actually apply the new title until #apply() is called. | ||
| */ | ||
| change: (newTitle: ChromeDocTitleChange, apply?: boolean) => void; |
There was a problem hiding this comment.
So one annoying thing about our doc tooling is it will only generate documentation for @param tags if the function is defined as a method rather than a function property:
change(newTitle: ChromeDocTitleChange, apply?: boolean): void;
May want to do that here so that the @link is actually in the docs. Same for the other methods below.
There was a problem hiding this comment.
Well, thats pretty good to know.
| export class DocTitleService { | ||
| private document = { title: '' }; | ||
| private baseTitle = ''; | ||
| private current = defaultTitle; |
There was a problem hiding this comment.
Why use an additional property instead of this.title$.value? Seems like unnecessary state to track.
There was a problem hiding this comment.
indeed it is, thanks
| this.title$.next(this.baseTitle); | ||
|
|
||
| return { | ||
| get$: () => this.title$.pipe(takeUntil(this.stop$)), |
There was a problem hiding this comment.
What actually uses this?
There was a problem hiding this comment.
No one atm. Just thought it might be useful to expose it so its already present if a plugin may want to use it in the futur. Do you think it's better to just remove it ?
There was a problem hiding this comment.
Yeah let's just remove it. There's some APIs similar to this in the ChromeService that I think we can also remove soon too. I think the smaller the surface the better so that when we declare the API stable we don't have to maintain anything unnecessary.
rudolf
left a comment
There was a problem hiding this comment.
Every small reduction / simplification in the API is a win, so I hope we can remove some of the options if they are indeed unnecessary.
There was a problem hiding this comment.
There's currently only one plugin that uses excludeBase=true, although we want to keep BWC in most cases in my opinion we should remove this flag and make it consistent across Kibana. I've asked the ingest team for feedback if they rely on this behaviour.
kibana/x-pack/legacy/plugins/monitoring/public/services/title.js
Lines 18 to 22 in 7ac8e4d
There was a problem hiding this comment.
I think this is a good way to bridge the old tests.
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
|
I've made the changes.
This greatly simplify the code and test @rudolf and @joshdover PTAL |
💚 Build Succeeded |
|
ack: Will re-review today |
| * @public | ||
| */ | ||
| export type ChromeDocTitleChange = string | string[] | ChromeDocTitleEntry; | ||
| export type ChromeDocTitleChange = string | string[]; |
There was a problem hiding this comment.
optional: Is there any advantage to having a named type? It feels like it might be simpler if to inline if we're only using primitive types, but happy for you to merge this either way.
There was a problem hiding this comment.
I had the same question. I'm quite used to always use named types from were I worked before, but for that kind of scenario, I cant really think of any real advantage (except maybe refactoring if one day we modify/extend the type), and I agree that I doesn't really makes documentation more clear. If we think this is better I definitely can fall back to inline types
Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
💚 Build Succeeded |
* create NP docTitle service and bridge LP to it Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * properly prefix the docTitle public types Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update documentation Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * replace direct NP access with closure to avoid error when importing module in tests with no usages Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove arrow functions for doc generation Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove get$ from the api Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove apply param and excludeBase option Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove removed export Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * adapt legacy service to new api Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * add entry about docTitle in the migration guide Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * add link in migration guide Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update generated doc Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update chrome mock Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update snapshots due to api change Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove ChromeDocTitleChange in favor of inline type Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
* create NP docTitle service and bridge LP to it Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * properly prefix the docTitle public types Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update documentation Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * replace direct NP access with closure to avoid error when importing module in tests with no usages Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove arrow functions for doc generation Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove get$ from the api Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove apply param and excludeBase option Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove removed export Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * adapt legacy service to new api Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * add entry about docTitle in the migration guide Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * add link in migration guide Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update generated doc Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update chrome mock Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update snapshots due to api change Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove ChromeDocTitleChange in favor of inline type Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
* create NP docTitle service and bridge LP to it Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * properly prefix the docTitle public types Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update documentation Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * replace direct NP access with closure to avoid error when importing module in tests with no usages Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove arrow functions for doc generation Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove get$ from the api Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove apply param and excludeBase option Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove removed export Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * adapt legacy service to new api Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * add entry about docTitle in the migration guide Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * add link in migration guide Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update generated doc Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update chrome mock Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * update snapshots due to api change Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co> * remove ChromeDocTitleChange in favor of inline type Signed-off-by: pgayvallet <pierre.gayvallet@elastic.co>
Summary
Migrate ui/doc_title to new platform:
ui/doc_titleto use the NP serviceFixes #46077
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.- [ ] This was checked for cross-browser compatibility, including a check against IE11- [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support- [ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers
- [ ] This was checked for breaking API changes and was labeled appropriately- [ ] This includes a feature addition or change that requires a release note and was labeled appropriatelyDev Docs
Migrate
chrome.docTitleto new platform. Plugins can now change the page title using this API.