Add dangerouslyRecycleNode RFC

[zackargyle]

Allow a DOM node from an unmounted component to be reused within a newly mounted component. This is particularly helpful when doing cross-route transition animations, or forwarding video playback to a detailed view from a feed.

This is a new feature request, and would have no backwards incompatibility issues.

The proposed solution is to add a dangerouslyRecycleNode={id} react internal prop that can be added to raw dom nodes (like dangerouslySetInnerHTML). If an unmounting node contains the prop, React caches the node and if a mounting node has the same id, it will reuse the exact DOM node from the previously unmounted component.

Proposal

[NE-SmallTown]

class -> className ?

[kyleshevlin]

Asking for some clarity here. Your use case is to maintain a DOM node for component/route transitions, but then you say to "immediately remove it from cache". What happens when the user wishes to use the Back button? Would we need to maintain the node in cache, or would we be able to setup the same transition, just in reverse?

[zackargyle]

That's a great point. Maybe it should remain in cache until there is no element with the corresponding ID. So don't remove it from cache immediately after mounting the new tree, but set a timeout after unmounting the recycleable node. The cache could have some kind of data structure like this?

type RecycleCache = {
  [id: string]: {
    node: HTMLElement,
    unmountTime: null | number,
  }
};

[kyleshevlin]

I think that would be an option. I think the other is to clear the cache but enable transitions in both directions somehow. I mean, in theory, the same DOM node could transition across more than one dismount of parent components. Having the ability to do this no matter how many destinations I think could be useful.

[mattbasta]

This would, however, be backwards incompatible with any existing component that--though unlikely--uses a prop named dangerouslyRecycleNode.

[zackargyle]

This could be fixed with a codemod to rename their prop.

[mattbasta]

Perhaps a solution to the memory leak issue is to require the developer to specify their own cache which they manage manually. For instance:

const myCache = new Map();

const RecycledCompoonent = (props) =>
  <MyComponent
    dangerouslyRecycleNode={{cache: myCache, key: props.id}}
    {...props}
  />;

This would also solve many unaddressed problems:

• Third party libraries wouldn't need to worry about conflicting with IDs from other libraries
• Developers could add their own cache eviction policy. This RFC is fundamentally a performance enhancement, and performance is not one-size-fits-all solution.
• The cache could be traversed manually, flushed, or otherwise manipulated if a change in application state makes cached values invalid.
• The cache key is not limited to strings.
• Developers could implement their own .set() method that rejects nodes from the cache, potentially saving resources under memory pressure.
• etc.

[zackargyle]

What if dangerouslyRecycleNode instead took in an actual node? The upside is that it'd be even simpler internally. The downside is that developers may create memory leaks since they control the caching mechanism.

class Page1 extends React.Component {
  onClick(event) {
    this.props.history.replace({ node: event.target });
    this.props.history.push('/new-route', { node: event.target });
  }
  render() {
    return (
      <div>
        <image
          src={...}
          onClick={this.handleClick}
          dangerouslyRecycleNode={this.props.location.state?.node}
        />
      </div>
  }
}

class Page2 extends React.Component {
  render() {
    return (
      <div>
        <image
          src={...}
          dangerouslyRecycleNode={this.props.location.state?.node}
        />
      </div>
  }
}

[sophiebits]

FWIW, one workaround you can do today is to render the node you want to move into its own React root (via a portal), and then manually move that container around using DOM operations. However it is clumsy and does require extra wrapper elements.

[gaearon]

The transition use case is interesting and something @sebmarkbage has recently been thinking about. However, it is unlikely that recyling the DOM node is how we'll go about it. Instead, we might want to have a first-class way for components to specify their exit animations. This will likely tie into other Concurrent Mode features. So I'll close this particular RFC but we care about the use case.

Note that the "reverse portal" use case can be implemented in userland. I describe how here: facebook/react#12247 (comment).