27

In my React app, I want to do optimistic updates to create a responsive experience for my users.

Having said that I want to send a user entry to my backend with an ID that will be used so that there won't be a different Id for the user's entry next time he/she uses the app. For example, if the user enters a comment, I want to assign its ID with a real UUID and then send it to my API.

I understand JavaScript or React don't really have a built-in way to generate UUID/GUID values. I've seen many articles that produce randomized values that look like UUID/GUID's but they really are not and I don't want to use them as ID's for user entries.

How do I get real UUID/GUID values in my frontend? Do I call my backend API to get them? I can create an endpoint in my API that spits out 10 or 20 GUID's at a time and I can store them for future use in my frontend but this sounds a bit absurd.

I don't want to reinvent the wheel here as I'm not the first person to face this scenario. How do I get real UUID values on my frontend?

Flip
  • 6,233
  • 7
  • 46
  • 75
Sam
  • 26,817
  • 58
  • 206
  • 383

2 Answers2

28

You can use the uuid npm package. You probably want to use a v4 UUID. (Previous UUID versions use things like a timestamp or network card MAC address as seeds to the random generator).

markau
  • 854
  • 8
  • 21
  • Cool! Are they real UUID's? A quick look suggests they are. I wasn't aware of this package. – Sam Apr 13 '18 at 01:33
  • I haven't used that package in production, but it worked well for my testing, and it has a lot of downloads, so I'd trust it. – markau Apr 13 '18 at 01:40
3

You're probably just fine generating them client-side - it takes many, many UUIDs before you even approach a 1 in a million rate of collision (citing the answer below).

This answer has several solutions to generating them client-side in a way that complies with RFC4122:

Create GUID / UUID in JavaScript?

Alternatively, you could generate temporary optimistic IDs and then replace them when you get a response from the server.

Dan Wilkerson
  • 81
  • 6
  • Thank you for your answer. I've seen so many articles like the post you've referenced. I'm just not crazy about using such an approach. Assigning some ID and then replacing is doing the work twice. If those are my options, I think I'd rather create an API end point that spits out UUID values, say 20 at a time. I can then use them in different parts of my app because I want to do optimistic updates in multiple modules. When I'm down to 2 UUID's in my Redux store, I can make another call to get 20 fresh ones. Why not use this approach? – Sam Apr 13 '18 at 01:31
  • Well, I guess I'd say that the approach adds complexity to the code without generating value (compared to generating them client-side and simply using those). Plus, what happens when the ID-provisioning service needs to scale? There's still the same chances of a collision. To be clear, I agree that using a temporary ID also adds complexity; I'd advocate for simply generating them client-side and using those values. – Dan Wilkerson Apr 13 '18 at 02:16
  • The downside of generating them client-side is that a malicious actor can repost and change your client generated uuid to an existing uuid, and that could mess up your primary keys. (lots of assumptions in that, but that's why I generate them server side.) – TomEberhard May 07 '21 at 18:47