Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we remove support for some types of newContent? #103

Open
botandrose opened this issue Feb 13, 2025 · 1 comment
Open

Can we remove support for some types of newContent? #103

botandrose opened this issue Feb 13, 2025 · 1 comment

Comments

@botandrose
Copy link
Collaborator

botandrose commented Feb 13, 2025

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?

@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

@botandrose
Copy link
Collaborator Author

Just noticed this in the README:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant