Module in JavaScript

Wir haben import/export bereits genutzt, um Konto und Sparkonto in eigene Dateien aufzuteilen – Zeit, das ES-Module-System systematisch zu behandeln und unser Projekt sauber zu strukturieren.

Named Exports

src/kategorien.js

export const STANDARD_KATEGORIEN = ['Miete', 'Lebensmittel', 'Freizeit', 'Gehalt'];

export function istGueltigeKategorie(kategorie) {
  return STANDARD_KATEGORIEN.includes(kategorie);
}

// Einzeln importieren, exakt beim Namen:
import { STANDARD_KATEGORIEN, istGueltigeKategorie } from './kategorien.js';

console.log(istGueltigeKategorie('Miete')); // true

Default Exports

Jede Datei darf HÖCHSTENS EINEN Default Export haben – typisch für den "Hauptexport" einer Datei, wie unsere Konto-Klasse:

src/konto.js

export default class Konto {
  constructor(name, startguthaben) {
    this.name = name;
    this.kontostand = startguthaben;
  }
}

// Default-Import: der Name beim Import ist FREI wählbar (keine geschweiften Klammern!)
import Konto from './konto.js';
// Ebenso gültig: import Girokonto from './konto.js';

Achtung: In diesem Tutorial und in unserem Haushaltsbuch-Projekt bevorzugen wir DURCHGEHEND Named Exports (wie bei Konto in Kapitel 19) – der Import-Name ist damit an allen Stellen des Projekts KONSISTENT, und Editoren können Umbenennungen zuverlässiger nachverfolgen. Default Exports sind ein legitimes, weit verbreitetes Muster, aber diese Konsistenz-Eigenschaft macht Named Exports für größere Projekte oft die robustere Wahl.

Umbenennen mit as

// Beim Export umbenennen:
export { STANDARD_KATEGORIEN as KATEGORIEN };

// Beim Import umbenennen, z. B. bei Namenskonflikten:
import { STANDARD_KATEGORIEN as AlleKategorien } from './kategorien.js';

Alles als Namespace importieren

import * as Kategorien from './kategorien.js';

console.log(Kategorien.STANDARD_KATEGORIEN);
console.log(Kategorien.istGueltigeKategorie('Miete'));

Das Haushaltsbuch-Projekt sauber strukturieren

Mit Modulen teilen wir unser bisher in einer einzigen index.js gewachsenes Projekt endlich sauber auf:

Projektstruktur nach Kapitel 21

haushaltsbuch-app/
├── package.json
└── src/
    ├── index.js
    ├── konto.js
    ├── sparkonto.js
    └── kategorien.js

src/index.js

import { Konto } from './konto.js';
import { Sparkonto } from './sparkonto.js';
import { STANDARD_KATEGORIEN, istGueltigeKategorie } from './kategorien.js';

const girokonto = new Konto('Girokonto', 1500);
girokonto.buchen('Gehalt Januar', 2400, 'Gehalt');

const sparkonto = new Sparkonto('Tagesgeld', 5000, 2.5);
sparkonto.jahresZinsenGutschreiben();

console.log(girokonto.formatiereKontostand());
console.log(sparkonto.formatiereKontostand());
console.log('Gültige Kategorien:', STANDARD_KATEGORIEN);
console.log(istGueltigeKategorie('Auto')); // false

ES Modules bringen zwei wichtige Eigenschaften mit, die CommonJS (Kapitel 2) fehlen: Jede Datei läuft automatisch im Strict Mode (relevant für Kapitel 17s this-Verhalten), und jede Datei hat ihren EIGENEN Modul-Scope – Top-Level-Variablen "lecken" NICHT automatisch in den globalen Scope, wie es bei klassischen <script>-Tags im Browser der Fall wäre.

Damit ist Phase 3 (Scope, Closures, OOP) abgeschlossen! Phase 4 widmet sich der Asynchronität: Iteratoren, dem Event Loop, Promises und async/await.