Page transitions and loading states

[david-crespo]

This is not something we need to worry about right away, I just want to write it down as something we'll have to do. I don't believe there's architectural risk in putting this off — whatever we decide to do, we're not building anything now that will make it especially difficult later. One thing to keep in mind is that the official built-into-React solutions for this (discussed below) won't be out for at least a few months, which means we may want a low-effort interim solution to make our demos look less janky while we wait for the real thing.

Right now we've kept loading states really really minimal, i.e., when a request is going through we literally show the word "loading" in place of the entire component. Because our requests are pretty fast (and we intend to keep it that way), that means we flash the loading state too fast to really see it. (A nice way to handle this is to only show the loading state if the loading time exceeds some low threshold, like 200-300ms.)

Now, regardless of whether your requests are fast or medium (with slow requests the experience is bad no matter what), the behavior you really want is that of classic server-rendered apps: navigation triggers a request, but the page doesn't change until that request comes back. That means you're sitting on the old page for a bit (potentially a very short time) and then the new content loads more or less instantly. So the visual transition is instantaneous even though you might have to wait a few hundred ms after you clicked to see it. The problem in React is that requests are triggered by rendering the component that needs the data, which means you have to attempt to render that component in order to kick off the request. That means you have to transition to the next page before the data for it is ready. Hence loading spinners.

This problem and potential solutions are discussed rather extensively in RFD 169. In order to mitigate the issue while staying browser-only, you have to define the data requirements for components separately from their rendering and have a top-level transition manager that registers the page you're trying to transition to, fetches the data, and only renders the new page once the data is ready. This is basically what Remix does, though it also has pretty heavy server integration. The React team is working on built-in tools in the forthcoming React 18 for managing transitions: useTransition in concurrent mode. Not sure when that's coming out (progress tracker here), but it's been in the works for months and updated alphas are published to npm every few days. That might be worth trying out.

[benjaminleonard]

Would it be useful to look at skeleton loading states for components that rely on an API call (https://css-tricks.com/building-skeleton-screens-css-custom-properties/)? Perhaps it's useful to think about the places on the console that might have the slowest responses, and create skeleton components for those parts.

[david-crespo]

I think so, at least as an interim solution. Though it will be hard to know what requests are slow until more of the system is built out.

[david-crespo]

Closing in favor of #737, the concrete task of using React Router loaders when they come out.