Your Composable Is Lying About Errors

<TLDR items={[ “A composable that exposes { data, error, isLoading } with error: Ref<Error | null> hides the most important thing about itself: how it can fail.”, “Swap the loose refs for a single Ref<Result<T, E>> where E is a discriminated union of the failures you actually care about.”, “Vue templates handle discriminated unions natively — v-if chains on a kind field narrow the type for free.”, “You don’t need a library. A working Result type is twelve lines. Reach for neverthrow, better-result, or Effect only when the boilerplate starts to bite.”, ]} /> The Composable That Lies Three years ago I wrote a post on error handling in Vue composables. The pattern was: catch inside the composable, expose a reactive error object, let the component react to it. It works. It’s also lying to you, and I want to talk about that. Here’s a useBooking composable in the shape most of us still write: // composables/useBooking.ts export function useBooking() { const booking = ref<Booking |…