Repository navigation
Tags: angular/angularfire
Tags
docs(compat): state the compatibility API's support status (#3810) * docs(compat): state the compatibility API's support status docs/compat.md had no statement of whether @angular/fire/compat is supported, and the v7 upgrade guide still told readers to stop at the compatibility API because the modular API was not feature complete, a sentence written for the 7.0 release. The new section records the decision for 22: the compatibility API is supported and kept working, its specs run in the same suite, it receives bug fixes and no new features, and no removal is planned. The v7 guide line now points at that section. * docs(compat): mention the turned-off compat tests The support section said the compatibility API is kept working, but CI skips the tests for AngularFirestoreCollection, AngularFirestoreCollectionGroup, AngularFirestoreDocument and one Cloud Storage upload. The section now says so and links the issue that tracks turning them back on.
docs: describe AngularFire 21 as released, not as a release candidate (… …#3813) The docs on 21.0.x still install with @angular/fire@next, call 21 a release candidate, and carry the AI-agent note for the firebase-tools 15.26 crash that #3769 fixed on this branch. The 21.0.0 tag is cut from this branch, so its docs should describe the release. The upgrade command keeps @angular/fire unversioned: only the first @angular/ package in an ng update command picks the CLI that runs it. The Node.js note gives the versioned form for updating AngularFire alone.
docs(app-check): explain App Check during server rendering (#3775) * docs(app-check): explain App Check during server rendering The App Check guide said nothing about server-rendered apps. #3773 stops AngularFire from creating an App Check instance during server rendering, so the new section explains that inject(AppCheck) is null there, that Firebase requests made while rendering carry no App Check token, and how to opt back in with APP_CHECK_ON_SERVER. It also shows a browser-only config for 21.0.0-rc.1 and earlier, where the guide's setup fails with "document is not defined". * docs(app-check): use the dev-mode warning's wording in the SSR section The warning AngularFire prints during server rendering says it skips App Check there. The section now opens with the same words, so a reader arriving from the console finds them.
fix(auth): stop beforeAuthStateChanged from holding the app unstable (#… …3770) AngularFire wrapped beforeAuthStateChanged so that registering the hook added a pending task, cleared only when the callback first runs. Firebase runs that callback only on a sign-in or sign-out, so for a visitor who does neither the app never became stable. Registered on the server, it failed ng build during route extraction and left server-rendered requests without a response. This restores the blockUntilFirst: false override from #3590, which #3613 dropped without comment while adding log-level overrides next to it. The callback still runs inside Angular's zone and injection context, and its returned promise still reaches Firebase, so a rejection still cancels the sign-in. A call outside an injection context now logs its per-call warning only at the verbose level, as onMessage does. Fixes #3748 docs(auth): scope the beforeAuthStateChanged note to rc.1 and earlier Merging this change closes #3748, so the section's present-tense note would point at a closed issue. Also removed the false claim that the @angular/fire/auth import makes ng build hang: the guide registers the hook only in the browser, so its own build succeeds. The docs/auth.md change is left out, since it edits a section of the guide that 20.1.x does not have. (cherry picked from commit f182972)
chore: bump version to 21.0.0-rc.1 (#3751) The publish job reads this literal at tag time. The sample's file: tarball dependency path and its README install example carry the same version, so they move together. The root lockfile records the same version in its two version fields. The sample's lockfile deliberately keeps the rc.0 tarball name, because it also records that tarball's integrity hash.
fix: Avoid handling promise rejections twice in stability helper (#3657) `PendingTasks.run` reports rejections of the promise to the `ErrorHandler`. This function already returns a promise that is meant to be handled in the developer's application. If there _is_ handling there, the rejection is handled both in the `PendingTasks.run` and in the developer callsite. This change updates the code to use `PendingTasks.add` instead, which has no built in error handling mechanisms. fixes angular/angular#61932
PreviousNext