Module in TypeScript: Import und Export

Wir haben import/export bereits seit Kapitel 7 durchgehend genutzt, ohne sie im Detail zu erklären. Zeit, das nachzuholen – inklusive der Feinheiten, die speziell mit TypeScripts Typsystem zusammenhängen.

Named Exports: das bisher genutzte Muster

// Buch.ts:
export interface Buch { /* ... */ }
export type BuchStatus = 'verfuegbar' | 'ausgeliehen' | 'reserviert';

// index.ts:
import { Buch, BuchStatus } from './models/Buch.js';

"Named" (benannt), weil JEDER Export einen EIGENEN Namen hat, und beim Import GENAU dieser Name (in geschweiften Klammern) verwendet werden muss – eine Datei kann BELIEBIG viele named exports haben, GENAU das Muster, das wir durchgehend genutzt haben.

Default Exports: EIN Hauptexport pro Datei

// Bibliothek.ts:
export default class Bibliothek { /* ... */ }

// index.ts:
import Bibliothek from './services/Bibliothek.js'; // KEINE geschweiften Klammern,
                                                     // Name frei wählbar beim Import

Achtung: Unser Projekt hat BEWUSST export class Bibliothek (named export) statt export default class Bibliothek verwendet – Named Exports sind heute die empfohlene Praxis, aus einem konkreten Grund: bei Named Exports MUSS der importierte Name mit dem exportierten übereinstimmen (Editor-Umbenennungen bleiben KONSISTENT über das gesamte Projekt), bei Default Exports kann JEDE importierende Datei einen ANDEREN Namen wählen – das führt in großen Projekten leicht zu Verwirrung.

Type-Only Imports: nur zur Kompilierzeit

import type { Buch } from './models/Buch.js'; // explizit NUR ein Typ, keine Laufzeit-Ware
import { Buch } from './models/Buch.js';       // funktioniert bei Interfaces GENAUSO,
                                                 // aber weniger EXPLIZIT dokumentiert

import type macht EXPLIZIT, dass NUR Typinformation importiert wird, die beim Kompilieren KOMPLETT verschwindet (siehe Kapitel 1) – bei einem Interface wie Buch ist das ohnehin der Fall (Interfaces existieren NIE zur Laufzeit), aber import type macht diese ABSICHT für Leser des Codes sofort ersichtlich, GENAU wie wir es bereits in "React für Profis" für RootState/AppDispatch gesehen haben.

Barrel Exports: ein zentraler Sammel-Export

Bei WACHSENDER Anzahl an Modellen wird es mühsam, JEDE Datei einzeln zu importieren – ein "Barrel" (Sammel-Datei) bündelt mehrere Exporte:

src/models/index.ts

export * from './Buch.js';
export * from './Autor.js';
export * from './Hoerbuch.js';
export * from './Medium.js';
export * from './Genre.js';
export * from './HatIsbn.js';

// Statt VIER separater Imports:
import { Buch } from './models/Buch.js';
import { Autor } from './models/Autor.js';
import { Genre } from './models/Genre.js';

// EIN gebündelter Import:
import { Buch, Autor, Genre } from './models/index.js';

Achtung: Barrel Exports sind bequem, haben aber einen bekannten Nachteil bei größeren Projekten: SÄMTLICHE Dateien, die vom Barrel re-exportiert werden, werden potenziell GELADEN, sobald IRGENDETWAS aus dem Barrel importiert wird – bei sehr großen Projekten kann das die Kompilierzeit/Bundle-Größe unnötig aufblähen. Für unser überschaubares Bibliotheksprojekt ist das kein Problem, aber ein wichtiger Punkt für spätere, größere Projekte.

Eine Falle: zirkuläre Imports

// A.ts importiert von B.ts, B.ts importiert von A.ts -
// funktioniert manchmal "zufällig", bricht aber leicht bei Refactorings
// und ist grundsätzlich ein Zeichen für unsauber getrennte Verantwortlichkeiten

Unsere Modellhierarchie (Medium → Buch/Hoerbuch, Autor unabhängig) ist BEWUSST als reiner "Baum" ohne Zyklen aufgebaut – Autor.ts importiert NIE von Buch.ts, obwohl Buch.ts Autor importiert. Diese EINSEITIGE Abhängigkeitsrichtung vermeidet zirkuläre Imports von Grund auf.

Tipp: Faustregel: export (named) für ALLES in diesem Tutorial, import type für reine Typ-Importe (macht Absicht klar), Barrel Exports NUR bei tatsächlicher Notwendigkeit, zirkuläre Imports durch bewusste, EINSEITIGE Abhängigkeitsrichtung von vornherein vermeiden.