Hacker News Reader

Comment by kristiandupont | Hacker News Reader

I don't see why. I greatly prefer typescript's structural typing for almost everything. But id's in data models are an exception, so I use branding for those. It works perfectly, the only overhead is in the write-once declaration and now I am protected from accidentally using an AccountId where a MemberId was expected, even though they are both just strings.

View on HN

How do ids of different types accidentally get into a place they shouldn't be? Is this simply a case where someone mistakenly passes along a property that happens to be called "id", not noticing it's an account id rather than a member id (as in, an implementation error)?

Yeah, or what's more likely is that you originally used an AccountID everywhere, but then you decided that you want to use a UserAccountID. So you update your functions but you miss a spot when you're updating all your call sites.

Or you have a client library that you use to interact with your API, and the client library changes, and you don't even notice.

Or you change the return type of a function in a library, and you don't even know who all the callers are, but it sure would be nice if they all get a build error when they update to the latest version of your library.

Lots and lots and lots of ways for this to happen in a medium+ sized project that's been around for more than a few months. It's just another way to leverage the power of types to have the compiler help you write correct code. Most of the time most people don't mess it up, but it sure feels good to know that it's literally impossible to mess up.

This kind of mistake is quite easy to make, especially when somebody writes a function that takes several IDs as arguments next to each other. I've seen it happen a number of times over the years

    function foo(customerId, itemId, orderId) {
        if(!customer[customerId]) throw new Error("Customer with id=" + customerId + " does not exist");
        if(!item[itemId]) throw new Error("Item with id=" + itemId + " does not exist");
        if(!order[orderId]) throw new Error("Order with id=" + orderId+ " does not exist");
    }

Just an example of how you can detect errors early with defensive programming.

As oppose to a zero cost build time check, that's 3 expensive runtime DB checks, plus an account and a member could have the same ID, so it might run anyways but on the wrong DB rows.

You made two points that are correct in theory, but in practice those lookups would/could take micro-seconds, and the bug would be detected within minutes in a production environment. And it would take five minutes or less to patch.

If you're cowboy coding as a solo dev, sure.

We could argue if having 1-3 code cowboys is better then a large team. If the code cowboys can produce higher quality, quicker. They will be difficult to replace after many years though.

Yeah this is exactly why using primitive types for ids is bad. If you encode it in the type system then you cannot make this error and don't need to check it at runtime.

Most bugs are found at runtime. The static analysis mostly finds silly errors that are easy to fix. A great type system do make it easier to write spaghetti code though, and you can have one letter variable names - naming is difficult.

If you have a distance argument typed as a number, for example, and you pass miles instead of km.

It is equivalent to newtype in haskell.

Another example somebody mentioned here is a logged in user. A function can take a user and we need to always check that the user is logged. Or we could simply create a LoggedUser type and the compiler will complain if we forget.

A lot of code may end up dealing with multiple kinds of IDs at the same time.

For Rust I wrote newtype-uuid to provide newtype wrappers over UUIDs, which has already found a couple of bugs at Oxide.

[1] https://crates.io/crates/newtype-uuid

Happens a lot with junction tables ime. e.g. At my last job we had three tables: user, stream, user_stream. user_stream is an N:N junction between a user and a stream

A user is free to leave and rejoin a stream, and we want to retain old data. So each user_stream has columns id, user_id, stream_id (+ others)

Issues occur when people write code like the following:

streamsService.search({ withIds: userStreams.map((stream) => stream.id), });

The issue is easily noticed if you name the “stream” parameter “userStream” instead, but this particular footgun came up _all_ the time in code review; and it also occurred with other junction tables as well. Branded types on the various id fields completely solve this mistake at design time.

Would it help if the junction tables named something else? "Session" or "participations"?

Yes! I've wanted this in Typescript for ages! Is it possible to brand primitives though?

Yes you can, it works just the same :-)

Sorry, with the Symbol? How does it work?

You don't even need the symbol. If you want the simplest thing that will work:

    type Velocity = number & { BRAND: "Velocity" }
    type Distance = number & { BRAND: "Distance" }

    var x = 100 as Distance

Reply on news.ycombinator.com