RFC: suspendable subscriptions

[jamesknelson]

Update useSubscription to allow components to fetch data from multiple independent data sources without encountering waterfalls.

Changes:

• Support passing an array of subscriptions
• Add support for an isSuspended() option, letting useSubscription suspend until all subscriptions are ready

function Page() {
  // The component will suspend until all subscriptions are ready
  const [
    user,
    todos
  ] = useSubscription([
    useQuery(USER_QUERY),
    useFetch('/api/todos')
  ])

  // Rendered output goes here...
}

[gaearon]

The concern with waterfalls isn’t just multiple calls in a single file. It’s multiple calls in parent in children. This proposal doesn’t solve that so it seems insufficient as a general solution.

There are ways to solve the more general problem but they need to be more ambitious. Relay is one such approach.

It’s true triggering fetches early can be annoying manually. So you want to colocate data requirements with components. That makes sense and seems to be the problem you’re trying to solve.

But putting them into component body isn’t the only way to colocate them. And as we see from the inherent waterfalls, not the most efficient one.

One different way you can solve this is by having a parallel “data component” hierarchy whose files sit next to your components, but that represent data. This is the Flight idea started in facebook/react#16398. We haven’t talked much about it yet, but you can think of it as a non-GraphQL solution for composing arbitrary data logic in a parallel hierarchy to your components.

[jamesknelson]

A parallel data component hierarchy makes sense to me. I just took a look at react-flight -- I've been using Navi in a similar way, but Flight obviously has more time/thought put into it (and could integrate with React's context, which is one of the big issues I ran into with Navi).

Given that React is heading towards Flight, I agree that it doesn't make sense to try and put this into React core. I feel like it'd still be a useful option for useSubscription though, as it certainly can help in smaller apps -- at least until Flight is ready. Maybe it'd make a useful 3rd party package?

[Ephem]

@gaearon Preventing waterfalls is a very different conversation when talked about in the general framework-level sense as opposed to at the application-specific level. For less complex apps, it can be almost trivial to prevent waterfalls by other means than hoisting data fetching to the top. For those the complexity of maintaining a parallel hierarchy in order to fetch early might not always be worth it in my opinion.

This is a more general discussion of course and I would be happy to have it in a more suitable place if there is one you would prefer?

I love that you are working on/exploring a more general solution, it would be an awesome addition to React, but I think this RFC was aiming at solving a specific problem for cases where you don't want to hoist? That is, giving us an additional mechanism to solve waterfalls in different ways than the officially recommended one.

This isn't a comment on the RFC itself (which is very well written!), I'm not sure if this is something general/common enough to warrant expanding the API-surface of React when it could conceivably be solved in userland. 😄

[gaearon]

Flight obviously has more time/thought put into it

Just to clarify, Flight has barely been fleshed out beyond the initial idea. It will likely become a major focus soon, but not a lot of work has been put into it yet.

That is, giving us an additional mechanism to solve waterfalls in different ways than the officially recommended one.

I wouldn't say this mechanism is solving waterfalls. It only solves a subset of them. I don't think this by itself is valuable enough to expand the API surface.