Repository navigation
Discussion: the road to AngularFire v6聽#2267
Description
The road to AngularFire v6
Angular 9 is coming soon! Let's kick off discussions on what AngularFire v6 will look like. We've managed to keep the API stable and introduce no (intentional) breaks for over a year! 馃帀
Hope everyone has enjoyed this consistency.
Why break at all?
We currently support three Angular (6, 7, and 8) and Firebase majors (5, 6, and 7) with the current version of AngularFire... that's a lot of work.
To support older versions of Firebase we have a number of conditionals and a lot of unneeded code/types.
To maintain support for older versions of Angular, we've been holding back our typescript version and not adopting any new APIs.
Plan of action
Version 5.3:
Release it, WIP here #2187
Version 5.4:
Reimplement @angular/fire/database-deprecated using @angular/fire/database under the hood. It's been raised that database-deprecated has been pretty broken since we've dropped it from our test suite but it is holding back some of our developers from upgrading. We should try to get them on the latest version of 5, before we start breaking things.
Perhaps at this point we'll mark peer support for Angular 9.0 final. So far in my testing the release candidates seem to work fine and we shouldn't need to break a major to support.
Once we've dealt with that:
Version 5.3.1:
Cherry-pick the fixes for the ng add and ng deploy commands.
Version 6:
- Bump the peer dependency to the latest minor of Firebase (currently v7.6)
- Bump the peer dependency of Angular to v9
- Bump the peer dependency of Typescript to bring inline with Angular v9 (currently v3.6)
- Various bugs / types / export naming (see
SEMVERcomments in the source) - Change our build process to use
ng-packagrWIP Refactor build process聽#2117 - Drop the
angularfire2shim releases on NPM - Add the SDK proxy that
AngularFireAnalyticsandAngularFireRemoteConfiguse in the upcoming 5.3 release (Adding AngularFireAnalytics, AngularFireRemoteConfig, and refactoring DI Tokens聽#2187) to all the modules and drop the instance getters. Make all modules side-effect free (no longer importing the SDKs)
Version 6.1:
- "Lazy" versions of all the "non-lazy" modules. These do not assume the developer has loaded any of the Firebase SDKs and will dynamically import them; obviously some APIs will be different.
Version 7:
- Drop the "non-lazy" modules
- Move all our operators, observables, etc. to pure-functions (more on this soon)
- whatever else we think of by then...
Things we're thinking of:
- Reduce the amount of code in this library by leaning on RxFire
Can we build a migrator forDuring my investigation I found little evidence that those still using@angular/fire/database-deprecatedin a reasonable timespan? If so, I'll dropdatabase-depreciatedin version 6, if not we'll punt until version 7.database-depreciatedhad moved to 5.0 stable; I've decided to drop for 6.0.- How different would the "lazy" modules actually be? Can we just migrate over to them in 6 rather than have them be optional until 7?
Require the userngcc no longer has issue with thisimport 'firebase/*'themselves before use of the non-lazy modules, this would allow us to export all the packages under@angular/fireand mark them as having no side-effects.- Shallow up the exports, if we're entirely side-effect free we can export everything in
@angular/firerather than having sub-packages. - Strong type support in the vanilla Firestore SDK is available now with FirestoreDataConverter. Can we leverage this to get some of our Firestore type work for free in AngularFire & make the guarantees "stronger"? Can we use this for production-worthy state-transfer?
Activity
[-]Discussion: 6.0 release[/-][+]Discussion: the road to AngularFire v6[/+]vikerman commentedon Dec 18, 2019
@mgechev - Maybe add Cloud functions/run support for Angular ssr as part of ng deploy?
mgechev commentedon Dec 18, 2019
@jamesdaniels, I'll be happy to push SSR support with Cloud functions (at first) as part of the next major release.
Cloud functions seems like a good incremental rollout of a more complete & robust dynamic SSR solution. We're a step away from making deployments with pre-rendering generally available. As the next step, we can re-iterate on the dynamic SSR to optimize for cold start.
WDYT?
rubenheymans commentedon Jan 6, 2020
looks great! Better documentation on how to use the firebase emulator with angularfire, local database and firestore triggers would be nice too
jamesdaniels commentedon Jan 8, 2020
@vikerman @mgechev absolutely. In v6 too I'll change the default setup instructions to be
ng add @angular/fire. I'm eager for all the Universal 9 improvements.@rubenheymans great point. I've been meaning to work on those docs also move our tests over to the emulator by default so they're less flaky (and we're dogfooding the emulator integrations).
Timebutt commentedon Jan 10, 2020
What is the current approach/timeline towards v6? I see there's one big PR here #2282.
What I'm interested in the most right now is the change to
ng-packagrfor the build, as it's blocking me (and probably others) from building my application using Bazel in Angular 9. I see it the original issue #2117 got closed in favor of #2282, does that mean the work in that branch is close to being done, or it wasn't possible to move tong-packagrwithout doing lots of other changes?Can we contribute in any way right now?
Thanks for your great work!
jamesdaniels commentedon Jan 11, 2020
Timeline is the rehaul commit going on master in the next day or two, which will mean canary builds on NPM.
Helping test those builds against ng9 would be very helpful, as I鈥檒l probably have too much on my plate to thoroughly dogfood before the first RC.
jamesdaniels commentedon Jan 29, 2020
FYI I've cut an initial build of version 6 on NPM
6.0.0-next.018 remaining items
jamesdaniels commentedon Mar 27, 2020
@hiepxanh I'll discuss with other stakeholders at some point, see if that's something we're open to.
We are aiming to be more diligent with errors, documentation, and Stackoverflow once 6.0 is out the door.
hiepxanh commentedon Mar 28, 2020
@jamesdaniels I'm glad you're fine. That's so good to know that. Just feeling happy you are safe out there. Be healthy, and let us know anything we can help.
BTW, I just want to help you resolve some issues. Since David East seem to be busy. Hope that everything is fine.
johanchouquet commentedon Mar 30, 2020
@jamesdaniels , so glad that you're ok and your family too! Working from home is indeed a bit challenging, with this situation from one part, and also when you have kids to deal ^^.
About the lib: great news and excellent planning for the community
EdricChan03 commentedon Apr 2, 2020
Hey @jamesdaniels, I see that you've just landed v6.0 of AngularFire (0be51e6). However, could you detail how to update our apps to use AngularFire v6.0? I see that there are many breaking changes, but no description detailing exactly how to migrate our apps.
For e.g., the changelog mentions that:
However, there's no detailed description of how exactly to migrate functionality related to the service.
(And there aren't any typings for the underlying
firebase.auth.Authclass? For e.g. I'd tried accessing the current user via thefirebase.auth.Auth.currentUserproperty, but found out that there was no such property in the typings as per the error below)EDIT:
Turns out that the issues were caused by me updating AngularFire while Angular CLI was still serving my app. I solved the issue by terminating the serve process then reissuing the command.
EDIT No. 2:
It seems that the properties in the Firebase JS SDK now return Promise versions of their counterparts.
For e.g.
AngularFireAuth.auth.currentUserused to returnUser | null. However,AngularFireAuth.currentUsernow returnsPromise<User | null>. Is this intentional?jamesdaniels commentedon Apr 2, 2020
@EdricChan03 sorry about that changelog entry being dense & not well explained. I'll make sure to document that better.
Re your edit no. 2, yes that's intentional. Our plan is to lazy-load the Firebase JS SDK while we are waiting for them to become more modular / tree-shakable; hence our "promise proxy". No timeframes but hoping that our work there will begin bearing fruit soon. I will absolutely do a doc push but just had to get this release out the door, don't mind any rough corners & feel free to send any PRs if you have an idea on how to better communicate this!
curiouscod3 commentedon Apr 3, 2020
currentUser returns null.
#2378
hiepxanh commentedon Apr 4, 2020
Hello, I just experience some buggy or not clearly on the "How Angular Fire work". Specificly:
take(1)with angularfire. It's just not refresh the data.snapshotChanges trigger twice聽#2336
unexpected: AngularFirestore#collection() returns cached value on initial subscription聽#2012
And then trying to debug and I find out that It return data twice instead of one. If I undestand correctly, so we should take the second If we dont want to get realtime update. For example: if you get the data using
take(1)it only return cache value (addeddata). If you want to get fresh and not want to subscribe on everytime data update. usetake(2)to getmodifeddata.Don't you mind if you looking into this, sir? @jamesdaniels can you confirm my idea above and help me to explain the idea behind? that could help us update the docs on this angularfire 6 version. And close 3 issues above
yasinkocak commentedon May 23, 2020
Feature request:
i have multiple angular projects (admin/frontend/mobile) and they have separate firebase hosting.
added
deploysection on all projects inangular.jsonbutng deploydo just 1 project. And pick up the first hosting target onfirebase.rcdoes not match.other requested feature is.
i have 2 firebase instance (development/production). Normally u can switch with
firebase use productionthis does not support.BianchiSeb commentedon May 28, 2020
Feature request : fix all bugs and make an usable tool
hiepxanh commentedon May 29, 2020
This project only maintain by @jamesdaniels I consider to help him to clear issues and address problem but he doesn't need
hiepxanh commentedon Jun 13, 2020
I hope we can add this PR to coming release: #2497
jamesdaniels commentedon Jun 24, 2020
Just cut a preview of
6.0.1to@canarywhich should address some issues. Will push out a proper release and write release notes after I do some smoke tests in the AM.jamesdaniels commentedon Nov 18, 2020
With the recent release of 6.1 I'm really feeling happy with the 6 series and that despite some rocks in the road (that we've overcome together) it's living up to what I hoped. I'm going to close this issue.
That's not to say 6-series is done. Things I'd like to get done in minors in the coming weeks/months:
Other than those issues, really just continuing to tighten the API, I don't foresee doing any other major API work until 7.0 (or whatever the next tick release is for us).
On the horizon we have JS SDK vNext which is a modular rewrite of the Firebase JS SDK. I'm still thinking about what this will mean for AngularFire and will start a
vNextroadmap once I have enough thoughts together to take community feedback.