The description of suspending sounds exactly like yielding generators and/or async await; why not build this feature on top of existing language constructs? I am quite sure the react core team has put more than the 30 seconds of thought I have into this question, so I'm curious what their reasoning is for using this implementation.

Seb explains the reason here https://github.com/facebook/react/issues/7942#issuecomment-2...

That's a great thread, thanks for the link!

This seems to me like a workaround for the fact that React requires `render` methods to return React elements. And I suppose it also takes advantage of the fact that the `read` method can `throw` its way out of your `render` function, obviating the need to check its result and manually `return`. But not gonna lie, I'm pretty suspicious of overreliance on creative use of `throw`ing as something that is going to cross through application code's control flow. But perhaps it will prove convenient enough to be worth it.

So I am guessing if a prop is `instanceof Promise` or some other constructor then it must trigger this response . . . is that correct?

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.)

> throws a promise

> ...

> It's...promising to say the least!

^ this guy :finger_guns:

Is the cache global?

It's up to you. I intentionally kept moving parts to the minimum in my demo, but here's the real thing I was using behind the scenes: https://github.com/facebook/react/tree/master/packages/simpl.... So in that sense it's not global, you can create as many as you like and then isolate them (e.g. per subtree).

The `simple-cache-provider` is just a reference implementation though. It's somewhat naïve, e.g. it doesn't have invalidation strategy and just lets you replace the whole cache with a new one if you want to invalidate.

We'll publish more details on lower level API and how to write your own cache in the future.

It seems from https://github.com/facebook/react/blob/master/packages/simpl... that in the live version you'll be specifying which cache to use; this could be global, provided via React's old or new Context APIs, or passed down through props. And you could always write your own fetcher factory if you want to do something really custom; there's nothing special about the SimpleCacheProvider, and it doesn't use any React internals.

FWIW my demo code looked like

    export let cache;
    function initCache() {
      cache = createCache(initCache);
    }
    initCache();

    export function createFetcher(fetch) {
      const res = createResource(fetch);
      return {
        read(...args) {
          return res(cache, ...args);
        },
      };
    }