Join the discussion
Comments
Loading comments...
Cookie preferences
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
Join the discussion
Loading comments...
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
Wie React Fehler im Komponentenbaum abfängt und eine Fallback-Benutzeroberfläche rendert.
Fehlergrenzen sind React-Klassen-Komponenten, die JavaScript-Fehler überall in ihrem Kind-Komponentenbaum abfangen, diese Fehler protokollieren und eine Fallback-Benutzeroberfläche anstelle des Absturzes der gesamten Anwendung anzeigen. Sie funktionieren wie ein JavaScript-catch{'}-Block, aber für den Komponentenbaum. Eine Fehlergrenze fängt Fehler während des Renderings, in Lifecycle-Methoden und in Konstruktoren des gesamten Baums darunter ab.
Wenn eine Komponente im Teilbaum während des Renderings (oder in einer Lifecycle-Methode) wirft, beginnt React, den Fehler durch den Fiber-Baum nach oben weiterzugeben und sucht nach der nächsten Fehlergrenze.
React durchläuft aufwärts durch übergeordnete Fibers. Wenn es eine Klassen-Komponente findet, die getDerivedStateFromError oder componentDidCatch implementiert, stoppt es dort. Wenn es die Wurzel erreicht, ohne eine zu finden, hebt die gesamte App auf.
React ruft getDerivedStateFromError(fehler) auf der Grenzklasse auf. Diese statische Methode gibt neuen Zustand zurück (z.B. '{' hasError: true '}'), der bewirkt, dass die Grenze mit der Fallback-Benutzeroberfläche neu rendert.
Nachdem die Fallback-Benutzeroberfläche angezeigt wird, ruft React componentDidCatch(fehler, fehlerInfo) auf — ein guter Ort, um den Fehler an einen Logging-Dienst wie Sentry zu senden.
Die Grenzkomponente prüft ihren Zustand (hasError) und rendert entweder die Kinder (normal) oder ein Fallback-JSX-Element. Der Rest der App außerhalb der Grenze funktioniert weiterhin normal.
Statische Klassenmethode. Wird während der Render-Phase aufgerufen, wenn ein Kind wirft. Gibt neuen Zustand zurück, um Fallback-Rendering auszulösen.
Instanzmethode. Wird während der Commit-Phase nach dem Rendern des Fallbacks aufgerufen. Für Fehler-Logging verwenden. Empfängt Fehler + Komponentenstapel.
Fehler blubbern durch den Fiber-Baum zur nächsten Grenze, genauso wie Ausnahmen durch Aufrufstapel hochblubbert.
Grenzen können durch Ändern ihrer key-Prop zurückgesetzt werden, was React veranlasst, den gesamten Teilbaum frisch unmounten und remounten.
1class ErrorBoundary extends React.Component {2 state = { hasError: false, error: null };34 static getDerivedStateFromError(error) {5 // Called during render — must be pure, no side effects6 return { hasError: true, error };7 }89 componentDidCatch(error, info) {10 // Called after commit — safe for side effects like logging11 logErrorToSentry(error, info.componentStack);12 }1314 render() {15 if (this.state.hasError) {16 return <FallbackUI error={this.state.error} />;17 }18 return this.props.children;19 }20}2122// Usage:23<ErrorBoundary>24 <MyComponent /> {/* If this throws, ErrorBoundary catches it */}25</ErrorBoundary>
Ohne Fehlergrenzen stürzt ein einzelner unbehandelter Render-Fehler Ihre gesamte React-App ab und zeigt einen leeren Bildschirm. Fehlergrenzen ermöglichen es Ihnen, Fehler auf isolierte Abschnitte der Benutzeroberfläche zu begrenzen — der Rest der App funktioniert weiter. Dies ist entscheidend für Produktions-Apps, bei denen man nicht jeden Edge-Case vorhersehen kann.
Your e-commerce app crashes in production when a product with malformed data renders. The entire page goes white and users see nothing — you lose the sale and have no visibility into what happened.
Without error boundaries, a single component throwing an error unmounts the ENTIRE React tree. The user sees a blank page. No error tracking fires because the crash happened during rendering, not in a try/catch block.
Wrap critical sections in error boundaries with strategic granularity: one around the product card, one around the cart, one around the whole page. Use componentDidCatch to send the error + componentStack to Sentry. Show a helpful fallback UI ('Something went wrong, refresh to try again') instead of a blank page.
Takeaway: Error boundaries are your PRODUCTION safety net. Place them at route level (catch everything), feature level (isolate failures), and widget level (for third-party components you don't control). Always log to an error tracking service in componentDidCatch.
You embed a third-party analytics chart widget in your dashboard. After a library update, the widget occasionally throws during rendering due to unexpected data formats.
The chart crash cascades — it's nested inside your dashboard layout, so the error propagates up and takes down the entire dashboard, including the navigation, sidebar, and all other widgets.
Wrap ONLY the third-party widget in its own error boundary. The fallback shows a placeholder ('Chart unavailable — refresh to retry'). The rest of the dashboard remains fully functional. Users can still use all other features while you investigate the chart issue.
Takeaway: Error boundaries give you component-level fault isolation, similar to microservice circuit breakers. Treat each third-party or unstable component as an isolated fault domain.