Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Here are some core improvements to the htmx 4 morphing algorithm based on some ideas and learnings from morphlex
Improvements
It now skips finding best node to match for non element text nodes because from testing the time to search and then morph these text only nodes is actually slower than just inserting new text nodes and there is no state to lose here. only morphing elements makes morph node simpler.
If node has a non persistent ID instead of doing a full scan to find a non id'ed node ( because it is not persistent we know it won't match a id'ed node) to soft match and morph over top of we can just return null and insert this probably new node straight away saving some time.
When removing content to make way for the placement of the best found match instead of just removing the nodes it now scans forward scan limit nodes to find if these nodes are perfect matches with future new content. If they are then it marks them as future matches and moves them to the end of the parent to be matched later. This allows reordering of non id nodes without having to remove and re-create the nodes.
Removed the old 2 next sibling look ahead logic and instead replace it with a system where if we couldn't find a perfect match and fall back to the first softmatch we can check if this softmatch is a perfect future match for some upcoming new content sibling and if it is don't softmatch and insert the current node instead as this softmatch will match later. This allows multiple nodes to be inserted without them morphing over upcoming matching nodes.
We still have a 10 node default scan limit so it will not search all siblings for better large list performance.
Corresponding issue:
Testing
Most of my testing for these changes was done manually or with idiomorph test suites that we don't have fully in htmx yet.
Checklist
masterfor website changes,devforsource changes)
approved via an issue
npm run test) and verified that it succeeded