[Draft RFC] First-class support for promises and async/await #2

If fetchInfo is expected to handle its promise rejection by not throwing...

Nah it's supposed to just reject, so that if you pass it to use it can be caught by error boundaries.

But yeah that's a really annoying error. One "solution" is to attach a listener that reports preloading errors, perhaps with a helper (logIfPreloadFails(promise)), which is maybe a good practice but is quite annoying to mandate for every use case.

Worth nothing this isn't React-specific, it affects regular async/await, too. It really should be addressed by the JavaScript runtimes.

Like IMO you should be able to write code that looks like this:

async function getAsyncData() {
 // Loads in parallel because nothing has been awaited yet
 const aPromise = getA();
 const bPromise = getB();
 return {
 a: await aPromise,
 b: await aPromise,
 };
}

but you can't because if both aPromise and bPromise rejects, bPromise will be considered unhandled. So you have to do Promise.all instead. Clowny.

Maybe there's some clever way we can intercept these warnings in the React runtime but I don't have any ideas right now.

I suppose we could preventDefault inside a global unhandledrejection event handler for the entire render phase. The rationale being that any async operation during rendering must be idempotent, so unhandled rejections can be safely ignored. If you do unwrap with use, the error will be surfaced like a regular error (i.e. trigger the nearest error boundary). https://developer.mozilla.org/en-US/docs/Web/API/Window/unhandledrejection_event

EDIT: Probably won't work as-is because the promise will usually reject well after the render phase has completed. But something along these lines would be nice.

Yeah that's correct. If it ends up being too annoying in practice, one thing we could do is provide a non-hook version of that API, because the current Server Components implementation of that hook is just a per-request counter. However, the downside there is that it won't work as a Shared Component anymore.

In general what we've found is that most use cases for hooks in Server Components can be replaced with a request-local version of the same API. For example, instead of a useRequestHeaders hook, frameworks can provide a getRequestHeaders function that reads from AsyncLocalStorage. It doesn't need to be contextual per tree.

Note that you can always just create a "Shared Component" that you only render on the Server. It's mainly semantics.

I think the direction we're headed eventually is that hooks will have custom syntax and we'll compile those to a generator-like form. But this is a longer term idea since it requires custom syntax that would need to be integrated into everyone's toolchains.

Yeah, I think if a compiler is already potentially in scope for other performance reasons, the runtime overhead doesn't seem too relevant in the grand scheme of things. I figure you could probably do a transform from e.g.

const foo = yield bar();

to:

let $$yeeted;
// ...
const foo = (React.yeet($$yeeted, bar()) ? yield $$yeeted.value : $$yeeted.value);

to avoid most of the additional overhead when no suspense is needed.

The hook abstraction problem is real, though my hunch is that people would probably prefer to know when a hook might suspend, and for such changes to be clearly documented and breaking, though I can appreciate the difference in opinions.

Note that on the client, it's always possible for new props to flow in from above while still loading - causing the first generator to be invalid. When that happens, you're still back to square one. So it does help optimizing a bit for this case, but doesn't fully solve the issue and makes it worse for updates.

Since that problem doesn't exist on the Server (except setState in render which will be deprecated) it's much more viable there.

What about usecases where you want to progressively render data from a chunked http call or generator? Like @stream in GrapQL?

Comment from @phryneas (Redux Toolkit / RTK Query maintainer):

Suggestion from my side: put these additional properties on symbols (and export the symbols so other libs can choose to access them).
In RTKQ we already add the properties arg, requestId, abort, unwrap, unsubscribe, reset and cancel on the promise. We can do that because our library creates those promises - we own them. There is a good chance that another library already has a status property on there - especially if it is not using native promises, but some kind of promise polyfill. I actually think I almost added one myself.
Now, React doesn't "own" those promises. It's a consumer. And it should not pollute the string-properties of those because it could cause conflicts with existing properties. It potentially could affect non-react code.

Yea, it's expected that other libraries/frameworks set these up front.

Note that React doesn't override it if a string already is set but React does expect it to become the string "fulfilled" later. It allows for other statuses to exist.

In fact, the React Server Components client runtime does both of these.

The type accepted by use(...) only accept Promises that either don't have this property or has a status corresponding to React. So it accepts either a "React Promise" or a "Regular Promise". For other kinds of Promises, it's an invalid type but you can pass a wrapper using Promise.resolve(otherPromise).

Now, React doesn't "own" those promises. It's a consumer. And it should not pollute the string-properties of those because it could cause conflicts with existing properties. It potentially could affect non-react code.

The owner/consumer distinction is fair enough, but I think it's important to note that React isn't intercepting random promises willy nilly. These properties are only added to promises that are passed explicitly to React. And it's part of the contract of use that React will add these properties. If there's a conflict, you can wrap it another layer, or rename the fields. Or use a different API that better meets your needs.

Using Symbols instead is a reasonable suggestion, but part of our motivation here is to try to create some grassroots alignment with other libraries and frameworks. It's in everyone's best interest if we all choose the same convention.

One can argue it's slightly provocative — honestly, it's intentional. We hope if it gains enough traction it'll convince the standards bodies to address this themselves.

I think it's important to note that React isn't intercepting random promises willy nilly

Though we do have another proposal in the works that will probably do something like this :D