- Einstieg: zweiter Teil zu TypeScript, heute Inference, Narrowing und die fortgeschrittenen Konstrukte
- Nicht auf dem Titel verweilen
- Kurz an Teil 1 anknuepfen: Typsystem-Grundlagen sitzen, jetzt die Compiler-Intelligenz
- Roadmap zeigen: vier Stationen, am Ende der Workshop
- Typen im Beispiel erfragen: number, string[], (number | string)[]
- Faustregel: Inferenz nutzen, bei oeffentlichen APIs explizit typisieren
- JSON.parse liefert any, payload ist damit ungeschuetzt
- Empfehlung: Rueckgabewerte bei oeffentlichen APIs annotieren
- Im if-Zweig ist value string, danach automatisch number
- Der Editor versteht die Pfade ohne Zusatzaufwand
- 'data' in result unterscheidet die beiden Formen der Union
- Rueckbezug zu Teil 1: genau unser Result-Typ aus der Uebung
- instanceof prueft die Prototype-Kette zur Laufzeit
- Hinweis: fuer reine Interface-Typen nicht nutzbar, die existieren zur Laufzeit nicht
- "member is ..." ist die Predicate-Signatur, sie macht das Narrowing wiederverwendbar
- Nach dem if kennt der Compiler skills als string[]
- as const: env wird 'prod' statt string, alles readonly
- typeof config macht daraus einen praezisen Typ ohne Doppelpflege
- Pair Programming, danach kurze Loesung im Plenum
- Hinweis auf Array.isArray als eingebauten Guard geben
- Musterloesung: Array.isArray narrowt auf User[] bzw. User
- Optional diskutieren: was passiert bei leerem Array?
- Jetzt die Konstrukte, die in echten Codebasen staendig auftauchen
- Nur 'light' oder 'dark' sind erlaubt, Tippfehler fallen sofort auf
- Typische Einsatzfaelle: Status, Aktionen, Flags
- Gemeinsames kind-Feld als Diskriminator, switch narrowt pro Fall
- Muster fuer API-Antworten, Events, Zustandsmodelle empfehlen
- [K in keyof T] iteriert ueber alle Keys, ? macht sie optional
- Praktisch fuer DTOs, Formulare, Partial-Updates
- Utility Types sind eingebaute Mapped Types
- Kurz fragen: welche Utility Types nutzt ihr bereits?
- infer U entpackt den Promise-Inhalt: A = string, B = number
- Nur als Werkzeug vorstellen, nicht in die Tiefe gehen
- unknown zwingt zum Narrowing vor der Nutzung, any nicht
- Frage ans Plenum: wann ist any vertretbar?
- Erwartete Antworten: 1. Record, 2. gemeinsames kind-Feld, 3. infer in Conditional Type
- Fragen nacheinander stellen, kurz abstimmen lassen
- Jetzt anwenden: ein kleines Modul gemeinsam von any zu sauberen Typen
- Bezug zum Semesterprojekt: Task-Board ist bewusst projektnah gewaehlt
- Erwartungsmanagement: kleine Schritte, gemeinsames Refactoring
- Probleme benennen lassen: alles any, keine Fehlerbehandlung, globaler Zustand
- Teams ueberlegen zuerst das Datenmodell (Task, Board)
- Datenmodell mit Literal-Union fuer status, optionaler assignee
- Funktionen pure gemacht: Board rein, neues Board raus
- Task | undefined zwingt Aufrufer zum Narrowing
- Abschluss: Takeaways sichern und Bogen zu den naechsten Vorlesungen
- Kernaussagen langsam und deutlich formulieren
- Studierende in eigenen Worten wiederholen lassen
- Think-Pair-Share, danach Support-Wuensche einsammeln
- Wuensche fuer kommende Uebungen notieren
- Offene Fragen zu Stoff, Uebungen oder Projektumsetzung
- Reminder: Slides und Code-Snippets stehen im Repo bereit