Daniel Friesen

> I think it would reset the currentTime of the video, too. Well. If you really wanted. You could build a `` component which would make all the state in...

@polkovnikov-ph There are dom states that do not get discarded when you call `removeChild` on them. And the ability to retain React Components while reparenting is just as important. But...

To dive more into this issue of removeChild/appendChild and state loss I've built a series of simple dom reparent tests that will reparent an element using just appendChild, removeChild +...

Something else that is hard to test is selection behaviour. This probably isn't an issue for overall selection (I notice that even when completely removing and creating dom nodes a...

Important discussion points: Is it possible to hydrate a server-rendered DOM tree and know, without needing deterministic IDs, and know what portion of it belongs to a Reparent and should...

I've added a possible alternative to `.unmount()`, a [`.keep()`](https://github.com/dantman/rfcs/blob/reparenting/text/0000-reparenting.md#keep) signal. I'd like some feedback on that idea. If people like it I may refactor the RFC to use `.keep()` and...

> My use cases do not care to explicitly .keep() instances around, nor do they particularly care about being bound to some component higher in the tree (though it is...

> What I meant with the complexity of the createReparent, and .keep() is that for my simple use case, I'd love to just have eg. React.createElement("div", { key: React.createReparentableKey(idParam) })...

> I like the idea of moving nodes around, but this seems as a needless overhead for the developer. Why not introduce new react-specific attribute, similar to the key that...

> I think it's also against the design principles of React that the render method has side effects. In this case, the render method might return null but we still...