You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the newContent argument passed to the main morph function can be a dizzying array of types:
Element
Node
HTMLCollection
Array<Node>
string
null
Also, for the first 4 types, newContent may or may not be already attached to the DOM, which opens the possibility of additional complications. It could conceivably have hidden state, or have siblings that we don't want to morph, etc.
Can we pare this possibility space down at all, and safely support less use-cases?
Note that [Idiomorph.morph] is a destructive operation with respect to both the existingNode and the newNode.
This isn't true anymore, at least in that newNode is now preserved, largely to ensure that the callback arguments are called with the correct values. But it does indicate that maybe we can at least reparent newNode if necessary.
Right now, the
newContent
argument passed to the main morph function can be a dizzying array of types:Also, for the first 4 types,
newContent
may or may not be already attached to the DOM, which opens the possibility of additional complications. It could conceivably have hidden state, or have siblings that we don't want to morph, etc.Can we pare this possibility space down at all, and safely support less use-cases?
@MichaelWest22 has already done some exploration about this in branches:
https://github.com/MichaelWest22/idiomorph/tree/fix-outer-normalize
https://github.com/MichaelWest22/idiomorph/tree/fix-outer-normalize2
The text was updated successfully, but these errors were encountered: