იმის გამო, რომ TypeScript არის სტრუქტურულად აკრეფილი, UserId და OrderId, რომელიც ორივე string არის, ჩანაცვლებადია — კომპილერი ვერ აკეთებს იმას, რომ თავიდან აიცილო ისინი ერთმანეთით მოსახლეობა. სიმულაციის სახით რეალიზებს აკრეფას უნიკალური, ფანტომური "ბრენდის" მიერთებით, რათა სხვაგვარად იდენტური ტიპები განსხვავდებული გახდეს.
// 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
სახელმწიფო __brand არასდროს არსებობს runtime-ში (მნიშვნელობა მხოლოდ string-ია), მაგრამ ტიპის სისტემაში ის UserId და OrderId შეუთავსებელს ხდის — დაბნეულობის მთელი კატეგორიის ხელშეწყობის თავიდან აცილება.
function toUserId(s: string): UserId {
if (!s.startsWith("u")) throw new Error("invalid UserId");
return s as UserId; // validation happens here, once
}
ერთხელ დაასახელეთ საზღვარზე; კოდის დანარჩენი ნაწილი ენდობა ბრენდირებულ ტიპს.
ID-ები (UserId vs OrderId), გადამოწმებული/სანიტარული სტრიქონები (Email, SafeHtml), ერთეულები (Meters vs Feet), PositiveNumber — ყველა იმ ადგილას, სადაც ორი მნიშვნელობა საზიარო პრიმიტიულ ტიპს იყენებს, მაგრამ არ უნდა აგვერიოს.
ბრენდირებული ტიპები ნომინალურ უსაფრთხოებას ემატება სადაც სტრუქტურული აკრეფა ზედმეტად დაშვებულია.
ისინი ხაფიან არგუმენტის თანმიმდევრობის შერევისა და "გადამოუწმებელი წ. გადამოწმებული" დაბნეულობას კომპილაციის დროს, ნულოვანი runtime ღირებულებით — ძლევამოსილი ნიმუში დომენის მოდელირებისთვის დიდი, სისწორის კრიტიკულ საფუძველზე.