"Warning: Firebase API called outside injection context" on non-async functions
anisabboud opened this issue · 3 comments
This is related to #3605 and #3607 where a workaround has been suggested #3590 (comment).
But my question is specifically for non-async functions.
First of all, thank you @jamesdaniels for the new guide at https://github.com/angular/angularfire/blob/main/docs/zones.md.
(I think the doc would benefit from some concrete examples.)
My understanding is that direct calls to docData where it's called say from within an rxjs switchMap, should be wrapped in runInInjectionContext
loadDoc<T>(docPath: string): Observable<T | undefined> {
return docData<T>(doc(this.firestore, docPath));
}↓↓↓
private injectionContext = inject(EnvironmentInjector);
loadDoc<T>(docPath: string): Observable<T | undefined> {
return runInInjectionContext(this.injectionContext, () => {
return docData<T>(doc(this.firestore, docPath));
});
}However, even after adding runInInjectionContext wrappers for all load & set operations, there are still warnings from functions that are not async in nature such as where, snapToData, serverTimestamp, increment, orderBy, limit:
This is because tools/build.ts is applying ɵzoneWrap to every Firebase function:
angularfire/src/firestore/rxfire.ts
Lines 22 to 27 in 8ce95bf
angularfire/src/firestore/firebase.ts
Lines 76 to 144 in 8ce95bf
Should AngularFire take a more granular approach and throw warnings only on async functions such as docData to avoid extraneous warnings?
This issue does not seem to follow the issue template. Make sure you provide all the required information.
It may make sense to make this configurable. Perhaps tone down the number of warnings.
Def need to improve the doc but I'd rather be verbose since zone instability is a lot of support burden.
I wrap everything as we've been bitten in the past by seemingly innocent APIs like query and doc triggering side-effects which pulled in setTimeouts.
Is it somehow possible to wrap all the Firebase APIs in an injection context inside the AngularFire library code itself?
This way users of this library would just keep using Firebase APIs as normal, and the injection context is handled behind the scenes.
Right now it's just weird forcing everyone to wrap every usage of each AngularFire function in runInInjectionContext boilerplate.
The DX has become terrible in v19.
