Yeah, _we library maintainers_ are feeling the same way :) - https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i https://bsky.app/profile/acemarke.dev/pos

Yeah, _we library maintainers_ are feeling the same way :) - https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i https://bsky.app/profile/acemarke.dev/post/3lcitbmmfss2i Big picture as I understand it: The legacy and always-undocumented-but-everyone-knew-about-it approach was throwing a promise while rendering. `use` still actually does the same thing, but it also attaches some extra status fields to that promise, _and_ checks to see if you're consistently passing in the _same_ promise reference. In other words, it's the job of an external data fetching library to keep track of what query entry is being asked for, create and save a promise per cache entry _outside_ of the React component tree, and then return that promise somehow so the app developer can pass it to the `use` hook. In a sense, it's an async `Map`. As another example of this, my former teammate Brian Vaughn (previously on the React core team) ended up building his own implementation of that behavior in the conveniently-named `suspense` package: - https://suspense.vercel.app/ https://suspense.vercel.app/ Ultimately, the `use` hook and Suspense _does_ do exactly what you're asking for - the rest of the component gets to assume the data _does_ exist, since `use` will only let the execution continue once the promise has resolved.