Sauberer Pinia-Store: Struktur und Best Practices

Saubere Pinia-Store-Struktur: Bewährte Best Practices

In großen Vue-Projekten blähen sich Pinia-Stores oft auf und machen die Wartung zum Albtraum. Eine solide Struktur behebt das: Mutationen nur über Actions, Setup-Syntax und keine Nebenwirkungen im Store. So bleibt alles vorhersehbar und testbar – ideal für Mid- bis Senior-Entwickler.

Mutationen nur über Actions

Direkte State-Änderungen aus Komponenten verwischen die Verantwortlichkeiten. Hier ein problematischer Code:

const docStore = useDocumentStore()
const { client } = storeToRefs(docStore)
client.value = null // Verstreute Mutationslogik

Mit der Zeit wird Debugging unmöglich, da Änderungen über Komponenten verteilt sind. Die Lösung? Zentralisierte Actions:

export const useDocumentStore = defineStore('documents', () => {
  const client = ref(null)
  const resetClient = () => { client.value = null }
  return { client, resetClient }
})

// In der Komponente
 docStore.resetClient()

Ein zentraler Einstiegspunkt erleichtert Validierung, Logging oder Analytics, ohne überall Code anzupassen.

Setup-Stores statt Options API

Die Options API ist für Stores veraltet. Die Setup-Variante (defineStore(() => { ... })) bietet:

• Transparente Reaktivität ohne this.
• Einfacheres Testen.
• Nahtlose Integration mit Composables.

Weniger Boilerplate, Reaktivität wie in Komponenten. Für neue Stores ist der Wechsel Pflicht – der Unterschied schlägt sofort ein.

Keine Watcher in Stores

Watcher in Stores lösen versteckte Nebenwirkungen bei State-Änderungen aus und erschweren das Debugging. Stores sollten nur Daten halten, keine Events dispatchen.

Ersetzt Watcher durch explizite Aufrufe aus Komponenten oder Composables. Routenwechsel, URL-Parsing oder externe Events extern behandeln und fertige Daten über Actions weiterleiten.

Persistenz über Plugins

Synchronisation mit localStorage gehört nicht zur Business-Logik. Nutzt pinia-plugin-persistedstate oder einen eigenen getesteten Wrapper.

Direkte localStorage.setItem-Aufrufe in Actions vermeiden – sie zerstören die Store-Reinheit und behindern Refactoring.

Stores als reine Datenhalter

Stores kümmern sich nur um Lesen, Speichern und Aktualisieren von Daten. Auslagern:

• Router-Subscriptions.
• Token-Parsing.
• WebSocket-Logik.
• Cross-Store-Berechnungen.

Pre-Commit-Checkliste:

• Könnte ich diesen Store durch eine einfache Datei mit Konstanten und Funktionen ersetzen, ohne die Architektur zu zerstören?
• Wenn nicht, ist er überladen – Logik extrahieren.

Wichtige Erkenntnisse

• Zentralisierte Mutationen: Actions statt direkter Ref-Zugriffe.
• Setup-Syntax: Einfacheres Testen, kein this.
• Keine Watcher: Nebenwirkungen raus, Store bleibt vorhersehbar.
• Getrennte Persistenz: Plugins, nicht in Actions.
• Einzelverantwortung: Komplexe Logik in Composables.

Dieser Ansatz hält Stores schlank, mockbar und refactorfreundlich. Projekte bleiben wartbar, und die Gewohnheit setzt sich schnell durch.

— Editorial Team