Skip to content

Migrate ui/doc_title to New platform#48121

Merged
pgayvallet merged 18 commits intoelastic:masterfrom
pgayvallet:kbn-46077-np-doc-title
Oct 24, 2019
Merged

Migrate ui/doc_title to New platform#48121
pgayvallet merged 18 commits intoelastic:masterfrom
pgayvallet:kbn-46077-np-doc-title

Conversation

@pgayvallet
Copy link
Copy Markdown
Contributor

@pgayvallet pgayvallet commented Oct 14, 2019

Summary

Migrate ui/doc_title to new platform:

  • Add a DocTitle sub-service to ChromeService
  • Bridge the legacy ui/doc_title to use the NP service

Fixes #46077

Checklist

Use strikethroughs to 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

For 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 appropriately

Dev Docs

Migrate chrome.docTitle to new platform. Plugins can now change the page title using this API.

coreStart.docTitle.change('My Title');

@pgayvallet pgayvallet added Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// Feature:New Platform v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.5.0 labels Oct 14, 2019
@elasticmachine
Copy link
Copy Markdown
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

Comment on lines 88 to 91
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good way to bridge the old tests.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with removing this test completely.

Copy link
Copy Markdown
Contributor Author

@pgayvallet pgayvallet Oct 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

docTitle.change(
i18n.translate('xpack.monitoring.stackMonitoringDocTitle', {
defaultMessage: 'Stack Monitoring {clusterName} {suffix}',
values: { clusterName, suffix }
}), true);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 = .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ingest team is happy for us to drop the true flag in this PR so that monitoring also uses the baseTitle.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rudolf ok great. then I guess I will change the type to export type ChromeDocTitleChange = string | string[]

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But yes, the dual logic between displaying the title and the join(' - ') is quite annoying :)

Comment on lines 33 to 34
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I'm referring to in previous comment.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

render seems to be an unused export, so removing it was avoiding another method bridging.

@elasticmachine
Copy link
Copy Markdown
Contributor

💔 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>
@pgayvallet pgayvallet force-pushed the kbn-46077-np-doc-title branch from 122b7d5 to 08f20ad Compare October 14, 2019 18:48
@elasticmachine
Copy link
Copy Markdown
Contributor

💚 Build Succeeded

@pgayvallet pgayvallet marked this pull request as ready for review October 15, 2019 05:35
@pgayvallet pgayvallet requested a review from a team as a code owner October 15, 2019 05:35
@pgayvallet pgayvallet self-assigned this Oct 15, 2019
@pgayvallet pgayvallet added release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. v7.6.0 and removed release_note:skip Skip the PR/issue when compiling release notes v7.5.0 labels Oct 15, 2019
Copy link
Copy Markdown
Contributor

@joshdover joshdover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you go ahead and a entry in the migration guide table as part of this PR?

Comment on lines +65 to +68
* @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;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, thats pretty good to know.

export class DocTitleService {
private document = { title: '' };
private baseTitle = '';
private current = defaultTitle;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why use an additional property instead of this.title$.value? Seems like unnecessary state to track.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed it is, thanks

this.title$.next(this.baseTitle);

return {
get$: () => this.title$.pipe(takeUntil(this.stop$)),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What actually uses this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@rudolf rudolf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

docTitle.change(
i18n.translate('xpack.monitoring.stackMonitoringDocTitle', {
defaultMessage: 'Stack Monitoring {clusterName} {suffix}',
values: { clusterName, suffix }
}), true);

Comment on lines 88 to 91
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
@pgayvallet
Copy link
Copy Markdown
Contributor Author

I've made the changes.

  • __legacy.setBaseTitle has been kept, as without it I had to basically remove every old karma tests
  • I removed the apply option and logic. It was only used for the angular router events, and was not, in fact, required. Now, we only call reset during the route change start event, and the behaviour appears to be exactly the same (and CI seems to confirm this)
  • removed the $get and currentTitle as they were unused.
  • removed the excludeBase option
  • doc updated and entry in migration guide added.

This greatly simplify the code and test

@rudolf and @joshdover PTAL

@elasticmachine
Copy link
Copy Markdown
Contributor

💚 Build Succeeded

@joshdover
Copy link
Copy Markdown
Contributor

ack: Will re-review today

* @public
*/
export type ChromeDocTitleChange = string | string[] | ChromeDocTitleEntry;
export type ChromeDocTitleChange = string | string[];
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@pgayvallet pgayvallet Oct 24, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@elasticmachine
Copy link
Copy Markdown
Contributor

💚 Build Succeeded

@pgayvallet pgayvallet merged commit ccd01a3 into elastic:master Oct 24, 2019
pgayvallet added a commit to pgayvallet/kibana that referenced this pull request Oct 24, 2019
* 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>
pgayvallet added a commit to pgayvallet/kibana that referenced this pull request Oct 24, 2019
* 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>
pgayvallet added a commit that referenced this pull request Oct 25, 2019
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Feature:New Platform release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// v7.6.0 v8.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Migrate ui/doc_title to New Platform

4 participants