RFC: Pending export

[ryanflorence]

Route Module Pending Component Export

There are two primary approaches to page transitions (ignoring suspense's ditched attempt at a third)

1. Indefinitely wait on the old screen
2. Transition immediately to spinners/skeleton

Right now Remix has picked (1), but with a new export to a route module, we could support both.

Today, if you have this, Remix will wait for all data to load before displaying the page

export function loader({ params }) {
  return User.find(params.userId);
}

export default function UserProfile() {
  let user = useRouteData();
  return <UserProfile user={user} />;
}

Like ErrorBoundary, we could add a Pending export:

export function loader({ params }) {
  return User.find(params.userId);
}

export function Pending() {
  return <UserProfileSkeleton />;
}

export default function UserProfile() {
  let user = useRouteData();
  return <UserProfile user={user} />;
}

If a route module exports a Pending component, Remix could switch to mode (2) and immediately display this screen when the location changes, dispalying <Pending/> until the route data all lands.

What about nested routes?

Remix will wait for any routes that don't export a Pending before displaying any other routes' Pending export. Some scenarios:

• All routes have Pending: can transition immediately.
• Parent without Pending, child route with Pending: wait for Parent, then transition immediately for Child.
• A-Pending -> B-No -> C-Pending: Wait for B, transition to Pending

In summary, wait for all routes w/o pending, then transition.

So what?

On web and native, both types of transitions are common, and both have their tradeoffs depending on the data being fetched or the type of app you're building. In apps with very "app like" layouts with lots of persistent UI between location changes (rather than typical "pages" on the web with very little persistent UI), immediate transitions to skeleton UI is feels much better. For example, in Discord, it would feel weird to click on a channel and not go immediately to a shimmer/skeleton page. Conversely, we all know how terrible many webpages feel when clicking a link results in 12 spinners bouncing around before the page is built.

There's room for both transitions.

What's really interesting with Remix is that the Pending components in layouts can still render an outlet. This means that if a parent route's data is not as important as a child's you don't have to block the transition on it.

For example, load up a youtube video on a slower connection and you'll notice the primary content loads first, then the layout shows up around it.

Consider a typical master/detail view with these routes:

routes/
  - users.tsx
  - users/
    - index.tsx
    - $user.tsx

And let's say the UI has a sidebar of the users on the left, and the profile on the right:

  <Users>           <$User>
|----------------------------------|
|  bob     |       Bob Thornton    |
|  sally   |                       |
|  curtis  |                       |
...

The most important data at /users/bob-thornton is Bob's profile, not the user list.

So to get the users's profile displaying as fast as possible it could look like this:

// routes/users.tsx
export function loader() {
  return Users.findAll();
}

export function Pending() {
  return (
    <>
      <UsersSidebarSkeleton/>
      <Outlet/> {/* <-- Can still render an outlet! */}
    </>
  )
}

export default function UsersLayout() {
  let users = useRouteData()
  return (
    <>
      <UsersSidebar users={users}>
      <Outlet/>
    </>
  )
}

// routes/users/$userId.tsx
export function loader({ params }) {
  return Users.find(params.userId);
}

// no pending export we want to wait for this
export default function User() {
  let user = useRouteData()
  return (
    <UsersProfile user={user}>
  )
}

Now if you're looking at /recent-activity and click on a user's name, navigating to /users/sally-mae Remix will:

• Keep the recent activity screen up
• Start loading Users.findAll() and Users.find("sally-mae") in parallel for both users.tsx and users/$userId.tsx
• As soon as users/$userId.tsx is complete, Remix will transition to the page
• If users.tsx has not finished loading (probably more expensive anyway), the sidebar will just keep shimmering until it's loaded, but Sally's profile will be up!
• Instead if users.tsx finished before users/$userId.tsx, then you're transitioned to a fully formed page.

Implementation

• Transition hook: just like hasLoader and hasAction, we can easily know which loaders to wait on in the transition hook with a hasPending.

• Transition hook: while we still kick off the fetches for the routes with pending ui and loaders, we don't await them. When they land, we just setState into routeData.

• Client side redirects will be a little tricky, to get consistent behavior across document requests, no pending UI, and pending UI, we'd need to wait for all loaders to land (even the pending ones) before deciding to redirect. This means a child route without pending UI could render, and then a parent route with pending ui could redirect after. Also, a child route with pending UI that redirects, should stay in the pending state until all routes data has landed and then decide where to redirect.

• <RemixRoute>: With a mix of hasLoader and hasPending, when it comes time to render the route, we can put a placeholder in the routeData state, or add a new piece of state to track which routes we're still waiting on, to decide to render the pending UI or not.

• Server rendering: if a route has pending UI, do we skip the loader on the server render and go straight to pending? Ignore pending and always render the full page on the server? Add a way to let apps decide? I think we just render the whole thing. This would bring consistent results across document/fetch requests and then we could add a way to skip it later if we decide it's worth it.

[sergiodxa]

I love this idea, specially this

What's really interesting with Remix is that the Pending components in layouts can still render an outlet. This means that if a parent route's data is not as important as a child's you don't have to block the transition on it.

For example, load up a youtube video on a slower connection and you'll notice the primary content loads first, then the layout shows up around it.

I think for SSR the pending should be ignored, YouTube does respect it in the first paint (check https://youtu.be/dQw4w9WgXcQ) but most likely they are not doing SSR anyway. Maybe have a way to enable it for SSR in the remix.config.js but just ignoring it always for SSR it's not a bad default.

[ryanflorence]

export function Pending() {}
Pending.ssr = true
// default false

[itsMapleLeaf]

This is really elegant. I was actually thinking about how I'd get that "pending loading spinner UX" that I previously had in my client rendered app.

Would this also support a timeout, similar to timeoutMs in Suspense config? e.g. Show the previous UI for X amount of milliseconds, when that's passed, then show pending?

[kentcdodds]

Server rendering: if a route has pending...

Is there a way for my loader to know whether it's being called for SSR or from a client-side render? If it did, then I could decide whether I want to skip loading the perf-problematic request during SSR. Not sure I like that any better than the .ssr = true idea though 🤔

[ryanflorence]

Would this also support a timeout, similar to timeoutMs in Suspense config? e.g. Show the previous UI for X amount of milliseconds, when that's passed, then show pending?

I don't think so. The React team has backpedaled on that in suspense, too. It seems you really just want to "wait for this indefinitely" or "transition to spinners ASAP". One very tricky problem is when the timeoutMs expires 1ms before the data loads, lots of jank in that situation. I've got some ideas there (after timeout expires wait another timeout to let an animation complete even though data is ready to avoid the jank) but I'd rather just start simpler.

[ryanflorence]

@kentcdodds

Is there a way for my loader to know whether it's being called for SSR or from a client-side render?

I'm not sure how this helps (or what you're supposed to return from the loader?). We just need some config. Loaders are simply request in, response out. Configuring the behavior of a Remix transition/initial render isn't their job.

[kentcdodds]

I was just suggesting that if you didn't want the loader to run on SSR, it could just return null in that case.

[ryanflorence]

Ah gotcha. You can already return null from a loader and that means ... null. (You can return anything that can go to JSON.stringify(...)). So now your useRouteData() will change from whatever data was in there to null on the next render.

[kentcdodds]

Clearly I'm striking out on suggestions tonight 😅 I'll get back to doing the dishes and stop being a distraction 🤣

[ryanflorence]

Haha, no worries, it's good to help think about it from other angles. I think the core issue is that we're trying to figure out how to define the pending/transition behavior but loaders are just the data, so trying to give loaders the responsibility of defining both behavior and data is mixing responsibilities.

In this case the behavior (don't wait for this data and transition to pending if other loaders are ready) and the data (this route still has data!) are both needed. So returning null doesn't really make sense, we still care about the data, we just aren't going to wait for it.

[mjackson]

Alternative idea for a name: Fallback. Ofc, copied from the <Suspense fallback> naming.

It's more of a noun, like ErrorBoundary.

[ryanflorence]

Fallback to me made the most sense with suspense's "timeoutMs", so you "fallback to this if the timeout expires" where pending is like "This is the pending ui", no idea of "falling back" it's just the pending state.

I'm fine with either, but that's how I think about it.

[ryanflorence]

Oops, accidentally submitted.

Additionally, everything else about loading in remix is "pending", pendingLocation pendingFormSubmit etc. and a Pending export falls within the same set of features.

But again, I'm fine with either.

[mjackson]

Yeah, I'm fine with either too. The way I think about it is "fall back to this when we aren't ready to show the component yet, for whatever reason".

[kiliman]

@kentcdodds

Is there a way for my loader to know whether it's being called for SSR or from a client-side render? If it did, then I could decide whether I want to skip loading the perf-problematic request during SSR. Not sure I like that any better than the .ssr = true idea though 🤔

Although neat in theory, the issue would be that it would break the "no javascript" case as the client would never request the SSR data after initial render. I think for "heavy" loaders, you would want to implement a server-side cache and return that... even serving up stale data if it's not critical.

[norman-ags]

Not sure if it's a bad idea, will just throw it here:

Is it possible to have the loader to be similar to getInitialProps of next? Or maybe have an option that after the initial load, the succeeding call would be client-side.

export let loader = {} => {
 // logic
}
// something like this: 
loader.clientSideOnSucceedingCalls = true

[sergiodxa]

@norman-ags check #179

[roydigerhund]

I'm testing Remix on a just for fun currently and came across this topic.
Is there any decision or progress made here or are there better options to implement a skeleton state?

I have an app with some data-heavy routes and a skeleton state would be a big improvement to the UI.

If there is something I could help with, let me now.

[sergiodxa]

I think the current approach is

1. Try to make everything faster so you don't need a pending UI
2. Prefetch so you don't need a pending UI
3. Use useTransition to know if it's transitioning and replace the outlet on the parent with the loading UI

[roydigerhund]

Is there a way (without changing something in the remix core) to get an exported skeleton state for the next route and replace the outlet with it? useTransition is only providing the raw URL for the next route and useMatches only the file-route for the current route.

The only idea I have right now is writing my own route-matching with assigned skeleton functions. This would then be needed on every parent component with an outlet.

[roydigerhund]

Something like this:

const transition = useTransition();
const skeletons = [
  {
    pathRegex: /\/path\/to\/test$/,
    component: skeletonComponent,
  },
];
const skeleton =
  transition.state === 'loading' && skeletons.find((s) => s.pathRegex.test(transition.location.pathname))?.component;

{skeleton ? skeleton() : <Outlet />}

[roydigerhund]

I ran the code above in a local test (the fastest I can get regarding points 1 & 2) and had the following results.

• Without skeleton state, it took 14 frames (nearly 0,5 seconds) from the click on a link to the next page showing up.
• With skeleton state, it took 5 frames (about 0,15 seconds) for the skeleton state to be displayed and 16 frames until the page was fully loaded.

Although the difference isn't that much, the response felt much quicker and better.

What does not work with this solution is the isActive state of the NavLink component.

@ryanflorence is it planned to bring in the Pending export in the future?

[dan-cooke]

This would be amazing to have in remix - i've been using this framework for 3 or 4 months now, and this is the first time i've hit a blocker with something.

While your suggestions @sergiodxa are definite solutions

I think the current approach is

Try to make everything faster so you don't need a pending UI
Prefetch so you don't need a pending UI
Use useTransition to know if it's transitioning and replace the outlet on the parent with the loading UI

It would be great to have this functionality.

Prefetching data can be costly, especially with long running IO on the loader,

I'm actually resorting to performing these intensive fetches on the client side, which is going against the framework quite a bit.

[dan-cooke]

@ryanflorence would the following work as a simple alternative to Pending component.

1. useTransition default state is loading
2. Remix renders the tree once without calling loaders
3. This allows components to render their own Skeleton based on the useTransition state
4. Remix calls loaders and renders as normal

This may slow down the TTI quite a bit, so its probably not a great solution - what do you think?

[Simonpedro]

I've been using Remix for +4 months now, and I can also say this feature would be very handy. Sometimes it's not possible or easy to prefetch the data for a particular page and you want the page transition to be instant even if the data hasn't loaded.

In my use case, I have a login page that (after successful login) redirects to a data-heavy page. Most of the time, the data is cached, but not always, so with server rendering, the user would be stuck on the login page and the UI would feel unresponsive until the data has completely loaded.

Similar to @dan-cooke, that's why I ended up fetching data on the client-side. I felt guilty about going against Remix philosophy 🙈

[kentcdodds]

This use case will be handled better than you're probably imagining by the upcoming deferred API :) Learn more: https://www.youtube.com/watch?v=95B8mnhzoCM

We're likely weeks away from a stable release of this, but if you'd like to try it we've got it published under the tag titled deferred. Stay tuned!

[dan-cooke]

That is bonkers, wow. You are totally right I could not even have imagined a better API for this.

[Simonpedro]

That's exactly what I need! Thanks for sharing 😄

[mclngl]

The deferred API looks very good, but we currently deploy on AWS through architect and it's not supported.
Is there any plan to address this ? Any news on the Pending component export ? I think it would still be useful.

[sergiodxa]

Is there any plan to address this?

This is sadly something the platform needs to change to allow streaming responses, without that it's not possible for Remix to solve it.

Any news on the Pending component export?

There haven't been progress on this AFAIK (I'm not part of the team) and the deferred API is probably going to be the suggestion, also the Pending component would also need streaming support, otherwise React would have to buffer the response before sending it, so Pending would only work for client-side navigation.