TypeScript ist strukturell typisiert. Was heißt das in der Praxis, und wo beißt es dich?

Strukturelle Typisierung heißt, dass Kompatibilität über die Form entschieden wird und nicht über den deklarierten Namen, jedes Objekt mit den richtigen Properties erfüllt also den Typ. Das macht Typen billig und kombinierbar, es heißt aber auch, dass zwei unverwandte Konzepte mit gleicher Form austauschbar sind, ein userId-String lässt sich also übergeben, wo ein orderId-String erwartet wird. Der übliche Fix ist ein Branded Type oder ein kleiner Wrapper, der dem Wert eine eigene Form gibt.

Es heißt, dass TypeScript Formen vergleicht und keine Namen, wenn etwas also die richtigen Properties hat, ist es zuweisbar, egal woher es kam. Das ist meistens ein Geschenk, weil sich Typen dadurch wie Dokumentation anfühlen und nicht wie Zeremonie. Es beißt dort, wo zwei Typen dieselbe Form haben, aber unterschiedliche Konzepte sind. Bei mir waren alle IDs schlichte Strings, eine User-ID in eine Funktion zu geben, die eine Order-ID erwartet, kompilierte also einwandfrei und fiel in der Produktion um. Repariert habe ich das mit Branded Types, einer Intersection mit einem eindeutigen Tag, den nur eine Konstruktorfunktion erzeugen kann, damit der Compiler sie nicht mehr als gleich behandelt. Die andere Falle ist, dass Typen gelöscht werden, zur Laufzeit prüft also nichts die Antwort einer API. Alles, was eine Grenze überquert, parse ich mit einem Schema-Validator und lasse den Typ daraus abgeleitet fließen, damit Typ und tatsächliche Daten nicht auseinanderdriften können. Und ich weiß, dass Excess Property Checking nur für frische Objektliterale gilt, was viel Verwirrung darüber erklärt, warum ein zusätzliches Feld mal ein Fehler ist und mal nicht.