You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The intro of this exercise explains the problem of requesting resources, namely waterfall. Then proceeds to explain the existing behavior that we could easily create a waterfall situation and how to potentially fix or workaround the problem.
The problem is that the behavior that is explained in the video is not present in [email protected], which is the most stable release since last December. In this major release introduces a new improvement to Suspense, namely "pre-warm". Please read the official document to find the information about the behavior, I don't want to risk misunderstanding (an already hard to explain behavior) here. From what I know there have been some back and forth implementations and improvements of this behavior(in React<=18, it was one behavior, then in React RC0, it was another one, and finally in React RC1, it is the behavior that they decided to pick it into the React major release 19, facebook/react#29898 (comment).
To quickly see the difference, here are some examples:
I forked this example project from React document. But I adjusted the delay the make it more obvious(getBio() for 3000ms and getAlbums() for 1000ms). When clicks an "Open the Beatles artist page" button, will render which renders that will get artist bio resources and that will get album resources. However, the behavior is not the same in each React version.
What will happen is, when attempts to render for the first time, it will request for a bio resource which is not yet there, will trigger suspense, then will immediately commit fallback at the root.
Immediately after committing a fallback at the root, React "will schedule another render for the siblings in order to "prewarm" the lazy requests in that tree while the tree is still suspended", (facebook/react#29898 (comment)), which eventually will cause another suspense to occur from rendering (requesting album resources).
After waiting around 3000ms, all resources will be resolved, causing React to render again with a complete data.
The behavior is exact same issue as described in the video(you will see 2 fallbacks and waterfall requests. It will display the root fallback while waiting for getBio() for 3000ms, then will display another fallback while waiting for getAlbums() for 1000ms)
I think the behavior is worth more attention and exploration and I couldn't wait it to be covered in the course.
The text was updated successfully, but these errors were encountered:
The intro of this exercise explains the problem of requesting resources, namely waterfall. Then proceeds to explain the existing behavior that we could easily create a waterfall situation and how to potentially fix or workaround the problem.
The problem is that the behavior that is explained in the video is not present in [email protected], which is the most stable release since last December. In this major release introduces a new improvement to Suspense, namely "pre-warm". Please read the official document to find the information about the behavior, I don't want to risk misunderstanding (an already hard to explain behavior) here. From what I know there have been some back and forth implementations and improvements of this behavior(in React<=18, it was one behavior, then in React RC0, it was another one, and finally in React RC1, it is the behavior that they decided to pick it into the React major release 19, facebook/react#29898 (comment).
Because of the new behavior in Suspense. If I start the exercise "06/01/problem" in playground, without any fixing or editing, the behavior is already correct(there is no waterfall request, the app makes get-ship and get the ship image request at the same time) because, in the exercise, it is React 19, https://github.com/epicweb-dev/react-suspense/blob/main/package-lock.json#L6947 and https://github.com/epicweb-dev/react-suspense/blob/main/package.json#L51.
To quickly see the difference, here are some examples:
I forked this example project from React document. But I adjusted the delay the make it more obvious(
getBio()
for 3000ms andgetAlbums()
for 1000ms). When clicks an "Open the Beatles artist page" button, will render which renders that will get artist bio resources and that will get album resources. However, the behavior is not the same in each React version.On React 19, the most stable: https://codesandbox.io/p/sandbox/react-dev-forked-new-suspense-r2tvpq.
new-suspense.mp4
What will happen is, when attempts to render for the first time, it will request for a bio resource which is not yet there, will trigger suspense, then will immediately commit fallback at the root.
Immediately after committing a fallback at the root, React "will schedule another render for the siblings in order to "prewarm" the lazy requests in that tree while the tree is still suspended", (facebook/react#29898 (comment)), which eventually will cause another suspense to occur from rendering (requesting album resources).
After waiting around 3000ms, all resources will be resolved, causing React to render again with a complete data.
On React 19.0.0-beta-94eed63c49-20240425, https://codesandbox.io/p/sandbox/react-dev-forked-old-suspense-95kmkx.
I guess it was same version at the time of recording the video.
old-suspense.mp4
The behavior is exact same issue as described in the video(you will see 2 fallbacks and waterfall requests. It will display the root fallback while waiting for getBio() for 3000ms, then will display another fallback while waiting for getAlbums() for 1000ms)
I think the behavior is worth more attention and exploration and I couldn't wait it to be covered in the course.
The text was updated successfully, but these errors were encountered: