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.
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>
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.
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>
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>
Philipp Mildenberger