First-class shadow DOM?

[bsidhom]

Is it possible to use transparently enable shadow DOM when creating custom components? This is a cleaner/easier way to manage styles since it severs the inheritance chain (with a few exceptions, such as fonts). I'm a big fan of Lit and custom components in general for this reason.

I'm sure this can be done by directly manipulating the DOM, but I would much rather use the view! macro to automatically insert shadow nodes where desired. Not sure if this is already implemented and I've missed it or if there are design reasons to specifically not include this.

In the meantime, in order to use off-the-shelf components or more complex visual components with styles, I've been implementing custom elements in JS and then just inserting those elements into the view. Since custom elements are expose vanilla JS widgets, this works out of the box, and very cleanly.

It might also be nice to include the ability to create and register components as custom elements for use outside of Leptos, but I suspect this is out of scope. It's also not clear how you would use such a component as a third-party dependency since you'd need to import Leptos itself and any other Rust code used as WASM.

[gbj]

Design-wise: the biggest concern here (historically and still now) has been server-side rendering: specifically that there's no concept of a shadow root in HTML and so if you render HTML that includes scoped styles they will leak until some JS runs to attach the shadow roots.

There's now declarative shadow DOM and a polyfill for that, so that's one route of course. Or if you're just using CSR it doesn't really matter, and you can create a wrapper component that mounts its children to a shadow root.

[bsidhom]

Yeah, I did consider a wrapper component (I'm using CSR), but it's a bit cludgy. Declarative shadow DOM sounds like a decent solution though. Thanks!

[bsidhom]

On the note of using custom elements, is it possible to somehow register types for custom events? Or some other way to avoid having to downcast in each listener implementation?

[bsidhom]

I was just playing around with custom element and event definitions on the Rust side and couldn't figure out how to dispatch events from a custom element. As far as I can tell, most (if not all) other elements implement Deref<Target = Object>, which provides dispatch_event et al. However, html::Custom notably does not and also does not have any helpful fields that would allow you to access the underlying HTML element. The upshot is that you can't apparently get a ref to a custom element and then dispatch events on it, etc. I assume this is an oversight, but perhaps I'm missing another way to do this.

Also related: to create a custom event with a detail payload, I had to reach into web-sys and manually create it, as the necessary constructor variant doesn't exist on ev::CustomEvent. This one does seem to be an oversight, since the struct seems to closely match web_sys::CustomEvent. In particular, it has the deprecated nit_custom_event_with_can_bubble_and_cancelable_and_detail but not the detail constructor.

[gbj]

On the note of using custom elements, is it possible to somehow register types for custom events? Or some other way to avoid having to downcast in each listener implementation?

You could implement EventDescriptor for your custom event type, which would handle type inference via the on() method. I think using this, in practice, would rely on using the builder pattern, since the macro just has a built-in list of event names it recognizes and the others use the generic custom event type.

I was just playing around with custom element and event definitions on the Rust side and couldn't figure out how to dispatch events from a custom element. As far as I can tell, most (if not all) other elements implement Deref<Target = Object>, which provides dispatch_event et al. However, html::Custom notably does not and also does not have any helpful fields that would allow you to access the underlying HTML element.

An example might be helpful here. Something like this seems at least to compile for me:

#[component]
pub fn App() -> impl IntoView {
    let el_ref = NodeRef::<Custom>::new();
    Effect::new(move |_| {
        if let Some(el) = el_ref.get() {
            let event = Event::new("customEvent").unwrap();
            el.unchecked_ref::<EventTarget>().dispatch_event(&event);
        }
    });
    view! { <some-element node_ref=el_ref></some-element> }
}

Also related: to create a custom event with a detail payload, I had to reach into web-sys and manually create it, as the necessary constructor variant doesn't exist on ev::CustomEvent. This one does seem to be an oversight, since the struct seems to closely match web_sys::CustomEvent.

It is a re-export of web_sys::CustomEvent, so I'm not sure what the source of the discrepancies would be. Using web-sys seems very appropriate here, to me.

[bsidhom]

No dice. I believe this issue is as I described above where html::Custom does not implement Deref<Target = Object>. This is the compiler error I see: no method named dispatch_eventfound for structleptos::HtmlElement in the current scope.

If I instead create a ref to html::AnyElement, the closure seems to type check, but the ref can no longer be assigned, i.e., _ref=button_ref causes the following error: mismatched types expected struct `leptos::NodeRef<leptos::html::Custom>` found struct `leptos::NodeRef<AnyElement>`

[bsidhom]

Here's another indication that this is due to html::Custom not implementing Deref as the other elements. I can't get your snippet to compile even after useing JsCast and explicitly resolving the trait method:

#[component]
pub fn MyWidget() -> impl IntoView {
    use wasm_bindgen::JsCast;
    let el_ref = NodeRef::<html::Custom>::new();
    Effect::new(move |_| {
        if let Some(el) = el_ref.get() {
            let event = ev::Event::new("customEvent").unwrap();
            <HtmlElement<html::Custom> as JsCast>::unchecked_ref::<web_sys::EventTarget>(&el).dispatch_event(&event);
        }
    });
    view! { <some-element node_ref=el_ref></some-element> }
}

error[E0277]: the trait bound `wasm_bindgen::JsValue: From<leptos::HtmlElement<leptos::html::Custom>>` is not satisfied
  --> client/src/lib.rs:76:14
   |
76 |             <HtmlElement<html::Custom> as JsCast>::unchecked_ref::<web_sys::EventTarget>(&el).dispatch_event(&event);
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<leptos::HtmlElement<leptos::html::Custom>>` is not implemented for `wasm_bindgen::J
sValue`, which is required by `leptos::HtmlElement<leptos::html::Custom>: Into<wasm_bindgen::JsValue>`

I would blame my own environment (dependencies or clashing imports, etc.), but the upstream leptos docs clearly show that html::Custom does not implement Deref: https://docs.rs/leptos/latest/leptos/html/struct.Custom.html. Compare to <a> for example: https://docs.rs/leptos/latest/leptos/html/struct.A.html.

I'm surprised that it's working on your side. Are you using leptos::html::Custom or am I using the wrong path?

[gbj]

Not sure what to tell you. Here's a complete, working example: (All I did relative to the example code you shared earlier was adding the generic ::<Custom> to create_node_ref as I'd suggested earlier)

use leptos::html::Custom;
use leptos::*;
use wasm_bindgen::{JsCast, JsValue};
use web_sys::{CustomEvent, CustomEventInit, Event, EventTarget};

#[component]
pub fn App() -> impl IntoView {
    view! {
        <MyWidget on:foo-event=|ev| {
            web_sys::console::log_1(&ev);
        }/>
    }
}

#[component]
fn MyWidget() -> impl IntoView {
    let button_ref = create_node_ref::<Custom>();
    let on_click = move |event: ev::MouseEvent| {
        event.stop_propagation();
        let mut init = CustomEventInit::new();
        init.detail(&JsValue::from_str("payload"));
        let event = CustomEvent::new_with_event_init_dict("foo-event", &init).unwrap();
        let el = button_ref.get().unwrap();
        el.dispatch_event(&event).unwrap();
    };
    view! {
        <my-custom-button _ref=button_ref on:click=on_click>"Click me"</my-custom-button>
    }
}

Cargo.toml

[package]
name = "weird"
version = "0.1.0"
edition = "2021"

[dependencies]
leptos = { version = "0.6", features = ["csr"] }
web-sys = { version = "0.3", features = ["CustomEventInit"] }
wasm-bindgen = "0.2"

[bsidhom]

Well, that explains it. The full example doesn't compile for me. 😂

cargo build
...
warning: unused import: `JsCast`
 --> src/lib.rs:3:20
  |
3 | use wasm_bindgen::{JsCast, JsValue};
  |                    ^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused imports: `EventTarget`, `Event`
 --> src/lib.rs:4:45
  |
4 | use web_sys::{CustomEvent, CustomEventInit, Event, EventTarget};
  |                                             ^^^^^  ^^^^^^^^^^^

error[E0599]: no method named `dispatch_event` found for struct `leptos::HtmlElement` in the current scope
  --> src/lib.rs:24:12
   |
24 |         el.dispatch_event(&event).unwrap();
   |            ^^^^^^^^^^^^^^ method not found in `HtmlElement<Custom>`

For more information about this error, try `rustc --explain E0599`.
warning: `weird` (lib) generated 2 warnings
error: could not compile `weird` (lib) due to 1 previous error; 2 warnings emitted
warning: build failed, waiting for other jobs to finish...

In case anybody else experiences a similar breakage and wants do some sleuthing for diffs, here's my corresponding lockfile: https://gist.github.com/bsidhom/57e887904dd977bd93b509b85958c1dd. Not sure what's going on here but it's possibly an inconsistent transitive dep. At least I can rule out the wildcard wasm-bindgen prelude import, as this example doesn't use that.

[bsidhom]

OK, figured it out. I was building your example against the host machine triple rather than wasm32-unknown-unknown. Similarly, while trying to debug my own build, I was using the host target.

[bsidhom]

Thanks for all the pointers so far! It turns out that declarative shadow DOM only works for server-side rendering, since declarative DOM needs to be fully materialized at parse time. I took stab at wrapping shadow DOM in a component. Do you have any suggestions for how to improve it? Would something in this vein be appropriate for inclusion in Leptos proper? I assume there are better patterns for interfacing between Leptos and JS. Unfortunately, I had to include the cludgy extern block to bring in some JS bindings that were not available in web-sys. I'm also not happy with the untyped string styles, but this works for my purposes.

On the note of styles/templating: what steps does Leptos take at the moment to ensure that values are escaped/sanitized?

use std::ops::Deref;

use leptos::component;
use leptos::html;
use leptos::html::ElementDescriptor;
use leptos::view;
use leptos::Children;
use leptos::IntoView;
use wasm_bindgen::prelude::wasm_bindgen;
use wasm_bindgen::JsCast;
use wasm_bindgen::JsValue;
use web_sys::CssStyleSheet;
use web_sys::HtmlElement;
use web_sys::ShadowRootInit;
use web_sys::ShadowRootMode;

#[wasm_bindgen(start)]
fn main() {
    console_error_panic_hook::set_once();
    leptos::mount_to_body(|| view! { <App/> });
}

#[component]
fn App() -> impl IntoView {
    let host = html::main;
    let styles = vec![
        r###"
        :host {
            font-family: "Roboto";
            color: orange;
        }
        "###,
    ];
    view! {
        <Shadow host styles>
            <UnprotectedParagraph/>
            <ProtectedParagraph/>
        </Shadow>
    }
}

#[component]
fn UnprotectedParagraph() -> impl IntoView {
    view! { <p>"Styled text!!"</p> }
}

#[component]
fn ProtectedParagraph() -> impl IntoView {
    let host = html::div;
    // Prevent the color and font styles from piercing shadow DOM.
    let styles = vec![
        r###"div {
            all: initial;
        }"###,
    ];
    view! {
        <Shadow host styles>
            <div>
                <p>"Plaintext..."</p>
            </div>
        </Shadow>
    }
}

#[component]
fn Shadow<F, Elem, IntoElem>(
    host: F,
    #[prop(default = vec![])] styles: Vec<&'static str>,
    children: Children,
) -> impl IntoView
where
    F: FnOnce() -> html::HtmlElement<Elem>,
    Elem: ElementDescriptor + Deref<Target = IntoElem>,
    IntoElem: JsCast,
{
    let host = host();
    let shadow_host: &web_sys::Element = host.deref().unchecked_ref();
    let shadow_root = shadow_host
        .attach_shadow(&ShadowRootInit::new(ShadowRootMode::Open))
        .unwrap();
    {
        let shadow_root: &ShadowRootExt = shadow_root.unchecked_ref();
        let sheets = shadow_root.adopted_style_sheets();
        for &style_str in styles.iter() {
            let style = CssStyleSheet::new().expect("construct stylesheet");
            style
                .replace_sync(style_str)
                .expect("add style rule to constructed stylesheet");
            sheets.push(&style);
        }
    }
    leptos::mount_to(shadow_root.unchecked_into::<HtmlElement>(), children);
    host
}

#[wasm_bindgen]
extern "C" {
    pub type ShadowRootExt;
    pub type StyleSheetList;

    #[wasm_bindgen(method, getter = adoptedStyleSheets)]
    pub fn adopted_style_sheets(this: &ShadowRootExt) -> StyleSheetList;

    #[wasm_bindgen(method)]
    pub fn push(this: &StyleSheetList, value: &JsValue);
}

[bsidhom]

Turns out this does not work as desired. If you try to create a component under a Shadow component as defined above and add event listeners to the sub-component (e.g., click or input events), the event target is resolved as the shadow root rather than the inner element. This is strange and unexpected because the listeners are fully defined and resolved within the same shadow DOM. I assume that the breakage is due to how Leptos manipulates the DOM, since it's not aware of the shadow DOM when it's attaching listeners, etc.

[gbj]

You can opt out of event delegation using on:click:undelegated etc. Shadow DOM re-targeting in event delegation is possible but not (yet?) implemented, and afaik you're the first person ever to try this. Feel free to make a PR, and I'm happy to point you to the right place.

[ActuallyHappening]

I'm still interested in this, maybe gated behind the csr feature for the moment

[gbj]

Are you interested in working on implementing it?

[ActuallyHappening]

I've just made a workaround for me at the moment, sorry no
This does fit into the "when I don't need to work to pay for everything" list though