Support for wasm-bindgen

[FrankenApps]

I think it would be great if glam could expose a feature that would allow passing the Vecs and Mats via wasm-bindgen, similar to how the integration with serde already works.

In my opinion this feature would be useful, because I can imagine that there is a whole potential user base that needs fast SIMD accelerated linear algebra in the browser or in nodejs.

Without this feature I had to resort to implementing my own wrapper types just for passing the values from javascript to webassembly:

use glam::Vec4;
#[cfg(target_arch = "wasm32")]
use wasm_bindgen::prelude::*;

/// A four-dimensional vector mainly used to pass data via `wasm-bindgen`.
#[cfg_attr(target_arch = "wasm32", wasm_bindgen)]
#[derive(Debug, Clone, Copy)]
pub struct Vector4 {
    pub x: f32,
    pub y: f32,
    pub z: f32,
    pub w: f32,
}

#[cfg_attr(target_arch = "wasm32", wasm_bindgen)]
impl Vector4 {
    /// Creates a new [Vector4].
    ///
    /// Arguments:
    /// * `x`: The x component of the vector.
    /// * `y`: The y component of the vector.
    /// * `z`: The z component of the vector.
    /// * `w`: The w component of the vector.
    #[cfg_attr(target_arch = "wasm32", wasm_bindgen(constructor))]
    pub fn new(x: f32, y: f32, z: f32, w: f32) -> Self {
        Self { x, y, z, w }
    }
}

impl Vector4 {
    /// Creates a new [Vector4] from a [Vec4].
    ///
    /// Arguments:
    ///
    /// * `vec4`: The [Vec4] that will be converted.
    pub fn from_vec4(vec4: Vec4) -> Self {
        Self {
            x: vec4.x,
            y: vec4.y,
            z: vec4.z,
            w: vec4.w,
        }
    }

    /// Creates a new [Vec4] from this [Vector4]
    pub fn to_vec4(&self) -> Vec4 {
        Vec4::new(self.x, self.y, self.z, self.w)
    }
}

impl Default for Vector4 {
    fn default() -> Self {
        Self {
            x: 0f32,
            y: 0f32,
            z: 0f32,
            w: 0f32,
        }
    }
}

impl std::fmt::Display for Vector4 {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "({}, {}, {}, {})", self.x, self.y, self.z, self.w)
    }
}

using something like this it now becomes possible to use the Vector4 in javascript for example like this:

let backgroundColor = new Vector4(0, 0, 0, 255);
console.log(backgroundColor.w); // 255
backgroundColor.w = 7;
console.log(backgroundColor.w); // = 7

and then I use to_vec4() to convert it to an actual glam::Vec4.

I think having built-in support for at least this basic use case of passing values around would probably be quite beneficial for some users. I am however not sure if it would make sense to also expose all the associated functions to wasm. This almost feels like it would be a bit to much, but I am not sure.

If you can give me a hint on how to specify the wasm-bindgen attribute on for example a Vec4 and if you would be interested in that feature I could go ahead and make a Draft PR for this...

[bitshifter]

This seems like a reasonable request, however I don't know much about how wasm-bindgen works. Does every method need to be exposed or is it just a case of adding #[cfg_attr(target_arch = "wasm32", wasm_bindgen)] to the type?

Would there be a way to automate testing of this?

[FrankenApps]

It depends. Thats why I had trouble to figure out how this could be done given the architecture of glam. It is possible to annotate structs or impl blocks with the attribute. When an impl block is annotated with wasm_bindgen all pub functions inside are exposed. However I am not sure how to do this here, because as far as I can tell almost all associated functions are implemented using macros.

Apart from that a method to also expose the fields (x, y, etc.) would be needed. For example a Vec3 seems to be some form of generic trait under the hood and not a struct as in the case shown in my original post...

I have no prior experience regarding tests with wasm_bindgen, but it seems that there is at least experimental support for tests.

Btw. I am sure you already know this, but #[cfg_attr(target_arch = "wasm32", wasm_bindgen)] would unconditionally enable wasm-bindgen for wasm targets (which might be desired or not).

[bitshifter]

There is usually only ever one impl for each type, so it that sense there should be a limited number of places where annotations would be required.

The x, y, etc. accessors use the Deref and DerefMut trait, no idea if wasm-bindgen can expose those.

If should be possible to do something like #[cfg_attr(all(target_arch = "wasm32", feature="glam-wasm-bindgen"), wasm_bindgen)] so people can opt in to this.