- Einstieg: heute TypeScript, der typisierte Aufsatz auf JavaScript
- Nicht auf dem Titel verweilen
- Kernbotschaft: TS ist kein Bruch, sondern ein Aufsatz auf JS
- Drop-In Replacement: bestehende Codebasis kann Datei fuer Datei migriert werden
- Sektionsauftakt: warum TypeScript, Bezug zum Semesterprojekt
- Roadmap kurz zeigen: fuenf Stationen heute, Teil 2 folgt
- Bezug zum Projekt herstellen: stabile Web-App im Team
- Betonen: TS ersetzt nichts, es ergaenzt das vorhandene JS-Wissen
- Gemeinsame Typbasis: Domaenenmodell und API-Vertrag (REST-Vorlesung) als TS-Interfaces im Front-End
- Back-End ist Spring Boot (Java); TS-Back-Ends nur als Ausblick erwaehnen
- Links JS: Bug bleibt unsichtbar bis zur Laufzeit
- Rechts TS: der Editor warnt sofort beim Aufruf mit String
- Frage: "Wo wuerde dieser Bug in eurem Projekt auftauchen?"
- Kurze Partneruebung, danach 1-2 Beitraege im Plenum einsammeln
- Erwartung: jeder hat schon Zeit durch Typfehler verloren
- Kurzer Rueckblick auf JavaScript, dann typische Bug-Kategorien
- Vorwissen aus den JS-Vorlesungen aktivieren
- Kurz nachfragen, wer schon mit Node/npm gearbeitet hat
- Beispiel laut durchgehen: minus konvertiert zu Zahl, plus konkateniert
- Kurzes Stimmungsbild einholen, nicht lange diskutieren
- Falsy-Falle zeigen: factor=0 ist gueltig, wird aber wie fehlend behandelt
- Kurz Antworten sammeln (=== undefined, Default-Parameter, Typen)
- JSON.parse liefert any: der Editor kann nicht warnen
- Mit optionalem Feld email? wuerde der Zugriff sofort angemeckert
- Konkrete Stories aus dem Plenum sammeln
- Schluesselwoerter am Whiteboard notieren, spaeter darauf zurueckkommen
- Erwartete Loesung: "345" wird geloggt, String-Konkatenation statt Summe
- Ueberleitung: TypeScript haette den Typ string[] erkannt
- Jetzt praktisch: Dateiendungen, Setup, erster Compiler-Lauf
- Grafik: Browser kann TS nicht ausfuehren, erst der Compiler macht JS daraus
- Superset-Kreis zeigen: JS steckt komplett in TS drin
- Drei Befehle live zeigen oder zumindest vorlesen
- Playground als Null-Setup-Alternative fuer schnelle Experimente
- Nur die vier wichtigsten Flags erklaeren, Rest ist Nachschlagewerk
- strict: true als Empfehlung fuer das Projekt aussprechen
- Idealerweise live im Editor vorfuehren: umbenennen, annotieren, Fehler sehen
- Der Aufruf mit '3' wird sofort rot unterstrichen
- Typannotationen verschwinden beim Kompilieren komplett
- Zur Laufzeit gibt es keine Typpruefung mehr, nur zur Compile-Zeit
- Kernkapitel: die Bausteine des Typsystems der Reihe nach
- Hierarchie nur grob zeigen: unknown ganz oben, never ganz unten
- Strukturell: entscheidend ist die Form der Werte, nicht der Name
- Primitive kurz durchgehen, Literaltypen als Besonderheit hervorheben
- any-Warnung deutlich machen: Schutz faellt komplett weg
- Tupel: feste Laenge und feste Typen pro Position
- Frage kurz diskutieren (z.B. Koordinaten, Key-Value-Paare)
- Union = oder, Intersection = und
- Vorgriff: Union braucht spaeter Narrowing (Teil 2)
- Faustregel: reine Objektformen als interface, alles andere als type
- Keine Glaubensfrage daraus machen, beides ist ok
- Stillarbeit oder Zweiergruppen, danach Vergleich
- Bonusfrage: Interface oder Type Alias, wofuer entscheidet ihr euch?
- Musterloesung zeigen, Abweichungen der Teams kurz besprechen
- Optionale Felder und Literal-Union hervorheben
- Letzte Sektion heute: Funktionen, Klassen und der Einstieg in Generics
- Roter Faden der Sektion: drei Bausteine, ein Ziel
- "Ohne Doppelarbeit" = kein Copy-Paste pro Typ
- Optionaler Parameter title? und Rest-Parameter im Beispiel zeigen
- Autocomplete-Vorteil betonen: Signatur ist Dokumentation
- Funktionstypen als eigenstaendige Typen begreifen
- Antwort auf die Frage: Rueckgabetyp Promise<...> im Alias erzwingen
- Parameter-Properties im Konstruktor hervorheben (private readonly id)
- implements: Interface als Vertrag fuer die Klasse
- abstract execute() muss von der Kindklasse implementiert werden
- Hinweis: nur ueberschreiben, was noetig ist, sonst waechst Komplexitaet
- T wird beim Aufruf automatisch bestimmt: string[] bzw. boolean[]
- Bekannte Generics nennen, die alle schon benutzt haben (Promise, Array)
- extends Identifiable garantiert, dass jedes T eine id hat
- Ohne Constraint kennt der Compiler item.id nicht
- Ein Repository fuer User, Task, Board ohne Copy & Paste
- Bruecke zum Projekt: solche Bausteine kommen in jedem Backend vor
- Kurzer Austausch (2 Minuten), ein Beispiel im Plenum teilen lassen
- Auch die Grenze ansprechen: zu viel Generik wird unlesbar
- Pair Programming, danach kurze Demo eines Teams
- Hinweis geben: Union aus zwei Objektformen
- Musterloesung: eine Zeile, Union aus data- und error-Form
- Ausblick: dieses Result-Muster kommt in Teil 2 beim Narrowing wieder