dnrops
/
xilem
mirror of https://github.com/linebender/xilem
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
xilem/xilem_web/Cargo.toml

184 lines
4.3 KiB
TOML
Raw Normal View History

Add wasm DOM implementation for xilem. I'm doing all the work in a single commit so it's easier to rebase. Below is a list of the individual changes I did - Squash prev commits - Remove top-level action handler (use Adapt instead). - Type events in the same way as elements (could also do attributes the same) - Allow users to avoid compiling the typed html/attributes/events - Use more specific types for mouse events from web_sys - change "click" from PointerEvent to MouseEvent (PointerEvent caused a panic on `dyn_into().unwrap()`)
2023-03-21 08:19:22 +08:00
[package]
Merge `xilem_html` and `xilem_svg` as `xilem_web` (#142) * Merged xilem_svg into xilem_html * Renamed xilem_html to xilem_web and removed xilem_svg * xilem_web: factor pointer to root, as it can be used for all Elements and refactor slightly * Rename example * xilem_web: Make BoxedView public * Rename cx.add_new_attribute_to_current_element -> add_attr_to_element and IntoAttributeValue::into_attribute_value -> IntoAttributeValue::into_attr_value * Add the `fill` and `stroke` attribute to the `g` element
2024-01-05 00:17:13 +08:00
name = "xilem_web"
Add wasm DOM implementation for xilem. I'm doing all the work in a single commit so it's easier to rebase. Below is a list of the individual changes I did - Squash prev commits - Remove top-level action handler (use Adapt instead). - Type events in the same way as elements (could also do attributes the same) - Allow users to avoid compiling the typed html/attributes/events - Use more specific types for mouse events from web_sys - change "click" from PointerEvent to MouseEvent (PointerEvent caused a panic on `dyn_into().unwrap()`)
2023-03-21 08:19:22 +08:00
version = "0.1.0"
Fill out and clean up all the `Cargo.toml` files. (#117)
2023-07-31 02:14:59 +08:00
description = "HTML DOM frontend for the Xilem Rust UI framework."
Rewrite xilem_web to support new xilem_core (#403) 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>
2024-06-28 16:30:18 +08:00
keywords = ["xilem", "html", "svg", "dom", "web", "ui"]
Fill out and clean up all the `Cargo.toml` files. (#117)
2023-07-31 02:14:59 +08:00
categories = ["gui", "web-programming"]
Move `xilem` onto a new `xilem_core`, which uses a generic View trait (#310) 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>
2024-06-06 23:16:36 +08:00
publish = false # Until it's ready
Fill out and clean up all the `Cargo.toml` files. (#117)
2023-07-31 02:14:59 +08:00
edition.workspace = true
Prepare `Cargo.toml` files for release. (#249) * Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry` to `xilem`. No directory structure changes yet to avoid merge conflicts before RustNL. * Base common dependencies on workspace dependencies. * Bump `masonry` version to `0.2.0`. * Remove some legacy docs.rs configuration inherited from Druid/Glazier that is no longer needed. * Unify ordering of properties.
2024-05-04 04:07:12 +08:00
license.workspace = true
Fill out and clean up all the `Cargo.toml` files. (#117)
2023-07-31 02:14:59 +08:00
repository.workspace = true
Prepare `Cargo.toml` files for release. (#249) * Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry` to `xilem`. No directory structure changes yet to avoid merge conflicts before RustNL. * Base common dependencies on workspace dependencies. * Bump `masonry` version to `0.2.0`. * Remove some legacy docs.rs configuration inherited from Druid/Glazier that is no longer needed. * Unify ordering of properties.
2024-05-04 04:07:12 +08:00
homepage.workspace = true
Correctly set `rust-version` in all `Cargo.toml`s (#438) Discovered in #432; this would otherwise cause errors for users of nightly (or 1.81 beta, due to be released next week)
2024-07-19 22:42:27 +08:00
rust-version.workspace = true
Add wasm DOM implementation for xilem. I'm doing all the work in a single commit so it's easier to rebase. Below is a list of the individual changes I did - Squash prev commits - Remove top-level action handler (use Adapt instead). - Type events in the same way as elements (could also do attributes the same) - Allow users to avoid compiling the typed html/attributes/events - Use more specific types for mouse events from web_sys - change "click" from PointerEvent to MouseEvent (PointerEvent caused a panic on `dyn_into().unwrap()`)
2023-03-21 08:19:22 +08:00
Migrate to the generic Linebender CI script. (#135)
2023-09-12 22:50:50 +08:00
[package.metadata.docs.rs]
all-features = true
# rustdoc-scrape-examples tracking issue https://github.com/rust-lang/rust/issues/88791
cargo-args = ["-Zunstable-options", "-Zrustdoc-scrape-examples"]
clippy: Configure via `lints` table in `Cargo.toml` (#185) As of Rust 1.74, lints can be configured within the `Cargo.toml` which allows us to not have to configure them in the source code as well as simplifying having a single configuration across an entire workspace. This is documented at: https://doc.rust-lang.org/nightly/cargo/reference/manifest.html#the-lints-section
2024-03-10 00:26:02 +08:00
[lints]
workspace = true
Add wasm DOM implementation for xilem. I'm doing all the work in a single commit so it's easier to rebase. Below is a list of the individual changes I did - Squash prev commits - Remove top-level action handler (use Adapt instead). - Type events in the same way as elements (could also do attributes the same) - Allow users to avoid compiling the typed html/attributes/events - Use more specific types for mouse events from web_sys - change "click" from PointerEvent to MouseEvent (PointerEvent caused a panic on `dyn_into().unwrap()`)
2023-03-21 08:19:22 +08:00
[dependencies]
xilem_web: Add async_repeat (#485) Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
2024-08-09 01:51:04 +08:00
futures = "0.3.30"
Prepare `Cargo.toml` files for release. (#249) * Rename classic `xilem` to `xilem_classic` and the new `xilem_masonry` to `xilem`. No directory structure changes yet to avoid merge conflicts before RustNL. * Base common dependencies on workspace dependencies. * Bump `masonry` version to `0.2.0`. * Remove some legacy docs.rs configuration inherited from Druid/Glazier that is no longer needed. * Unify ordering of properties.
2024-05-04 04:07:12 +08:00
peniko.workspace = true
Update dependencies. (#283) These are the results of running ```sh cargo upgrade --ignore-rust-version cargo update ``` in preparation for the upcoming release. These are semver compatible updates.
2024-05-08 03:38:40 +08:00
wasm-bindgen = "0.2.92"
xilem_web: Add a `MemoizedAwait` view (#448) 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>
2024-07-27 00:11:34 +08:00
wasm-bindgen-futures = "0.4.42"
xilem_web: Add async_repeat (#485) Co-authored-by: Philipp Mildenberger <philipp@mildenberger.me>
2024-08-09 01:51:04 +08:00
xilem_core = { workspace = true, features = ["kurbo"] }
Add wasm DOM implementation for xilem. I'm doing all the work in a single commit so it's easier to rebase. Below is a list of the individual changes I did - Squash prev commits - Remove top-level action handler (use Adapt instead). - Type events in the same way as elements (could also do attributes the same) - Allow users to avoid compiling the typed html/attributes/events - Use more specific types for mouse events from web_sys - change "click" from PointerEvent to MouseEvent (PointerEvent caused a panic on `dyn_into().unwrap()`)
2023-03-21 08:19:22 +08:00
[dependencies.web-sys]
Update dependencies. (#283) These are the results of running ```sh cargo upgrade --ignore-rust-version cargo update ``` in preparation for the upcoming release. These are semver compatible updates.
2024-05-08 03:38:40 +08:00
version = "0.3.69"
Add wasm DOM implementation for xilem. I'm doing all the work in a single commit so it's easier to rebase. Below is a list of the individual changes I did - Squash prev commits - Remove top-level action handler (use Adapt instead). - Type events in the same way as elements (could also do attributes the same) - Allow users to avoid compiling the typed html/attributes/events - Use more specific types for mouse events from web_sys - change "click" from PointerEvent to MouseEvent (PointerEvent caused a panic on `dyn_into().unwrap()`)
2023-03-21 08:19:22 +08:00
features = [
Rewrite xilem_web to support new xilem_core (#403) 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>
2024-06-28 16:30:18 +08:00
"console",
"CssStyleDeclaration",
"Document",
xilem_web: Fix `DomChildrenSplice::with_scratch` (#484) 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.
2024-08-05 17:08:34 +08:00
"DocumentFragment",
Rewrite xilem_web to support new xilem_core (#403) 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>
2024-06-28 16:30:18 +08:00
"DomTokenList",
"Element",
"Event",
"AddEventListenerOptions",
"HtmlElement",
"Node",
"NodeList",
xilem_web: Change `events::OnResize` to be a `ResizeObserver` (#494) Since [`on_resize`](https://developer.mozilla.org/en-US/docs/Web/API/Window/resize_event) on an `Element` is not really useful as it won't be called, we can reuse this event listener with a [`ResizeObserver`](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver/ResizeObserver) on itself, to be actually useful.
2024-08-09 16:40:24 +08:00
"ResizeObserver",
"ResizeObserverEntry",
"DomRectReadOnly",
Rewrite xilem_web to support new xilem_core (#403) 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>
2024-06-28 16:30:18 +08:00
"SvgElement",
"SvgaElement",
"SvgAnimateElement",
"SvgAnimateMotionElement",
"SvgAnimateTransformElement",
"SvgCircleElement",
"SvgClipPathElement",
"SvgDefsElement",
"SvgDescElement",
"SvgEllipseElement",
"SvgfeBlendElement",
"SvgfeColorMatrixElement",
"SvgfeComponentTransferElement",
"SvgfeCompositeElement",
"SvgfeConvolveMatrixElement",
"SvgfeDiffuseLightingElement",
"SvgfeDisplacementMapElement",
"SvgfeDistantLightElement",
"SvgfeDropShadowElement",
"SvgfeFloodElement",
"SvgfeFuncAElement",
"SvgfeFuncBElement",
"SvgfeFuncGElement",
"SvgfeFuncRElement",
"SvgfeGaussianBlurElement",
"SvgfeImageElement",
"SvgfeMergeElement",
"SvgfeMergeNodeElement",
"SvgfeMorphologyElement",
"SvgfeOffsetElement",
"SvgfePointLightElement",
"SvgfeSpecularLightingElement",
"SvgfeSpotLightElement",
"SvgfeTileElement",
"SvgfeTurbulenceElement",
"SvgFilterElement",
"SvgForeignObjectElement",
"SvggElement",
# "SvgHatchElement",
# "SvgHatchpathElement",
"SvgImageElement",
"SvgLineElement",
"SvgLinearGradientElement",
"SvgMarkerElement",
"SvgMaskElement",
"SvgMetadataElement",
"SvgmPathElement",
"SvgPathElement",
"SvgPatternElement",
"SvgPolygonElement",
"SvgPolylineElement",
"SvgRadialGradientElement",
"SvgRectElement",
"SvgScriptElement",
"SvgSetElement",
"SvgStopElement",
"SvgStyleElement",
"SvgsvgElement",
"SvgSwitchElement",
"SvgSymbolElement",
"SvgTextElement",
"SvgTextPathElement",
"SvgTitleElement",
"SvgtSpanElement",
"SvgUseElement",
"SvgViewElement",
"Text",
"Window",
"FocusEvent",
"HtmlInputElement",
"InputEvent",
"KeyboardEvent",
"MouseEvent",
"PointerEvent",
"WheelEvent",
"HtmlAnchorElement",
"HtmlAreaElement",
"HtmlAudioElement",
"HtmlBrElement",
"HtmlButtonElement",
"HtmlCanvasElement",
"HtmlDataElement",
"HtmlDataListElement",
"HtmlDetailsElement",
"HtmlDialogElement",
"HtmlDivElement",
"HtmlDListElement",
"HtmlEmbedElement",
"HtmlFieldSetElement",
"HtmlFormElement",
"HtmlHeadingElement",
"HtmlHrElement",
"HtmlIFrameElement",
"HtmlImageElement",
"HtmlInputElement",
"HtmlLabelElement",
"HtmlLegendElement",
"HtmlLiElement",
"HtmlLinkElement",
"HtmlMapElement",
"HtmlMediaElement",
"HtmlMenuElement",
"HtmlMeterElement",
"HtmlModElement",
"HtmlObjectElement",
"HtmlOListElement",
"HtmlOptGroupElement",
"HtmlOptionElement",
"HtmlOutputElement",
"HtmlParagraphElement",
"HtmlPictureElement",
"HtmlPreElement",
"HtmlProgressElement",
"HtmlQuoteElement",
"HtmlScriptElement",
"HtmlSelectElement",
"HtmlSlotElement",
"HtmlSourceElement",
"HtmlSpanElement",
"HtmlTableCaptionElement",
"HtmlTableCellElement",
"HtmlTableColElement",
"HtmlTableElement",
"HtmlTableRowElement",
"HtmlTableSectionElement",
"HtmlTemplateElement",
"HtmlTimeElement",
"HtmlTextAreaElement",
"HtmlTrackElement",
"HtmlUListElement",
"HtmlVideoElement",
Add wasm DOM implementation for xilem. I'm doing all the work in a single commit so it's easier to rebase. Below is a list of the individual changes I did - Squash prev commits - Remove top-level action handler (use Adapt instead). - Type events in the same way as elements (could also do attributes the same) - Allow users to avoid compiling the typed html/attributes/events - Use more specific types for mouse events from web_sys - change "click" from PointerEvent to MouseEvent (PointerEvent caused a panic on `dyn_into().unwrap()`)
2023-03-21 08:19:22 +08:00
]
xilem_web: Add hydration support, and a new view using it `Templated` (#495) 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>
2024-08-15 23:37:57 +08:00
[features]
default = ["hydration"]
hydration = []
xilem_web: Optimize element casting, and intern often used strings (e.g. "div") (#594) 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.
2024-09-18 02:49:15 +08:00
# This interns some often used strings, such as element tags ("div" etc.), which slightly improves performance when creating elements at the cost of a bigger wasm binary
intern_strings = ["wasm-bindgen/enable-interning"]