Thread by @AdamRackis

Wait hold up React fam ✋

A route only needs to block (Suspend) on the initial data, right?

If our Route were to preload its data, and also send down a read() method that got called on every render, and threw until the FIRST data were ready, wouldn’t that be sufficient?

1/

Subsequent data updates (and, well, the initial data) would be returned from the same GraphQL hooks we’re already using, with the same incremental spinners.

But now a single initial page reveal with all needed data. And render as you fetch.

Is there a downside I’m missing?

2/

So something like

const TodoList = (props) => {
// data already prefetching

props.res.read(); //throws if init data not ready

const { loading, data } = useSameOldGraphQLQuery(...);

// and go ...

✅ Prefetch
✅ Suspend initial render until all data ready
✅ Incremental spinner

❌ Really long wait times won’t revert to the <Suspense /> fallback but who cares?

@dan_abramov @sebmarkbage punish me ⛓🚬 and tell me why I’m wrong.

I’m ready

And no twisted, bizarre interactions between components mutating data, and your top-level router.

@dan_abramov @sebmarkbage To put an exclamation mark on this, with existing React clients (any of them)

const { loading, data } = useSameOldGraphQLQuery(...);

if you then mutate some local data on the other side of your app, this 👆 hook will re-fire, on its own, automatically, with updated data.

1/

@dan_abramov @sebmarkbage Without any need to tell the router to create a new resource object, without any manual work whatsoever. Without your GraphQL client needing to know what a Router is, let alone which you're using, or where it is.

It sees data update, and it pushes updates out of the hook

@dan_abramov @sebmarkbage That's what I want to keep, but still get the benefits of those Suspense demo's.

Ideally without boiling the ocean / re-writing everything.

@dan_abramov @sebmarkbage s/
if you then mutate some local data on the other side of your app/
if you then mutate data from the other side of your app/