search

dappsnation / akita-ng-fire

Akita ❤️ Angular 🔥 Firebase
MIT License
131 stars 27 forks source link

valueChanges vs getValue and ID column #142

Closed randallmeeker closed 4 years ago

randallmeeker commented 4 years ago

It would appear that on a collection valueChanges (Observable) and getValue (Promise) are different in that getValue will put the document ID on the returned array object and valueChanges will not. Is this expected behavior?

fritzschoff commented 4 years ago

Hey, will check it out next week. I'm off this week.

fritzschoff commented 4 years ago

you are absolutely right. image I will update the getValue method to be the same then the valuesChanges

fritzschoff commented 4 years ago

thanks @randallmeeker ! fix is available in 3.0.5

randallmeeker commented 4 years ago

This is great. Thanks.

randallmeeker commented 3 years ago

I finally was able to upgrade and I'm not seeing the changes, or possibly not understanding how it is supposed to be implemented. I was looking to have the ID column on the valueChanges method. But it is not. Does this mean is was never supposed to be on there and getValue was wrong?

fritzschoff commented 3 years ago

Let me check tomorrow

fritzschoff commented 3 years ago

so I just checked and I get the ids in both functions... Maybe there is something else wrong here?

randallmeeker commented 3 years ago

Following up on this

There and I don't think this is an easy fix

Basically, valueChanges() is just a passthrough, which does not return enough info to merge and ID on the field.

https://github.com/dappsnation/akita-ng-fire/blob/v5/projects/akita-ng-fire/src/lib/collection/collection.service.ts#L522

vs

https://github.com/dappsnation/akita-ng-fire/blob/v5/projects/akita-ng-fire/src/lib/collection/collection.service.ts#L478

This would probably have to be a new method on the collection service (maybe called collectionService.select) that performs builds a ministore and watches for changes.

Hopefully, I have some time and maybe can help contribute to this

fritzschoff commented 3 years ago

thanks for coming back about that. Will have a look today into that

fritzschoff commented 3 years ago

do you put your id inside of the document? Cause if you don't then yes you won't get an id back if you are using the valueChanges method. But if you would use the add function when adding something to a collection, the id will get merged with the new data. I could overwrite it again the idKey to make sure that we include the id in the new data, but this can have a lot of side effects image

randallmeeker commented 3 years ago

Unfortunately in this instance, the data is not being initially generated by my app. So the ID field does not exist on the document itself.

Just one of those hinky things where this library does so much out of the box, that I need to be explicit when working with other systems that are also working with the data that they need to put an ID field on the records.

We are early enough in this app that adjustments can be made as such.

I'm still intrigued by a select method on the collection service though. It would like a synced store. So that when a change occurs your not hit for a full run of reads for the entire query. Plus you solve this ID field issue. Unless there is already a smart way to do this.