React isn't changing any logic of the types of props; if you actually pass a Promise as a prop, it will be treated 100% as it was in previous React versions.

What's happening instead is that imageFetcher.read() either returns a string OR throws a promise; it never returns a Promise.

So <Component foo={fooFetcher.read(...)} /> either gets instantiated with the fetched Foo, or throws so React.createElement(Component, ...) never gets called in the first place.

Only if you physically throw a Promise (or "thenable") does the new logic apply: https://github.com/facebook/react/pull/12279/files#diff-1996... is called inside an exception handler.

Wow, I never would have considered throwing anything other than an Error. On the face of it, this seems like an incredibly powerful technique, but is it an abuse of a language feature?

Is a feature of the exceptions to let you handle exceptional cases far away from the caller, up in the stack.

You should keep a distinction between exceptions that means "error" and exceptions that means "some kind of event happened", and handle them accordingly.

Python “abuses” exceptions in a similar way every time you iterate over a generator: https://softwareengineering.stackexchange.com/questions/1124...

At the end of the day it’s just a control flow mechanism. And theoretically, if you lack data needed to render, it’s an exceptional condition.

It's a very interesting technique; I will definitely be keeping an eye out for appropriate use cases.

My guess is that it won't catch on in the long run. But, you never know.

The key phrase is "thenable", which is a term for anything where `typeof variable.then === "function"` is true.

But only when passed to HTML elements I hope. Because say I have my own type of the shape `{ then(): Whatever }` and try to pass that as a prop to one of my components I don't want React to invoke that function.

It's not about passing props - the "thenable" detection comes into play if you throw a promise (or something shaped like a promise) from within `render()`.

Wait, can render functions now throw, legally?

Yup. This builds on error boundaries and componentDidCatch: https://reactjs.org/blog/2017/07/26/error-handling-in-react-...

Yes. (For this use case.)