Events
Introduction
Yew integrates with the web-sys
crate and
uses the events from that crate. The table below lists all of the web-sys
events that are accepted in the html!
macro.
You can still add a Callback
for an event that is not listed in the table
below, see Manual event listener.
Event Types
All the event types mentioned in the following table are re-exported under yew::events
.
Using the types from yew::events
makes it easier to ensure version compatibility than
if you were to manually include web-sys
as a dependency in your crate because you will not
end up using a version which conflicts with the version that Yew specifies.
The event listener name is the expected name when adding an event Callback
in the html
macro:
use yew::prelude::*;
html! {
<button onclick={Callback::from(|_| ())}>
// ^^^^^^^ event listener name
{ "Click me!" }
</button>
};
The event name is the listener without the "on" prefix, therefore, the onclick
event listener
listens for click
events. See the end of this page for a full list of available event with their types.
Event bubbling
Events dispatched by Yew follow the virtual DOM hierarchy when bubbling up to listeners. Currently, only the bubbling phase
is supported for listeners. Note that the virtual DOM hierarchy is most often, but not always, identical to the actual
DOM hierarchy. The distinction is important when working with portals and other
more advanced techniques. The intuition for well-implemented components should be that events bubble from children
to parents. In this way the hierarchy in your coded html!
is the one observed by event handlers.
If you are not interested in event bubbling, you can turn it off by calling
yew::set_event_bubbling(false);
before starting your app. This speeds up event handling, but some components may break from not receiving the events they expect. Use this with care!
Event delegation
It can be surprising that event listeners are not directly registered on the element where they are rendered. Instead, events are delegated from the subtree root of the Yew app. Still, events are delivered in their native form, and no synthetic form is created. This can lead to mismatches between the event you would expect in HTML listeners and those showing up in Yew.
-
Event::current_target
points to the Yew subtree root instead of the element the listener is added on. UseNodeRef
if you want access to the underlyingHtmlElement
. -
Event::event_phase
is alwaysEvent::CAPTURING_PHASE
. Internally, the event will behave as if it was in the bubbling phase, the event propagation is replayed and the event bubbles up, i.e. event listeners higher up in the virtual DOM will trigger after event listeners below them. Currently, capturing listeners is not supported by Yew.This also means that events registered by Yew will usually fire before other event listeners.
Typed event target
In this section target (Event.target
)
is always referring to the element at which the event was dispatched from.
This will not always be the element at which the Callback
is placed.
In event Callback
s you may want to get the target of that event. For example, the
change
event gives no information but is used to notify that something has changed.
In Yew getting the target element in the correct type can be done in a few ways and we will go through
them here. Calling web_sys::Event::target
on an event returns an optional web_sys::EventTarget
type, which might not seem very useful when you want to know the value of your input element.
In all the approaches below we are going to tackle the same problem, so it is clear where the approach differs as opposed to the problem at hand.
The Problem:
We have an onchange
Callback
on my <input>
element and each time it is invoked we want to send
an update Msg
to our component.
Our Msg
enum looks like this:
pub enum Msg {
InputValue(String),
}
Using JsCast
The wasm-bindgen
crate has
a useful trait; JsCast
which allows us to hop and skip our way to the type we want, as long as it implements JsCast
. We can
do this cautiously, which involves some runtime checks and failure types like Option
and Result
,
or we can do it dangerously.
Enough talk, more code:
[dependencies]
# need wasm-bindgen for JsCast
wasm-bindgen = "0.2"
use wasm_bindgen::JsCast;
use web_sys::{EventTarget, HtmlInputElement};
use yew::prelude::*;
#[function_component]
fn MyComponent() -> Html {
let input_value_handle = use_state(String::default);
let input_value = (*input_value_handle).clone();
let on_cautious_change = {
let input_value_handle = input_value_handle.clone();
Callback::from(move |e: Event| {
// When events are created the target is undefined, it's only
// when dispatched does the target get added.
let target: Option<EventTarget> = e.target();
// Events can bubble so this listener might catch events from child
// elements which are not of type HtmlInputElement
let input = target.and_then(|t| t.dyn_into::<HtmlInputElement>().ok());
if let Some(input) = input {
input_value_handle.set(input.value());
}
})
};
let on_dangerous_change = Callback::from(move |e: Event| {
let target: EventTarget = e
.target()
.expect("Event should have a target when dispatched");
// You must KNOW target is a HtmlInputElement, otherwise
// the call to value would be Undefined Behaviour (UB).
// Here we are sure that this is input element so we can convert it to the appropriate type without checking
input_value_handle.set(target.unchecked_into::<HtmlInputElement>().value());
});
html! {
<>
<label for="cautious-input">
{ "My cautious input:" }
<input onchange={on_cautious_change}
id="cautious-input"
type="text"
value={input_value.clone()}
/>
</label>
<label for="dangerous-input">
{ "My dangerous input:" }
<input onchange={on_dangerous_change}
id="dangerous-input"
type="text"
value={input_value}
/>
</label>
</>
}
}
The methods from JsCast
are dyn_into
and unchecked_into
and you can probably see, they allowed
us to go from EventTarget
to HtmlInputElement
.
The dyn_into
method is cautious because at
runtime it will check whether the type is actually a HtmlInputElement
and if not return an
Err(JsValue)
, the JsValue
is a catch-all type and is essentially giving you back the object to try again.
At this point you might be thinking... when is the dangerous version ok to use? In the case above it
is safe1 as we've set the Callback
on to an element with no children so the target can
only be that same element.
1 As safe as anything can be when JS land is involved.
Using TargetCast
It is highly recommended to read Using JsCast first!
TargetCast
was designed to feel very similar to JsCast
- this is to allow new users to get a feel
for the behaviour of JsCast
but with the smaller scope of events and their targets.
TargetCast
vs JsCast
is purely preference, you will find that TargetCast
implements something
similar to what you would using JsCast
.
The TargetCast
trait is built on top of JsCast
and is specialized towards getting typed event
targets from events.
TargetCast
comes with Yew so no need to add a dependency in order to use the trait methods on events
but it works in a very similar way to JsCast
.
use web_sys::HtmlInputElement;
use yew::prelude::*;
#[function_component]
fn MyComponent() -> Html {
let input_value_handle = use_state(String::default);
let input_value = (*input_value_handle).clone();
let on_cautious_change = {
let input_value_handle = input_value_handle.clone();
Callback::from(move |e: Event| {
let input = e.target_dyn_into::<HtmlInputElement>();
if let Some(input) = input {
input_value_handle.set(input.value());
}
})
};
let on_dangerous_change = Callback::from(move |e: Event| {
// You must KNOW target is a HtmlInputElement, otherwise
// the call to value would be Undefined Behaviour (UB).
input_value_handle.set(e.target_unchecked_into::<HtmlInputElement>().value());
});
html! {
<>
<label for="cautious-input">
{ "My cautious input:" }
<input onchange={on_cautious_change}
id="cautious-input"
type="text"
value={input_value.clone()}
/>
</label>
<label for="dangerous-input">
{ "My dangerous input:" }
<input onchange={on_dangerous_change}
id="dangerous-input"
type="text"
value={input_value}
/>
</label>
</>
}
}
If you followed the advice above and read about JsCast
, or know the trait, you can probably
see that TargetCast::target_dyn_into
feels similar to JsCast::dyn_into
but specifically
does the cast on the target of the event. TargetCast::target_unchecked_into
is similar to
JsCast::unchecked_into
, and as such all the same warnings above JsCast
apply to TargetCast
.
Using NodeRef
NodeRef
can be used instead of querying the event given to a Callback
.
use web_sys::HtmlInputElement;
use yew::prelude::*;
#[function_component]
fn MyComponent() -> Html {
let input_node_ref = use_node_ref();
let input_value_handle = use_state(String::default);
let input_value = (*input_value_handle).clone();
let onchange = {
let input_node_ref = input_node_ref.clone();
Callback::from(move |_| {
let input = input_node_ref.cast::<HtmlInputElement>();
if let Some(input) = input {
input_value_handle.set(input.value());
}
})
};
html! {
<>
<label for="my-input">
{ "My input:" }
<input ref={input_node_ref}
{onchange}
id="my-input"
type="text"
value={input_value}
/>
</label>
</>
}
}
Using NodeRef
, you can ignore the event and use the NodeRef::cast
method to get an
Option<HtmlInputElement>
- this is optional as calling cast
before the NodeRef
has been
set, or when the type doesn't match will return None
.
You might also see by using NodeRef
we don't have to send the String
back into state as we always access to input_node_ref
- so we could do the following:
use web_sys::HtmlInputElement;
use yew::prelude::*;
#[function_component]
fn MyComponent() -> Html {
let input_node_ref = use_node_ref();
let onchange = {
let input_node_ref = input_node_ref.clone();
Callback::from(move |_| {
if let Some(input) = input_node_ref.cast::<HtmlInputElement>() {
let value = input.value();
// do something with value
}
})
};
html! {
<>
<label for="my-input">
{ "My input:" }
<input ref={input_node_ref}
{onchange}
id="my-input"
type="text"
/>
</label>
</>
}
}
Which approach you take depends on your component and your preferences, there is no blessed way per se.