Add ref to Fragment (alternative) #32465
Conversation
github-actions
bot
added
the
React Core Team
jackpope
force-pushed
the
fragment-refs-alt
branch
from
fb008d4 to
87d09a8
Compare
jackpope
force-pushed
the
fragment-refs-alt
branch
from
3ae668f to
0f40078
Compare
jackpope
force-pushed
the
fragment-refs-alt
branch
from
0f40078 to
2c926ba
Compare
| focus(): void, | ||
| }; | ||
|
|
||
| function FragmentInstancePseudoElement( |
There was a problem hiding this comment.
Nit: This is not really a "PseudoElement" in the DOM terminology. The reason ViewTransitionPseudoElement is called this is because it represents a reified/first-class version of a PseudoElement Instance as a DOM concept of an Element that's part of another Element.
This is similar but it's conceptually more like a real Element or just a Fragment.
So maybe FragmentInstance is the right name? or maybe just Fragment?
This matters for when you log these object in the console and the name of the instance shows as [Fragment].
There was a problem hiding this comment.
Yes just realized this as I started to read the view transition spec with the PsuedoElement concepts. Will rename to FragmentInstance and have the type be FragmentInstanceType
| newChild.key === null; | ||
| if (isUnkeyedTopLevelFragment) { | ||
| newChild.key === null && | ||
| (enableFragmentRefs ? newChild.props.ref === undefined : true); |
There was a problem hiding this comment.
This is subtle but this means that null and undefined are different and will reconcile differently. Which is technically a breaking change.
It also means that <div ref={maybeUndefined && ref}>{children}</div> will clear the state of the whole subtree when it switches.
If it was ref === null || ref === undefined then it would clear state even if you did <div ref={c ? ref : null}> which also doesn't seem right.
So I think what you have is probably the best compromise.
There was a problem hiding this comment.
This is specific to Fragment components, right? So your example of clearing state of the <div /> subtree would be limited to <Fragment ref={}> subtree?
I basically want to know here whether a ref prop was declared at all. But I don't think we can distinguish a maybeUndefined ref value.
There was a problem hiding this comment.
function Component({ children, header, c }) {
const ref = useRef();
return <Fragment ref={c ? ref : undefined}>
<h1>{header}</h1>
{children}
</Fragment>
}
This would clear the state of all children and header deeply any time c changes.
It could also be written as:
function Component({ children, header }) {
const ref = useRef();
if (header) {
return <Fragment ref={ref}>
<h1>{header}</h1>
{children}
</Fragment>
} else {
return <>
<h1>Default Header</h1>
{children}
</>
}
}
If header switches from existing to not existing this would clear the state of children if the ref exists but it would not if the ref doesn't exist.
It also shows up in situations like:
<div>
<Fragment ref={ref}>{...}</Fragment>
</div>
Or if it's a component that just returns children.
So not necessarily the return value of a Component.
| updateFragmentInstanceFiber(finishedWork, current.stateNode); | ||
| } | ||
| if (flags & Ref) { | ||
| safelyAttachRef(finishedWork, finishedWork.return); |
There was a problem hiding this comment.
I don't know where this pattern is coming from but this should be in reappearLayoutEffects, not here. Attaching refs happen in the layout effects which can happen either in commitLayoutEffects or reappearLayoutEffects.
There was a problem hiding this comment.
Question regarding reappearLayoutEffects, I see a bunch of // TODO: Check flags & Ref. What's the reason those aren't already checked? Does the flag not come through at this phase?
There was a problem hiding this comment.
I think it's not safe to check the flag because it would've already been reset at this point. The reappearing doesn't always happen on a tree that was just rendered so those can be old Fibers. I think it would have to be like a static flag. I think the TODO isn't quite right (which isn't unusual for TODOs).
| } | ||
|
|
||
| export function commitNewChildToFragmentInstance( | ||
| childElement: Element, |
There was a problem hiding this comment.
The type that this should reference is Instance because that's the type that's exposed to the react-reconciler. Technically it should be opaque and so this would be wrong if it was.
| while (parent !== null) { | ||
| if (isFragmentInstanceParent(parent)) { | ||
| const fragmentInstance: FragmentInstance = parent.stateNode; | ||
| commitNewChildToFragmentInstance(fiber.stateNode, fragmentInstance); |
There was a problem hiding this comment.
You expect this to be an Element but this Fiber can be either a HostText or HostComponent so it can also be a Text. Because you call commitFragmentInstanceInsertionEffects for both HostText and HostComponent.
Currently you don't have any methods that operate on Text Nodes so you could probably skip HostText or call another Config that is a noop for now. Like maybe React Native could focus HostText?
There was a problem hiding this comment.
For now I'll check against HostComponent specifically and then follow up with any additional work to enable text for React Native.
| @@ -298,6 +339,9 @@ function insertOrAppendPlacementNodeIntoContainer( | |||
| } else { | |||
| appendChildToContainer(parent, stateNode); | |||
| } | |||
| if (enableFragmentRefs) { | |||
| commitFragmentInstanceInsertionEffects(node); | |||
There was a problem hiding this comment.
This is called for both insertions AND moves which is not what I think you expected because you'd add duplicate event listeners any time something moves.
I think maybe it's currently ok to check if node.alternate === null to know if it's an initial insertion.
| @@ -214,6 +219,38 @@ function getHostParentFiber(fiber: Fiber): Fiber { | |||
| ); | |||
| } | |||
|
|
|||
| export function commitFragmentInstanceInsertionEffects(fiber: Fiber): void { | |||
| let parent = fiber.return; | |||
| while (parent !== null) { | |||
There was a problem hiding this comment.
I don't love this loop. If you add 1000 children in bunch of nested components, you'd have to backtrack the same number of levels 1000 times.
And this is for every insertion whether you use Fragment refs or not.
That's why getHostParentFiber is called earlier and passed into insertOrAppendPlacementNode. That way if one Component is mounted which has 1000 children, we only get the getHostParentFiber once.
There's two cases here. A) is that the Fragment is above the Placement or the same level as the Placement. B) is if the Fragment is below the Placement.
For A you could do the loop at the same time as getHostParentFiber and use the same loop. Since this is for every update whether you use Fragment refs or not, it really applies to every update anyway. Might as well unify. Then you can build up an array of parent FragmentInstances and pass that array down though the same way the parent argument is passed to insertOrAppendPlacementNodeIntoContainer. Otherwise pass null if there is none. So there's only an allocation if there are many matches. It's an unfortunate allocation but since there can be more than one match it kind of needs to be one but it would only be the case where the children of the Fragment directly changes. That way if you have 1000 children being inserted into one fragment, we only collect that parent fragment once.
If it's below the Placement itself then it really must be new itself and so it shouldn't even have a a FragmentInstance yet because that gets created in the layout phase. So we don't need to care about B.
There was a problem hiding this comment.
Unifying with getHostParentFiber makes sense to me, thanks for the explanation here.
commitFragmentInstanceInsertionEffects is also called from reappearLayoutEffects. I don't think we can avoid this loop at each HostComponent there, but let me know if you see a way there. If that turns out to slow down the reappear effects, maybe we could hold some state on the hidden HostComponent fibers to signal they were attached previously and should search for fragment instance parents again on reappear. Just to avoid running it on all HostComponent.
*This API is experimental and subject to change or removal.* This PR is an alternative to #32421 based on feedback: #32421 (review) . The difference here is that we traverse from the Fragment's fiber at operation time instead of keeping a set of children on the `FragmentInstance`. We still need to handle newly added or removed child nodes to apply event listeners and observers, so we treat those updates as effects. **Fragment Refs** This PR extends React's Fragment component to accept a `ref` prop. The Fragment's ref will attach to a custom host instance, which will provide an Element-like API for working with the Fragment's host parent and host children. Here I've implemented `addEventListener`, `removeEventListener`, and `focus` to get started but we'll be iterating on this by adding additional APIs in future PRs. This sets up the mechanism to attach refs and perform operations on children. The FragmentInstance is implemented in `react-dom` here but is planned for Fabric as well. The API works by targeting the first level of host children and proxying Element-like APIs to allow developers to manage groups of elements or elements that cannot be easily accessed such as from a third-party library or deep in a tree of Functional Component wrappers. ```javascript import {Fragment, useRef} from 'react'; const fragmentRef = useRef(null); <Fragment ref={fragmentRef}> <div id="A" /> <Wrapper> <div id="B"> <div id="C" /> </div> </Wrapper> <div id="D" /> </Fragment> ``` In this case, calling `fragmentRef.current.addEventListener()` would apply an event listener to `A`, `B`, and `D`. `C` is skipped because it is nested under the first level of Host Component. If another Host Component was appended as a sibling to `A`, `B`, or `D`, the event listener would be applied to that element as well and any other APIs would also affect the newly added child. This is an implementation of the basic feature as a starting point for feedback and further iteration. DiffTrain build for [6aa8254](6aa8254)
*This API is experimental and subject to change or removal.* This PR is an alternative to #32421 based on feedback: #32421 (review) . The difference here is that we traverse from the Fragment's fiber at operation time instead of keeping a set of children on the `FragmentInstance`. We still need to handle newly added or removed child nodes to apply event listeners and observers, so we treat those updates as effects. **Fragment Refs** This PR extends React's Fragment component to accept a `ref` prop. The Fragment's ref will attach to a custom host instance, which will provide an Element-like API for working with the Fragment's host parent and host children. Here I've implemented `addEventListener`, `removeEventListener`, and `focus` to get started but we'll be iterating on this by adding additional APIs in future PRs. This sets up the mechanism to attach refs and perform operations on children. The FragmentInstance is implemented in `react-dom` here but is planned for Fabric as well. The API works by targeting the first level of host children and proxying Element-like APIs to allow developers to manage groups of elements or elements that cannot be easily accessed such as from a third-party library or deep in a tree of Functional Component wrappers. ```javascript import {Fragment, useRef} from 'react'; const fragmentRef = useRef(null); <Fragment ref={fragmentRef}> <div id="A" /> <Wrapper> <div id="B"> <div id="C" /> </div> </Wrapper> <div id="D" /> </Fragment> ``` In this case, calling `fragmentRef.current.addEventListener()` would apply an event listener to `A`, `B`, and `D`. `C` is skipped because it is nested under the first level of Host Component. If another Host Component was appended as a sibling to `A`, `B`, or `D`, the event listener would be applied to that element as well and any other APIs would also affect the newly added child. This is an implementation of the basic feature as a starting point for feedback and further iteration. DiffTrain build for [6aa8254](6aa8254)
[diff facebook/react@0ca3deeb...6aa8254b](facebook/react@0ca3dee...6aa8254) <details> <summary>React upstream changes</summary> - facebook/react#32465 - facebook/react#32540 - facebook/react#32565 </details>
`focus()` was added in #32465. Here we add `focusLast()` and `blur()`. I also extended `focus` to take options. `focus` will focus the first focusable element. `focusLast` will focus the last focusable element. We could consider a `focusFirst` naming or even the `focusWithin` used by test selector APIs as well. `blur` will only have an effect if the current `document.activeElement` is one of the fragment children.
was added in #32465. Here we add and . I also extended to take options. will focus the first focusable element. will focus the last focusable element. We could consider a naming or even the used by test selector APIs as well. will only have an effect if the current is one of the fragment children. DiffTrain build for [c69a5fc](c69a5fc)
This API is experimental and subject to change or removal.
This PR is an alternative to #32421 based on feedback: #32421 (review) . The difference here is that we traverse from the Fragment's fiber at operation time instead of keeping a set of children on the
FragmentInstance. We still need to handle newly added or removed child nodes to apply event listeners and observers, so we treat those updates as effects.Fragment Refs
This PR extends React's Fragment component to accept a
refprop. The Fragment's ref will attach to a custom host instance, which will provide an Element-like API for working with the Fragment's host parent and host children.Here I've implemented
addEventListener,removeEventListener, andfocusto get started but we'll be iterating on this by adding additional APIs in future PRs. This sets up the mechanism to attach refs and perform operations on children. The FragmentInstance is implemented inreact-domhere but is planned for Fabric as well.The API works by targeting the first level of host children and proxying Element-like APIs to allow developers to manage groups of elements or elements that cannot be easily accessed such as from a third-party library or deep in a tree of Functional Component wrappers.
In this case, calling
fragmentRef.current.addEventListener()would apply an event listener toA,B, andD.Cis skipped because it is nested under the first level of Host Component. If another Host Component was appended as a sibling toA,B, orD, the event listener would be applied to that element as well and any other APIs would also affect the newly added child.This is an implementation of the basic feature as a starting point for feedback and further iteration.