docs: Routes are wrapped w/ Activity in Cache Components #85309
Conversation
| useLayoutEffect(() => { | ||
| const el = document.getElementById('portal-root') | ||
| setContainer(el) | ||
|
|
||
| // Hide the portal container when this component is hidden by Activity | ||
| return () => { | ||
| if (el) el.style.display = 'none' | ||
| } | ||
| }, []) |
There was a problem hiding this comment.
I'm not sure this works for all cases. I've tried this solution and it doesn't seem to work.
Plus, is this being proposed as a workaround or as an actual solution? I think this should be handled at the framework side since users don't expect Next.js to hide their previous route with Activity
I think Next.js should either hide portals on navigation or revert #84923 and make routerBfCache optional again, not attached to cacheComponents
For example, I'd like to use cacheComponents but not bfCache until this behavior is fixed. They shouldn't be under the same flag
There was a problem hiding this comment.
I'm not sure this works for all cases. I've tried this solution and it doesn't seem to work.
I tried a few variations on my React codesandbox and it worked though. https://codesandbox.io/p/sandbox/react-dev-forked-626mp3?file=%2Fsrc%2FSidebar.js
But I can imagine in some cases the code controlling the container might be handled by UI library code, and not the developer code necessarily.
Plus, is this being proposed as a workaround or as an actual solution? I think this should be handled at the framework side since users don't expect Next.js to hide their previous route with Activity
I think Next.js should either hide portals on navigation
This is a React Activity + Portals limitation. Next.js might separate the config option, but the root issue will still be there.
Part of the reason I haven't merged is to collect this kind of feedback, but also because today we'll have time to discuss this. I'll try to post an update when I know more.
There was a problem hiding this comment.
Thanks for looking into this and sharing the codesandbox example.
I agree this should also be looked into on React side, so I’ve also opened an issue upstream to track this:
facebook/react#35000
That being said, I'm not sure this is a bug or expected behavior for the Activity component.
Manually hiding the portal container can work when we own the code that manages the portal target.
The challenge in this case is that developers aren’t explicitly choosing to wrap routes in Activity. Next.js now applies it automatically when cacheComponents is enabled, and there’s currently no way to opt out of the hidden-routes behavior without also disabling component caching entirely.
If I were using Activity directly in my code, I could choose not to combine it with portals or implement a visibility-aware container. But since this is happening inside the framework, we don’t have control over the portal target or lifecycle, and some libraries manage their own portal containers. This makes the workaround impractical or impossible for many real-world setups.
There are also other side-effect concerns documented in React’s Activity docs. Some apps may want component caching but not hidden-route behavior exactly because of these trade-offs.
That’s why I believe cacheComponents and the routerbfCache should ideally be separate flags, so users can adopt one without implicitly opting into the other.
Happy to help test any changes on either side. Thanks again for taking the time to discuss before merging.
There was a problem hiding this comment.
I'll move the note about Activity being used in Routes to new Cache Components entry, it makes sense to be there, there's already a lot of info on Linking and Navigating, and this only happens under Cache Components.
Regarding the portals, I don't know yet, so I'll will remove its mention - this is not a Closes: XYZ PR either, and we need to mention that Activity wraps routes in Cache Components. It does feel like it is more in React's field at the moment. Thanks for opening an issue over there.
No description provided.