@hakimio User/ScreenTracking are automatic, they don't need to be called to begin functioning. The isSupported error is likely cause the firebase JS SDK needs to be updated in that sample.

@jamesdaniels not sure I understand what you mean by "don't need to be called". In angularfire v6, you had to add those services to the app providers. Isn't that the case in v7? How are they supposed to be used now?

EDIT: ScreenTracking service usage in v6.

@hakimio woops, don't mind me. I peek at this on mobile and it looked like you deleted those lines, rather than added them. Good catch.

@jamesdaniels
Minor nitpicking:

• instead of creating multiple subscriptions with async pipe, you could use *ngrxLet to resolve the observable or @ngneat/until-destroy to automatically unsubscribe when component is destroyed.
• To avoid mistakes like this one, might be a good idea to rename user to user$.

Unrelated question/issue: because of includeMetadataChanges, docdata() emits duplicate values. Is there a good reason for those duplicates or can this be fixed? valueChanges() from angularfire v6 did not have this issue (I verified).

EDIT: imho, changing includeMetadataChanges from default false in Firebase JS SDK to true in rxfire and not allowing user to change it, makes no sense and just creates confusion from user side 😕

In the samples I don't think we want to take on any additional dependencies, just for the sake of being able to quickly validate correct functionality with any Angular version, including RCs, before other NPM modules are compatible.

Thanks for pointing out this is the case with docData, I mostly stick to snapshots rather than values, so I didn't notice this was different in rxfire. One thing to note, the metadata could be consumed in a class converter, so it's probably safer to keep metadata included by default... we do want this to be configurable but in the meantime I think it makes sense to build a distinctUntilChanged() into doc/collectionData.