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

Cleaning up code by making vnode.attrs always non-null #2819

Closed
wants to merge 4 commits into from

Conversation

kfule
Copy link
Contributor

@kfule kfule commented Feb 10, 2023

Commit f9e5163 made vnode.attrs always non-null, so there is no need for code to make vnode.attrs null or assume vnode.attrs is null.

Description

The following two processes have been removed

  • Workaround for vnode of textarea when vnode.attrs is null
  • Processing of key removal to set vnode.attrs to null

For the latter, the behavior will change when there is only key in attrs (key is not removed from attrs). Some tests have also been changed to ensure that the changes are appropriate.

Motivation and Context

There is still a not very useful code that assumes that vnode.attrs will be null. Removing that code will reduce the amount of code and improve the outlook of the process.

How Has This Been Tested?

Running "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)
  • Documentation change

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have updated docs/changelog.md

dependabot bot and others added 3 commits February 7, 2023 04:59
Bumps [minimatch](https://github.com/isaacs/minimatch) from 3.0.4 to 3.1.2.
- [Release notes](https://github.com/isaacs/minimatch/releases)
- [Changelog](https://github.com/isaacs/minimatch/blob/main/changelog.md)
- [Commits](isaacs/minimatch@v3.0.4...v3.1.2)

---
updated-dependencies:
- dependency-name: minimatch
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>
Bumps [async](https://github.com/caolan/async) from 2.6.3 to 2.6.4.
- [Release notes](https://github.com/caolan/async/releases)
- [Changelog](https://github.com/caolan/async/blob/v2.6.4/CHANGELOG.md)
- [Commits](caolan/async@v2.6.3...v2.6.4)

---
updated-dependencies:
- dependency-name: async
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>
Because vnode.attrs is never null by commit f9e5163
Copy link
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.

If it's truly redundant, the tests shouldn't need modified. Please revise this such that tests can pass as-is.

I suspect your intuition is right, but the patch as written is not.

@pygy
Copy link
Member

pygy commented Feb 11, 2023

@dead-claudia we're ignoring "key" in setAttr(), and, after this patch, in order to not have it there would mean either

  1. deleting it from the user supplied object, or
  2. iterating over the attrs to make sure it is the only one and replace attrs with an empty object.

When there are other props key is left on the attrs.

I'd rather avoid 1).

Regarding 2) I assume that setAttr() is inlined in setAttrs() and updateAttrs(), and "key" is the first check we make in there. So looking for a lone key in execSelector will not save anything perf-wise.

@dead-claudia
Copy link
Member

@pygy My concern wasn't perf, but in unnecessary breakage and ensuring it's only removing the truly redundant parts.

Any changes to the tests reduces my confidence in the removed parts being truly redundant, if it helps.

@pygy
Copy link
Member

pygy commented Feb 11, 2023

Understood but in this case I'm not sure the tests are right. If the intent was to filter key out of the attrs of DOM vnodes, the current logic is broken, and only partially tested. We don't test for m("x", {key, a}), and we keep the key in that scenario.

@kfule
Copy link
Contributor Author

kfule commented Feb 11, 2023

Thanks for the review.

I understand your motivation for not wanting to change the test, but please consider that the changed test is changed by the commit f9e5163 (which made attrs always non-null), too.
f9e5163#diff-048b8c57f4a13b5784f875e7a5c31e2c2a6502c38e64c31d619e0212e5586e74R274
f9e5163#diff-048b8c57f4a13b5784f875e7a5c31e2c2a6502c38e64c31d619e0212e5586e74R346

iterating over the attrs to make sure it is the only one and replace attrs with an empty object.

As a result of removing just such a process, the test needed to be changed...
https://github.com/MithrilJS/mithril.js/pull/2819/files#diff-60b8d5249940bc09c5a4d14138469f40b3def8e635b25fbd59ff61493ec10581L67

Because vnode.attrs is never null by commit f9e5163
@kfule
Copy link
Contributor Author

kfule commented Feb 12, 2023

To make the purpose of this pr easier to understand, I have re-modified the code with minimal changes.

I have reverted back to the original logic for the following lines, but there seems to be a bug when sharing attrs, so I would like to issue a separate issue or pr.
https://github.com/MithrilJS/mithril.js/pull/2819/files#diff-60b8d5249940bc09c5a4d14138469f40b3def8e635b25fbd59ff61493ec10581L41

@kfule kfule requested review from dead-claudia and removed request for StephanHoyer February 12, 2023 10:29
@dead-claudia dead-claudia added the Area: Core For anything dealing with Mithril core itself label Sep 2, 2024
@dead-claudia dead-claudia requested a review from a team as a code owner September 23, 2024 11:58
Copy link
Collaborator

@JAForbes JAForbes left a comment

Choose a reason for hiding this comment

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

Looks good to me, let's at least get it into next and we can see if there's any observable perf difference in the wild?

@dead-claudia dead-claudia deleted the branch MithrilJS:next September 25, 2024 05:23
@dead-claudia
Copy link
Member

Closed due to the next branch being deleted. Thanks to https://github.com/orgs/community/discussions/139697, I can't resurrect this PR, so it'd have to be re-created against main.

@JAForbes If you get a chance, can you figure out how this fares in npm run bench with and without this patch? If it's not significant, you can file a PR yourself with this PR reapplied and I'll merge it.

@JAForbes
Copy link
Collaborator

Will try to find the time, if not @kfule I think we'd be happy to merge this if you could re-open the PR against main and run npm run bench before/after the change and verify there's no substantial change.

@kfule
Copy link
Contributor Author

kfule commented Sep 25, 2024

@JAForbes ok, I will re-open the PR against main.

@kfule
Copy link
Contributor Author

kfule commented Sep 25, 2024

I re-opened the PR at #2977.

@kfule kfule deleted the non-null-attrs branch October 19, 2024 11:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Core For anything dealing with Mithril core itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants