Recommended way to attach client-side callbacks?

[M1cha]

Within on:click I want to call a JS-function. That obviously only works on the client and thanks to wasm_bindgen also only compiles on the client. So if I want to write code that works with all SSR/CSR modes, how can I do that?

First a related question: How do callbacks work with SSR? Are they ignored on the server and simply attached by the client? In other words: Do I have to worry about callbacks accidental being run on the server in certain configurations?

Anyway, this seems to work:

let onclick = move |ev| {
    cfg_if! { if #[cfg(feature = "hydrate")] {
        log::info!("sup?");
    }}
};

But this causes lots of "unused" warnings depending on the implementation:

• ev. I could just rename it to _ev but that would suppress warnings when I actually don't use it on the client
• if I want to use a node_ref I have to compile that for the server as well so I can't disable it via cfg_if completely and I'll get warnings for not using that ref for the ssr binary.

Also, is there any overhead to having that empty callback on the server in first place?

[gbj]

Within on:click I want to call a JS-function. That obviously only works on the client and thanks to wasm_bindgen also only compiles on the client. So if I want to write code that works with all SSR/CSR modes, how can I do that?

This doesn't follow for me... wasm-bindgen types in general do compile for the server, they just panic if you try to actually call them. Maybe an example of what you're actually trying to do here with wasm-bindgen would help. But in general, it's also perfectly possible to do something like

#[cfg(not(feature = "ssr"))]
#[wasm_bindgen /* ... */]
fn my_js_function() { /* */ }

#[cfg(feature = "ssr")]
fn my_js_function() { /* */ }

First a related question: How do callbacks work with SSR? Are they ignored on the server and simply attached by the client? In other words: Do I have to worry about callbacks accidental being run on the server in certain configurations?

Here's what adding an event handler with on:whatever does in SSR:

leptos/leptos_dom/src/html.rs

Lines 941 to 947 in 3c6748b

	#[cfg(not(all(target_arch = "wasm32", feature = "web")))]
	{
	_ = event;
	_ = event_handler;
	self
	}

This will never be run on the server.

Also, is there any overhead to having that empty callback on the server in first place?

See above; not really.

[M1cha]

This doesn't follow for me... wasm-bindgen types in general do compile for the server, they just panic if you try to actually call them. Maybe an example of what you're actually trying to do here with wasm-bindgen would help

You're right, while there are dependencies that don't compile on WASM, wasm-bindgen is not one of them. I usually separate server and client dependencies via optional = true and [features] though (to reduce compile times, and it seems cleaner to me). Meaning wasm-bindgen simply isn't a crate available to my server binary.

But in general, it's also perfectly possible to do something like

Functions make code more complex than closures when needing multiple variables, e.g. refs. My current solution is this:

let ref = create_node_ref::<Div>(cx);

#[cfg(feature = "hydrate")]
let onclick = move |_ev| {
    ref.get();
});

#[cfg(not(feature = "hydrate"))]
let onclick = move |_ev| {
    let _ = ref;
});

view! {cx, <div ref_=ref />}

Would there be a way to change to view macro so it doesn't use the value of the handler at all in SSR mode? That way it'd be legal to put create_node_ref behind cfg as well.

[gbj]

The server side of your app crate is already compiling wasm-bindgen as part of Leptos to support the ability to have ordinary on:click and so on and have the events typed properly via web-sys etc., so I don't think it would add any compile time at all to use it to generate a binding that you'll call in an event listener.

Changing the view macro so it doesn't use the value of the handler at all in SSR mode would generate "unused variable" warnings for all event listeners while running in SSR mode, which is surely not desirable.

It seems like there are a few different options here, and which one you want to use is a matter of personal preference, but there aren't really technical limitations on how you're able to do it. In general, it's possible to compile (but not call) browser-only code for the server, so any of these options work.

[M1cha]

so I don't think it would add any compile time at all to use it to generate a binding that you'll call in an event listener.

That is not true, the other way around though(especially when crates have native dependencies). So I just like to separate dependencies so it's very clear which side needs what.

So what I take from this is that the recommended way is to not separate dependencies. And if one wants to do that anyway they have to use one of the solutions/workarounds mentioned in this discussion because there doesn't seem to be a generic way to remove the warning for both client and server. That totally answers my question and I'm happy with that, thanks for your quick responses 👍