Support for reparenting

[dantman]

When writing a component that contains a set of large subtrees that stay relatively the same, but are simply moved around such that React's virtual DOM diffing can't detect the movement, React will end up recreating huge trees it should simply be moving.

For example, pretend blockA and blockB are very large structures. They may be made of several levels of children and components. For example one could be the entire page contents and the other the sidebar, while this render() is the page root.

render() {
    var blockA = <div>AAA</div>,
        blockB = <div>BBB</div>;

    if ( this.props.layoutA ) {
        return <div>
            <div className="something">{blockB}</div>
            <div className="something">{blockA}</div>
        </div>;
    } else {
        return <div>
            {blockA}
            {blockB}
        </div>;
    }
}

Because the blocks aren't at the same level React cannot see the relation between these blocks and key cannot be used to give React any hints. As a result, when layoutA is changed, instead of the two blocks being moved to their new location the entire page is essentially completely unrendered and then re-rendered from scratch.

I understand why this is the case. It would be far to expensive for React to be able to detect movement of nodes like this.

But I do believe we need a pattern to hint to React that this component has large blocks that may be moved around at different levels.

Note that there may be a component in between the rendering component root and the block. So parent semantics scoped to the nearest component won't work. This'll need owner scoping.

I understand that React is trying to eliminate the need for React.createElement to be used and owner scoping within special attributes interferes with that. So instead of a component scoped key="" variant I think a method/object style interface kind of like React.addons.createFragment might work.

[gaearon]

This is a tricky problem. You might want to share your input here.

[vkurchatkin]

How about such hint:

render() {
    var blockA = <div>AAA</div>,
        blockB = <div>BBB</div>;

    if ( this.props.layoutA ) {
        return <div>
            <div className="something">{blockB}</div>
            <div className="something">{blockA}</div>
        </div>;
    } else {
        return <div>
            <div>{blockA}</div>
            <div>{blockB}</div>
        </div>;
    }
}

[dantman]

@vkurchatkin I don't see any hint or change in your version of the example.

[gaearon]

@vkurchatkin For two different render calls, those would be two different React element instances. So this doesn't really help, as React can't “guess” if you're using the same variables inside render branches or not. Also, in some cases build tools will optimize constant element creation and put it outside render, so even if such guessing was possible, you'd get false flags for constant elements reused several times inside one rendered tree.

[vkurchatkin]

@Gaeron well, in this particular case both trees have the same shape, so they will be reconciled just fine, won't they? in other case it should be easy enough to wrap subtrees in components to give React a hint.

[jimfb]

@gaearon Yeah, guessing is even trickier than that, because render could create multiple copies of elements (either in a loop or via a helper function), resulting in distinct elements, even though they were created in the same "location" in code.

@dantman I think your best bet (at least medium term) is going to be to hoist the component state up above the tree (rather than relying on component state). See #3653 (comment). That will, in general, solve the re-parenting problem from a correctness point of view. Then, the only remaining 'issue' is performance (re-creating DOM instead of re-using the 'moved' markup), but React is pretty fast and I'm guessing that isn't too much of a concern.

@dantman The change is the addition of the divs in the else block of the render function. @vkurchatkin is correct that this should preserve the DOM shape/structure, thus allowing React to better figure out what's going on during reconciliation and re-use the structure. His change is subtle, but correct.

[syranide]

I'd just like to point out that you can do reparenting manually today, if you render the component you want to reparent into a separate non-React node, this node can then be reparented manually anywhere you like (but remember that you may only put it in empty React nodes).

[dantman]

@syranide The caveat is that since you're doing that by rendering into a separate DOM node it doesn't work on the server.

I actually experimented with that recently. I tried getting around the server limitation with a messy setup where I'd render() the node in react for the server, then on the client drop that and re-render into a dom node that can be relocated. Unfortunately I ran into some issues with React stumbling on modified DOM and had to scrap the experiment.

[kof]

Maybe more real life use cases can add some priority to this issue ...

[syranide]

@kof Could you expand on that? It's a wall of text and I don't see anything that obviously applies, intuitively I don't see any use for reparenting in an implementation of virtual lists?

[kof]

@syranide is this a good explanation? #7460
Quick summary:
To measure the size of a rendered component invisibly from the user, before we show it to the user, we need to

1. mount it in a hidden container
2. calc the size
3. unmount
4. mount again in the visually visible container

What we need is:

1. mount in a hidden container
2. calc the size
3. reparent to a visually visible container without much overhead

[bvaughn]

There's a lot of background with that particular use-case that's specific to the architecture of react-virtualized. Trying to summarize as much as possible: RV needs to know the actual sizes of its elements at some point so it can window things. For elements ahead of the current cursor sizes can be estimated, but for elements behind (above, left-of) actual sizes need to be known (or scrolling would be janky).

The CellMeasurer HOC helps to just-in-time measure a given row or column. Sometimes the cells it's measuring aren't actually visible (eg if a user quick-scrolls and skips a range or cells, RV needs to measure the ones that were skipped). So CellMeasurer uses unstable_renderSubtreeIntoContainer to measure these cells in a hidden div. The same measured cells may later be rendered (depending on which direction the user scrolls).