Replace WidgetMut methods with free functions. #705
Merged
Conversation
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 PR was created with heavy assistance from Cursor Tab (an AI-assisted IDE). The workflow with that IDE is that you make a change, then the IDE goes "Oh, so you probably also want to change this line? And this line?" and you go tab-tab-tab as it proposes successive line edits. I tried to make sure all the changes were signature-only and didn't affect program behavior, but I might have let some slip. I'll try to double-check again later in the day. |
|
All tests except doc tests passed on the first try, so that's encouraging. |
DJMcNab
reviewed
Oct 22, 2024
DJMcNab
approved these changes
Oct 22, 2024
|
Yeah, documentation is very WIP. |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Oct 28, 2024
…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
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.
See discussion here #663 and on zulip.
Basically, previous code was using
WidgetMut<MyWidget>as a receiver. This can be done when WidgetMut is a local type, but external users wouldn't be able to do it. The result would be that users importing Masonry as a dependency but copy-pasting code from one of our widgets would get compile errors.This PR switches to a syntax that external crates will be able to use when declaring widgets. It's a more verbose, less readable syntax, but it's unambiguous and doesn't require clever tricks.
We can consider switching back to WidgetMut-as-a-receiver when
#![feature(arbitrary_self_types)]or some equivalent gets stabilized. See rust-lang/rust#44874 (comment) for current progress.