[Chrome] Prep for new side navigation

[Dosant]

Summary

Most of it is extracted from #228162 plus some changes to support old layout

---

This refactor establishes a foundation for new side navigation integration while maintaining backward compatibility through the v1/v2 component structure and feature flagging system.

chrome_service.tsx

Navigation Rendering Strategy

• Centralized Control: Lifted ProjectNavigation rendering from ProjectHeader to chrome_service for easier v1/v2 swapping.
• Layout-Aware Navigation: Conditional rendering to swap between v1 and v2 sidenav components based on layout type (fixed vs grid).

Simplified Header Semantics

• Removed unnecessary as prop on header component (now uses semantic <header>).
• Updated layout to use <div> to prevent duplicate header elements.

Streamlined API Naming

• isSideNavCollapsed$ → isCollapsed$
• toggleSideNav → sidenav
• Reduced verbosity for cleaner navigation component integration.

New Side Navigation Components Entry Points

• SideNavV2CollapseButton: Custom collapse button based on EuiCollapsibleNavBeta, tailored for new sidenav interaction patterns.
• fixed_layout_sidenav.tsx: Entry point for new sidenav with legacy fixed layout system.
• grid_layout_sidenav.tsx: Entry point for new sidenav with modern grid layout system.
• Navigation Migration: Moved existing navigation to sidenav_v1/navigation.tsx for backward compatibility.

core-chrome-layout

Component Cleanup

• Removed navigationPanel: No longer needed in new architecture.
• Updated nav components to use <div> instead of semantic <nav> for layout flexibility.

Layout Improvements

• Header Semantics Fix: Changed header to <div> as chrome layer now handles semantics.
• Breadcrumbs Enhancement: Added max-width to header for proper breadcrumb truncation.
• Dynamic Layout Updates: Added useLayoutUpdate for responsive layout changes when nav is toggled.
• Updated Styles: Styling adjusted for dynamic nav widths.

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[tsullivan]

Note: moved the Router rendering up from https://github.com/elastic/kibana/pull/229110/files#diff-333fe32fe36772f661ce2091cb24ec608f14efda629e44abd1ada1ae8d8ddb0aL261

[tsullivan]

Nit:

Suggested change

	* @deprecated - clean up https://github.com/elastic/kibana/issues/225264
	* @deprecated - do not extend this, needs cleanup https://github.com/elastic/kibana/issues/225264

[tsullivan]

Approving to unblock.

The relocations make sense from a code organization perspective.

The new semantics make sense as well.

The TODOs and commented code is acceptable, as this PR is part of a set of isolated PRs that are closely follow each other.

[weronikaolejniczak]

non-blocking, just thinking out-loud:

Like we talked, setWidth feels awkward and like it doesn't belong here. The reason we are using it is because the side nav changes its width: expanded, collapsed, side panel open, side panel closed. The new grid layout needs to know in advance the static value for the side navigation width (and all other cells as well). There are 2 variables here: isCollapsed and isSidePanelOpen.

I thought about this and I believe passing through a memoized setter is probably the simplest solution.

What we could do is create a hook that does this width calculation, expose it through @kbn/core-chrome-navigation, and then feed isCollapsed and isSidePanelOpen from the parent into the navigation component but this would result in even more props passed through and consequently potential wasted re-renders on opening the side panel. We could also feed this data through context inside the navigation component but that would couple it with the usage.

Personally, I'd proceed with setWidth prop.

[Dosant]

setWidth seem to be working fine for now for both grid and fixed, so I agree to proceed like this and then review if needed 👍

Only, i'd maybe rename this prop to onWidthChange or onResize or something like that?

[weronikaolejniczak]

It would imply that there's some change happening in the navigation component that the parent might want to listen into. But the fact is, we're passing a setter and we're using it in the navigation component for the parent's sake, right?

At the same time, onWidthChange sounds more natural. I don't have anything against using that.

But onResize might not be a good idea considering we want the side panel to be resizable in the future.

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 4646a85
• Storybooks Preview

Failed CI Steps

• Jest Tests #7
• Jest Tests #17
• Jest Tests #19
• Investigations - Security Solution Cypress Tests #1
• Investigations - Security Solution Cypress Tests #1
• Investigations - Security Solution Cypress Tests #4

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
core	444	445	+1

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/core-chrome-layout	3	5	+2

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
@kbn/core	891	892	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	476.0KB	478.1KB	+2.1KB

Unknown metric groups

API count

id	before	after	diff
@kbn/core-chrome-layout	3	5	+2
@kbn/core-chrome-layout-components	13	14	+1
total			+3

ESLint disabled line counts

id	before	after	diff
@kbn/core-chrome-browser-internal	3	5	+2

Total ESLint disabled count

id	before	after	diff
@kbn/core-chrome-browser-internal	3	5	+2

History

• 💔 Build #323226 failed 8249966
• 💔 Build #323221 failed 5de53bb
• 💚 Build #322381 succeeded e38d3c7