Skip to content

Discussion: the road to AngularFire v6 #2267

Closed
@jamesdaniels

Description

@jamesdaniels

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 SEMVER comments in the source)
  • Change our build process to use ng-packagr WIP Refactor build process #2117
  • Drop the angularfire2 shim releases on NPM
  • Add the SDK proxy that AngularFireAnalytics and AngularFireRemoteConfig use 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 for @angular/fire/database-deprecated in a reasonable timespan? If so, I'll drop database-depreciated in version 6, if not we'll punt until version 7. During my investigation I found little evidence that those still using database-depreciated had 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 user import 'firebase/*' themselves before use of the non-lazy modules, this would allow us to export all the packages under @angular/fire and mark them as having no side-effects. ngcc no longer has issue with this
  • Shallow up the exports, if we're entirely side-effect free we can export everything in @angular/fire rather 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?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions