-
Notifications
You must be signed in to change notification settings - Fork 47.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[joke] its not fine #28524
[joke] its not fine #28524
Conversation
Comparing: 64f354c...294322c Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
cd011b8
to
294322c
Compare
What would be needed to enable cross-renderer contexts instead? |
What if it’s installed globally? |
@markerikson this is a cheeky joke. Obviously we wouldn't land this. The issue to track that feature request is still #13332. It's unclear how to implement support for that feature, but we've been talking to @drcmda about options for third-party renderers. When we have more info, we'll update the issue. |
Spent some time investigating. Regardless the versions would have to be in perfect lock-step but that turns out to be a requirement anyway so that's fine. The proper solution that behaves like a Portal should forward the value during a concurrent render into the child. Meaning it should actually be part of the same render phase. That's not just an issue with Context but Props too. Ideally it shouldn't have to commit the outer root before forwarding the inner values. Additionally, it's not just Context that is contextual. There's internal contexts and for example if you Suspend in the child renderer outside a Suspense boundary, it should affect the parent render. E.g. a startTransition in the parent should stall or . That's the proper implementation. It's very difficult, and may require compromising on performance for everyone, but it's not impossible. Realistically, that amount of work, I don't see that getting prioritized any time soon. There's just way more pressing issues. The smaller version of converting an outer render into a sync secondary render after commit, with no Suspense or Transition integration etc. is easier. That might be "good enough". However, there's the question of whether encouraging thinking of these is a single root given that new features won't work seamlessly anyway. So it might've been "good enough" before but not "good enough" in the future. There's also a whole other approach of creating fake DOM nodes using the DOM renderer. |
hello @sebmarkbage we hacked the context via its-fine by injecting it https://github.com/pmndrs/its-fine/blob/main/src/index.tsx#L217-L234 a renderer must wrap its contents into a bridge. this of course is tapping into fiber internals. we hacked suspense as well as error boundaries with a throw. now the renderer can suspend the dom while loading assets, or be caught in the dom if it fails. we would be very happy if there are official means. export function Block({ set }) {
useIsomorphicLayoutEffect(() => {
set(new Promise(() => null))
return () => set(false)
}, [set])
return null
}
function Canvas(...) {
...
const [block, setBlock] = React.useState(false)
const [error, setError] = React.useState(false)
// Suspend this component if block is a promise (2nd run)
if (block) throw block
// Throw exception outwards if anything within canvas throws
if (error) throw error
...
root.current.render(
<Bridge>
<ErrorBoundary set={setError}>
<React.Suspense fallback={<Block set={setBlock} />}>{children}</React.Suspense>
</ErrorBoundary>
</Bridge>,
) |
cheeky idea for blocking this import