and then what? Client-side Static assets /index.html /scripts/ember.js /scripts/ember-data.js /scripts/handlebars.js /scripts/app.js /public/Logo.png /…/… Dynamic data ✔ Ember Data ! … because yeah, we want to use Ember Data. And then what?
.find()ing a record, we want to save it locally. 1. Oh, but we also want to check if the record exists locally when .find()ing it. 1. If the record does exist locally, we want immediately return the local version of the record and then attempt to .reload() it from the server. 1. If it turns out the record has been deleted server-side, we want to remove the record locally as well, unless there are local changes in which case we want to… 1. … go get coffee. And use gem “turbolinks”.
or localStorage. But wait a minute! https://github.com/daleharvey/pouchdb https://github.com/axemclion/IndexedDBShim https://github.com/axemclion/jquery-indexeddb https://github.com/aaronpowell/db.js
a tad more of an effort. So, two strategies to consider Model-controller layer ✔ No reinventing the REST wheel ✔ Separation of concerns ✔ Querying ✔ Filterable ✔ Computed properties ✔ Em.SortableMixin ! ✘ Verbose Ember Data adapter ✔ Custom adapter ✔ Simple wrapping ✔ Silent failing ! ✘ Error handling ✘ Conflict resolution ✘ Querying ✘ Fast
to be aware of. Checklist • Load all locally stored records when bootstrapping • Clear all locally stored records when a user logs out • Figure out how you want to handle conflicts - last-write-wins etc. • Be sure to return promises when implementing .findRecord() etc. • Be sure to never use Ember Data directly, but always using the corresponding model controller (that does use it, of course) • Check for changes to a record when finding it, saving it, and so on. • Have the user resolve any conflicts - you cannot possibly automate this all by yourself, neither can any library out there.