Skip to content

Make vnode.domSize assignment consistent between create and update.#3055

Merged
dead-claudia merged 3 commits intoMithrilJS:mainfrom
kfule:refactor-dom-size
Nov 8, 2025
Merged

Make vnode.domSize assignment consistent between create and update.#3055
dead-claudia merged 3 commits intoMithrilJS:mainfrom
kfule:refactor-dom-size

Conversation

@kfule
Copy link
Copy Markdown
Contributor

@kfule kfule commented Nov 1, 2025

This PR makes the code and behavior of create and update processes more consistent.

Description

  • vnode.domSize in updateFragment is now always set to an integer and not left undefined.
    • In createFragment, vnode.domSize is always an integer (temp.childNodes.length), so updateFragment follows it.
    • Accordingly, checks for vnode.domSize === 1 have been added to moveDOM and removeDOM.
  • vnode.domSize and vnode.dom assignment code in createComponent and updateComponent are now consistent.

The behavior remains unchanged except that vnode.domSize, which was intentionally undefined, will now be set to 1.
npm run test passes as is.

Also, unnecessary a comment immediately after vnode.domSize in createHTML has been removed as well.

Motivation and Context

This PR fixes inconsistencies in domSize for the following create and update processes:

var comp = {
  view: () =>  m.fragment(m("div"))
}

// create
var v1 = m(comp)
m.render(document.body, v1)
console.log(v1.domSize)          // 1
console.log(v1.instance.domSize) // 1

// update
var v2 = m(comp)
m.render(document.body, v2)
console.log(v2.domSize)          // undefined
console.log(v2.instance.domSize) // undefined

flems

For component vnodes, the code was redundant in both create and update, so I made it simpler and consistent.
Also, the bundle size becomes 8,952 bytes gzipped.

How Has This Been Tested?

npm run test

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • My code follows the code style of this project.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • My change requires a documentation update, and I've opened a pull request to update it already:
  • I have read https://mithril.js.org/contributing.html.

@kfule kfule requested a review from a team as a code owner November 1, 2025 03:37
Copy link
Copy Markdown
Member

@dead-claudia dead-claudia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add new tests to verify this behavior? It's clearly a bug fix, so I'd like tests to make sure it doesn't regress further.

@kfule
Copy link
Copy Markdown
Contributor Author

kfule commented Nov 5, 2025

@dead-claudia Thank you for your review.
It looks like the existing tests avoided cases where domSize is 1, so I’ve added assertions for those to the existing test cases. I also added checks for other domSize values to keep things consistent with the surrounding code.
Does this look okay to you?

Edit: I also added test cases for consistency of vnode.domSize regarding component vnodes.

kfule added 3 commits November 7, 2025 20:51
For fragment and component vnodes, the assignment of `vnode.domSize` was inconsistent between create and update. In particular, when the fragment vnode corresponded to exactly one DOM node, it was set to `1` on creation but left `undefined` on update. Although leaving it undefined in the single-node case was intentional, it reduced behavioral consistency and code readability.

This commit aligns the behavior between creation and update. To minimize internal impact from `domSize` transitioning from `undefined` to `1`, additional checks were added in the move and remove paths.
This was a supplemental comment about capturing DOM nodes in `vnode.instance`, but the related code has already been removed.
@dead-claudia dead-claudia merged commit ca72c73 into MithrilJS:main Nov 8, 2025
7 checks passed
@JAForbes JAForbes mentioned this pull request Nov 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants