Support for asynchronous values (like Promises and Observables)

At the moment, it is quite cumbersome to work with promises in React. Either you write a lot of code to update the state inside the then() callbacks or you use a library like react-promise which only works for children (not properties) because it is based on components.

Another option is to traverse the whole virtual dom and replace promises before they are passed to React. (I have read once a blog post about this but cannot find it any longer.) This is obviously not ideal for the rendering performance.

Since promises are now a standard, I think there should be simpler way to use them directly in the view. One option would be to introduce an AsyncValue type with a Promise implementation. The AsyncValue type would then be supported for children as well as properties.

Promises could then simply be used like this:

<div>{promise(this.state.myPromise)}</div>

Opposed to supporting promises everywhere (directly without the promise function), this should not have unexpected side effects. Moreover, other types of asynchronous values (for example Observables) could be added later easily just by creating another AsyncType implementation.

Angular 2 takes a similar route with the async pipe. There you can simply write

{{ myPromise | async }}

in attributes as well as normal content.

This feature would also be very convinient for libraries like Flux because it allows to fetch properties directly inside the view and avoids the reptition which you have with Relay:

<div>{promise(this.state.model.get('property'))}</div>

What do you think about this proposal?
Has this been discussed before? I couldn't find a thread which covers this particular topic.

[iamdustan]

Hey @joelrich,

I’m fairly certain that this proposal runs counter to some of the goals the project has and the direction it is headed. Specifically around scheduling.

While not a direct answer, you can glean some of the thoughts surrounding this in the following threads:

• New Core Algorithm (#6170)
• Webworkers

Unable to find a source, default react state is natively serializeable and synchronous right now. This allows React to reason about and have tight control over reconciliation and rendering. This also allows React to decide on scheduling. Promises as an abstraction remove all of these properties making current and future optimizations difficult or impossible.

Hi @iamdustan,

Do you see another way to improve the support for promises - especially for use cases with libraries like Falcor where most values in the view are promises? Or do you think the current solution is good enough?

I do not think that the scheduling is a big problem. Similar to then + setState, you would only have to schedule an update if the promise is resolved/rejected.

What exactly do you mean with "react state is natively serializeable"? For example, if you put an object of an ES6 class into the state, is the state then still serializable? Sure, you can JSON.stringify it, but you lose the information about the class. You would not be able to parse it and replace the previous state with it without risking that there will be problems. Is there a reason why the view state has to be serializable?

[zpao]

cc @sebmarkbage for some additional thoughts / links.

[nfcampos]

don't know if this helps but see https://github.com/heroku/react-refetch (specifically https://github.com/heroku/react-refetch/blob/master/src/PromiseState.js) for a serialisable, immutable representation of the state of a Promise that you can use to stand in for a promise in a way that makes sense inside a render method.
cc @ryanbrainard

[sebmarkbage]

This has been discussed so many times that there is no single easy link to post to. We should probably make a new summary but I'll do my best here.

We did have an idea to allow promises passed to setState(promise) as a convenience. That would also allow it to clean up itself automatically if the component gets unmounted if it gets resolved earlier.

1. If you allow a Promise or Observable in render, you end up in an intermediate state. What do you do with your UI in the mean time? What goes into the <div> in the example of <div>{promise(this.state.myPromise)}</div> before it gets resolved? What about when the value updates? We didn't want to encourage a system where you could block the UI by accidentally putting a too long Promise in there.

2. One of the benefits of React over what came before it was that as a user you never deal with specialized data structures. Like change tracking sets, Promises or Observable values. It's all plain data. async/await gets closer to that but still requires a lot of explicit opt-in. In other languages there are solutions that doesn't require this but still have the capabilities that you want here.

3. Promise and Observable chains execute whenever the async dependencies get resolved. They're push oriented. When something happens, immediately compute all the artifacts of it. The scheduling work mentioned above is about making sure that such operations don't steal CPU cycles. Because if that work is low-priority, it will cause responsiveness issues for higher priority work.

Now there are mitigating factors for all these things:

1. We have an idea for how we could do forked behavior of components where they could live in two states at once and then rebase. This would allow a component to update itself (remain responsive) while a pending update is still being processed.

2. We could potentially design the API around generators or async/await to avoid exposing users to first-class Promise values. (Or even better, algebraic effects.)

3. The ECMAScript Zones proposal could allow for overriding the default scheduling of Promises. Allowing us to defer work that is not high priority. This would make the whole idea of push oriented values more palatable.

@sebmarkbage, thank you for the summary. My take on 1) is that the promise function would allow to specify a loading value. Example:

<div>{promise(this.state.myPromise, 'Loading...')}</div>

Alternatively, you could also wrap multiple elements with another helper function to wait until all promises are resolved. Since this function would just return another promise, this would not have to be part of React as long as it is allowed to return a (wrapped) promise from render().

Regarding 3), I am still not sure if I understand the problem. When the promise is resolved, the behaviour could be very similar to promise.then(v => this.setState({value: v})). I haven't looked at how setState is implemented, but if for the example the DOM update only happens in the next animation frame, then it would still be possible to do the same: If the promise is resolved, schedule a DOM update for this virtual DOM subtree and perform it (together with other promise changes) during the next animation frame.

[satya164]

@joecritch How about you have a component which can render a promise? Something like,

<PromisedValue
    promise={promise}
    renderLoading={() => <...>}
    renderItem={value => <...>}
    renderError={err => <...>}
/>

Should be easy enough to write such a component.

@satya164 unfortunately, this does not work for properties.