search

hoodiehq / pouchdb-hoodie-api

:dog: Hoodie-like API for PouchDB
https://hoodiehq.github.io/pouchdb-hoodie-api
Apache License 2.0
44 stars 11 forks source link

trigger events before methods resolve #54

Closed gr2m closed 9 years ago

gr2m commented 9 years ago

When I run this code

api.on('change', function(){ console.log('change') })
api.add({}).then(function(){ console.log('add') })

add gets logged first, then change. What we want is to have change being trigger first though, this is also the expected behavior from a developers perspective. It became a problem while working on the .hasLocalChanges() method on pouchdb-hoodie-store, where we currently have this behavior:

store.add({id: 'test'}).then(function() {
  store.hasLocalChanges('test') // should be true, but is false at this point, because "change" events are triggerd after "add" resolves.
})
brunopedroso commented 7 years ago

I got the point of timing events, but does this implementation of 'eventifying' add method (for example) handles the case of an object being added to pouch because of a replication?

Also, this is not a safe way to diferentiate updates and adds because the replication protocol may ignore old revisions... that, also, should work if I'm the only one to change the db, but it wont if the DB changes in server and is replicated to my local db.

gr2m commented 7 years ago

Also, this is not a safe way to diferentiate updates and adds because the replication protocol may ignore old revisions

I know, but it’s the best we can do right now, PouchDB does not expose if a document was added for the first time or not. This used to be part of PouchDB itself, but they removed it because it was really a lie as you point out correctly :/

Can you check in with PouchDB community if there are any news on this?

gr2m commented 7 years ago

I got the point of timing events, but does this implementation of 'eventifying' add method (for example) handles the case of an object being added to pouch because of a replication?

This is really tough. We had a really nice implementation for events using the .changes feeds once but we couldn’t figure out the timing of when events are being triggered and promises being resolved. I still hope we can figure it out eventually, I prepared this issue for it: https://github.com/hoodiehq/camp/issues/13

feel free to give it a go!

brunopedroso commented 7 years ago

This used to be part of PouchDB itself, but they removed it because it was really a lie as you point out correctly :/

It remains a lie in hoodie as well.. =( Maybe we should just expose 'change' event, just like Pouch/Couch?

Can you check in with PouchDB community if there are any news on this?

I don't think so. Seems like its a CouchDB sync protocol caracteristic... =(

brunopedroso commented 7 years ago

hoodiehq/camp#13 feel free to give it a go!

Thanks. I'll consider it.

gr2m commented 7 years ago

So we are kinda back to one via https://github.com/hoodiehq/pouchdb-hoodie-api/pull/123. I gave this a lot of thought and my conclusion is that it’s not worth the amount of added complexity needed in order to enforce the order of events before promise resolve. I will add a note to the documentation about it.