[Umbrella] Releasing Suspense #13206
Comments
Isn't this already exposed? |
|
I meant remove the |
|
I am looking forward to open source of the unnamed code-splitting library 💯 |
|
What does it mean [Umbrella]?🤔☂️ |
|
This mean, it's a feature which impact several projects/packages/tools. |
|
@ghoullier I see, Thank you so much! |
|
Hey @acdlite, just a question about how to best prepare for this. Not asking for / expecting any kind of timeline, but wondering: Are you currently expecting these features to drop into React 16 and be easy to adopt incrementally, like the new Context API that landed with 16.3? Or are you thinking it'll be something that pushes React to v17 and require more work to adopt? Asking because I'm working on a roadmap that crosses over significantly with pretty much everything on your list and am trying to work out how to best deal with that. Also do you have any tips on how to best prepare (in terms of code written today, that wants to be future compatible with these improvements to React) - polyfills / techniques / etc? (apologies if these questions are answered elsewhere and I've missed them) |
|
Adding another question to @JedWatson's questions:
Thank you! ❤️ |
|
IMO, they will provide a blog post like before before it's been landed. And I think you don't need to prepare too much because there is no breaking change(it does have many features that maybe would seems different/conflict with current practices, like redux fetch with suspense, but there will be a codemod or easy encapsulation to do this, you know, fb has 3W+ components). And if you watch the talk of @acdlite (about ssr suspense in ZEIT) and @gaearon (about client suspense in iceland), you will know you don't need to worry about too much and it's not invasive. By the way, you can just search the key 'Umbrella' in the repo and you will find more info like #8830 and #12152
IIRC, this is a misoperation? |
|
@JedWatson This comment helped me understand what a developer must do to help ensure that their application's are async safe. |
|
I'm working on rolling out the suspense module and new APIs in facebook. In case @acdlite is busy with something else, I'd like to share some of my thoughts of our experience in facebook and answer some questions of @JedWatson.
I'm not sure if it will come with React 16 or 17. According to the React team, it's likely to be released before the end of this year, which depends on how well it runs in facebook and how the related API is ready or not. But code-wise, I'm happy to say that it would be easy to adopt, because we've been experimenting for quite a while in facebook. The suspense feature will still work for the existing codebase. But with additional changes (like async rendering), you'll have more bonus that the new feature will bring you.
I'd say the migration is rather incremental and progressive. Like @NE-SmallTown said, we don't want to introduce any breaking changes. That would also be painful to roll out to facebook because we have a so large codebase. But so far, the roll out has been smooth and doesn't require you to do additional changes. |
Incrementally. Always incrementally :) Otherwise there's no way we'd be able to ship this at Facebook. Here's what I'm expecting:
*In sync mode, Suspense will work without any changes to your existing components. At one point we thought we might require So the idea is that users will start migrating to Suspense even before they're ready to migrate to asynchronous rendering. Then once a subtree is ready, they can opt-in by wrapping in For new apps, though, the story is different: go async by default. We'll introduce a new root API (a replacement for There will be an awkward period after the initial release where many third-party frameworks (Redux, Apollo, React Router...) may not work properly in async mode. That might hurt adoption for a while. But the idea is that the new features will be so compelling that it won't take long for libraries to either adapt or be superseded by an async-compatible alternative.
Wrap everything in |
Apollo doesn't do awkward - we'll be ready! 🕺😳 Seriously though, we ❤️ all things React, so making sure we're in-line with these changes for the initial release is not only a high priority, but it's also something we're super excited about! Thanks for all of your amazing work on this @acdlite! |
|
I'll chime in and say that the Redux team is working on async compat for React-Redux. I laid out a potential roadmap at reduxjs/react-redux#950 . TL;DR:
We'd appreciate more eyes on our WIP, and hopefully people can give us some more feedback and discussion on how they're looking at using Redux with React Suspense and async rendering so we can make sure use cases get covered properly. We're also hoping to have some more discussions with the React team about exactly what constraints we need to work with, and it'd be helpful if we could get some sample apps that would let us see what problems we need to solve for all this to work correctly. |
|
looking forward to the release of Async rendering and Suspense |
|
@acdlite Also question about suspense and async rendering. I assume it can be trickier to write react code with suspense and async rendering (maybe due to some new API or other constraints), and for those who don't need it, why force them to use react in a new way? And not allow them to code in react the way they do now? |
Have you had a chance to watch the second half of my talk? I'd say quite the opposite — it's way less trickier to use suspense for data fetching than anything else (including Redux, local state, or some other library). |
|
@gaearon I haven't. I was speaking more in theory. Imagine there is already set of people who know react. If people don't need the feature of async rendering and suspense, why force them learn "new" react? Especially if the "new" react is tricker to use? But: I am not well informed so I might be wrong say about the "trickier" part - I am just sharing some of my thoughts :). In a way I am saying if 10% of apps need the feature of Suspense and async rendering, why in those other 90% cases force people to learn "new" react? But again I might be wrong, since I didn't gather much info about suspence and async rendering yet. |
|
I think it's hard to have a conversation if you haven't looked at my demos yet. To be clear: there's no "new React", these features don't break any existing patterns 🙂. They are additive. You don't need to write code in a completely different way to use those features either — although some of them only work if you use modern lifecycle methods. While this is not directly related to your concern, I disagree they're "trickier to use". I think suspense is much simpler to use than any other loading mechanism that currently exists. That's the reason I'm so excited about it. But again, you don't have to use any of the new features if you don't want to. Old patterns will keep working. I really do recommend watching my talk. I'm sure this will make a lot more sense once you see these features in action. |
Thanks for feedback Dan. Yeah that is how I thought, I suppose if people don't need those features they should be able to write the way they used to before those features were added. good luck. |
|
Hey Dan(@gaearon), I am not nitpicking but want to figure it out. Above you said:
Which would suggest that I can code in new React the same way I did in "old" React, e.g. I could use the life cycle methods in the same way, etc. right? However, here, bvaughn says that getDerivedStateFromProps (or componentWillReceiveProps) could be called many times for one update, hence his solution not to fetch data inside it. So my question is, after all, it does seem we can't use the new React in exactly the same way as before right? Because AFAIK in current react componentWillReceiveProps doesn't get called many times for one update, isn't it? |
|
@Giorgi-M : yes, the lifecycle methods are changing, but the point is that Suspense itself is an opt-in feature. All your existing React render methods and React's rendering behavior will work as-is. However, if you opt in by adding an |
|
@Giorgi-M |
|
@markerikson So you say that what bvaughn said here, that getDerivedStateFromProps can be called many times for one update, is not necessarily the case, if I haven't enabled the ps. bvaughn also didn't mention the optionality of that in the linked thread, hence it raised my suspicion. |
|
Should a method for enqueueing asynchronous updates (e.g. From my understanding, any updates for fibers in async |
|
It’s in the check list for the time slicing umbrella. |
|
MobX is a tricky case because it diverges from our direction. We want it to work but we can't make it benefit from features built on the opposing principle. Like, there's no amount of magic that can make an approach fundamentally taking advantage of immutability ("we can render two versions of state independently") fully compatible with an approach fundamentally built on mutability ("changing this property immediately propagates"). I think the most we can count on here is not breaking the apps using it, which we'll be trying our best to do during the community rollout phase. But there's nothing we can do to make it benefit from new features that are built on (and enabled by!) the very opposite principle. That's the nature of picking a tradeoff. That said, in practice it depends on how much mutation is happening and at what stage. E.g. Relay happens to rely on mutation in its implementation details today, and although technically it's breaking the rules, it works fine at scale because its updates aren't super common (mostly network responses), and we have some fallback mechanisms to recover from failures. We'd like to offer some APIs for mutable stores to integrate better with React, first with deopts like |
|
As for a broader question, there is definitely a lot the community can do to help once we figure out the full upgrade story. I realize there's been a lot of annoyance with us not publishing some kind of "upgrade guides" earlier, but the whole point is we don't know the full story yet and we're still changing it so that it makes more sense. We don't want to churn people without a really good reason. I'm literally writing an internal guide now that we'll be using to migrate legacy surfaces to Concurrent roots, even the ones relying on Flux and mutation. We'll see if that goes well. Once we try those out, we'll use them as a basis for the open source guides. We hope to publish this information together with a release candidate, at which point we'll rotate fully to supporting open source libraries and helping them overcome any difficulties and common issues with migration. At that stage, we expect to gather some common recipes, and we'll definitely welcome (and need!) the community's help to propagate the knowledge and common solutions through the ecosystem. Although, like I said, a bulk of our current work is to make as much as possible just work out of the box — at least until you start using new features. Then you get to decide whether these new features are worth it, both as an application user and as a library author who's considering whether to invest some time in following the rules better. |
|
Btw, @rickhanlonii updated the time slicing demo (from the original JSConf Iceland talk) if you wanna play with it :-) as you can see some APIs have changed but they should make a bit more sense now (figuring out the right APIs and heuristics was a large part of the effort). #21401 (keep in mind the demo is not representative of the most efficient way to draw a chart per se, but shows some of the benefits we want to unlock in general for arbitrary component trees) |
This is in progress. We've tweaked and unprefixed some APIs (for the experimental channel only). #21488 |
|
@gaearon That's awesome! Does that mean a stable release with these things is coming soon? Will this be React 17.1? |
|
We are getting closer to the first release that would have an actual number version on it. It will be tagged as an alpha. Like always, we’ll announce it on the blog. A stable release is going to take place at least several months after that since we’re going to work closely with the ecosystem and it will take some more time to fill in the gaps. Sorry this is brief, preparing the communication for this is another part of the team’s ongoing work. |
|
|
Yesterday, we published The Plan for React 18. tldr:
React 18 will include a lot of foundational work for Suspense. This includes a brand new streaming server renderer which uses the To reflect the current roadmap, I have updated the initial post in this thread. It shows the work we have already done over these years (most checkboxes correspond to multiple months of work), and the remaining work is grouped by the release timeline. |
|
Additionally, I'd like to share this thread from @rickhanlonii reflecting on the journey to React 18 alpha. I hope it provides some insight on why these things are taking time and we could not get this Alpha out earlier. |
|
Hi! I'm trying to upgrade from the nightly version to alpha but I found |
|
Yes, the Cache API is still more experimental than the rest so you’ll need an |
|
I know that removing |
|
We have not made a decision on this yet. We will include information about any deprecations or removals in future blog posts. |
|
What would happen if a library uses the new APIs like |
|
It won’t crash but it also won’t get treated as a transition. Just a regular state update. |
|
Wrote some updates on what we're working on and the state of different pieces. It's about React 18 overall but some parts there relate to Suspense: reactwg/react-18#98 (comment) |
|
I've updated the umbrella to document the current progress. There is nothing more blocking the initial React 18 release, so we've released the last call for feedback: |
|
We've been making some changes to the strategy, in particular, to avoid the need for "forked" IO libraries like |
|
@gaearon is this new API superseding the Suspense cache ( |
|
I think we’re not super clear yet on whether Cache will be moving forward or not, but this API could potentially work together with it in the future. |
|
This might be outdated question after v18 release, but I wonder we don't need using loadable-components library for using Suspense in SSR? |
and others
Let's use this issue to track the remaining tasks for releasing Suspense to open source.
Last updated: March 24, 2022
Blog post: The Plan for React 18
Completed: React 16
<Suspense>withReact.lazyfor client-side lazy loadingCompleted: React 18 Alpha
<Suspense>quirks: Previously, effects would fire inside a suspended tree too early. For example, you would see an effect from a component that's still hidden behind a placeholder. Now effects will run only after the content has been revealed. We expect this to fix existing application code bugs.useLayoutEffectcleanup (same ascomponentWillUnmount) on "hide", anduseLayoutEffectsetup (same ascomponentDidMount) on "show". We expect this to fix existing application and library code bugs.<Suspense>on the server no longer throws: It used to be a hard error to render<Suspense>in a tree on the server. Now, for the old server renderer, it silently emits the fallback (and lets the client try to render the content instead). This shouldn't affect existing apps because previously it was not possible to render<Suspense>on the server at all.startTransitionlets you avoid hiding existing content even if it suspends again. This is useful to implement the "show old data while refetching" pattern with minimal code.React.lazyworks with SSR out of the box.<Suspense>boundaries to stream the page HTML in visual chunks.<Suspense>boundaries to hydrate the page in chunks, improving responsiveness.<Suspense>boundaries.react-fetchandreact-pg.Completed: React 18
react-dom/unstable-fizztoreact-dom/server.<Suspense>on mismatches instead of patching up the tree.onRecoverableErrorto gather production reports about SSR mismatches.Features that may or may not appear in 18.x
<SuspenseList>lets you declaratively coordinate the order in which<Suspense>nodes inside will reveal.<Suspense>boundaries (not final naming): A way to specify that you'd like React to ignore this boundary during initial render (as if it's not there), unless React is forced to hide existing content. We sometimes call these "ugly spinners" or "last resort spinners". This use case might seem a bit exotic but we've needed it quite a few times.unstable_avoidThisFallback<Suspense>for CPU-bound trees (not final naming): A way to tell React to immediately show a placeholder without even trying to render the content. This is useful if you have an expensive tree inside. This use case is unrelated to network — it's about showing a spinner for some tree that takes a while to render. See Suspense for CPU-bound trees #19936.unstable_expectedLoadTimeReactDOM. unstable_scheduleHydrationReact 18.x (post-18.0): Suspense for Data Fetching
All of the above changes are foundational architectural improvements to
<Suspense>. They fill the gaps in the mechanism and make it deeply integrated with all parts of React (client and server). However, they don't prescribe a particular data fetching strategy. That will likely come after the 18.0 release, and we're hoping that to have something during the next 18.x minor releases.This work will include:
react-fetch, which is a lightweight and easiest way to fetch data with Suspense.<Cache>which will likely be the primary recommended way for third-party data fetching libraries to integrate with Suspense. (For example,react-fetchuses it internally.)The text was updated successfully, but these errors were encountered: