Skip to content

Conversation

aligator
Copy link
Collaborator

@aligator aligator commented May 4, 2025

Description

Similar problem as #149.
However I think I understand it now better:
the example on https://github.com/snabbdom/snabbdom describes that the first patch should be on the dom-element, but the second patch should be on the vnode from before.

So it now saves the last vnode and patch it. Only on the first patch (if vnode is not set yet), it patches the element.

Motivation and Context

Closes #137

How Has This Been Tested?

FF and chrome, mobile and desktop tested

Screenshots/links:

image

image

Checklist:

  • My code follows the code style of this project. (CI will test it anyway and also needs approval)
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.

Similar problem as freifunk#149.
However I think I understand it now better:
the example on https://github.com/snabbdom/snabbdom describes that the first patch should be on the dom-element, but the second patch should be on the vnode from before.

So it now saves the last vnode and patch it. Only on the first patch (if vnode is not set yet), it patches the element.
@rotanid
Copy link
Contributor

rotanid commented May 4, 2025

fixing the bug confirmed by local testing on my laptop, thanks!

cc @skorpy2009

@skorpy2009 skorpy2009 merged commit b27c968 into freifunk:main May 4, 2025
2 checks passed
@rotanid rotanid deleted the 137-fix-sorting branch May 4, 2025 13:24
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

Successfully merging this pull request may close these issues.

Sorting Nodes breaks UI
3 participants