Iframe's reinitialise when moving down within a group of components

[pieterv]

When moving a component with an iframe down within a group of components it reinitialises the iframe. The iframe only reinitialises when moving down, moving upward seems to work fine.

Example: http://jsfiddle.net/pieterv/fnkLf/

[vjeux]

I can't see anything wrong with your code from a 2 min inspection. You are properly using key and the reconciliation should work fine. cc @jordwalke

[sophiebits]

Curious. I'll take a look later.

[plievone]

Up/Down asymmetry may be related to this (ok by itself): https://github.com/facebook/react/blob/338ce60/src/core/ReactMultiChild.js#L336-L343
And iframe reset may be related to this https://github.com/facebook/react/blob/338ce60/src/dom/DOMChildrenOperations.js#L100-L105 or https://github.com/facebook/react/blob/338ce60/src/dom/DOMChildrenOperations.js#L48-L52.
(Have you tried with own iframe content?)

[benjamn]

<iframe>s reload whenever they are reattached to the DOM. So it might not be reasonable to expect this to work. Consider two frames that need to trade places. One has to get removed from the DOM and reattached, no matter what you do. Hoping to get away with lucky re-renderings is a recipe for fragile code.

[pieterv]

@benjamn yes that makes sense thinking about the DOM operations required to reorder the elements, it was just because of reacts preference to move things downward as @plievone pointed out that the up operation was working without reinitialising.

[sophiebits]

You might think that you could just call insertBefore or appendChild without ever removing the elements from the DOM but at least in Chrome, that still makes one of the iframes reload. Maybe that means we can't fix this.

[syranide]

Yeah, just did some manual tests as well, this actually appears to be impossible to workaround in the DOM, and some internet searching suggests the same.

The only universal solution I see is to somehow be able to mark a component as mustNotMove which will apply all the way up to the root, which would prevent any move operation on those nodes and the siblings would be used for reordering instead. It would work for all cases except for when two mustNotMove components changes sides.

However, I'm curious how much of an issue this actually is today? Does this make iframe in React virtually pointless because of conditionals further up in parents, or is it really only an issue when explicitly moving components with iframes around?

[benjamn]

This is one of the most regrettable misfeatures of <iframe>s, in my opinion. And, yes, it makes them pretty much useless in situations where DOM manipulations are abstracted out of your control, as they are in React.

[plievone]

To prevent reloading of <iframe>s, one can keep each of them in separate divs, somewhere safe from DOM manipulations, and move/scale them with absolute positioning in sync with some placeholder elements. :)

[syranide]

@plievone Yeah, but the only way to keep them perfectly in sync would be to poll every frame, and this would cause lag on IE8 as it doesn't support requestAnimationFrame. Also, you'll have issues with z-index.

[syranide]

@spicyj @benjamn I had a look at React and it is possible to solve this as good as it gets (i.e. an iframe may never move to the other side of another iframe) by applying a immovable-flag up the hierarchy for iframes. When React wants to move such a component it should instead shuffle the siblings over to the other side of it instead of moving the node itself. This should have virtually zero cost when no immovable component is moved.

Been trying to wrap my head around ReactMultiChild and DOMChildrenOperations for a bit, it seems like it should be possible. But my head is apparently not up for the task right now. :)

[pieterv]

Just for reference i got an implementation going as @plievone suggested by absolute positioning the iframe into place, http://jsfiddle.net/pieterv/fnkLf/6/, but as expected it seems to be pretty fragile code, you would really need to have the siblings as set height elements to get away with not polling their position on every frame.

[syranide]

@pieter-vanderwerff FYI, I have a proof-of-concept for a React PR working right now, just fixing the last issues. With it, iframes will work as they should as long as two iframe containing components never switch sides. Meaning, it should basically solve most common use-cases, except for moving say comments with iframes up/down in a list, but static iframes and blog style pages will work perfectly.

It seems like it's a relatively light-weight fix too so hopefully they accept it.

[pieterv]

@syranide awesome, i look forward to seeing it!