For what is worth, there are libraries that do this on the client, similar to morphdom but then it uses the node’s parent and children nodes to identify if it changed or not, reducing the amount of churn.
My critique about this approach is that you are relying on something completely out of your control to keep the client state and it will break in very subtle and unexpected ways when you do a change elsewhere.
I don’t think moving the tree to the server fundamentally addresses this problem either. As the problem is the same: if you have two trees, which nodes are the same and which ones are not? Because they are not identical trees where nodes simply change, you can have children nodes being added anywhere at any moment, or being moved around in terms of nesting.
But if you folks want to play with keeping more DOM elements around and reduce morphdom trashing, one option would be to try JS libraries like above, but you can also try to get some help server side, for example:
- Change HEEx to add a data-heex-id to each element, which is generated at compile time
- Change morphdom to compare the children of a given node using the data-heex-id to detect lateral movements (i.e. a child moving up or down its siblings)
The ID search goes through the whole tree, but this is to help detect sibling movements (nodes added or moved around to a given parent). But once again, it won’t be perfect, and people may accidentally rely on this.
