xilem/xilem_web/Cargo.toml

173 lines
3.9 KiB
TOML
Raw Normal View History

[package]
name = "xilem_web"
version = "0.1.0"
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"]
categories = ["gui", "web-programming"]
publish = false # Until it's ready
edition.workspace = true
license.workspace = true
repository.workspace = true
homepage.workspace = true
rust-version.workspace = true
[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"]
[lints]
workspace = true
[dependencies]
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
xilem_core = { workspace = true, features = ["kurbo"] }
peniko.workspace = true
wasm-bindgen = "0.2.92"
wasm-bindgen-futures = "0.4.42"
[dependencies.web-sys]
version = "0.3.69"
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",
"DomTokenList",
"Element",
"Event",
"AddEventListenerOptions",
"HtmlElement",
"Node",
"NodeList",
"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",
]