This document keeps track of all the work and tasks to define the routing foundation for the site editor based on previous learnings.

Requirements

• Library Avoid reinventing the wheel, rely on a strong router library (TanStack or ReactRouter). At the same time, these libraries are likely to evolve over time, so provide a curated set of APIs for routes to use for navigation, access to parameters...
• Lazy loading Every route should be lazy-loaded by default. Loading the admin shouldn't require loading all the routes JS and CSS files, instead each route should be a separate chunk (WordPress supports scripts modules that can be used as a foundation here)
• i18n Route chunks will need to support lazy-loaded translations.
• DevX Writing script modules, adding them to the import map and loading them at the right moment can be tedious work, it's boilerplate code that developers shouldn't have to think about when writing route. We should offer a dedicate convention and build tool for third-parties to register routes without any boilerplate.
• Editor APIs and wp global The big amount of JS APIs that developer use to write their plugins (i18n, components, block-editor...) are scripts that register wp global variables. Unfortunately, these scripts can't be lazy-loaded. Rewriting these to modules is multi-year project that should be explored separately. Initially, routes should be able to use a fixed list of global variables that will always assumed to be available.
• Preloading The router should support advanced performance optimization techniques (like loaders for routes, preloading links on hover...)
• Transitions and animations Consistent transitions and animations between the different routes, consider view transitions.
• Backwards compatibility Automatic handling of WordPress's menu API. third-party pages registered using the WordPress Menu API and written in php could be rendered in these new routing based pages.