Admin UI: Decouple Page component from `@wordpress/route`

[aduth]

What problem does this address?

Currently, @wordpress/admin-ui has a hard dependency on @wordpress/route to handle routing behaviors (e.g. in breadcrumbs links). This makes it difficult or impossible to use its components in projects which may have their own routing implementations.

This also creates conflicts between dependency versions. @wordpress/route depends on Tanstack Router, which in turn imposes its own set of requirements. This causes challenges in e.g. handling React version dependencies (see real-world example). There's also a question of whether multiple bundled versions of these packages can co-exist, since routing relies heavily on React context, but multiple versions (copies) of the same dependency cannot share React context.

What is your proposed solution?

Remove @wordpress/admin-ui's dependency on @wordpress/route, while providing an easy way for applications to specify the link rendering behavior of components like breadcrumbs.

What this might look like in practice:

• The Page component receives configurable breadcrumbs prop, including label and to props, like what was proposed in Admin UI: Page header design spec #76709 (comment)
  • <Page breadcrumbs={ [ { label: 'Parent', to: '/' }, { label: 'Current' } ] } />
• A consumer can provide their own link rendering behavior. The default behavior uses plain anchor tags <a />
  • Example: <Page components={ { link: Link } } /> (or context provider if needed)
  • WordPress itself (@wordpress/boot) would provide this with the implementation of Link from @wordpress/route
• This builds on UI: Add Breadcrumb component (adapted from admin-ui) #77039, where the existing Breadcrumb component would be replaced by a combination of a lower-level @wordpress/ui primitive + admin-ui "wiring it up"

This retains the high-level usefulness of the page component in handling generalized routing, while not being overly prescriptive/restrictive of the actual implementation.

[MrSuddenJoy]

It's overcomplicating already complicated things.
If WordPress/UI or any other component wants to use router space, then so be it.
Simplify router instead of complicating it.