Async render function?

[pie6k]

Since Fiber is here - did you, as React team, even consider having render functions like:

class UserInfo extends Component {
  async render() {
    const apiData = await fetchUser(this.props.userId);
    return <div>{apiData.userName}</div>;
  }
}

Obviously, it's changing some core ways about how react is working.

There are few consequences about such approach:

• every render needs to be promise. (it'd be back-compatible tho)
• it'd require figuring out how loading state is shown up

I imagine whole new way you could write apps that rely on async api's:

class UserInfo extends Component {
  async render() {
    const apiData = await fetchUser(this.props.userId);
    return <div className={await fetchUserType()}>{apiData.userName}</div>;
  }
}

What do you think about it?

[Jessidhia]

Looks like a big footgun 🤔

Your component would re-download user data on every single reconciliation, and the component tree would be stuck waiting on your component to finish downloading every time.

[stephenkingsley]

I think if provide async render, you can do something fetch request abandon redux. And It will let your project store or state is messy.

[gaearon]

Please see #6481.

[maxjf1]

Your component would re-download user data on every single reconciliation, and the component tree would be stuck waiting on your component to finish downloading every time.

@Kovensky not necessarily, this is an development choice. I could for instance cache the request if i didn't need to redownload it

[gaearon]

This is exactly what we’re doing with Suspense. Please see second part of my talk: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html.

[rodinhart]

Suspense does handle this use case, but I'm looking for a value for fallback (in <Suspense) that will keep the "previous" DOM visible until all the promises have been resolve and the new tree can be rendered?