-
Notifications
You must be signed in to change notification settings - Fork 115
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
xilem_web: Add a few boolean attribute modifiers for `HtmlInputElemen…
…t` and factor element state flags out of these modifiers into `ElementFlags` (#717) This PR starts with supporting specialized elements (i.e. more than just the `Element` DOM interface), starting with boolean attributes in `HtmlInputElement` (`checked`, `default_checked`, `disabled`, `required`, `multiple`). With a general `OverwriteBool` modifier which is optimized by encoding boolean flags into a `u32`, thus not requiring allocations (compared to the other modifiers we currently have), but is limited to max 32 overwrites, which I don't think should be a real-world limitation (i.e. `input_el.checked().checked()...checked()` 32 times makes no sense), I also started adding tests for this, as it juggles around with bit-operations (and we should generally start writing more tests). I have originally planned to feature-flag this (i.e. have a feature like `HtmlInputElement`). But I'd like to see how far we can go without this, I haven't yet noticed significant (binary-size) regressions in the todomvc example (which uses `input` elements) that justifies the worse DX that additional features introduce. Having features for this is also not optimal for another reason: It changes the API (e.g. `DomNode::Props` is `props::HtmlInputElement` instead of `props::Element`. It also factors the element state flags (`was_created`, `in_hydration`) into a separate `ElementFlags` which is shared within a `Modifier<M>` struct (similar as `PodMut` or `WidgetMut` in masonry), so that we don't have to duplicate that state in every modifier. Additionally a new flag `needs_update` is introduced, which indicates that the element in general needs to update any modifier, and is entirely an optimization to avoid checking every modifier whether it has changed (not yet that important, but when we have a lot of modifiers per element, having to check every modifier is less efficient, it's also already *slightly* visible in the js-framework-benchmark). For this, it unfortunately suffers similar as #705 from the free-form syntax by being a little bit more verbose (which may be reverted after `arbitrary_self_types` are stable). It should also fix #716
- Loading branch information
Showing
18 changed files
with
1,392 additions
and
609 deletions.
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
This file contains 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
This file contains 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
Oops, something went wrong.