How to get dimensions of the parent element for a mouseover / hover event?

[austinvhuang]

Moving this question discussion from the discord to here per @mc1098 's suggestion.

What's the best way for for a mouse callback to get dimensions of the parent element the mouse is in?

For example, I need to calculate where the mouse is hovering horizontally proportional to the width of the component in a component to pass some values to an API. The values I get from offset_x() of the MouseEvent are in absolute pixels. I need to get the parent element's total width to calculate the proportion.

seems related to https://stackoverflow.com/questions/3234256/find-mouse-position-relative-to-element but with yew instead of jquery/js

I also see https://docs.rs/yew-component-size/0.1.0/yew_component_size/ but that dependency might be a little bit too bleeding edge (1 star on the repo currently).

Also some related discussion here #329 but this thread is 3 years old.

[mc1098]

Thank you for moving it over to the Discussions :) hopefully this can then help others new to Yew/ web_sys and wasm_bindgen too.

I'll do a quick overview of some of the topics then as we run through the Rust code I'll hit on those topics again - so you can get the overview, then an example of how that works for this question :)

A detour down web_sys lane

So before going any further web_sys is a crate that provides Rust bindings to browser web APIs. So any element, event type can be found in web_sys, actually that link is even better than this because you can search through web_sys, js_sys, wasm_bindgen, and wasm_bindgen_futures so if your looking at vanilla JS you will probably find bindings to it using that search.

Derefs all the way down

When you checkout web_sys you might notice that most types implement std::ops::Deref and they do this to help simulate JS inheritance. An example here might help, consider the HtmlTextAreaElement (basically the object representing a textarea) this implements Deref for HtmlElement which does the same for Element then again for Node. This is to say that when checking an object for a field or function - check the derefs too!

Importance of JsCast (from wasm_bindgen)

Rust has a strong type system and JS...doesn't 😞 So in order for Rust to maintain these strong types but still be convenient the wasm team came up with a pretty neat trait JsCast. It's job is to help you move from one JS "type" to another, which sounds vague but it means that if you have an EventTarget which you know is really an Element you can use the functions of JsCast to jump from one type to the other. It's a nice trait to get to know when working with web_sys, wasm_bindgen, js_sys - you'll notice lots of types will implement JsCast from those crates.

Back to the question

So I'm essentially going to go through the vanilla JS answer from that SO question but with Rust and Yew. This should hopefully be pretty helpful for converting any vanilla JS web code to Rust and Yew.

For convenience here is the vanilla JS answer from SO:

document.getElementById('clickme').onclick = function clickEvent(e) {
      // e = Mouse click event.
      var rect = e.target.getBoundingClientRect();
      var x = e.clientX - rect.left; //x position within the element.
      var y = e.clientY - rect.top;  //y position within the element.
      console.log("Left? : " + x + " ; Top? : " + y + ".");
    }

Now Rust:

// use your imagination that we are inside a Component impl block :)
fn view(&self) -> Html {
    let onmousemove = self.link.callback(move |e: web_sys::MouseEvent| {
        if let Some(target) = e.target().and_then(|event_target: web_sys::EventTarget| {
            event_target.dyn_into::<web_sys::Element>().ok()
        }) {
            let rect: web_sys::DomRect = target.get_bounding_client_rect();
            let x = (e.client_x() as f64) - rect.left();
            let y = (e.client_y() as f64) - rect.top();
            web_sys::console::log_1(&format!("Left? : {} ; Top? : {}", x, y).into());
        }
    });
    html! {
        <div onmouseover={onmouseover} />
    }
}

I've tried to be quite verbose with the types used so that it's easier to understand why some of the conversion are required!
So nearly all¹ the on** event handlers in Yew will require a Callback that takes in an event that mirrors the ones from JS and that actual types are found in web_sys. This is a list of all the supported event handlers and their respective events for Yew.

¹oninput and onchange are unique and have special types for Yew.

In this case for onmouseover the event type is web_sys::MouseEvent. If you look at the MouseEvent link you might be surprised to not find the target function (for Rust you will find most JS object fields are in the form of getter and setter functions), however, thinking back to the Deref section you can follow the implementations down from MouseEvent to UiEvent to Event and look at that Event has a target function. The target function returns an Option<web_sys::EventTarget>, because events can be created without a target then passed to event handlers manually it's possible (but unlikely) that target is undefined, thus the option.

First step down, we have an optional target so we use and_then to map our target into an Element because the bounding client rect is available on Elements and not EventTargets. In comes JsCast, for our use case we only care if the target was our Element so, we use dyn_into providing the JsCast type we want to convert into (in this case an Element). dyn_into returns a Result<Element, JsValue>² which can be converted into an Option<Element> using ok().

²I explain bit more about JsValue in the console log section below!

Second step down, we have ourselves a target Element in our if let. You can try and call get_bounding_client_rect on Element, however, if you haven't activated the DomRect feature from the web_sys crate this function won't exist for Element. Once you have the feature activated then you can call get_bounding_client_rect on Element and where you would use fields in JS you use functions in Rust calling left() instead of using left. It's worth noting that web_sys::DomRect::left (and top) returns an f64 whereas e.client_x()(MouseEvent::client_x) returns an i32 so casting is required here.

Final step! logging the output to the console. There are lots of more pleasant ways to do this weblog comes to mind, but there are others too. Anyway, we are on the web_sys band wagon so might as well use it for logging to the console, gives me an excuse to sneak in an explanation about JsValue too.

The JsValue is where all the derefs lead to! when I first explained about how derefs were used in web_sys / wasm_bindgen I stopped at Node but actually it keeps going to EventTarget then Object (yes, representing a JS Object type) to lastly a JsValue. So a JsValue is kind of a catch all type, if a function can accept any JS type then it will often use JsValue.
The web_sys::console::log_1 function is expecting a &JsValue as input so this pretty much a reference to a catch all JS type - but we really want to use a normal String from Rust...luckily JsValue has quite a few From implementations for Rust types one of them being for String. This is why the syntax is using a .into() at the end of the format macro.

phew that was a lot! hopefully this helps not only answer the question but kind of give a overview of how web_sys, wasm_bindgen and Yew all work in a way that is similar to how vanilla JS works in the web.

Note: This was over what you were asking but this is quite a nice example to cover a lot of these topics so I did hijack the question a bit to add more information which will hopefully be helpful to others in the future doing something similar!

[austinvhuang]

Thanks for the detailed explanation @mc1098. This makes me realize how much incidental complexity happens modeling the typed/untyped boundary between languages. I suppose that's just the price to pay in order to write javascript in rust.

This was very helpful to peel back the layers of magic.

[mc1098]

I'm glad it helped :). if you think it has covered the question then please mark it as answered (think it will help others find this post!) and if not then let me know.

Yew does cover some of the magic, see this section on sending closures to JS as an example of part of what Callbacks do behind the scene. I'd look at crates like gloo which are some common abstractions over web_sys, js_sys, you'll see this recommendation more when v0.19.0 of Yew lands :)