[Stoids]

Congratulations to the React team on the release! I've kept up somewhat with the development of these features since Dan first introduced some of the ideas at JSConf 3 years ago. It's interesting to see how the APIs have changed over time—I'm sure as a result of some tough lessons learned at Facebook.

As someone who has worked on large React projects worked on by multiple teams, I can see a lot of the value proposition being delivered in this release. I can already think of many places where I'll want to slot in the transition API.

I'm curious if the SuspenseList API is making the cut here or if it's still on the roadmap? I played with it a while back and thought it was very cool, albeit slightly niche perhaps.

The only part that's a bit of a bummer is the recommendation on using suspense for data fetching. I'm already itching to get rid of lots of if (loading) {} code that plagues many of our components and makes orchestration and re-use of them a bit more painful than we'd like. I see lots of power in the idea of suspense as a way to orchestrate various generic async operations, but it feels like they don't want us to build solutions on this abstraction unless we buy into some opinionated framework. I can't really tell my team "let's use remix now lol".

All that being said this is a tremendous step forward and I'm looking forward to seeing what problems the React team tackles next.

[danabramov]

>It's interesting to see how the APIs have changed over time—I'm sure as a result of some tough lessons learned at Facebook.

Oh yeah definitely. For history nerds, I've included a bunch of old (but relevant) PRs in the full changelog so that you can see the evolution. For example:

>Add useTransition and useDeferredValue to separate urgent updates from transitions. (#10426, #10715, #15593, #15272, #15578, #15769, #17058, #18796, #19121, #19703, #19719, #19724, #20672, #20976 by @acdlite, @lunaruan, @rickhanlonii, and @sebmarkbage)

See https://github.com/facebook/react/blob/main/CHANGELOG.md. I also wrote a thread about some of the lessons learned: https://twitter.com/dan_abramov/status/1402927593406582787. Might make a full-fledged recap post at some point.

>I'm curious if the SuspenseList API is making the cut here or if it's still on the roadmap? I played with it a while back and thought it was very cool, albeit slightly niche perhaps.

We've postponed it because there were some gaps we need to figure out. But it's likely coming in one of the minor releases.

>I see lots of power in the idea of suspense as a way to orchestrate various generic async operations, but it feels like they don't want us to build solutions on this abstraction unless we buy into some opinionated framework. I can't really tell my team "let's use remix now lol".

Hear, hear. The reason we suggest that is that implementing refetching in the data layer is currently too challenging. Relay implemented it, but it is pretty opinionated about other things so it's easier for Relay. Next.js doesn't currently support refetching for getServerSideProps anyway, so it wouldn't be a regression. But for a generic non-framework API, this feature is very important. We're working on a cache mechanism that might solve this, but it's work in progress and it's hard to provide guarantees that it'll ship in the same form as it is now. We just don't have all the answers yet.

[Stoids]

Thanks for the links! Will certainly check them out, might even send me down memory lane a bit when I was first reading about these. Would love a full-fledged recap at some point—it's really interesting getting insight into the the internal mechanics of the problems my UI framework solves for me in my day-to-day. I always come away feeling more informed when you write something, but you've earned a long break after this release, so no pressure!

I hear you on the data fetching and always appreciate your teams' cautious approach. It gives me a lot of confidence in the APIs you all end up landing on, and I appreciate the focus on backwards compatibility and incremental upgrading as opposed to shipping out the first iteration of a cool idea that comes to mind. I know just enough about React to probably shoot myself in the foot with this type of stuff, but add in the idea of concurrency and all that likely falls over.

I think the story here with Relay and GraphQL is really awesome. I hope the Relay team has an article in the future showing off some of the possibilities—I think it makes a really strong argument for itself in conjunction with these features, even taking into account the restrictions you mention. Showing how some of these features flesh out in a more complete framework would be helpful in framing them in a vacuum. Or maybe I'll stop complaining and explore and write something myself!

[charlie_hebert]

If your team's using React Router, there's an upcoming release that aims to address the problem you describe (taken from Remix, as it's by the same guys): https://remix.run/blog/remixing-react-router

[Stoids]

Thanks for the link! Hadn't seen that release, looks promising. I think this could definitely work for some of our newer apps that haven't fully bought into GraphQL yet. Not sure if the loader / action prop callbacks will be sufficient when you start getting into more complicated GraphQL use cases around caching. Haven't played with it though, so might be wrong! Good to see that these will already be in place for the community to leverage.

[swyx]

jsconf iceland was 4 years ago, not 3 years :) been a looooong wait https://youtu.be/nLF0n9SACd4