Skip to content
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

Add ILM url generator and use it in Index Management #82165

Merged
merged 10 commits into from
Nov 6, 2020

Conversation

yuliacech
Copy link
Contributor

@yuliacech yuliacech commented Oct 30, 2020

Summary

Fixes #79843.
This PR cleans up ILM to only use 1 service for navigation instead of hard coding paths, registers an url generator in ILM plugin setup and uses it in Index Management to link to edit page of an ILM policy.

Release Note

In the Index Management app, you can now click a data stream's index lifecycle policy to view it in the Index Lifecycle Policies app.

@yuliacech yuliacech marked this pull request as ready for review November 2, 2020 15:17
@yuliacech yuliacech requested a review from a team as a code owner November 2, 2020 15:17
@yuliacech yuliacech added Feature:ILM Feature:Index Management Index and index templates UI Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.11.0 v8.0.0 labels Nov 2, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/es-ui (Team:Elasticsearch UI)

@yuliacech
Copy link
Contributor Author

@elasticmachine merge upstream

@cjcenizal
Copy link
Contributor

@yuliacech Would you mind phrasing the release note from the user's/reader's point of view? For example, "In the Index Management app, you can now click a data stream's index lifecycle policy to view it in the Index Lifecycle Policies app."

@yuliacech
Copy link
Contributor Author

Sure @cjcenizal , I'll add your wording to Release notes, thanks a lot for this suggestion!

@yuliacech yuliacech requested a review from jloleysens November 4, 2020 11:27
@yuliacech
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

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

Great work @yuliacech !

I tested locally and the code worked as intended.

I'd like to block this PR on 2 comments

  • My comment about simplifying types in url_generator
  • My comment about refactoring useUrlGenerator

The rest are all non-blocking!

Another general question I have is, do we also want to deep link from index template details to ILM since we can attach an ILM policy to those?

return encodeURI(`/policies/edit/${encodeURIComponent(policyName)}`);
};

export const getPolicyCreatePath = () => {
return `/policies/edit`;
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think of replacing this with ROUTES.edit. Otherwise I think we can remove the use of string literals to conform to other string usages.

@@ -4,6 +4,20 @@
* you may not use this file except in compliance with the Elastic License.
*/

export const getPolicyPath = (policyName: string): string => {
export const ROUTES = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Calling this const REACT_ROUTER_ROUTES could make this even clearer. Since the strings are coupled to how react router works.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd prefer keeping ROUTES variable name here for shortness sake and it seemed to me as a good convention to use for a react-router config paths.

Comment on lines 20 to 45
export enum ILM_PAGES {
LIST = 'policies_list',
EDIT = 'policy_edit',
CREATE = 'policy_create',
}

export interface IlmPoliciesListUrlGeneratorState {
page: ILM_PAGES.LIST;
absolute?: boolean;
}

export interface IlmPolicyEditUrlGeneratorState {
page: ILM_PAGES.EDIT;
policyName: string;
absolute?: boolean;
}

export interface IlmPolicyCreateUrlGeneratorState {
page: ILM_PAGES.CREATE;
absolute?: boolean;
}

export type IlmUrlGeneratorState =
| IlmPoliciesListUrlGeneratorState
| IlmPolicyEditUrlGeneratorState
| IlmPolicyCreateUrlGeneratorState;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can compress these types in the following way:

export interface IlmUrlGeneratorState {
  page: 'policies_list' | 'policy_edit' | 'policy_create';
  policyName?: string;
  absolute?: boolean;
}

// then the switch statement further down becomes - with auto complete for string literals

switch (state.page) {
  case 'policy_create': {
    return `${await getAppBasePath(!!state.absolute)}${getPolicyCreatePath()}`;
  }
  case 'policy_edit': {
    return `${await getAppBasePath(!!state.absolute)}${getPolicyEditPath(
      state.policyName!
    )}`;
  }
  case 'policies_list': {
    return `${await getAppBasePath(!!state.absolute)}${getPoliciesListPath()}`;
  }
}

I think this makes the code a bit easier to understand - just because there is less of it :). What do you think?

| IlmPolicyEditUrlGeneratorState
| IlmPolicyCreateUrlGeneratorState;

export class IlmUrlGenerator implements UrlGeneratorsDefinition<typeof ILM_URL_GENERATOR_ID> {
Copy link
Contributor

Choose a reason for hiding this comment

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

I probably would have used a factory pattern here to capture getAppBasePath.

const createIlmUrlGenerator = (getApppBasePath: getAppBasePath: (absolute?: boolean) => Promise<string>): UrlGeneratorsDefinition<typeof ILM_URL_GENERATOR_ID> => {
   return { id: ILM_URL_GENERATOR_ID, /* etc */ }
}

I think it would result in slightly less code. But I believe this is mostly stylistic preference!

@@ -287,4 +290,82 @@ describe('Data Streams tab', () => {
});
});
});

describe('url generators', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Great job on these test cases!!

const {
core: { getUrlForApp },
} = useAppContext();
const [ilmPolicyLink, setIlmPolicyLink] = useState<string | undefined>();
Copy link
Contributor

Choose a reason for hiding this comment

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

We should move this piece of state into useUrlGenerator and have it return { url?: string }. Then we can also remove setLinkCallback.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't think about using setState inside useEffect, great idea @jloleysens !

@yuliacech
Copy link
Contributor Author

Thank you for the review, @jloleysens ! Great suggestions, I made url generator types easier in ILM and added state into useGenerator effect. Would you please have another look please?

@yuliacech
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

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

Great work @yuliacech ! Thanks for addressing my feedback, did not test this again locally but the code is looking in great shape 🍻

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

@kbn/optimizer bundle module count

id before after diff
indexLifecycleManagement 111 112 +1
indexManagement 508 511 +3
total +4

async chunks size

id before after diff
indexLifecycleManagement 224.4KB 224.4KB +18.0B
indexManagement 1.5MB 1.5MB +4.3KB
total +4.3KB

page load bundle size

id before after diff
indexLifecycleManagement 71.8KB 77.0KB +5.2KB
indexManagement 113.6KB 113.8KB +273.0B
total +5.5KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@yuliacech yuliacech merged commit 71ec5bd into elastic:master Nov 6, 2020
yuliacech added a commit to yuliacech/kibana that referenced this pull request Nov 6, 2020
* Add ILM url generator and use in IM for cross linking to policy edit page

* Fix policy name in the link

* Add review suggestions

* Fix import

* Fix eslint error

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
yuliacech added a commit that referenced this pull request Nov 6, 2020
* Add ILM url generator and use in IM for cross linking to policy edit page

* Fix policy name in the link

* Add review suggestions

* Fix import

* Fix eslint error

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
@yuliacech yuliacech deleted the ilm_url_generator branch December 3, 2020 10:52
@sebelga
Copy link
Contributor

sebelga commented Jan 5, 2021

Testing this PR as part of the BC QA testing. I wonder if it is expected to have a full page refresh when navigating from the data stream details panel to the ILM app?

If I click the ILM app link in the left menu I don't have this page refresh. WDYT @yuliacech ?

@yuliacech
Copy link
Contributor Author

Hi Seb @sebelga , thanks a lot for testing this PR! I created an issue #87876 to add an SPA friendly navigation to this link.

@sebelga
Copy link
Contributor

sebelga commented Jan 14, 2021

Thanks @yuliacech !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:ILM Feature:Index Management Index and index templates UI release_note:enhancement Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.11.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Index Management] Deep link from data streams to ILM
6 participants