from Hacker News

TypeScript: Branded Types

by arbol on 4/24/24, 4:48 PM with 203 comments

  • by spankalee on 4/24/24, 6:06 PM

    To me the real benefit of branded types is for branded primitives. That helps you prevent mixing up things that are represented by the same primitive type, like say relative and absolute paths, or different types of IDs.

    You really don't need the symbol - you can use an obscure name for the branding field. I think it helps the type self-document in errors and hover-overs if you use a descriptive name.

    I use branding enough that I have a little helper for it:

        /**
     * Brands a type by intersecting it with a type with a brand property based on
     * the provided brand string.
     */
    export type Brand<T, Brand extends string> = T & {
      readonly [B in Brand as `__${B}_brand`]: never;
    };
    Use it like:

        type ObjectId = Brand<string, 'ObjectId'>;
    And the hover-over type is:

        type ObjectId = string & {
      readonly __ObjectId_brand: never;
    }

  • by thepaulmcbride on 4/24/24, 9:19 PM

    Anytime I’ve come across the need to do this, I’ve found a class is a better and less complicated solution.

    I really like the pattern of value objects from Domain Driven Design. Create a class that stores the value, for example email address.

    In the class constructor, take a string and validate it. Then anywhere that you need a valid email address, have it accept an instance of the Email class.

    As far as I understand classes are the only real way to get nominal typing in TypeScript.

  • by epolanski on 4/24/24, 11:33 PM

    An example of what you can implement on top of branded types that I want to share with fellow hackers:

    - currencies

    You may have some sort of integer representing the number of cents of some currency and you want to avoid doing operations between the wrong currencies (such as adding euros and pesos).

    You can create branded types and functions that work on those Euro branded numbers and then decide how to do math on it. Or numbers representing metals and such.

    It's useful in other scenarios such as a, idk, strings, you could theoretically brand strings as idk ASCII or UTF-8 or the content of an http body to avoid mixing those up when encoding but I want to emphasize that often many of those hacks are easier to be handled with stuff like dictionaries or tagged unions.

    An example of what can be achieved with similar approaches (beware it's oriented for people that are at least amateur practitioners of functional programming) is Giulio Canti's (an Italian mathematician and previously author of t-comb, fp-ts, io-ts, optic-ts, and now effect and effect/schema), the money-ts library:

    https://github.com/gcanti/money-ts

  • by jonathanlydall on 4/24/24, 5:51 PM

    I can see this being useful and it seems about as neat a solution as you can currently get in TypeScript as it stands today, but it’s still cumbersome.

    My feeling is that while you can do this, you’re swimming upstream as the language is working against you. Reaching for such a solution should probably be avoided as much as possible.

  • by munk-a on 4/24/24, 10:51 PM

    Isn't this just the classic issue of inferred typing coming back to bite us in the way everyone originally predicted? Go runs into the same issue where wildly different types may be considered the same based purely on coincidental naming and matching against interfaces the original authors had no intent to match against. At the end of the day I think the easier system to work with is one in which all type compatibility needs to be explicitly declared - if your array is iterable defining that it implements iterable lets your compiler shout at you if iterable suddenly gets another abstract method that you didn't implement - and it makes sure that if you add a method `current` to a class it doesn't suddenly means that it properly supports iterable-ity.

    Determining types by what things appear to do instead of what they state they do seems like a generally unnecessary compromise in typing safety that isn't really worth the minuscule amount of effort it can save.

  • by JJMalina on 4/24/24, 6:06 PM

    Zod has branded types: https://zod.dev/?id=brand it works really nicely with Zod schemas

  • by dvt on 4/24/24, 7:20 PM

    Weird idea, as types in TS are structural by design. If this is something you need, it smells like "runtime checking" not amending the type system.

  • by Slix on 4/24/24, 9:00 PM

    This is also useful for having a type that needs to be verified in some way before being used or trusted. UnverifiedLoginCookie vs. VerifiedLoginCookie

  • by zbentley on 4/24/24, 6:51 PM

    It's a clever trick, but the compiler errors leave a lot to be desired. If a TS library makes heavy use of nominal (branded/distinct) types in a domain where accidentally passing values of the wrong type is common, I can imagine a lot of library users being more confused, not less, by code that uses this approach.

    The article reads more like an endorsement of languages that do structurally-aware nominal typing (that is, languages that are nominally typed but that have awareness of structural equivalence so that zero-cost conversions and intelligible compile-time errors for invalid conversions are first class) than a persuasive case for the symbol-smuggling trick described.

  • by techn00 on 4/24/24, 6:24 PM

    Very useful for DDD, like having an Email type, or String100 (string of 100 characters)

  • by hankchinaski on 4/24/24, 11:25 PM

    Maybe is me but this seems way overengineered

  • by herpdyderp on 4/24/24, 10:45 PM

    The implementation for `RemoveBrand` is incorrect: it currently grabs all property types of `T`, it's not removing the property `[brand]` from `T`. It should be `Omit<T, typeof brand>`

  • by dimitrisnl on 4/24/24, 7:07 PM

    Selfish plug about the same topic https://dnlytras.com/blog/nominal-types

  • by leecommamichael on 4/24/24, 6:15 PM

    The Odin language has a ‘distinct’ type-qualifier which accomplishes this tersely. It’s a big part of the type system, and C’s type-system for that matter.

  • by beders on 4/24/24, 8:40 PM

    Ah, the magical disappearing type system - now being used for nominal typing.

    I'm curious to see what the JS code looks like for casts and type checks in that case.

  • by aleksiy123 on 4/24/24, 11:42 PM

    Anyone else sometimes get more sucked in to perfectly typing stuff instead of writing code.

    I guess working in the pure logic and formalism of types is just addictive.

    I love it.

  • by gmdrd on 4/26/24, 11:33 AM

    Is there something wrong with creating opaque types using this method?

      type ObjectId = string & { 
  readonly __tag: unique 
  symbol }
    This way, we don't need to use `never`, but we still prevent the creation of a structurally equivalent type by mistake.

  • by satvikpendem on 4/24/24, 9:50 PM

    Reminds me of another sort of type-driven development, making invalid states unrepresentable: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...

  • by SergeAx on 4/25/24, 3:41 PM

    Seems like patching earlier language architecture mistake. If you create custom types, you should not use duck typing on them. You should use typecasting, so the programmer would write something like `result = processEntityA(A(B))`

  • by rowanG077 on 4/25/24, 1:15 AM

    How do you ensure someone doesn't reuse a brand string? Seems pretty brittle to me.

  • by black_puppydog on 4/25/24, 7:23 AM

    Structural typing, and especially for primitives, with these work-arounds being so clunky and not built into the standard library, was the reason I started picking up Rust...

  • by erik_seaberg on 4/24/24, 8:29 PM

    This works because casts are allowed to quietly create values whose types are wrong. It would have been better if the cast added a runtime check, or at least we distinguish sound (checked) and unsound casts the way C++ does.

    I think Haskell avoid this by actually requiring you to write sound conversion functions between phantom types (it helps that phantom types don't involve any visible state at runtime).

  • by lang_agnostic on 4/24/24, 9:02 PM

    Isn't this just phantom types in other programming languages?

  • by bazoom42 on 4/24/24, 9:38 PM

    I think Typescript need nominal type aliases for primitives.

  • by klysm on 4/24/24, 7:04 PM

    The downside of structural typing

  • by jibbit on 4/24/24, 6:55 PM

    or a tagged type if you're old enough to have ever been exposed to another language

  • by mirekrusin on 4/24/24, 6:59 PM

    Flow is much better with opaque types.

    Also nominal types for classes.

    And correct variance.

    And adhering to liskov substitution principles.

    And exact object types.

    And spread on types matching runtime behavior.

    And proper no transpilation mode with full access to the language.

    And has 10x less LoC than ts.

    ps. before somebody says "flow is dead" have a look at flow contributions [0] vs typescript contributions [1]

    [0] https://github.com/facebook/flow/graphs/contributors

    [1] https://github.com/microsoft/TypeScript/graphs/contributors

  • by pprotas on 4/24/24, 5:48 PM

    Amazing, we have invented nominal typing in a structural typing system.

    Sometimes I wonder what kind of programs are written using all these complicated TS types. Anecdotally, we use very simple, basic types in our codebase. The need for tricks like this (and other complicated types) is simply not there. Are we doing something wrong?