I keep finding places where I need to use UUIDs - mostly because they are recognizable as such. I’m wondering if we should look at exposing an API to generate conforming RFC4122 UUIDv4s on the Web.
Something like: https://gist.github.com/bentranter/ed524091170137a72c1d54d641493c1f
What’s wrong with leaving it in a function like the one you linked?
Technically, nothing (apart that it’s annoying to have to have a special library just for that)… but it seems like there is so many places where one can use a UUID, that it makes sense to just expose it.
Following the extensible web manifesto, I we can use: https://www.npmjs.com/package/uuid
As a guide for how many things depend on it in the Node ecosystem. There are 4755 projects that depend on UUID of some form, and there has been 19,411,452 downloads in the last month.
Sorry, rereading, I might have misunderstood what you were asking. Where you asking if we should just use the function I provided or expose it as uuid() in the browser on window?
I think things like this belong in libraries, and it’s actually better to put it there. Building code in to the browser is actually incredibly inflexible, since it basically can never be changed due to backwards compatibility concerns. So it’s a lot more flexible and more future-proof to just leave that in a library.
Marcos, I agree with Ashley. Use crypto.getRandomValues(new Uint8Array(16)) and convert to a string however fits best. UUIDs are hugely overrated as unique identifiers, they aren’t as random as the above, and they have weird formatting peccadilloes. If for some bizarre reason you actually need a UUID, yeah, JSL.
What would be your use cases, for example? If you want to use them in HTML/CSS somehow, I can understand, but in JavaScript it is simply too easy to include a UUID generator.
For example, I was working on this app, whereby I needed to store UUIDs as primary keys in IDB. The team I work with was using "GUID"s in legacy code for Firefox’s AutofillDB - I’m doing the Credit Card DB, and so wanted to also use UUIDs for the primary key - while also associating a credit card with an address via a UUID:
I know any random key could have been used there. The point is that a team had already used UUID, and I wanted consistency.
Agree, Martin. There is no actual valid technical reason. It’s just “I need a unique thing for this”… if it’s universally unique, in the true sense, doesn’t matter too much.
Agree, Ashley… looking at the node UUID lib - it supports multiple versions, etc. which is testament to the extensibility that the library approach provides.
For examples of this going poorly, look no further than the broken implementations of btoa() and atob() that are still hanging around on window today.
For info, the Web Bluetooth API had to define some Bluetooth UUIDs at https://webbluetoothcg.github.io/web-bluetooth/#uuids
Yep, although we don’t need any way to generate UUIDs. They’re just constant strings with a particular format for Web Bluetooth.