You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0b70a12
Browse filesBrowse the repository at this point in the historyBrowse files
fix: surface observable errors via status instead of re-throwing (#735)
In non-suspense mode (the default), errors from reactfire hooks are now returned via `status: 'error'` instead of being thrown unconditionally, which made `status: 'error'` unreachable in practice. In suspense mode errors are still re-thrown so a React Error Boundary can catch them.
Breaking change, targeted at v5. Documented in docs/use.md (Error Handling) and docs/upgrade-guide.md (v4 to v5).
Closes#535, closes#540.
Copy file name to clipboardExpand all lines: docs/upgrade-guide.md
+24Lines changed: 24 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,27 @@
1
+
# Upgrade from ReactFire v4 to v5
2
+
3
+
ReactFire v5 contains breaking changes. This section lists them as they land; add an entry here in any PR that changes public behavior.
4
+
5
+
## Error handling behavior change
6
+
7
+
Previously, errors from any reactfire hook were thrown unconditionally, making `status: 'error'` unreachable in practice. In v5, error handling depends on the mode:
8
+
9
+
-**Non-suspense mode** (default, or `suspense: false`): errors are returned via `status: 'error'` so components can handle them locally.
10
+
-**Suspense mode** (`suspense: true`): errors are re-thrown so a React Error Boundary can catch them. No change from prior behavior.
11
+
12
+
**If you rely on a React Error Boundary to catch Firebase errors in non-suspense mode**, you must add an explicit re-throw in your component:
if (status==='error') throwerror; // re-throw to reach your Error Boundary
17
+
```
18
+
19
+
**If you already check `status` before using `data`**, no change is needed.
20
+
21
+
Note: once an observable errors there is no automatic retry. The errored observable remains in the global cache under its `observableId`, so unmounting and remounting the same component rejoins the same errored state. Today the only workaround is to change the `observableId`. A proper retry mechanism is tracked in [#742](https://github.com/FirebaseExtended/reactfire/issues/742).
22
+
23
+
---
24
+
1
25
# Upgrade from ReactFire v3 to v4
2
26
3
27
As announced in [Discussion 402](https://github.com/FirebaseExtended/reactfire/discussions/402), ReactFire v4 contains breaking changes. This guide details how to upgrade from v3 to v4.
*[Display the current signed-in user](#display-the-current-signed-in-user)
11
15
*[Only render a component if a user is signed in](#only-render-a-component-if-a-user-is-signed-in)
@@ -167,6 +171,51 @@ function FirebaseComponents({ children }) {
167
171
168
172
See the [App Check setup guide in the Firebase docs](https://firebase.google.com/docs/app-check/web/recaptcha-provider#project-setup) for more detailed instructions.
169
173
174
+
## Error Handling
175
+
176
+
ReactFire hooks report errors from the underlying Firebase observable, and how an error surfaces depends on whether suspense mode is enabled.
177
+
178
+
### Non-suspense mode (default)
179
+
180
+
By default (or with `suspense: false`), an error is returned through the hook's `status` so you can handle it where the data is used:
return <imgsrc={imageURL}alt="cat reading the newspaper" />;
198
+
}
199
+
```
200
+
201
+
If a hook emits a value and then errors, `status` becomes `'error'` while `data` keeps its last emitted value.
202
+
203
+
### Suspense mode
204
+
205
+
When suspense is enabled (`<FirebaseAppProvider suspense={true}>`, or `suspense: true` on the hook), errors are thrown instead so the nearest React [Error Boundary](https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary) can catch them. In this mode the hook never returns `status: 'error'`:
206
+
207
+
```tsx
208
+
<ErrorBoundaryfallback={<span>Something went wrong</span>}>
Once an observable errors, there is no automatic retry. The errored observable stays in ReactFire's global cache under its `observableId`, so unmounting and remounting the same component rejoins the same errored state. The only workaround today is to use a different `observableId`. A retry mechanism is tracked in [#742](https://github.com/FirebaseExtended/reactfire/issues/742).
218
+
170
219
## Auth
171
220
172
221
The following samples assume that `FirebaseAppProvider` and `AuthProvider` components exist higher up the component tree (see [setup instructions](#setup) for more detail).
0 commit comments