Ponieważ TypeScript ma typy strukturalne, UserId i OrderId, które są obydwa string, są wymienne — kompilator nie może Cię zatrzymać przed pomyleniem ich. Typy znakowane symulują typy nominalne, dołączając unikalny, fantomowy "znak", dzięki czemu inaczej identyczne typy stają się różne.
// the brand is a property that exists only in the type system, never at runtime
type Brand<T, B> = T & { readonly __brand: B };
type UserId = Brand<string, "UserId">;
type OrderId = Brand<string, "OrderId">;
function getUser(id: UserId) { return id; }
const uid = "u1" as UserId;
const oid = "o1" as OrderId;
getUser(uid); // ✅
getUser(oid); // ❌ Error: OrderId is not assignable to UserId
getUser("u1"); // ❌ Error: plain string is not a UserId
Właściwość __brand nigdy nie istnieje w czasie wykonania (wartość to tylko ciąg znaków), ale w systemie typów czyni UserId i OrderId niezgodnymi — zapobiegając całej klasie błędów pomyłki.
function toUserId(s: string): UserId {
if (!s.startsWith("u")) throw new Error("invalid UserId");
return s as UserId; // validation happens here, once
}
Sprawdzaj poprawność raz na granicy; reszta kodu ufa znakowanemu typowi.
Identyfikatory (UserId vs OrderId), walidowane/oczyszczone ciągi (Email, SafeHtml), jednostki (Meters vs Feet), PositiveNumber — wszędzie tam, gdzie dwie wartości współdzielą typ prymitywny, ale nie powinny być mylone.
Typy znakowane dodają bezpieczeństwo nominalne tam, gdzie typizacja strukturalna jest zbyt permisywna.
Zapobiegają pomyłkom w kolejności argumentów i pomyłkom między "niewalidowanym a walidowanym" w czasie kompilacji, bez żadnych kosztów w czasie wykonania — potężny wzorzec do modelowania domenowego w dużych, krytycznych dla poprawności bazach kodowych.