Closed ryanflorence closed 2 years ago
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.
export function Pending() {}
Pending.ssr = true
// default false
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?
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 🤔
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.
@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.
I was just suggesting that if you didn't want the loader to run on SSR, it could just return null
in that case.
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.
Clearly I'm striking out on suggestions tonight 😅 I'll get back to doing the dishes and stop being a distraction 🤣
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.
Alternative idea for a name: Fallback
. Ofc, copied from the <Suspense fallback>
naming.
It's more of a noun, like ErrorBoundary
.
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.
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.
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".
@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.
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
@norman-ags check https://github.com/remix-run/remix/issues/179
Route Module Pending Component Export
There are two primary approaches to page transitions (ignoring suspense's ditched attempt at a third)
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
Like
ErrorBoundary
, we could add aPending
export: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:Pending
: can transition immediately.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:
And let's say the UI has a sidebar of the users on the left, and the profile on the right:
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:
Now if you're looking at
/recent-activity
and click on a user's name, navigating to/users/sally-mae
Remix will:Users.findAll()
andUsers.find("sally-mae")
in parallel for bothusers.tsx
andusers/$userId.tsx
users/$userId.tsx
is complete, Remix will transition to the pageusers.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!users.tsx
finished beforeusers/$userId.tsx
, then you're transitioned to a fully formed page.Implementation
Transition hook: just like
hasLoader
andhasAction
, we can easily know which loaders to wait on in the transition hook with ahasPending
.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 ofhasLoader
andhasPending
, when it comes time to render the route, we can put a placeholder in therouteData
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.