export default vs export: Was in TypeScript wählen?

TypeScript export vs default export: Ein für alle Mal verstehen

Hallo, Freund! Wenn du gerade erst mit TypeScript anfängst (oder schon kein Anfänger mehr bist, aber dich bei den Exporten immer noch unsicher fühlst), dann ist dieser Artikel dein Rettungsring. Das Thema "TypeScript export vs default export" ist eines der heißesten auf Stack Overflow, und das nicht ohne Grund. Es scheint eine Kleinigkeit zu sein, aber wie viele Diskussionen wurden schon geführt! Lass uns das Ganze Schritt für Schritt aufschlüsseln, damit wir uns für immer merken, wann man export und wann export default verwendet.

Wir werden nicht trocken die Regeln aufzählen. Wir besprechen lebendige Beispiele, typische Anfängerfehler und geben konkrete Empfehlungen. Los geht's!

Was ist ein Export in TypeScript und wozu braucht man ihn?

Stell dir vor, du schreibst ein großes Programm. Du wirst doch nicht den gesamten Code in eine Datei packen? Natürlich nicht. Du teilst ihn in Module auf: Eine Datei ist für die Benutzerverwaltung zuständig, eine andere für Berechnungen, eine dritte für die Oberfläche. Export ist die Art, TypeScript mitzuteilen: "Hey, diese Funktion, Klasse oder Variable kann in anderen Dateien verwendet werden". Und Import ist die Art zu sagen: "Lass mich dieses Ding aus einer anderen Datei holen".

In TypeScript gibt es zwei Hauptarten von Exporten: den benannten Export (named export) und den Standard-Export (default export). Und hier wird es richtig interessant.

Benannter Export (named export) – Präzision und Ordnung

Ein benannter Export liegt vor, wenn du explizit den Namen dessen angibst, was du exportierst. Es ist, als ob du an jede Kiste in deiner Garage ein helles Etikett hängst: "Werkzeug", "Sportausrüstung", "Alte Lehrbücher".

Die Syntax ist sehr einfach. Füge einfach das Schlüsselwort export vor die Deklaration hinzu:

Beispiel für einen benannten Export

// utils.ts\nexport const PI = 3.14159;\n\nexport function calculateArea(radius: number): number {\n  return PI * radius * radius;\n}\n\nexport class Circle {\n  constructor(public radius: number) {}\n}

Und jetzt importieren wir das in eine andere Datei:

// app.ts\nimport { PI, calculateArea, Circle } from './utils';\n\nconsole.log(PI); // 3.14159\nconst area = calculateArea(5);\nconst myCircle = new Circle(10);

Beachte die geschweiften Klammern { } beim Import. Sie sind das sichere Zeichen für einen benannten Export. Du kannst nur das importieren, was du brauchst, und du musst dabei dieselben Namen verwenden, die beim Export angegeben wurden (oder sie mit as umbenennen, aber dazu später mehr).

Vorteile des benannten Exports

\n
• Eindeutigkeit: Du siehst immer genau, was aus einem Modul exportiert wird.
\n
• Autovervollständigung: Die IDE (z. B. VS Code) schlägt beim Import hervorragend Namen vor.
\n
• Refactoring: Wenn du eine exportierte Funktion umbenennst, benennt die IDE sie an allen Importstellen um. Das ist sicher.
\n
• Tree-shaking: Bundler (Webpack, Vite) können ungenutzten Code entfernen und so die endgültige Bundle-Größe reduzieren.
\n

Standard-Export (default export) – Bequemlichkeit und Prägnanz

Ein Standard-Export liegt vor, wenn du sagst: "In dieser Datei gibt es eine Hauptentität, und ich möchte, dass sie bequem importiert werden kann." Es ist, als ob du sagst: "Hier ist meine Visitenkarte, darauf steht alles Wesentliche."

In jedem Modul kann es nur einen Standard-Export geben. Die Syntax:

Beispiel für einen Standard-Export

// logger.ts\nconst log = (message: string): void => {\n  console.log(`[LOG]: ${message}`);\n};\n\nexport default log;

Oder du kannst es direkt deklarieren:

export default function log(message: string): void {\n  console.log(`[LOG]: ${message}`);\n}

Der Import sieht so aus (ohne geschweifte Klammern!):

// main.ts\nimport myLog from '