5 ms·

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 tha

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.