Fortgeschrittene Vue 3 Composables: Wiederverwendbare Muster und Interviewfragen 2026

Vue 3 Composables haben sich als Standardmechanismus fuer die Extraktion und Wiederverwendung reaktiver Logik ueber Komponentengrenzen hinweg etabliert. Mit der Einfuehrung von Alien Signals und der Kompatibilitaet mit dem Vapor Mode in Vue 3.6 wirkt sich die Beherrschung von Composable-Mustern unmittelbar auf Anwendungsarchitektur, Performance und Wartbarkeit im Jahr 2026 aus.

Die Composition API hat die Art und Weise grundlegend veraendert, wie Entwickler Logik in Vue-Anwendungen organisieren und wiederverwenden. Im Zentrum dieser Transformation stehen Composables: Funktionen, die reaktiven Zustand, Geschaeftslogik und Seiteneffekte in unabhaengige, wiederverwendbare Einheiten kapseln. Im Gegensatz zu den Mixins von Vue 2, die Namenskonflikte und versteckte Abhaengigkeiten verursachten, bieten Composables vollstaendige Transparenz, statische Typisierung mit TypeScript und explizite Komposition.

Die Beherrschung fortgeschrittener Composable-Muster ist 2026 zu einer grundlegenden Anforderung fuer mittlere und Senior-Positionen in der Vue-Entwicklung geworden. Dieser Leitfaden untersucht die am haeufigsten in technischen Vorstellungsgespraechen abgefragten Muster, von der Anatomie eines gut strukturierten Composable bis hin zur Dependency Injection mit provide/inject, einschliesslich Teststrategien zur Validierung der Reaktivitaet jeder einzelnen Komponente.

Anatomie eines gut strukturierten Composable

Ein produktionsreifes Composable folgt einer vorhersehbaren Struktur: Konfiguration ueber Argumente entgegennehmen, reaktiven Zustand intern erzeugen und ein typisiertes Rueckgabeobjekt bereitstellen. Dieses Muster gewaehrleistet Komponierbarkeit, Testbarkeit und klare API-Grenzen.

import { ref, computed, type Ref } from 'vue'

interface UseCounterOptions {
  min?: number
  max?: number
  initialValue?: number
}

interface UseCounterReturn {
  count: Ref<number>
  doubled: Ref<number>
  increment: () => void
  decrement: () => void
  reset: () => void
}

export function useCounter(options: UseCounterOptions = {}): UseCounterReturn {
  const { min = 0, max = Infinity, initialValue = 0 } = options

  const count = ref(initialValue)
  const doubled = computed(() => count.value * 2)

  function increment() {
    if (count.value < max) count.value++
  }

  function decrement() {
    if (count.value > min) count.value--
  }

  function reset() {
    count.value = initialValue
  }

  return { count, doubled, increment, decrement, reset }
}

Mehrere Aspekte dieses Musters verdienen besondere Beachtung. Das Interface UseCounterReturn definiert explizit den Vertrag des Composable, was die Autovervollstaendigung in Editoren erleichtert und versehentliche Aenderungen an der oeffentlichen API verhindert. Das Optionsobjekt mit Standardwerten ermoeglicht eine flexible Konfiguration, ohne die Funktionssignatur zu ueberladen. Jeder Aufruf von useCounter() erzeugt eine unabhaengige Zustandsinstanz und eliminiert damit vollstaendig die Probleme des geteilten Zustands, die bei Mixins auftraten.

Der explizite Rueckgabetyp UseCounterReturn erfuellt zwei Zwecke: Er dokumentiert die oeffentliche API des Composable und verhindert die versehentliche Offenlegung interner Implementierungsdetails. Konsumierende Komponenten destrukturieren genau das, was sie benoetigen, und halten die Template-Bindungen transparent.

Asynchrone Composables mit Fehlerbehandlung und Ladezustaenden

Das Abrufen von Daten zaehlt zu den haeufigsten Anwendungsfaellen fuer Composables. Ein robustes asynchrones Composable verwaltet Ladezustand, Fehlerbehandlung und automatische Bereinigung. Diese Muster werden in Vorstellungsgespraechen regelmaessig abgefragt.

import { ref, watchEffect, onUnmounted, toValue, type Ref, type MaybeRefOrGetter } from 'vue'

interface UseFetchReturn<T> {
  data: Ref<T | null>
  error: Ref<string | null>
  isLoading: Ref<boolean>
  refresh: () => Promise<void>
}

export function useFetchData<T>(
  url: MaybeRefOrGetter<string>
): UseFetchReturn<T> {
  const data = ref<T | null>(null) as Ref<T | null>
  const error = ref<string | null>(null)
  const isLoading = ref(false)
  let abortController: AbortController | null = null

  async function fetchData() {
    // Cancel any in-flight request
    abortController?.abort()
    abortController = new AbortController()

    isLoading.value = true
    error.value = null

    try {
      const response = await fetch(toValue(url), {
        signal: abortController.signal
      })
      if (!response.ok) throw new Error(`HTTP ${response.status}`)
      data.value = await response.json()
    } catch (err) {
      if (err instanceof DOMException && err.name === 'AbortError') return
      error.value = err instanceof Error ? err.message : 'Unknown error'
    } finally {
      isLoading.value = false
    }
  }

  // Re-fetch when URL changes reactively
  watchEffect(() => {
    fetchData()
  })

  onUnmounted(() => abortController?.abort())

  return { data, error, isLoading, refresh: fetchData }
}

Dieses Composable fuehrt mehrere fortgeschrittene Konzepte ein. Der Parametertyp MaybeRefOrGetter<string> akzeptiert sowohl einfache Strings als auch Refs oder Getter-Funktionen und bietet damit maximale Flexibilitaet fuer den Aufrufer. Die Funktion toValue() extrahiert den zugrunde liegenden Wert unabhaengig vom Eingabetyp. Der Einsatz des AbortController verhindert Race Conditions, indem veraltete Anfragen abgebrochen werden, sobald sich die URL aendert, bevor die vorherige Antwort eintrifft.

Der watchEffect etabliert ein automatisches reaktives Tracking: Jede Ref oder jeder Getter, auf die innerhalb des Callbacks zugegriffen wird, wird automatisch zu einer Abhaengigkeit. Wenn die URL eine Ref ist und sich ihr Wert aendert, wird der Effekt automatisch erneut ausgefuehrt. Der Hook onUnmounted garantiert die Bereinigung von Ressourcen, wenn die Komponente zerstoert wird.

Komposition von Composables: Abstraktionen hoeherer Ebene

Die wahre Staerke von Composables zeigt sich, wenn sie andere Composables komponieren. Dies spiegelt das Prinzip der funktionalen Komposition wider: kleine, fokussierte Einheiten werden zu komplexem Verhalten kombiniert, ohne auf Vererbungshierarchien zurueckzugreifen.

import { ref, computed, watch, type Ref } from 'vue'
import { useFetchData } from './useFetchData'
import { useDebouncedRef } from './useDebouncedRef'

interface UsePaginatedSearchReturn<T> {
  query: Ref<string>
  page: Ref<number>
  results: Ref<T[] | null>
  totalPages: Ref<number>
  isLoading: Ref<boolean>
  error: Ref<string | null>
  nextPage: () => void
  prevPage: () => void
}

export function usePaginatedSearch<T>(
  baseUrl: string,
  perPage = 20
): UsePaginatedSearchReturn<T> {
  const query = useDebouncedRef('', 300)
  const page = ref(1)
  const totalPages = ref(1)

  const apiUrl = computed(
    () => `${baseUrl}?q=${encodeURIComponent(query.value)}&page=${page.value}&limit=${perPage}`
  )

  const { data, error, isLoading } = useFetchData<{ items: T[]; total: number }>(apiUrl)

  const results = computed(() => data.value?.items ?? null)

  watch(data, (response) => {
    if (response) {
      totalPages.value = Math.ceil(response.total / perPage)
    }
  })

  // Reset to page 1 when query changes
  watch(query, () => { page.value = 1 })

  function nextPage() {
    if (page.value < totalPages.value) page.value++
  }

  function prevPage() {
    if (page.value > 1) page.value--
  }

  return { query, page, results, totalPages, isLoading, error, nextPage, prevPage }
}

Die Komposition erfolgt auf mehreren Ebenen. useDebouncedRef liefert eine Ref mit integriertem Debouncing, die ueberfluessige Anfragen waehrend der Eingabe verhindert. useFetchData erhaelt apiUrl als computed, was bedeutet, dass jede Aenderung an query oder page die URL neu berechnet und automatisch eine neue Anfrage ausloest. Der Watcher auf query setzt die Paginierung bei jeder Aenderung des Suchbegriffs auf Seite 1 zurueck.

Dieses Muster demonstriert ein grundlegendes Prinzip: Jedes Composable loest ein spezifisches Problem, und die Komposition verbindet sie ohne Kopplung. In einem technischen Vorstellungsgespraech zeigt die Erklaerung dieser Reaktivitaetskette (query aendert sich -> apiUrl wird neu berechnet -> useFetchData fuehrt erneut aus -> results wird aktualisiert) ein tiefes Verstaendnis des reaktiven Systems von Vue.

Dependency Injection mit provide/inject fuer Composable-Architektur

Bestimmte Zustaende muessen ueber einen Komponentenbaum hinweg geteilt werden, ohne dass Props durch jede Ebene durchgereicht werden muessen. Das provide/inject-System von Vue erzeugt in Kombination mit Composables ein typisiertes und sicheres Kontextmuster.

import { provide, inject, ref, readonly, type InjectionKey, type Ref } from 'vue'

type Theme = 'light' | 'dark' | 'system'

interface ThemeContext {
  theme: Readonly<Ref<Theme>>
  setTheme: (t: Theme) => void
  resolvedTheme: Readonly<Ref<'light' | 'dark'>>
}

const ThemeKey: InjectionKey<ThemeContext> = Symbol('theme')

export function provideTheme(initial: Theme = 'system') {
  const theme = ref<Theme>(initial)

  const resolvedTheme = computed<'light' | 'dark'>(() => {
    if (theme.value !== 'system') return theme.value
    return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'
  })

  function setTheme(t: Theme) {
    theme.value = t
  }

  const context: ThemeContext = {
    theme: readonly(theme),
    setTheme,
    resolvedTheme: readonly(resolvedTheme)
  }

  provide(ThemeKey, context)
  return context
}

export function useTheme(): ThemeContext {
  const context = inject(ThemeKey)
  if (!context) {
    throw new Error('useTheme() requires a parent component to call provideTheme()')
  }
  return context
}

Dieses Muster trennt die Bereitstellung vom Konsum. Die Root-Komponente (oder ein Layout) ruft provideTheme() einmalig auf, und jede beliebige Nachkommenkomponente greift ueber useTheme() auf den Kontext zu, unabhaengig von der Tiefe im Komponentenbaum. Die Verwendung von InjectionKey<ThemeContext> mit Symbol garantiert Typsicherheit zur Kompilierzeit.

Die Funktion readonly() umschliesst die exponierten Refs, um direkte Mutationen durch konsumierende Komponenten zu verhindern. Nur setTheme() kann das Theme modifizieren, wodurch ein unidirektionaler Datenfluss erzwungen wird. Die Eigenschaft resolvedTheme loest den Wert 'system' auf, indem sie die Media Query des Browsers abfragt, und stellt somit immer einen konkreten Wert ('light' oder 'dark') bereit, den Komponenten direkt fuer die Anwendung von Styles verwenden koennen.

In Vorstellungsgespraechen wird dieses Muster haeufig mit React Context oder Pinia-Stores verglichen. Der entscheidende Unterschied besteht darin, dass provide/inject auf der Ebene des Komponentenbaums operiert (nicht global) und keine externen Abhaengigkeiten erfordert.

Wiederverwendbares Composable fuer Formularvalidierung

Die Formularvalidierung ist ein Bereich, in dem Composables besonders ueberzeugen. Sie ersetzen repetitive Logik durch ein deklaratives, regelbasiertes Muster.

import { reactive, computed, type UnwrapNestedRefs } from 'vue'

type ValidationRule<T> = (value: T) => string | true
type FieldRules<T> = { [K in keyof T]?: ValidationRule<T[K]>[] }

interface UseFormReturn<T extends Record<string, any>> {
  fields: UnwrapNestedRefs<T>
  errors: Record<keyof T, string>
  isValid: Ref<boolean>
  validate: () => boolean
  resetErrors: () => void
}

export function useFormValidation<T extends Record<string, any>>(
  initialValues: T,
  rules: FieldRules<T>
): UseFormReturn<T> {
  const fields = reactive({ ...initialValues }) as UnwrapNestedRefs<T>

  const errors = reactive(
    Object.keys(initialValues).reduce(
      (acc, key) => ({ ...acc, [key]: '' }),
      {} as Record<keyof T, string>
    )
  )

  function validate(): boolean {
    let valid = true
    for (const key of Object.keys(rules) as (keyof T)[]) {
      const fieldRules = rules[key] || []
      errors[key] = '' as any
      for (const rule of fieldRules) {
        const result = rule(fields[key])
        if (result !== true) {
          errors[key] = result as any
          valid = false
          break // Stop at first error per field
        }
      }
    }
    return valid
  }

  function resetErrors() {
    for (const key of Object.keys(errors)) {
      (errors as any)[key] = ''
    }
  }

  const isValid = computed(() =>
    Object.values(errors).every((e) => e === '')
  )

  return { fields, errors, isValid, validate, resetErrors }
}

Das Composable empfaengt Initialwerte und eine Zuordnung von Validierungsregeln pro Feld. Jede Regel ist eine Funktion, die true zurueckgibt, wenn der Wert gueltig ist, oder einen String mit der Fehlermeldung. Die Methode validate() iteriert ueber die Regeln und stoppt beim ersten Fehler jedes Feldes, um zu vermeiden, dass mehrere Meldungen gleichzeitig angezeigt werden, was fuer Benutzer verwirrend waere.

Die Verwendung von reactive() anstelle von ref() fuer Felder und Fehler vereinfacht den Zugriff in Templates: fields.email statt fields.value.email. Die berechnete Eigenschaft isValid aktualisiert sich automatisch, wenn sich ein Fehler aendert, und ermoeglicht so die reaktive Aktivierung oder Deaktivierung von Absende-Buttons.

Dieses Muster ist erweiterbar. Asynchrone Regeln (Pruefung der Verfuegbarkeit einer E-Mail-Adresse), felduebergreifende Validierung (Passwortbestaetigung) und internationalisierte Fehlermeldungen koennen hinzugefuegt werden, ohne die Grundstruktur des Composable zu veraendern.

Composables isoliert testen

Composables, die reaktive APIs von Vue nutzen, benoetigen einen Komponentenkontext, um korrekt zu funktionieren. Die Hilfsfunktion withSetup loest diese Anforderung, indem sie eine minimale Komponente erstellt, die das Composable innerhalb von setup() ausfuehrt.

import { describe, it, expect } from 'vitest'
import { mount } from '@vue/test-utils'
import { defineComponent, h } from 'vue'
import { useCounter } from './useCounter'

function withSetup<T>(composable: () => T): { result: T; unmount: () => void } {
  let result!: T
  const wrapper = mount(
    defineComponent({
      setup() {
        result = composable()
        return () => h('div')
      }
    })
  )
  return { result, unmount: () => wrapper.unmount() }
}

describe('useCounter', () => {
  it('initializes with default value', () => {
    const { result } = withSetup(() => useCounter())
    expect(result.count.value).toBe(0)
  })

  it('respects min and max boundaries', () => {
    const { result } = withSetup(() =>
      useCounter({ min: 0, max: 3, initialValue: 3 })
    )
    result.increment()
    expect(result.count.value).toBe(3) // Capped at max

    result.count.value = 0
    result.decrement()
    expect(result.count.value).toBe(0) // Capped at min
  })

  it('computes doubled value reactively', () => {
    const { result } = withSetup(() => useCounter({ initialValue: 5 }))
    expect(result.doubled.value).toBe(10)
    result.increment()
    expect(result.doubled.value).toBe(12)
  })
})

Die Funktion withSetup ist ein Standardmuster im Vue-Oekosystem zum isolierten Testen von Composables. Sie mountet eine Wrapper-Komponente, die das Composable innerhalb von setup() aufruft, und bietet Zugriff auf das Ergebnis sowie eine unmount()-Funktion zur Simulation der Komponentenzerstoerung.

Jeder Test validiert einen spezifischen Aspekt: Initialisierung mit Standardwerten, Einhaltung konfigurierter Grenzen und Reaktivitaet berechneter Werte. Der dritte Test ist besonders wichtig, da er verifiziert, dass sich doubled automatisch aktualisiert, wenn count ueber increment() geaendert wird, und damit die korrekte Funktionsweise des reaktiven Graphen bestaetigt.

Fuer asynchrone Composables wie useFetchData erfordern die Tests Mocks von fetch und den Umgang mit Promises ueber flushPromises() von Vue Test Utils. In Vorstellungsgespraechen signalisiert die Vertrautheit mit diesem Testmuster professionelle Reife und Engagement fuer Codequalitaet.

Haeufige Interviewfragen zu Vue 3 Composables

Die folgenden Fragen erscheinen regelmaessig in Auswahlverfahren fuer mittlere und Senior-Vue-Positionen im Jahr 2026:

1. Worin besteht der Unterschied zwischen einem Composable und einem Mixin?

Mixins fuegen Eigenschaften implizit in die Komponente ein, was zu Namenskonflikten fuehrt und es erschwert, den Ursprung jeder Eigenschaft nachzuvollziehen. Composables geben Werte explizit zurueck, bieten vollstaendige Typisierung mit TypeScript und erlauben das Umbenennen von Variablen beim Destrukturieren der Rueckgabe. Jeder Aufruf erzeugt eine unabhaengige Zustandsinstanz, waehrend Mixins den Zustand ueber alle Komponenten hinweg teilen, die sie einbinden.

2. Warum muessen Composables innerhalb von setup() aufgerufen werden?

Vue assoziiert Lifecycle-Hooks (onMounted, onUnmounted, watch, watchEffect) mit der aktiven Komponenteninstanz waehrend setup(). Der Aufruf eines Composable ausserhalb dieses Kontexts unterbricht diese Assoziation, sodass Effekte weder registriert noch bereinigt werden. Dies ist eine der am haeufigsten gestellten Fragen in technischen Vue-Interviews.

3. Wie wird der Zustand zwischen mehreren Komponenten mit Composables geteilt?

Es gibt zwei grundlegende Strategien. Fuer globalen Zustand wird die Ref ausserhalb der Composable-Funktion deklariert (Singleton-Muster). Fuer kontextbezogenen Zustand in einem Teilbaum von Komponenten wird provide/inject mit typisiertem InjectionKey verwendet, wie im Beispiel von useTheme demonstriert. Fuer komplexere globale Zustandsverwaltung empfiehlt sich Pinia.

4. Was ist MaybeRefOrGetter und warum ist es wichtig?

Dabei handelt es sich um einen Utility-Typ von Vue, der einen einfachen Wert, eine Ref oder eine Getter-Funktion akzeptiert. Er ermoeglicht es Composables, sowohl statische als auch reaktive Eingaben entgegenzunehmen, und maximiert damit die Flexibilitaet fuer den Aufrufer. Die Funktion toValue() extrahiert den zugrunde liegenden Wert unabhaengig vom Eingabetyp.

5. Wie werden Composables getestet, die onMounted oder onUnmounted verwenden?

Es wird eine Hilfsfunktion wie withSetup verwendet, die eine Wrapper-Komponente mountet. Diese Komponente fuehrt das Composable innerhalb von setup() aus und stellt den notwendigen Instanzkontext bereit. Zur Ueberpruefung der Bereinigung wird unmount() aufgerufen und kontrolliert, ob Seiteneffekte (Listener, Timer, Abort Controller) entfernt wurden.

6. Wann sollte Pinia anstelle von Composables mit provide/inject eingesetzt werden?

Pinia ist vorzuziehen, wenn der Zustand global von jeder Komponente ohne hierarchische Beziehung zugaenglich sein muss, wenn Persistenz (localStorage/sessionStorage) erforderlich ist, wenn die Integration mit Vue DevTools fuer das Debugging benoetigt wird oder wenn mehrere Komponentenbaeume denselben Zustand teilen muessen. Composables mit provide/inject sind besser geeignet fuer kontextbezogenen Zustand, der auf einen bestimmten Teilbaum beschraenkt ist.

Fazit

Vue 3 Composables stellen mehr als nur eine Alternative zu Mixins dar: Sie sind ein Paradigma der Codeorganisation, das von einfachen Hilfsfunktionen bis hin zu komplexen Systemen mit Dependency Injection und mehrstufiger Komposition skaliert. Die Beherrschung dieser Muster unterscheidet Entwickler, die Vue lediglich verwenden, von jenen, die das reaktive System in der Tiefe verstehen.

Die zentralen Erkenntnisse im Ueberblick:

• Klare Struktur: Typisierte Ein- und Ausgabe-Interfaces mit UseXxxOptions und UseXxxReturn dokumentieren die API und verhindern versehentliche Offenlegung interner Details
• Zustandsisolation: Jeder Aufruf erzeugt eine unabhaengige Instanz und eliminiert damit Konflikte vollstaendig
• Explizite Komposition: Composables, die andere Composables konsumieren, erzeugen vorhersehbare Reaktivitaetsketten
• Ressourcenverwaltung: AbortController und onUnmounted garantieren die Bereinigung von Seiteneffekten und verhindern Memory Leaks
• Typisierte Injection: provide/inject mit InjectionKey ersetzt Prop Drilling ohne Einbussen bei der Typsicherheit
• Testbarkeit: Das withSetup-Muster ermoeglicht die Validierung der Reaktivitaet in vollstaendiger Isolation
• Pragmatismus: VueUse vor der Neuimplementierung gaengiger Funktionalitaet pruefen spart Zeit und nutzt bewaehrte Loesungen

Die Vorbereitung dieser Muster mit konkreten Implementierungen und der Faehigkeit, die Designentscheidungen hinter jedem einzelnen zu erklaeren, verschafft einen erheblichen Vorteil in technischen Auswahlverfahren fuer Vue-Positionen im Jahr 2026.