ErrorBoundary ist ein großartiges Tool zum Erfassen von Fehlern, die von React-Komponenten ausgelöst werden. Sie können je nach Art und Ort des Fehlers benutzerdefinierte Fehlermeldungen bereitstellen. Aber nicht alle Fehler werden von der ErrorBoundary behandelt! Was machst du damit?
Wenn man sowohl asynchrone Fehler als auch von außerhalb von React ausgelöste Fehler berücksichtigt, ist die ErrorBoundary unzureichend. Um dies zu mildern, habe ich in meinen Anwendungen einen sogenannten GlobalErrorHandler erstellt. Eine funktionale Komponente, die einfach A) einen Fehlerdialog öffnet und dem Benutzer mitteilt, dass etwas schief gelaufen ist, B) den Fehler auf dem Server protokolliert, damit wir ihn untersuchen und Lösungen finden können.
Die Idee ist einfach. Wir möchten einen GlobalErrorHandler im Stammverzeichnis unserer Anwendung. Dieser Handler sollte nur Fehler verarbeiten, die nicht von ErrorBoundary abgefangen werden. Darüber hinaus sollte es vom Benutzer leicht verworfen werden können und wir sollten davon ausgehen, dass die Anwendung weiterhin verwendbar ist.
Die Strategie ist also folgende: Der GlobalErrorHandler macht standardmäßig überhaupt nichts außer dem Rendern seiner untergeordneten Elemente. Es richtet jedoch zwei Ereignis-Listener ein, die auf alle Fehler- und nicht behandelten Ablehnungsereignisse im Browser warten. Anschließend wird der Fehler untersucht und festgestellt, ob er bereits von ErrorBoundaries behandelt wurde. Wenn dies nicht der Fall ist, wird schließlich ein Dialogfeld angezeigt, das dem Benutzer mitteilt, dass irgendwo ein Fehler aufgetreten ist, und ihm ermöglicht, das Dialogfeld zu schließen und die Anwendung weiter zu verwenden.
Bevor wir Endbenutzer zusätzlich zu der von ErrorBoundary durchgeführten Behandlung mit unnötigen Dialogen belästigen, müssen wir zunächst mit der Fehlerfrage beginnen: Wurden Sie bereits behandelt? Meine Lösung hierfür besteht darin, ein neues Feld für das Fehlerobjekt isHandledByBoundary einzuführen. Dies wird innerhalb von ErrorBoundary:
auf „true“ gesetzt.
componentDidCatch(error: Error, errorInfo: ErrorInfo) { (error as any).isHandledByBoundary = true; .... }
Da dies in allen ErrorBoundary-Komponenten (und anderen Maschinen, die nicht erfasste Fehler verarbeiten) vorhanden ist, können wir mit der Definition unseres GlobalErrorHandlers beginnen.
Dann können wir das Grundgerüst unseres GlobalErrorHandlers aufbauen. Es rendert seine untergeordneten Elemente direkt und rendert auch einen an anderer Stelle definierten „ErrorDialog“. (Wenn Sie diese Komponente anwendungsübergreifend teilen möchten, könnte der ErrorDialog stattdessen eine Requisite sein.)
import { useState, useEffect, ReactNode } from 'react'; import { ErrorDialog } from '../Components/ErrorDialog'; type Props = { children: ReactNode; }; export function GlobalErrorHandler({ children }: Props) { const [error, setError] = useState(null); const [isDialogOpen, setDialogOpen] = useState(false); useEffect(() => { .... }, []); function handleCloseDialog() { setDialogOpen(false); setError(null); } return ( {children} {isDialogOpen && error && ( )} > ); }
Das Einzige, was uns jetzt fehlt, ist die Fehlerbehandlung selbst, definiert in useEffect.
Der gesamte Code in diesem Abschnitt sollte sich innerhalb der useEffect-Funktion befinden!
Zuerst definieren wir handleWindowError. Dies muss an den Fehlerereignishandler des Fensterobjekts übermittelt werden. Hier ist nichts Geheimnisvolles, aber sehen Sie, dass das Fehlerereignis auch Informationen über Quelle, Zeilennummer und Spaltennummer enthält. Was zum Sammeln wertvoll sein könnte.
Normalerweise sind diese Informationen auch im Fehlerobjekt zu finden, ich muss dies jedoch noch empirischer untersuchen. Vielleicht sollten wir immer die vom Fehlerereignis gemeldeten Zeilen- und Spaltennummern beibehalten? In diesem Fall könnten wir auch einen Status dafür im GlobalErrorHandler haben (und sicherstellen, dass dieser beim Protokollieren des Fehlers gesendet wird).
function handleWindowError( message: string | Event, source?: string, lineno?: number, colno?: number, error?: Error ) { if (error && (error as any).isHandledByBoundary) { return true; } const errorMessage = error ? error : `Error: ${message} at ${source}:${lineno}:${colno}`; setError(errorMessage); setDialogOpen(true); return true; }
Wir werden auch den handleUnhandledRejection-Handler definieren. Dies gilt für Fehler, die innerhalb von Versprechen auftreten, bei denen wir jedoch vergessen haben, eine .catch()-Klausel zu schreiben.
function handleUnhandledRejection(event: PromiseRejectionEvent) { setError(`Unhandled promise rejection: ${event.reason}`); setDialogOpen(true); }
Dann müssen wir nur noch die Listener einrichten und entfernen, wenn GlobalErrorHandler nicht mehr gerendert wird:
window.addEventListener('error', handleWindowError); window.addEventListener('unhandledrejection', handleUnhandledRejection); return () => { window.removeEventListener('error', handleWindowError); window.removeEventListener( 'unhandledrejection', handleUnhandledRejection ); };
Bei den Return-Anweisungen kehren wir natürlich aus der Funktion zurück, die wir useEffect zuführen. Dadurch wird sichergestellt, dass wir beginnen, Ereignisse abzuhören und zu verarbeiten, wenn die Komponente gerendert wird, und aufhören, wenn die Komponente nicht mehr gerendert wird.
Daher haben wir einen GlobalEventHandler, um diese lästigen Fehler in unserer React-Anwendung zu behandeln, die entweder von asynchronen Quellen oder von außerhalb der React-Komponenten ausgelöst werden!
Haftungsausschluss: Alle bereitgestellten Ressourcen stammen teilweise aus dem Internet. Wenn eine Verletzung Ihres Urheberrechts oder anderer Rechte und Interessen vorliegt, erläutern Sie bitte die detaillierten Gründe und legen Sie einen Nachweis des Urheberrechts oder Ihrer Rechte und Interessen vor und senden Sie ihn dann an die E-Mail-Adresse: [email protected] Wir werden die Angelegenheit so schnell wie möglich für Sie erledigen.
Copyright© 2022 湘ICP备2022001581号-3