-
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
Add ILM url generator and use it in Index Management #82165
Conversation
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
@elasticmachine merge upstream |
@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." |
Sure @cjcenizal , I'll add your wording to Release notes, thanks a lot for this suggestion! |
@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.
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`; |
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.
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 = { |
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.
Calling this const REACT_ROUTER_ROUTES
could make this even clearer. Since the strings are coupled to how react router works.
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.
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.
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; |
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.
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> { |
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.
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', () => { |
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.
Great job on these test cases!!
const { | ||
core: { getUrlForApp }, | ||
} = useAppContext(); | ||
const [ilmPolicyLink, setIlmPolicyLink] = useState<string | 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.
We should move this piece of state into useUrlGenerator
and have it return { url?: string }
. Then we can also remove setLinkCallback
.
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.
I didn't think about using setState
inside useEffect
, great idea @jloleysens !
Thank you for the review, @jloleysens ! Great suggestions, I made url generator types easier in ILM and added state into |
@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.
Great work @yuliacech ! Thanks for addressing my feedback, did not test this again locally but the code is looking in great shape 🍻
💚 Build SucceededMetrics [docs]@kbn/optimizer bundle module count
async chunks size
page load bundle size
History
To update your PR or re-run it, just comment with: |
* 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>
* 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>
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 ? |
Thanks @yuliacech ! |
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.