-
Notifications
You must be signed in to change notification settings - Fork 8.5k
Refactoring nav links and header components #66685
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
Conversation
|
@pgayvallet @joshdover Hoping one/both of y'all can take a look at this while I start working on these tests. Hopefully this refactor is going in the right direction. Don't really plan on touching much more other than test files. Full description of changes in the description. |
pgayvallet
left a comment
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.
A few NITs and question, overall looking good. Thanks for the migration to FC!
| ...(isLegacyApp(app) | ||
| ? {} | ||
| ? { | ||
| href: url && !url.startsWith(app.subUrlBase!) ? url : baseUrl, | ||
| } | ||
| : { | ||
| url: relativeToAbsolute(appendAppPath(baseUrl, app.defaultPath)), | ||
| href: url, | ||
| url, | ||
| }), |
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.
Moving the url logic to this function instead of the component makes sense, but I'm not sure to understand why href was introduced instead of just using the existing url and baseUrl here?
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.
Mostly to align with EUI prop names otherwise it's one more prop I have to alias at the component level.
Also has a couple side benefits:
- Makes sure that nothing breaks if something else was low key relying on
urlbeing a certain thing at a certain time so makes the refactor a little safer (can refactor one thing at a time) - Also makes clear what this will be used for (URLs can be constructed in a lot of different ways so knowing exactly what you're getting can be a bit of a toss up. With
hrefyou know exactly what the ultimate purpose of the prop is.)
| basePath: HttpStart['basePath']; | ||
| isLocked$: Rx.Observable<boolean>; | ||
| navType$: Rx.Observable<NavType>; | ||
| loadingCount$: ReturnType<HttpStart['getLoadingCount$']>; |
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.
NIT: would just use Observable<number> here.
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.
Why's that? I thought it would be nice to have a single source of truth on the type.
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.
IDK, either way, TS compilation would fail if HttpStart['getLoadingCount$'] type changes (just not in the same file), and I find it way more readable. But it's a personal option, you can keep it like that.
(The same way I would replace HttpStart['basePath'] by it's IBasePath actual type)
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'll keep it like this for now then. If other people have opinions on this, would be nice to come to a consensus on what we should prefer in the Kibana repo.
|
Pinging @elastic/kibana-platform (Team:Platform) |
|
retest |
|
Ack: will review tomorrow |
pgayvallet
left a comment
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.
Some nits and comments, overall LGTM
| dataTestSubj: 'collapsibleNavAppLink', | ||
| navigateToApp, | ||
| onClick: closeNav, | ||
| ...(needsIcon && { basePath }), |
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.
Probably minor, but I find it a little misleading that the addition of the icon in createEuiListItem is only based on the presence or not of the basePath input.
| listItems={recentlyAccessed.map(link => { | ||
| // TODO #64541 | ||
| // Can remove icon from recent links completely | ||
| const { iconType, ...hydratedLink } = createRecentNavLink(link, navLinks, basePath); |
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.
NIT: adding a omitIcon = false param to createRecentNavLink seems a little better than spread exclusion?
| export function HeaderLogo({ href, navigateToApp, ...observables }: Props) { | ||
| const forceNavigation = useObservable(observables.forceNavigation$, false); | ||
| const navLinks = useObservable(observables.navLinks$, []); |
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.
NIT: not sure to see a real upside in using a rest parameter here, but I'm fine either way
snide
left a comment
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.
Ran through the sass changes, which were minimal. File move looks good.
lukeelmers
left a comment
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.
App arch change LGTM -- seems this just reordered some props that were included in our generated markdown documentation.
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
Co-authored-by: spalger <[email protected]> # Conflicts: # docs/development/plugins/data/public/kibana-plugin-plugins-data-public.querystringinput.md # docs/development/plugins/data/public/kibana-plugin-plugins-data-public.searchbar.md # src/core/public/chrome/chrome_service.tsx # src/core/public/chrome/ui/header/__snapshots__/collapsible_nav.test.tsx.snap # src/core/public/chrome/ui/header/collapsible_nav.test.tsx # src/core/public/chrome/ui/header/collapsible_nav.tsx # src/core/public/chrome/ui/header/header.tsx # src/core/public/chrome/ui/header/header_logo.tsx # src/core/public/chrome/ui/header/nav_drawer.tsx # src/plugins/data/public/public.api.md
Co-authored-by: spalger <[email protected]>
|
Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync. |
Co-authored-by: spalger <[email protected]> Co-authored-by: Josh Dover <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Summary
hrefprop toChromeNavLinkhrefinto to_nav_link.ts which consolidated how many times we had time figure it out at a few different leaf nodesNavLinkand could rely on theChromeNavLinkbeing passed aroundrelativeToAbsolute()because imports are a thing and we don't need two of themNavLinkandRecentNavLink(Add unit tests for new nav #65369)Closes #65369
Checklist
For maintainers