Implement `wasm_bindgen` conversion traits for `Uuid` #844

New issue

Open

opened 2025-10-08 09:10:50 -05:00 by demhadais · 4 comments

demhadais commented

2025-10-08 09:10:50 -05:00

(Migrated from github.com)

Hi! I read #653, and I was wondering if I could submit a simple PR implementing the conversion traits (like FromWasmAbi and friends) that just treats a Uuid to a string (converting it to and from Rust with Uuid's FromStr and Display impls). I think this is reasonable given that the JavaScript standard library produces v4 UUIDs as strings by default.

If this makes sense, I'd love to submit a PR with these trait implementations!

Hi! I read #653, and I was wondering if I could submit a simple PR implementing the conversion traits (like [`FromWasmAbi`](https://docs.rs/wasm-bindgen/latest/wasm_bindgen/convert/trait.FromWasmAbi.html) and friends) that just treats a `Uuid` to a string (converting it to and from Rust with Uuid's `FromStr` and `Display` impls). I think this is reasonable given that the JavaScript standard library [produces v4 UUIDs as strings by default](https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID). If this makes sense, I'd love to submit a PR with these trait implementations!

🚀 1

KodrAus commented

2025-10-13 17:45:50 -05:00

(Migrated from github.com)

Thanks for pointing that out @demhadais. That's certainly a point in favor of representing UUIDs as strings, but still isn't a single obviously correct representation for all possible users. I would be in favor of implementing the traits on our formatting adapters like Hyphenated that represented them as strings as a starting point.

Thanks for pointing that out @demhadais. That's certainly a point in favor of representing UUIDs as strings, but still isn't a single obviously correct representation for all possible users. I would be in favor of implementing the traits on our formatting adapters like `Hyphenated` that represented them as strings as a starting point.

demhadais commented

2025-10-14 00:29:39 -05:00

(Migrated from github.com)

@KodrAus I see - that makes sense to me. I'll get started on a PR, though you should note that the wasm-bindgen module in which these traits reside is explicitly marked as "unstable". Specifically, "no stability guarantees are provided". I thought this wasn't an issue, but the maintainer of jiff (a datetime crate) brought up good points in Burntsushi/jiff#424 because I wanted to submit a similar PR for the types in that crate. To summarize, even minor version upgrades might present breaking changes, which could pose a problem for uuid. I'm not sure how much of a problem that's actually going to be; taking a cursory glance at the history of this module, I don't see much actual change - it's mostly documentation stuff and non-breaking changes.

In any case, I did submit wasm-bindgen/wasm-bindgen#4726, but if you'd prefer to wait for a response to that issue and see if there are stronger semver-compatibility guarantees, that would also make sense to me.

Thanks!

@KodrAus I see - that makes sense to me. I'll get started on a PR, though you should note that the [`wasm-bindgen` module](https://docs.rs/wasm-bindgen/latest/wasm_bindgen/convert/index.html) in which these traits reside is explicitly marked as "unstable". Specifically, "no stability guarantees are provided". I thought this wasn't an issue, but the maintainer of `jiff` (a datetime crate) brought up good points in Burntsushi/jiff#424 because I wanted to submit a similar PR for the types in that crate. To summarize, even minor version upgrades might present breaking changes, which could pose a problem for uuid. I'm not sure how much of a problem that's actually going to be; taking a cursory glance at the history of this module, I don't see much actual change - it's mostly documentation stuff and non-breaking changes. In any case, I did submit wasm-bindgen/wasm-bindgen#4726, but if you'd prefer to wait for a response to that issue and see if there are stronger semver-compatibility guarantees, that would also make sense to me. Thanks!

KodrAus commented

2025-10-15 14:18:12 -05:00

(Migrated from github.com)

Ah yes, without wasm-bindgen being stable we’d need to add this behind a feature flag and using a compiler variable the same way we do for zerocopy. If you did want to take a crack at this I can give you some pointers on how that works.

Ah yes, without `wasm-bindgen` being stable we’d need to add this behind a feature flag and using a compiler variable the same way we do for `zerocopy`. If you did want to take a crack at this I can give you some pointers on how that works.

niusia-ua commented

2026-04-18 01:37:44 -05:00

(Migrated from github.com)

+1. This feature would be really useful.

Currently, I convert the Uuid type manually, which is a bit verbose and repetitive:

  /// Undoes the last edit in the pattern with the given ID.
  pub fn undo(&self, pattern_id: &str) -> Result<(), Error> {
    let pattern_id = uuid::Uuid::parse_str(pattern_id)?;
    let events = self.run(|editor| editor.undo(&pattern_id))?;
    self.send_events(&events)
  }

Being able to declare methods like fn undo(&self, pattern_id: &uuid::Uuid) (or an owned type) will remove much boilerplate from my code.

+1. This feature would be really useful. Currently, I convert the `Uuid` type manually, which is a bit verbose and repetitive: ```rust /// Undoes the last edit in the pattern with the given ID. pub fn undo(&self, pattern_id: &str) -> Result<(), Error> { let pattern_id = uuid::Uuid::parse_str(pattern_id)?; let events = self.run(|editor| editor.undo(&pattern_id))?; self.send_events(&events) } ``` Being able to declare methods like `fn undo(&self, pattern_id: &uuid::Uuid)` (or an owned type) will remove much boilerplate from my code.