-
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
[App Search] Convert Engine subnav and Engine Overview pages to new page template #102679
Conversation
- To facilitate this being broken up into multiple PRs, non-migrated views still get a wrapping layout
+ tweak CSS for new label - heads up that this will break the old nav, but will disappear as the pages get converted
9dc3392
to
3f1618d
Compare
import { mockEngineValues } from '../../__mocks__'; | ||
|
||
jest.mock('../../../shared/layout', () => ({ | ||
...jest.requireActual('../../../shared/layout'), // TODO: Remove once side nav components are gone |
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.
The Layout and SideNav components will get deleted in one final PR (likely shared with WS and AS).
describe('useEngineNav', () => { | ||
const values = { ...mockEngineValues, myRole: {}, dataLoading: false }; |
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.
This mostly copies the EngineNav
test suite down below, it just converts the assertions from expecting react components to expecting EuiSideNavItem objects. (except for portions of the nav that render raw jsx)
@@ -47,6 +55,255 @@ import { EngineLogic, generateEnginePath } from './'; | |||
|
|||
import './engine_nav.scss'; | |||
|
|||
export const useEngineNav = () => { |
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.
Again this is mostly just the existing EngineNav but converted to nav objects. It's not really possible in this branch to fully QA this (e.g. the nav icons), but I can push up a test branch with all pages converted (just not split out or any tests written) if folks really want it. Or we can wait til the end in any case, since this week is the week for QA passes 🤷
@@ -85,74 +87,76 @@ export const EngineRouter: React.FC = () => { | |||
} | |||
|
|||
const isLoadingNewEngine = engineName !== engineNameFromUrl; | |||
if (isLoadingNewEngine || dataLoading) return <Loading />; | |||
if (isLoadingNewEngine || dataLoading) return <AppSearchPageTemplate isLoading />; |
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.
This is a little odd-looking at first glance, but without it we get a flash of empty page when navigating between a non-engine and engine page. We also do need to wait for this data to be done loading since all subroutes expect top-level engine data to be present before their own logic begins.
FWIW, I had to do something similar for WS's Source views (#102592 (comment)).
if (dataLoading) { | ||
return <Loading />; | ||
} | ||
if (dataLoading) return <AppSearchPageTemplate isLoading />; |
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'm not a huge fan of this particular whole-page isLoading
early return, but unfortunately with pages that have page titles jump change based on loaded data (in this case, we show either Engine overview
or Engine setup
depending on whether the engine has documents), it's better not to show the page at all initially - otherwise what happens is you get a brief flash of the Engine setup
page which then jumps to Engine overview
🤷
WS has similar issues with their overview as well. Discussion for more context: #102592 (comment)
In this case, my ideal solution for this view would be to abstract the documentsCount / isEngineEmpty check to the top level engine
logic available to all engine pages. That would allow the setup vs overview check to happen instantaneously, no data loading needed. I didn't want to add more lines into this PR though, so I left it out for now - time permitting, I'll follow up with some UX polish PRs this week.
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.
Yeah I'd like to have a larger conversation about loading and how we handle it, I think we could improve the consistency of our loading patterns across the app for section routers, individual views, and individual componnennts. I agree it was better to limit this PRs scope
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.
The new page template does actually improve consistent page-level loading patterns fairly significantly! I like that the page headers load in instantaneously, it makes navigation feel much snappier - it just backfires in scenarios where we conditionally change the entire page header/title heh (which we should consider potentially moving away from as a UX pattern).
Like you said though, there's always room to improve and think about loading individual components instead 👍
expect(getPageHeaderActions(wrapper).find(EuiButton).prop('href')).toEqual( | ||
`${docLinks.appSearchBase}/index.html` |
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.
😎 new test_helpers already paying off in spades
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.
Looks good, one non-blocking comment
flex-direction: row; | ||
} | ||
.appSearchNavIcon { | ||
order: 1; |
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.
👀 👀 👀
Seeing order
rules in CSS always raises the hairs on the back of my neck. I trust there's a good reason for this, but could you leave a small comment in the code explaining what that reason is?
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.
Nice catch on this Byron! Kibana renders its icons to the left of text instead of to the right:
But we want the icons to the right, to match our previous UI:
If it had been more annoying than a simple CSS/flex re-order to do this I might have left them alone, but I figured since there's an easy way to quickly replicate our old nav icon UI/UX I might as well do so.
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.
Also, if EUI or Davey pushes back on this / wants it removed, it's definitely easy enough to do so in the future!
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.
Oh, just saw the request was for a code comment 🤦♀️ hope this looks good!
order: 1; | |
// EuiSideNav renders icons to the left of the nav link by default, but we use icons | |
// as warning or error indicators & prefer to render them on the right side of the nav | |
order: 1; |
if (dataLoading) { | ||
return <Loading />; | ||
} | ||
if (dataLoading) return <AppSearchPageTemplate isLoading />; |
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.
Yeah I'd like to have a larger conversation about loading and how we handle it, I think we could improve the consistency of our loading patterns across the app for section routers, individual views, and individual componnennts. I agree it was better to limit this PRs scope
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
…age template (elastic#102679) * Update routers - To facilitate this being broken up into multiple PRs, non-migrated views still get a wrapping layout * Set up Engine subnav in EuiSideNav format + tweak CSS for new label - heads up that this will break the old nav, but will disappear as the pages get converted * Convert Engine Overview pages to new page template * [PR feedback] Code comment explaining side nav icon reorder Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…age template (#102679) (#102797) * Update routers - To facilitate this being broken up into multiple PRs, non-migrated views still get a wrapping layout * Set up Engine subnav in EuiSideNav format + tweak CSS for new label - heads up that this will break the old nav, but will disappear as the pages get converted * Convert Engine Overview pages to new page template * [PR feedback] Code comment explaining side nav icon reorder Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Constance <constancecchen@users.noreply.github.com>
Summary
Follow up to #102170 - converts more App Search pages to the new KibanaPageTemplate. I'm attempting to break up the AS layout conversion into smaller, easier to review chunks.
This PR handles converting the Engine sub nav to an array of EuiSideNav items, and converts the original Engine Overview page as well so there's one view where the subnav can be seen. As always, follow along by commit (and turn off whitespace diffs).
Screencaps
Checklist