post.async.get('comment')

[Leooo]

Hi, getting into ember-sync and this is a great work thanks for sharing.

Different points below more or less linked, so I prefer to not open several github issues:

• npmjs.com repo not up to date? It may be obvious for many people to check the version when they do 'npm install ember-sync' but I didn't and I spent some hours debugging the same things you have dealt with these last months.. (I am discovering npm, bower etc. so this may be a very naive point).

• Doc: my understanding is that if you don't create / save or find a post Record through emberAsync, you will not be able to call post.emberAsync on it later on:
  => this may be clearer in the docs?

• When finding a record through this.emberSync.findQuery, the result's relationships don't have the method 'emberSync', so not possible to save them to both stores etc. (in my case, I change one relationship in a form but can not properly save it after).

  I think I see a trick to solve that (using this.emberSync.onRecordAdded(inst,inst.get('constructor.typeKey'))), but at the very least this is not in the docs.

  => It would be nice to see emberSyncing relationships possible in a future implementation, probably this would look something like "post.async.get('comment')"?

• It would be nice to be able to not fetch from the server if not needed, for example if we know that the records, if they exist, are more recent locally (the user is the author of these records).
  Admittedly we could use the offline store directly for this, but we could want to post the records both online and offline later on, after having fetched them and if not initialized properly with emberSync this is not possible.
  => So overall, ideally here would be more options for fetching records, like: 1) fetch only if they don't exist in the offline store [ 2) fetch only if they are more recent on the server (sending an updated_at in the request) etc. ]. 1) would really help in using emberSync for caching data locally.
  => A dirty solution in Find records from offline store, then from online store only if not found #33

• Small things:

  • this.emberSync.find('posts') returns an array, not a promise (this could be inconvenient if we want to wait for the result before the next step).
  • this.emberSync.find(post,23) leads to a Ember.RSVP error (it expects a string for the id).

Many thanks for the excellent work,

L

[kurko]

Thanks for the message :D

1. regarding releases, I just checked and something very weird happened. I've been releasing frequently, but for some reason https://www.npmjs.com/package/ember-sync was showing 0.1.2 now. Perhaps some old cache on their end? Anyway, I just pushed 0.2.3 and it's now showing the latest.

[kurko]

Doc: my understanding is that if you don't create / save or find a post Record through emberAsync, you will not be able to call post.emberAsync on it later on:
=> this may be clearer in the docs?

You're right. Could you open a PR to fix these things and give better instructions in the README?

When finding a record through this.emberSync.findQuery, the result's relationships don't have the method 'emberSync', so not possible to save them to both stores etc. (in my case, I change one relationship in a form but can not properly save it after).

I see what you're saying. I personally never needed it, so I ended up never implementing it. Would you be interested in working in a patch to include that?

It would be nice to be able to not fetch from the server if not needed, for example if we know that the records, if they exist, are more recent locally (the user is the author of these records).

Totally agree. Let's discuss that in #33.

this.emberSync.find('posts') returns an array, not a promise (this could be inconvenient if we want to wait for the result before the next step).

The thing here is that it returns a stream, which means that say you have 10 records offline and 5 online. You start showing the 10 records right away and then the next 5 are shown a second later.

I've been thinking about changing that to a promise, but we'd need to put more thought on it.