React 18 Update (August 20th) #83
Replies: 7 comments 10 replies
-
|
Just wondering why "in some cases native events cannot be replayed"? What was the issue? |
Beta Was this translation helpful? Give feedback.
-
|
As one example, let's say you have a tree like this, where there's a mix of React event handlers and native event handlers, and assume that we Suspend at "c" during hydration: <div id="a" onClick={() => console.log('a')}>
<div id="b" ref={n => n && n.onclick = () => alert('b')}>
<Suspense>
<div id="c" onClick={e => {console.log('c'); e.preventDefault();} />
</Suspense>
</div>
</div>When you click on "c" before hydration, we will attempt to hydrate down to "c", but the content suspends. So we queue the event to replay after the content resolves. But when we replay the event later, we can't replay the native event handler for "b", so you miss that event. To handle that case, we could fire all of the events down to the boundary in the first step. But that would result in unexpected cases where the event below interacts with the bubbling semantics like calling |
Beta Was this translation helpful? Give feedback.
-
|
This is very interesting, thank you so much for explaining it so clearly Ricky! |
Beta Was this translation helpful? Give feedback.
-
Any specifics on what / how you're planning to test this out? Related, I just posted a question about |
Beta Was this translation helpful? Give feedback.
-
|
@markerikson that PR and discussion is a great start! We have a team meeting early next week to kickstart picking up |
Beta Was this translation helpful? Give feedback.
-
|
this is a great update @rickhanlonii! thanks so much for making the time to present your progress on these projects and what to expect 🙏 I have a question about React Conf 2021. Do you see a way that you'd like to utilize those of us in this group? More specifically, are there React 18 topics that you hope folks in this group might speak on? |
Beta Was this translation helpful? Give feedback.
-
|
That's definitely an option we're discussing. The plans are not final, but once they are, we'll share an update and how to get involved! |
Beta Was this translation helpful? Give feedback.
-
Will the desired behavior be configurable somehow? At which level? The |
Beta Was this translation helpful? Give feedback.
-
|
It's configurable in the sense that if you want the old behavior, you could add a Suspense boundary that throws in the fallback, or if you want to show a fallback and start streaming immediately you could add a boundary. Do you have a use case in mind? This change will be |
Beta Was this translation helpful? Give feedback.
-
|
No - no specific use case comes to my mind at this time. It's only that the previous behaviour was helping catch users potential problems (not including a suspense boundary) which seems a common enough problem. I guess that allowing the new behaviour without changing the old one would require some new API/option somewhere, so maybe the proposed change is preferable in the end - to keep the API surface smaller. It's just a general question about this change - maybe best to wait for the final writeup about this though. I'm missing two points:
|
Beta Was this translation helpful? Give feedback.
-
We will still warn on the client if you forget a boundary.
We start streaming when we have a tree to stream. The recommendation is to put a Suspense boundary at the root of your app, so we'll start streaming the shell of the app immediately, and then the rest of the content as it comes in. The only exception to this in idiomatic apps is when you suspend waiting on data to render the head, but that's uncommon.
Right now we only warn on the client, and not on the server. |
Beta Was this translation helpful? Give feedback.
-
If we start adopting this hook, what are some of the testing strategies for library maintainers to validate the support of concurrent. I guess those existing tests coverage (within the lib) may not cover the expected use cases for it. (Apologize, if this question was been asked before) |
Beta Was this translation helpful? Give feedback.
-
|
It's tough to answer this in the abstract because I wouldn't expect tests to need updated unless they were deeply testing implementation details. Do you have a concrete example I can look at? |
Beta Was this translation helpful? Give feedback.
-
What will the update strategy be from the short-term to the long-term solution? Will it be possible to feature-detect this at the library level and handle both React 18 version ranges at the same time? If yes - how much of a problem will it be to support both "modes" at the library level? I'm very excited to learn about what you come up with in this area! |
Beta Was this translation helpful? Give feedback.
-
|
It's too early to say for sure what that will look like, but Stability is one of our Design Principles so we will work to make it as easy to switch over as possible. |
Beta Was this translation helpful? Give feedback.
-
|
I know I saw some recent discussion on the "stylesheet insertion" topic, but I'm having trouble locating where that was. Can someone link the relevant issues/PRs here for reference? |
Beta Was this translation helpful? Give feedback.
-
|
There was some discussion here #43 We'll be posting a summary of the space when we summarize the short-term escape hatch. |
Beta Was this translation helpful? Give feedback.
-
Overview
We want to start sharing semi-weekly updates on what the React 18 team is working on to give some context of what’s in progress and top-of-mind for the team. Below are the projects we’re currently working on for React 18.
Feel free to ask questions, but don’t worry about understanding all of the details for each project. These are in-progress projects so the details are summarized, and we’ll post detailed information once each project is finished.
useMutableSource
In Concurrent React for Library Maintainers, we shared that most of the libraries that we expect to be impacted by concurrent rendering are libraries that interact with external state. We’ve had a few productive discussions with data and state libraries like Apollo and Redux, and we’re now working to finalize
useMutableSourcefor React 18. This new API will allow these and other libraries to add “level 2” support (as defined in the linked post) for concurrent rendering. The first milestone we’re working towards is to try this Hook in Apollo and Redux, and ensure it’s sufficient for their use cases. After it’s proven out in this collaboration, we will likely recommend other state management libraries to adopt it.Stylesheets
We also shared that stylesheet libraries may need to adjust when exactly they insert the style tags. We’ve been researching the state of stylesheet library implementations and considering different tradeoffs. Based on this research, we’ve decided to provide two solutions: a short-term one to unblock React 18 that libraries will be able to use immediately, and a long-term one with better characteristics that will require a bit more work for libraries to adopt. The long-term solution is not specific to stylesheets, and it will support other head tags like
titleandmeta.We will publish an RFC for the long term solution soon. However, this proposal will likely not make it into the first React 18 release. This is why we’re also working on an escape hatch that style libraries will be able to use for 18. We’ll be posting details about both the long-term and the short-term solutions soon.
Event Replaying
We’ve shared that React 18 introduces a concept called “selective hydration” which is a feature that allows React to prioritize hydrating parts of the tree that the user interacts with. We also have a feature called “event replaying” where we capture user events that happen during hydration in parts of the tree that have not fully hydrated, queue them, and the “replay” them once the tree hydrates.
We found some flaws in this approach. One problem that we don’t have a satisfactory fix for is that in some cases native events cannot be replayed, even though React events can be. After discussion, we’ve decided to not do event replaying (at least, for now) and instead focus on selective hydration. In the new approach, we will add a capture phase listener which will attempt to synchronously hydrate the tree to the target. If the hydration is successful, the events will be fired. If it fails (e.g. suspends), then we will stop propagation of any events into the unhydrated tree, including native events.
When this works (which is the majority of cases, using idiomatic patterns), it will allow events to be fired earlier so the page feels more interactive. When it fails, then it will perform the same as the app does now, where events that fire before hydration get ignored. We’re working on these changes now and will have them live in the alpha shortly.
Uncaptured Suspending
Currently, when a tree suspends to the root and we don’t find a Suspense boundary to capture it, we will throw. In some cases though, this is not the desired behavior. For example, with server-side rendering, you may want to suspend waiting for data to populate the
head, but there’s no way to add a Suspense boundary inhead, so you want to be able to wait for data without a boundary.In those cases, the desired behavior is that when you suspend without a boundary, React should delay committing until we have all of the data to finish the render. This means on the client, we won’t show anything until we resolve (similar to a transition). On the server, we won’t start streaming the response until we resolve. To help catch issues where this is unexpected, we’re adding a warning.
These changes will be live in the alpha shortly.
ReactConf
You may have seen the CFP for ReactConf tweeted last week, which announced that ReactConf 2021 will be a virtual conference November 9th. We’re still planning out the structure and content of the conference, which will be React 18 focused. We plan to feature the Working Group heavily and recognize all of the work you all have done here, so stay tuned for updates!
Beta Was this translation helpful? Give feedback.
All reactions