This is another intermediary PR for the "restrict widget creation to
Mutate pass" feature.
The basic idea is that, in the near future, it will be impossible to
create a WidgetPod without a handle to the arena. In my current WIP
code, that handle is passed through ViewCtx. Therefore, this PR changes
all the sites in xilem that create a Pod and has them use a ViewCtx
method instead.
I've tested most xilem examples and they all worked (except for
variable_clock, which currently panics in the last main commit).
Some micro-optimizations, e.g. avoids a js call `instanceof` (via
`dyn_into`/`dyn_ref`) when constructing elements.
Leads to a small speed increase when constructing/visiting elements
(roughly 2%) and more importantly a leaner wasm binary (around 5 %),
respectively tested with the js-framework-benchmark suite.
I think I've covered every pub item at the top level.
It also renames (taking `Attributes` as example)
`start_attribute_modifier` -> `rebuild_attribute_modifier`,
and `end_attribute_modifier` -> `mark_end_of_attribute_modifier`, as I
think that makes it more clear what these methods do.
`start_attribute_modifier` was a noop in `View::build` and may lead to
buggy behavior when `DomNode::apply_props` is called before every parent
`View::build` has done modifying the props. This should make
`DomNode::apply_props` robust. And `AfterBuild` is fixed now with that.
This is mostly a first step towards SSR.
But we can use hydration to speed up creation of long (non-virtualized)
lists with the `Templated` view.
`Templated` stores a deep copy of the DOM node of the first occurence of
its `impl DomView` based on the `TypeId` in the `ViewCtx`,
and reuses it on every further invocation, where it will be hydrated and
updated based on the new attributes.
As it uses an `Rc` to achieve this, it also supports memoization,
similar to an `Arc<impl View>`.
Hydration is currently feature-gated, as it produces a little bit more
binary bloat. Though it's little enough to this being justified as
default.
---------
Co-authored-by: Markus Kohlhase <markus.kohlhase@slowtec.de>
This should fix the issue described in #440 by adding the type of the
`Children` `ViewSequence` to the type of element, which results in
unique types, so `AnyView` should not cause issues anymore. Fortunately
there's no regression with the compilation times here, so an
`AnyViewSequence` doesn't seem to be necessary in that case.
Should fix#461. This allows a `ViewSequence` (called `DomFragment`) of
`DomView`s as root component.
The `counter` example is updated to show this new behavior.
This allows returning `impl ViewSequence` as this was previously not
possibly as the `Marker` generic parameter couldn't be named (easily) in
`ViewSequence<..., Marker>`.
This also provides specialized `ViewSequence`s for xilem
(`WidgetViewSequence` and `FlexSequence`) as well as for xilem_web
(`DomFragment`). Additional doc-tests/documentation and a small example
(in `counter`) for xilem_web is provided as well.
This has the drawback to not being able to reeimplement `ViewSequence`
for types that already implement `View`, which was previously possible
(as seen by the now removed `NoElementView` `ViewSequence`
implementation).
And additionally by introducing more boilerplate by having to implement
`ViewMarker` for every type that implements `View`.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
I'm surprised that this was not noticed yet,
`DomChildrenSplice::with_scratch` previously only appended new elements
to the end of the children of an element in the DOM tree, whereas it
should've inserted it at the current index of the `ElementSplice`. This
should fix this, using a `DocumentFragment` which is shared on the
`ViewCtx` to avoid unnecessary allocations.
From manually testing in Chrome, values between `2**31` and `2**31 - 1`
work, so this takes an `i32`.
It's pretty trivial code, but I think it would be really nice to add
some kind of test, or even just an example which uses it.
What do you think about adding a "misc" example for `xilem_web`, which
exercises a bunch of small features? I was thinking a layout with a
column on the left with a list of items with a larger area on the right.
When an item on the left is clicked, the right side is populated with
whatever that item is.
In this case, the item name would be `ol-li-value`, which when clicked
would show something like this on the right:
```rust
ol((
li("foo"),
li("bar"),
li("baz").value(10),
li("qux"),
));
```
Ideally, this would be compiled as part of CI, to make sure that no
compilation errors are introduced. Any time a small feature is added, a
new item in the "misc" example could be added which uses it.
It would also be nice for development, to have a place where new, small
features like this can be exercised during development. An actual test
would be great, but from quick googling, I couldn't find an obvious way
to test WASM code which runs in the browser. There's
`wasm_bindgen_test`, but that only runs tests in WASM outside of a
browser environment.
I guess I missed this when adding #408, the doc-test should ensure that
`Box<AnyDomView>` is now really a `DomView`.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
I think we could also create some additional sugar around that, but
since the event is given to the user, they can handle that behavior
anyway.
Fixes#457
This is the `rerun_on_change` view described in #440, I named it
`MemoizedAwait` as I think that fits its functionality.
It got also additional features `debounce_ms` (default `0`) and
`reset_debounce_on_update` (default `true`) as I think that's quite
useful, in case a lot of updates are happening.
When `reset_debounce_on_update == false`, `debounce` is more a throttle
than an actual debounce.
This also adds a more heavily modified version of the example added in
#427, also showing `OneOf` in xilem_web (which didn't have an example
yet).
This *could* be considered as alternative to #440 (at the very least the
example) but those approaches could also well live next to each other.
---------
Co-authored-by: Markus Kohlhase <markus.kohlhase@slowtec.de>
There is one "semi-false-positive" lint triggered, which I have fixed.
Otherwise, the required
```
cargo upgrade --ignore-rust-version
cargo update
```
This uses the interface in Xilem Core from #394 and #436
Some thoughts:
1) You only need to specify the number of items in a single match arm.
I.e.
```rust
fn my_view(){
match x {
0 => OneOf3(...),
1=> OneOf9(...),
_=> OneOf9(...),
}
}
```
works. We probably should rename `OneOf9` back again in that case.
2) The example currently isn't that interesting. Any suggestions for a
more suitable state machine would be welcome.
See discussion in [#linebender > Standard Lint
set](https://xi.zulipchat.com/#narrow/stream/419691-linebender/topic/Standard.20Lint.20set)
Of note: I have taken steps to ensure that this can be practically
reviewed by *not* applying most of the lints.
The commented out lints make good follow-ups
---------
Co-authored-by: Olivier FAURE <couteaubleu@gmail.com>
I have intentionally left out the `xilem_core::adapt` variant here in
order to have a clear classic Elm example. I would rather show the
`adapt` variant in a separate example.
This ports xilem_web to the new xilem_core.
There's also a lot of cleanup internally:
* Get rid of all of the complex macros to support DOM interfaces, and
instead use associated type bounds on the `View::Element`.
* Introduce an extendable modifier based system, which should also work
on top of memoization (`Arc`, `Memoize`) and `OneOf` views with an
intersection of the modifiable properties.
* This modifier based system gets rid of the hacky way to propagate
attributes to elements, and takes inspiration by masonrys `WidgetMut`
type to apply changes.
* Currently that means `Attributes`, `Classes` and `Styles` to reflect
what xilem_web previously offered.
Downsides (currently, needs some investigation):
~~Due to more internal type complexity via associated types this suffers
from https://github.com/rust-lang/rust/issues/105900. The new trait
solver should hopefully mitigate some of that, but it seems currently it
completely stalls in the todomvc example (not in other examples).~~
~~The deep, possibly completely static composition via associated
type-bounds of the view and element tree unfortunately can take some
time to compile, this gets (already) obvious in the todomvc example. The
other examples don't seem to suffer that bad yet from that issue,
probably because they're quite simple.~~
~~I really hope we can mitigate this mostly, because I think this is the
idiomatic (and more correct) way to implement what the previous API has
offered.~~
One idea is to add a `Box<dyn AnyViewSequence>`, as every element takes
a "type-erased" `ViewSequence` as parameter, so this may solve most of
the issues (at the slight cost of dynamic dispatch/allocations).
Edit: idea was mostly successful, see comment right below.
I think it also closes#274
It's a draft, as there's a lot of changes in xilem_core that should be
upstreamed (and cleaned up) via separate PRs and I would like to
(mostly) fix the slow-compile time issue.
---------
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
This:
1) Renames the current/old `xilem_core` to `xilem_web_core` and moves it
to the `xilem_web/xilem_web_core` folder
2) Creates a new `xilem_core`, which does not use (non-tuple) macros and
instead contains a `View` trait which is generic over the `Context` type
3) Ports `xilem` to this `xilem_core`, but with some functionality
missing (namely a few of the extra views; I expect these to
straightforward to port)
4) Ports the `mason` and `mason_android` examples to this new `xilem`,
with less functionality.
This continues ideas first explored in #235
The advantages of this new View trait are:
1) Improved support for ad-hoc views, such as views with additional
attributes.
This will be very useful for layout algorithms, and will also enable
native *good* multi-window (and potentially menus?)
2) A lack of macros, to better enable using go-to-definition and other
IDE features on the traits
Possible disadvantages:
1) There are a few more traits to enable the flexibility
2) It can be less clear what `Self::Element::Mut` is in the `rebuild`
function, because of how the resolution works
3) When implementing `View`, you need to specify the context (i.e.
`impl<State, Action> View<State, Action, [new] ViewCtx> for
Button<State, Action>`.
---------
Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
For some reason the recent version of Trunk refused to serve some of the
examples due to them missing the <html> tags. Adding the tags calms it
down and allows it to work again. Trivial change, but would save someone
the pain of having to fix examples before running them with trunk serve.
Co-authored-by: Alex Pyattaev <me@example.com>
Olivier FAURE