Dashboard smoother routes

[acelaya]

This PR introduces a mechanism to load the data needed by a new section just before transitioning to it, allowing to keep the previous section rendered until the loading has finished.

This also provides an alternative approach to handle the initial loading, so it might replace https://github.com/hypothesis/lms/pull/6287

How it works

In order to achieve this, every component which represents a "page" and is therefore linked to a route is now expected to fulfill a module contract, exporting two symbols:

1. A loader function, which returns a promise resolving the data needed by the component.
2. A default export, which is the component to render, with a single loaderResult prop where the result of resolving the loader will be passed.

To orchestrate everything, we introduce a new component, which replaces the standard <Switch /> + <Route /> router components, and uses instances of useRoute to determine the matching route.

Once we know the matching route, we use a dynamic import(...) to load the corresponding module, call its loader, and once resolved, mount the corresponding component.

This also allow us to have three states.

1. At first there's no component loaded at all. This is the initial loading state, where we could show a global loader or splash screen. This is why I mentioned this PR could replace https://github.com/hypothesis/lms/pull/6287
2. When a component has already been loaded, we show it normally.
3. When transitioning between two routes, we keep showing previous component, with an optional subtle loading indicator of some kind, and once the new loader has resolved, we replace the rendered component.

References

This approach is inspired by how some react full-stack frameworks resolve data loading. In their case data is loaded in the server and then components are hydrated with the result, but conceptually it's similar to this.

• Remix loaders: Route modules export a loader function and a React component. The component can get the result of executing the loader function via a useLoaderData() hook.
• Next.js getServerSideProps: Page modules export a getServerSideProps function and a React component. The component gets the result of calling getServerSideProps implicitly as props.

Considerations and next steps

• The logic to match a module based on current route does not currently scale very well. The more routes we add, the more complex it will become.
• For every handled route, we need one call to useRoute. It somehow matches how the static routing config would work, via <Route /> components, but in the second case the children to render are implicit, while in here we still need to perform extra logic on the combined results of all useRoute calls.
• This POC does not currently allow to render any children until loading has ended. We may want to change that and make the loader return an object including the mandatory promise/es to await, and others that should not block rendering children.
• The logic is currently a bit coupled with the dashboard.

[acelaya]

I created another PR based on this one, where the route matching logic is extracted to its own hook, and the map of route -> module could be passed as a prop: https://github.com/hypothesis/lms/pull/6357

[acelaya]

I just noticed the usage of dynamic import(...) statements causes rollup to generate individual chunk files for those modules. I guess this should be ok, but I'm checking if it's somehow possible to incorporate them in the same bundle file.

EDIT: the output.inlineDynamicImports rollup option would solve this if we wish to bundle everything in a single file.

[acelaya]

Closing for now, until we come back to this.