Nice recap! like the idea of using IDeref
I think it’s worth pointing out that despite the warning about not fetching data during render, that’s precisely the design that Suspense encourages. Each component on first load initiates a fetch, might throw a Promise which tells the wrapping Suspense component to render the fallback loading state if defined. Suspense implementations expect that once the request has been fulfilled, it’s stored in cache so that subsequent renders don’t re-trigger the whole flow.
I think the value here is in allowing us to define more natural UIs where a component fetches the data it needs and once it arrives it can pass it to children which themselves might fetch more. Imagine rendering a Datomic Entity value, pulling a card many attribute, and passing those entities down the UI tree. Subcomponents can better manage the keys they need specifically (ala Spec 2, Rich’s “Maybe Not” talk).
Many critiques I’ve seen of suspense suggest you should just “fetch all the data in advance” and pass it to your UI as if that’s an easy, solved problem. In practice I find I do a lot of work marshaling the various data requirements of my components from the top level.
What happens if a state change occurs which should invalidate the cached fetch? That part I’m still pretty unclear about
Anyone else trying out the Suspense features?