Proposal: New observable properties

[davideast]

Properties not methods!

We’re thinking about introducing a new properties on the AngularFireCollection and AngularFireDocument classes.

const itemsCollection = afs.collection(‘items’, { includeMetadataChanges: false });
const itemSnap$ = itemsCollection.querySnapshot;
const items$ = itemsCollection.docs;
const itemsChanges$ = itemsCollection.docsChanges;

items$.subscribe(snapshot => {
  console.log(snapshot.docs);
  console.log(snapshot.docChanges);
});

items$.subscribe(docs => {
  const first = docs[0];
  console.log(first.data());
});

itemsChanges$.subscribe(changes => {
  const first = changes[0];
  console.log(first.type, first.data());
});

This helps avoid the sticky situation of loops. If you create an observable as a function inside a loop each render creates multiple observables with multiple subscriptions. If each observable has a different query criteria it will act unpredictably.

<!-- DONT DO THIS! -->
<ul>
  <li *ngFor=”let item of itemsCollection.snapshotChanges() | async”></li>
</ul>

Using a propery ensures that it’s only one instance of the observable, eliminating the unpredictable situations.

<!-- SO MUCH BETTER! -->
<ul>
  <li *ngFor=”let item of itemsCollection.docs | async”></li>
</ul>

We'll also add this for documents.

const itemDoc = afs.document(‘items/1’, { includeMetadataChanges: false });
const item$ = itemDoc.doc;

item$.subscribe(doc => {
  console.log(doc.data());
});

Leave a comment and let us know what you think of this proposal.

[codediodeio]

I like this and it aligns better with other modules in Angular like reactive forms valueChanges or the rotuer's queryParams.

One thing I'm not clear on... will the docs prop map the call to data() for you? Otherwise I believe you will get a "circular JSON" error with the async pipe, unless you map it yourself with RxJS, which is painful.

[davideast]

The docs prop will not map the call to data(). There's good information on the DocumentSnapshot so I don't want to strip it.

I'm thinking we can port your operators over from RxFire to do the unwrapping (#1820). What do you think?

[codediodeio]

Ah, that makes more sense. I think that's a reasonable way to go. The alternative would another prop like itemsCollection.data. A little less code, but not quite as flexible as Rx operators.

[davideast]

@codediodeio itemsCollection.data would only work if you configured it in AngularFireList:

const col = afs.collection(‘items’, { includeMetadataChanges: false }, { id: 'id' });
col.data.subscribe(items => {
  const first = items[0];
  console.log(first.id);
});

What do you think?

[pandamorphism]

any updates on this?

[jimmykane]

Guys why do you close the issues on a feature request that was never delivered?

[hiepxanh]

any update on this sir?

[johnzondr]

Can we please get a fix for this?

[kylecordes]

A related suggestion for this feature: in the meantime, if there is any hesitation because this is an API change, edit the code to ensure that (for example) .snapshotChanges() returns the same observable each time and not a new one. (It might already do this correctly, in which case, perhaps this API change might simply be abandoned as unnecessary.)

[hiepxanh]

@davideast any update on this sir?

[WebMex]

Is it already implemented? Is it possible to use includeMetadataChanges now?

[jamesdaniels]

metadata changes are always included in snapshotChanges as of 6.1