prosopo.io/articles/typescript-branding/
TypeScript Essentials: Distinguishing Types with Branding
View all comments
User deleted comment
1mo
Could always bundle what you're working on as a build step
User deleted comment
1mo
There are scenarios where it's extremely helpful.
First thing that comes to mind is an internal layer that makes the somewhat implicit assumption that data has been validated before it comes in. Accepting only branded types can force downstream users to use your validation and allow you to only accept data that you're reasonably sure is acceptable.
Speaking of validation, what if you have an extremely expensive piece of validation that needs to be run, say an API request to validate a token of some sort? Branding a type as IAlreadyInvestedABunchOfTimeToValidate<T> can be used as a quick, safe means to prevent duplicate, expensive work.
If we're gonna talk about expensive work, one of the most useful cases for branded types is any kind of data hydration. Let's say you have a Model with mandatory field id. You can accept Model | Hydrated<Model> all over the place, and the first time you see an unhydrated model, you can hydrate it, brand it, and encode that information into the type system, rather than (or in addition to) something like an isHydrated field.
And so on... I feel like this is one of those tools that you don't miss if you don't use it, but if you do use it, you see a ton of places for it to make your life 1-2% better. It's a small benefit when you can use it, but it's almost always (cognitively) free to use it, and small enhancements like this cascade and compound throughout a codebase.
Accepting only branded types can force downstream users to use your validation and allow you to only accept data that you're reasonably sure is acceptable.
It seems a bit silly to break every way of creating your object except for going through you validation. Especially when you talk about validation being expensive. Zod does validation with structural types with zero issues. API requests usually return the unknown type which then forces you to validate it. I think you're really just inventing problems that this can solve.
I haven't done hydration before so I can't really comment on it.
As a massive counterpoint to branding. Structural types work amazing well. If you have an object that's something simple like {id: number, name: string} you can easily create and use it in places. You don't need to use someone's personal validator/constructor to create it in order to pass it around as a prop.
The only people I've seen try to implement branding are those who love massively over-complicated class based data structures for something trivial.
It seems a bit silly to break every way of creating your object except for going through you validation
That's not silly, that's the point. There's a whole bunch of cases where that's exactly what you want: an ORM is a great case, where the only thing that should be able to make database entities is a factory of some sort that does all the ORM-y stuff that needs to be done; a reference to a file handler or other type of external handle is another; an API request or otherwise expensive validation that you don't trust is going to be done correctly externally, e.g. a configuration file that needs to be validated for real-world correctness that can't be expressed in the type system (you didn't specify a window's width/height larger than the screen, a user ID exists in the database, a user ID exists in multiple databases, etc.); you might want to control a small set of queries to run (against an API, DB, whatever) and don't want your downstream consumers to write their own. If the question is "If it would make my life easier and/or my code safer if I controlled the creation of X, what is X?" I feel like I could spend the rest of the day just listing one example after another. Every single answer to that question is potentially and probably a good use case for nominal types.
Structural typing is largely a better idea as a default construct because that question represents a small portion of the overall work you do in a programming language. In most cases, particularly in JS, it doesn't matter, but that doesn't mean it never does. Like I said before, it's probably never going to be the difference between good code and bad, but it does help, and compounding a bunch of little things that help 1% here and 2% there is how you create a culture of maintainability in a codebase.
Zod does validation with structural types with zero issues.
Zod uses branded types internally to hand the exact case I mentioned vis-a-vis not re-initializing validators and re-running validations. Whether you realize it or not, you recommended using them right here as a means to recommend not using them, because they're used appropriately here and there's no reason why you'd ever want to make an object Zod is going to brand except through one of the various functions that create said objects.
This is unrelated to the topic at hand, but Zod does not do anything with zero issues. It's phenomenally slow for validation at runtime, and the way its types are implemented make it fairly easy to make using TS impossible because of compile time performance. I did an experiment dumping my entire database via a Prisma schema as Zod schemas... however I tried, the TS language server couldn't handle only a few thousand Zod schemas, even after I had given it 8GB of RAM. Zod is terrible and puts a relatively low hard cap on the complexity and scope of your validation schemas because of its awful performance characteristics.
Kind of the inverse of what I said before, but stacking things that are slower than they should be but don't individually matter is how you wind up with slow software. If you don't care about the performance of your validators, it's fine, but when it's your validators, and your API access layer, and your state management, and the giant pile of abstractions that controls your routing, and the other giant pile of abstractions that controls your theming, and a hundred other core pieces of functionality that increase their fraction of runtime from 1% to 1.25% (or 0.01% to 0.0125%), then you wind up with software that feels slow and shitty and without any low hanging fruit.
I recommend typia or runtypes (in the case of react-native or some other bundler you can't easily use TS transformers with) now.