4 ms·

Thanks for your explanation. What I don't understand is why there's no easy way to conditionally render a subtree depending on promises contained in the props

Thanks for your explanation. What I don't understand is why there's no easy way to conditionally render a subtree depending on promises contained in the props of the top-level component. Kind of like a guardian HOC triggering a re-render whenever all props promises resolve. Is it because that would be a one-time thing and not synchronously reactive? Seems like people reimplement or reuse this kind of thing all the time, but often using useEffect (transforming side-effects into state, losing deterministic rendering). You're right that this would get ugly really fast with nested suspense boundaries though.

acemarke 2y ago
Hmm. Trying to understand what you're suggesting here. You can pass _any_ JS value as a prop to a child component, and there's nothing special about any of that as far as React is concerned. You can pass a primitive, an object, a Promise, an AbortController, a DOM node, anything. All React cares about is "here's what gets passed into the child". Suspense has a couple key bits of behavior: it needs to let _deeply_ nested components trigger the _nearest_ Suspense boundary, and it also needs a way for React to know when the async behavior is done (ie, the promise resolves) so that it knows when to re-render. Throwing a promise is certainly unusual conceptually, but makes sense in light of those constraints. (I'm probably misunderstanding what you're envisioning and didn't manage to answer it properly - feel free to clarify with an example if you'd like!)
- moritzwarhier 2y ago
  Yes I'm not sure myself if what I say makes sense when thinking it through again. I was thinking something like <WithPromises asyncProp={promise} asyncProp2={promise2}> {(resolvedValues) => children(resolvedValues)} </WithPromises> But that's already possible to do yourself I guess, but better in different way. E.g. not using a function prop as "children" etc. Many libraries also provide nice and clean interfaces to provide async state (e.g. react-query) and then of course there's good old useEffect. I think I see why they use a different approach. Guess I'd mainly just love a streamlined API for data fetching built into the core. Right now it's a lot better to just have async code outside of react change prop values. Love the section on client data fetching in the react docs though.

acemarke 2y ago

Hmm. Trying to understand what you're suggesting here. You can pass _any_ JS value as a prop to a child component, and there's nothing special about any of that as far as React is concerned. You can pass a primitive, an object, a Promise, an AbortController, a DOM node, anything. All React cares about is "here's what gets passed into the child". Suspense has a couple key bits of behavior: it needs to let _deeply_ nested components trigger the _nearest_ Suspense boundary, and it also needs a way for React to know when the async behavior is done (ie, the promise resolves) so that it knows when to re-render. Throwing a promise is certainly unusual conceptually, but makes sense in light of those constraints. (I'm probably misunderstanding what you're envisioning and didn't manage to answer it properly - feel free to clarify with an example if you'd like!)

moritzwarhier 2y ago
Yes I'm not sure myself if what I say makes sense when thinking it through again. I was thinking something like <WithPromises asyncProp={promise} asyncProp2={promise2}> {(resolvedValues) => children(resolvedValues)} </WithPromises> But that's already possible to do yourself I guess, but better in different way. E.g. not using a function prop as "children" etc. Many libraries also provide nice and clean interfaces to provide async state (e.g. react-query) and then of course there's good old useEffect. I think I see why they use a different approach. Guess I'd mainly just love a streamlined API for data fetching built into the core. Right now it's a lot better to just have async code outside of react change prop values. Love the section on client data fetching in the react docs though.