Adding Reusable State to StrictMode #19
Replies: 8 comments 36 replies
-
|
Is there any documentation for the offscreen API somewhere, such as a blog post or discussion post here? I'm also curious where this falls in the release schedule compared to Concurrent features and server components. Is this a "this feature is imminent so you should turn this on ASAP" or "this is something that will come eventually (more than a year) but you can start preparing for it now if you want" |
Beta Was this translation helpful? Give feedback.
-
To be clear, even if the feature was imminent, you could still keep Strict Effects off and not use the feature. But if you want to use the feature, Strict Effects help you verify that your component behaves as expected. (Similar constraints already apply to Fast Refresh.)
To give some background context, most of the code for |
Beta Was this translation helpful? Give feedback.
-
|
We have included it in demos before but we never gave it a name. The previous API used the There's a decent amount of work to prepare the feature for wide release but we've actually been experimenting with in production on Facebook dot com for quite a while. It's how we keep News Feed mounted in the background even if you switch tabs, but without slowing down the active route. |
Beta Was this translation helpful? Give feedback.
-
I'll emphasize @bvaughn's point here once again, in case someone skims over it in the original post: We rolled out Strict Effects across thousands of components with very little trouble. The few snags we did encounter were in some really complex library code that did lots of manual DOM manipulation. That's why we're confident that we can add this behavior to Strict Mode without imposing an undue burden on developers. Almost everything will just work. This "just work" theme is something you'll see us return to often when discussing React 18 and Concurrent React in general. In the past, we used to be super specific about what is and isn't concurrent "compatible" at a conceptual level. But we realized that by explaining each and every nuance in great detail, we were also coming across as pedantic about things that really don't come up that much in practice. We still need to explain them, because when they do occasionally come up, people need to know how to fix them. But we really just don't think most folks will have that many issues, and when they do the solutions will be relatively straightforward. That's been our experience over the past few years of testing. But we'll see if that trend continues! If we receive feedback that contradicts our findings, we may reevaluate and pick a different strategy. We're confident in our current plans, and we've put lots of thought and research into them. But nothing here is set in stone — that's exactly why we're starting these discussions. |
Beta Was this translation helpful? Give feedback.
-
actual TL;DR: #18 covers this already TL;DR: Reading this makes it sound like you already mentioned the following aspect in internal documents. When I originally read this I had to double check that Strict Effects will work slightly different than double-rendering due to effects having side-effects. Explaining that an effect consists of create and cleanup method and that you invoke create and cleanup in this mode might avoid some confusion. Given React.useEffect(function create() {
let cancelled = false;
fetch(url).then(data => {
if (!cancelled) setData(data);
})
return function cleanup() {
cancelled = true;
}
}, [])Strict Effects won't just result in fetching twice. Strict Effects will also call the cleanup inbetween double invokation to make sure that the cleanup actually cleans up the effect and doesn't leave some side-effects. What I mean is that one might think that Strict Effect means create();
+create();when it actually means +const cleanup = create();
+cleanup();
create(); |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that’s a great clarification. I edited that sentence, is it clearer? Feel free to suggest other wording changes please! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback, @eps1lon. This first doc used to show the example component and annotated sequence shown in the next doc (to clarify that) but there was concern we may be diving too deep too quickly and so it was moved to the second part. |
Beta Was this translation helpful? Give feedback.
-
|
Partial hydration named somewhere else really got me thinking. One thing I saw in the tests was hydration based on hovering. If I understand correctly, the upcoming Offscreen api is currently made for being able to unmount something and then remount it again with the same state it had before. But I'm wondering whether using it to "pre-render" components that haven't been rendered is also possible. I could see a router starting to render a page when a user hovers over a link to it. I guess you could do this already by making it invisible, but now with concurrent it seems like it would be possibly more preformant. This all is quite messy in my head, but I remember seeing useTransition with data loading to preload data for tabs not clicked on, but you wouldn't want to keep all state for a page in a router above the actual page. Pages tend to have very different state and state nested different components and so on. Ideally I think I'd want to: render hidden on hover, use isPending on the menu item if it takes a long time to load, and offscreen it again when clicking on another route. Guess my question is really, is Offscreen only for unmounting already rendered items or can it aslo be used to prerender things and how does all that tie into the other new APIs? |
Beta Was this translation helpful? Give feedback.
-
@acdlite this sounds like an awesome improvement for performing exit animation for two reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
For names, I throw Deferred into the ring. There's both a time and priority meaning to it, and it's a nice match with Suspend (which serves a related purpose). I'm not enough of a native speaker to know wether it's too technical of a term, though. |
Beta Was this translation helpful? Give feedback.
-
|
I like Deferred to. Kind of like a "do it later when you feel like" component. |
Beta Was this translation helpful? Give feedback.
-
Yes. We'd like to build first-class support for layout and exit animations into React, and solving things that aren't possible to solve in userland (such as delaying some state changes) will definitely be a part of that effort. It's not as simple as "the tree is entirely frozen" (some things could legitimately change mid-animation) but we have some initial thinking there. Concurrency helps with these problems, too. (We can render the same tree in different states and then interpolate between them, for example, or decide to include/omit individual state changes while animating based on heuristics.) This is a big separate topic and we're not yet ready to dive deep into it, but a lot of what we're doing now is in service of a future first-class Animation API. |
Beta Was this translation helpful? Give feedback.
-
|
Re: naming - we're still in the conceptual/research phase so we're really far out from landing on a name. Our approach is usually to start research based on first principles like "a component should be able to maintain state without being subscribed to data, and render at lower priority" and then build an API through exploring that idea. This may lead to a lot of different use cases that we may not expect, so the name for a particular feature naturally comes closer the end. |
Beta Was this translation helpful? Give feedback.
-
|
What about console.logs when reinvoking strict effects? Currently, React mutes the additional console.logs when rerendering within the StrictMode - would the same happen here? Note that I actually consider muting those console.logs having a negative impact on the overall DX. I find it too magical and I've already seen dozen of seasoned devs being tripped by this because they were not aware of this which lead to some serious hair pulling as the observed logs didn't match other observations they have made about the code execution at the same time 😉 If anything - I would switch the default and make console.log muting an opt-in through React DevTools. If you plan on muting them when reinvoking strict effects then probably even more people will start getting confused about this because this won't match a variety of other observable side-effects in the browser, like even the amount of requests in the Network panel of browser devtools. |
Beta Was this translation helpful? Give feedback.
-
|
React on Strict mode might tell the dev in the console that one of the invocations are going to be silent with a link to docs on how to make both visible. |
Beta Was this translation helpful? Give feedback.
-
|
Dan said over in #98 (comment) :
I'm not sure I saw this come up specifically previously. Does anyone have a reproduction, and if so, can we get it linked over in reduxjs/react-redux#1732 ? |
Beta Was this translation helpful? Give feedback.
-
|
I got very interested in why this has been broken so I've debugged this down. The problem is not that dispatching doesn't work (although you probably didn't mean exactly that) and it's not even because components are not subscribed - because they are. The problem is that the hooked up listener is a "proxy" listener: So what happens is that Provider gets notified about a store change - it should notify nested subscriptions but it doesn't because of the mentioned issue. And TLDR; lack of symmetry between setup/cleanup of an effect in the |
Beta Was this translation helpful? Give feedback.
-
|
Ooo, fascinating - great debugging work! |
Beta Was this translation helpful? Give feedback.
-
|
Nice! I looked at the code and tried to guess but you're right :) |
Beta Was this translation helpful? Give feedback.
-
Nice find, @Andarist! Lack of symmetry between create and destroy will definitely cause problems. |
Beta Was this translation helpful? Give feedback.
-
|
Should be an easy fix on the v8 branch. We might as well tweak it on v7 as well, even if it really won't have a meaningful difference there. |
Beta Was this translation helpful? Give feedback.
-
|
Framer Motion's <AnimatePresence>
{isVisible ? <motion.div exit={{ opacity: 0 }} /> : null}
</AnimatePresence>This animation is triggered by a However, a breaking change in React 18 is that Given this, how am I recommended to port this component to React 18? |
Beta Was this translation helpful? Give feedback.
-
|
Let's walk through the sequence without strict effects. I'll try to write up what confuses me. No Offscreen (no strict effects)function Router(url) {
return url === '/' ? <Feed /> : <Profile />
}
function Feed() {
let [toggle, setToggle] = useState(true)
return (
<>
<Checkbox value={toggle} onChange={setToggle}>Toggle child</Checkbox>
<AnimatePresence>{toggle ? <Child /> : null}</AnimatePresence>
</>
)
}
function Profile() {
return <h1>hi</h1>
}
Offscreen (no strict effects either)function Router(url) {
return (
<>
<Offscreen mode={url === '/' ? 'visible' : 'hidden'}>
<Feed />
</Offscreen>
<Offscreen mode={url === '/profile' ? 'visible' : 'hidden'}>
<Profile />
</Offscreen>
</>
)
}
function Feed() {
let [toggle, setToggle] = useState(true)
return (
<>
<Checkbox value={toggle} onChange={setToggle}>Toggle child</Checkbox>
<AnimatePresence>{toggle ? <Child /> : null}</AnimatePresence>
</>
)
}
function Profile() {
return <h1>hi</h1>
}
The point I am trying to make is that even without strict effects, in the second scenario, it seems like you're saying that going from Feed to Profile and then immediately back to Feed would cause us to see the exit animation. So that's the issue Strict Effects are simulating. It's not theoretical. "Show -> Hide -> Show" is an actual thing a user can do. We're not just double invoking out of principle, but to simulate what happens then. While it's true the feature itself is not ready yet, we've been using it in production for a few years, and it's very likely to ship soonish in the 18.x release cycle after 18.0. So we should probably think of a solution that would work with these constraints. That part about the current solution that seems dubious to me is that removing/hiding |
Beta Was this translation helpful? Give feedback.
-
|
@gaearon I think you're misunderstanding how AnimationPresence works. It's not when it gets deleted but when a special child of it is unmounted. (Unlike the built-in proposal we have for exit animations where the Presence component would be the one you delete.) Offscreen is actually in production in plain 18 in a special case. When a Suspense boundary rerenders using a sync/discrete update and that causes it to resuspend. The children go into Offscreen mode but it only affects useLayoutEffect. That's another distinguishing factor. You might want to use useLayoutEffect for animations for that reason. Note that for something like AnimatePresence you need the Offscreen (or Suspense boundary) to be a child of AnimatePresence to make this work. <AnimatePresence>
<Suspense fallback={null}>
<motion.div />
</Suspense>
</AnimatePresence>However, Offscreen/Suspense also immediately sets This is all details that would be so much easier with a built-in exit animation primitive which all this assumes will eventually be there. As for the DEV mode semantics. The idea is that it simulates hiding/showing. The idea is that an exit animation that immediately returns to the same state should be reversible. Similarly, an enter animation that immediately exits and then comes back on screen again should be reversible. So if your animation is reversible in both directions then playing enter, exit, enter in rapid sequence should yield the same visual effect. It's weird that this would always happen behind the scenes in DEV, and certainly makes DEV slower, but it helps flush out quirks upfront which is the purpose of the strict mode. As for modes, it's not fully flushed out yet but current thinking is a couple of modes:
Additionally these can be in another dimension be either in Temporary mode (it unmounts just useLayoutEffects, refs and Portals) or Aggro mode (it also unmounts useEffect for further resource savings). For the Offscreen case, I think you would want to replay enter animations (and log events like "visited this page"). Because it's conceptually the same as deleting the component. For the Out-of-viewport and Backgrounded cases, I think you don't want replay enter animations. My best idea for this case involves not replaying useEffects that didn't return destroy functions. However, I'm not sure how to deal with exit animations when you enter this case since there's no way to distinguish this case. When we add it we'll either have built-ins to expose some way to detect that case. |
Beta Was this translation helpful? Give feedback.
-
Hmm no I think I do get it — If I understand @mattgperry's situation correctly, the issue is that an exit animation plays (due to hide -> show -> hide triggering child cleanup), but really no animation should play at all. My point is just that it feels wrong to trigger exit animation when AnimatePresence itself is removed, since it's pointless — it's already too late. (Like you say, React won't wait.) So I was wondering if we can fix the extraneous show -> hide -> show animation by using a heuristic that an exit animation should only attempt to play when the child but not the parent AnimatePresence is removed. Since it can't possibly play if AnimatePresence is removed anyway. Although if it's reversible in the first place, then the problem is moot. |
Beta Was this translation helpful? Give feedback.
-
I bet Framer Motion already does something like that since otherwise nested AnimatePresence wouldn't work very well already. Similarly, you need something similar for enter animations since otherwise they would all play on initial mount instead of just the top one. I guess the question is, how does this heuristic work exactly and why doesn't it work anymore? We double invoke the entire tree as if it was mounted and unmounted at the root. As opposed to individual components, so it seems like it should keep working. |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes you’re right, if its the whole tree this shouldn’t be a problem (once I’ve rewritten to account for the possibility of remounting)
In 18 AnimatePresence is entirely broken but this has more to do with its use of rendering from mutable data sources. @Andarist has taken a stab at fixing this so I’m revisiting that discussion
I think this is basically what I was hoping to hear - I agree that Offscreen can be handled like an exit and that leaving the viewport/entering background state shouldn’t, and that there’ll be an API to distinguish these things when it comes to fruition. Thanks to you both for explaining this all with such detail, it helped me understand much better what’s going on and what’s planned. |
Beta Was this translation helpful? Give feedback.
-
|
I was looking for an exact definition or a document that describes what a Reusable State is, but I didn't find it. I read the documentation on Strict Mode and Discussion "18 How to support Reusable State in Effects" did not find an exact definition there. Which state exactly will be reusable. Is this a State created using useState and useRef? Or some other. |
Beta Was this translation helpful? Give feedback.
-
|
In other words, any |
Beta Was this translation helpful? Give feedback.
-
and useRef at least |
Beta Was this translation helpful? Give feedback.
-
Overview
Strict mode was released with React 16.3 as tool to identify coding patterns that may cause problems with React’s (then experimental) concurrent rendering APIs. Adding
<StrictMode>to a React application adds special behavior (only in DEV mode) to all of components it wraps around. For example, when running in “strict mode“ React will intentionally double-render components for in order to flush out unsafe side effects.With the release of React 18,
StrictModegets an additional behavior to ensure it's compatible with reusable state. When StrictMode is enabled, React intentionally double-invokes effects (mount->unmount->mount) for newly mounted components. Like other strict mode behaviors, React will only do this for development builds.Why is React adding reusable state?
There are multiple features we'd like to add to React that have the same constraint: a component needs to be resilient to being "mounted" and "unmounted" more than once.
The first such feature is already added — it's Fast Refresh. It's enabled by default in Next.js, Create React App, and React Native. With Fast Refresh, every time you save a file, your effects re-run. This means that if a component or a library breaks because of occasionally re-running its effects, it won't work with Fast Refresh well.
Other features we're building rely on the same constraint. For example, we are working on a new “Offscreen” API that will enable us to better support UIs like tabbed containers and virtualized lists and to make better use of new browser APIs like content-visibility. (It will also help with the pre-rendering optimizations the React Native team is working on.) But to get there we need to make changes to the way effects work.
Let’s say you have a component that gets rendered conditionally — for example, the current tab. If this component or any of its descendants have state inside of them, that state will be lost when the component is unmounted. Until now, the only way to preserve the state has been to “lift” it out into a higher component (or an external store like Redux).
The main motivation for the new Offscreen API (and the effects changes described in this post) is to allow React to preserve state like this by hiding components instead of unmounting them. To do this React will call the same lifecycle hooks as it does when unmounting– but it will also preserve the state of both React components and DOM elements.
This means that components may “mount” and “unmount” more than once.
When a component is hidden– whether it’s in a tabbed container or a virtualized list– it is no longer visible in the DOM, just like if it was unmounted (removed) from the DOM. It isn’t actually unmounted (because we want to preserve the state) but from a user’s perspective they are the same.
It wouldn’t make sense for an unmounted component to trigger some imperative code (e.g. to position a tooltip). The same is true for a component that’s been hidden. So React needs to tell the component that it is being hidden. How? By calling the same functions that it calls when the component is unmounted (either an effect cleanup functions or
componentWillUnmount).When a component get shown again after being hidden– it’s similar to being mounted again except that it will have all of its previous state. React will tell the component that it is being shown again by calling the same functions it calls on mount (either an effect or
componentDidMount).We've found that the majority of product code "just works" with this approach but some tweaks are necessary.
Opting out of StrictMode
If double invoking effects cause significant problems for your app, you can disable
<StrictMode>for it entirely until you're able to fix them. There is currently no way to keep the old<StrictMode>behavior—if you enable it, it will include double invoking effects.Related posts
For more information on supporting reusable state in StrictMode, see:
Beta Was this translation helpful? Give feedback.
All reactions