Error Boundary — vad är det, React Native-komponent och felhantering

Vad är Error Boundary

Error Boundary är en React-mekanism för graceful degradation vid renderingsfel. Introducerad i React 16 (2017) som en wrapper-komponent som implementerar en av två livscykelmetoder: static getDerivedStateFromError eller componentDidCatch. Error Boundary gör att användaren kan se ett meningsfullt meddelande istället för en tom vit skärm eller fullständig krasch av applikationen.

Hur Error Boundary uppstod

Före React 16 ledde varje ohanterat fel i render till krasch av hela applikationen med demontering av hela DOM-trädet. I webbapplikationer innebar detta en tom vit skärm, i React Native — fullständig krasch med återgång till Home Screen. React-teamet introducerade Error Boundary som en analog till catch-block för deklarativt UI, och lånade konceptet från “let it crash”-metoden i språket Erlang.

Betydelse för React Native

I React Native innebär frånvaron av Error Boundary fullständig krasch av applikationen vid varje renderingsfel. Användaren förlorar hela den aktuella sessionen utan möjlighet till återställning. Error Boundary i React Native är avgörande eftersom mobilapplikationer inte laddas om som webbsidor — användarsessionen förloras oåterkalleligt och användaren måste börja om från början.

Hur Error Boundary fungerar i React Native

Error Boundary fungerar på nivån av React-trädet. När en underordnad komponent kastar ett fel i render eller lifecycle, demonterar React inte hela trädet, utan överför kontrollen till närmaste Error Boundary högre upp i hierarkin. Boundary anropar getDerivedStateFromError, ställer in state.hasError = true och renderar fallback UI istället för den trasiga komponentgrenen.

import React, { Component, ErrorInfo, ReactNode } from "react"

interface Props {
    children: ReactNode
    fallback?: ReactNode
}

interface State {
    hasError: boolean
    error?: Error
}

class ErrorBoundary extends Component<Props, State> {
    constructor(props: Props) {
        super(props)
        this.state = { hasError: false }
    }

    static getDerivedStateFromError(error: Error): State {
        return { hasError: true, error }
    }

    componentDidCatch(error: Error, info: ErrorInfo) {
        console.error("Fångad av boundary:", error)
        Crashlytics.recordException(error)
    }

    render() {
        if (this.state.hasError) {
            return this.props.fallback || <FallbackUI />
        }
        return this.props.children
    }
}

getDerivedStateFromError ställer in tillståndet för att rendera fallback UI — detta är en statisk metod som anropas i renderingsfasen före bekräftelse av ändringar. componentDidCatch körs i bekräftelsefasen och är avsedd för sidoeffekter: loggning, skicka kraschrapporter till Crashlytics, analys. Två metoder delar ansvaret mellan hantering av UI-tillstånd och sidoeffekter.

Skapa Error Boundary-komponent

För att skapa Error Boundary måste du implementera en klasskomponent med metoderna getDerivedStateFromError och/eller componentDidCatch. Funktionskomponenter kan inte vara Error Boundary — React stöder denna funktionalitet endast för klasskomponenter eftersom åtkomst till livscykelmetoder krävs. I biblioteket react-error-boundary finns en färdig implementering med hooks-API för bekvämlighet.

// Exempel på användning av Error Boundary i React Native
import { ErrorBoundary } from "react-error-boundary"

const FallbackComponent = ({ error, resetError }: FallbackProps) => (
    <View style={styles.container}>
        <Text>Något gick fel</Text>
        <Text>{error.message}</Text>
        <Button title="Försök igen" onPress={resetError} />
    </View>
)

const App = () => (
    <SafeAreaView>
        <ErrorBoundary FallbackComponent={<FallbackComponent />}>
            <UserProfile userId={"123"} />
        </ErrorBoundary>
        <BottomNavigation />
    </SafeAreaView>
)

Inpackningsnivåer — Error Boundary kan placeras på olika nivåer i hierarkin. En global Boundary vid roten av applikationen visar fallback UI vid varje fel, men navigeringen fungerar fortfarande. Flera Boundary på skärmnivå gör det möjligt att isolera fel: om en skärm går sönder fortsätter de andra att fungera oberoende. react-error-boundary förenklar Reset-mekanismen via useErrorBoundary-hooken, vilket gör att tillståndet kan återställas utan omladdning. För typiska projekt anses schemat med tre Boundary-nivåer vara optimalt för React Native-applikationer.

Återställa Error Boundary-tillstånd

Efter att ett fel har inträffat kan användaren trycka på knappen “Försök igen”, som återställer hasError till false och renderar om det underordnade trädet. Reset-mekanismen är viktig för att återställa applikationens funktionalitet utan omladdning. I react-error-boundary används en onReset-callback som kan rensa cacheminnet, begära data på nytt eller uppdatera tillståndet högre upp i trädet.

Begränsningar för Error Boundary

Error Boundary fångar inte asynkrona fel — fel i setTimeout, setInterval, Promise, async/await. React kan inte fånga fel utanför renderingscykeln och lifecycle-hooks eftersom de körs i andra körningskontexter. För asynkrona fel krävs en separat try-catch i hanterare eller en global hanterare för unhandledrejection-händelsen.

Event-hanterare

Fel i onClick, onChange och andra event-hanterare fångas inte av Error Boundary eftersom de körs utanför React-rendering. Felhantering för event-hanterare bör ske inuti själva hanteraren via try-catch. Biblioteket react-error-boundary tillhandahåller hooken useErrorHandler för att överföra fel från event-hanterare till närmaste Boundary.

Server-side rendering och Next.js

Error Boundary fungerar inte på serversidan i Next.js eller Gatsby. Metoderna getDerivedStateFromError och componentDidCatch anropas inte vid SSR eftersom livscykelmetoderna endast är tillgängliga i webbläsaren. För serverfel krävs en separat strategi: try-catch i getServerSideProps, fallback-sidor error.js (Next.js 13+) eller global middleware.

React Native inbyggt lager

I React Native förhindrar Error Boundary inte krasch på nivån av inbyggda moduler. Inbyggd krasch (segfault, out-of-memory, inbyggt undantag) sker på nivån Objective-C eller Java och når inte JavaScript-lagret. För inbyggda krascher krävs Crashlytics NDK (Android) eller KSCrash (iOS). Error Boundary skyddar endast JavaScript-lagret i React Native-applikationen.

Bästa praxis för Error Boundary

Placera Error Boundary vid gränserna för meningsfulla moduler: en Boundary per skärm, en per widget från tredje part, en per komplext formulär. Detta isolerar fel och låter användaren fortsätta arbeta i resten av applikationen. Rot-Boundary måste alltid finnas — för kritiska fel i gemensamma navigeringskomponenter eller providers. Varje Boundary ansvarar för sitt eget gränssnittsfragment och påverkar inte angränsande komponenter när ett fel uppstår.

Loggning och övervakning

Skicka alltid felet till Crashlytics eller Sentry via componentDidCatch. Lägg till sammanhang: skärmnamn, userId, applikationsversion, navigeringsparametrar. I Sentry finns breadcrumbs — sekvensen av användaråtgärder före felet. För analys av frekvensen av icke-fatala fel, använd Crashlytics-instrumentpaneler med gruppering per issue.

Fallback UI

Använd inte “tom” fallback — skapa ett meningsfullt gränssnitt. Rekommenderad uppsättning för React Native: felmeddelande (användarvänligt, inte tekniskt), knapp “Försök igen”, länk till support eller chatt. Undvik tom View — användaren tror att applikationen har kraschat helt och stänger den. Fallback bör integreras i applikationens övergripande design.

Testning av Error Boundary

Testa varje Error Boundary med React Testing Library eller React Native Testing Library. Skapa en trigger-komponent som kastar ett fel vid rendering och kontrollera att fallback UI visas. För integrationstester, använd storybook med olika tillstånd för Error Boundary: normalt, fel, tillstånd efter återställning. Automatiserad testning av Boundary garanterar att fallback UI fortsätter att fungera korrekt i production när komponenten ändras. Testtäckning för varje Boundary bör vara ett obligatoriskt code review-krav för React Native-projekt.