Thread by @AdamRackis

* puts on a black robe *

* sacrifices a goat *

* lights incense *

"Dan Abramov"

"Dan Abramov"

"Dan Abramov"

Hey Dan 👋 How's London?

Anyway, I was just wondering if you could tell us React devs how preloading is supposed to work in this brave new Suspense world.

Thanks!

"preload high; read low" was the early advice, and that shit made *total* sense.

But now I'm hearing far, far more complex, and at times contradictory advice.

Especially confusing: difference between "fetch then render" & "fetch as you render" is utterly imperceptible 99.99% of the time—basically any time a component can render extremely fast, which is almost always.

Boring.

Let's talk about *real* waterfalls: network waterfalls.

Talk to me about components behind a network request: run of the mill code split components using React.lazy, or route-split components behind a <Route />

Especially considering the data args their queries use will often be known up front, before the component is import()ed

If I say

const ToDoListLazt = lazy(() => import("./todoList"))

and component has something like

ToDoList = () => {
const args = useTodoFilters();
// get data w/ args
}

then the data deps are known up front. Surely we should preload them AS the lazy import() is in flight?

Sure some crazy Suspense shit might happen, and that component may not wind up rendering at all, but surely it's better to waste a preload() call, vs toss a network waterfall on our users?

ONE CLARIFICATION

difference between "fetch then render" & "fetch as you render"

Should have said

difference between "render then fetch" [ie fetch in useEffect] & "fetch as you render"