conductor/backbone.hoard

XHR consolidation and configurable caching for Backbone.js

backbone.hoard's Issues

Handle data hash in GET request similar to jQuery

jQuery uses options.data to append query params to the url. This should definitely at least be a recipe.

var Model = Backbone.Model.extend({
  url: '/my-model'
});

//fetches url "/my-model?param=a" when using jquery
new model.fetch({ data: { param: 'a' }});

Ensure that CreateStrategy makes sense in the context of a Collection

CreateStrategy stores the result in the cache after a successful sync. This definitely makes sense in the context of a model, but it might not make sense for a collection. This should be investigated and addressed if found to be an issue.

Use new Promises instead of Promise.resolve().then

store-helpers proxySetItem and proxyGetItem can exhibit strange promise behavior.

From @Seebiscuit

  proxyGetItem: function (key, options) {
    var getItem = _.bind(this.backend.getItem, this);
    return new Hoard.Promise(function (resolve, reject) {
      var raw = getItem(key);
      var storedValue = JSON.parse(raw);
      if (storedValue !== null) {
        resolve(storedValue);
      } else {
        reject();
      }
    });
  },

Make it easy to overwrite default Strategies' calls to cache storage

A use for this is bypassing caching but still making use of XHR throttling.

Strategy should not modify the options

Modifying the options directly can mess with downstream behavior. By passing along a modified options.url, for example can cause a collection to set the url on a model during set/reset, which overwrites the model's natural url method.

Only affects Backbone 1.0.0

Proxy-wrap Backbone.sync instead of directly delegating

This should help for people who override Backbone.sync, making things just work, with less needed configuration

Hoard = {
 //...
  sync: function () {
    return Backbone.sync.apply(Backbone, arguments)
  }
}

Update collection cache on CRUD of model in collection

In most RESTful circumstances, it probably makes sense to update a collection when information about it's models changes. This will increase the usefulness of caching for collections by reducing the burden on the application logic.

Add so many comments.

A well documented codebase, being necessary to the maintainability of a library, the in-code documentation via comments, shall be improved.

Allow for expires: false in the Policy

There are cases when it makes sense not let the cache expire. For example, when using an in-memory store, it might make sense to never allow anything to expire. This should also be the default.

Pass unmodified options to Hoard.Sync

People doing fancy things with Backbone.Sync, may need access to the original options passed in to sync.

Strategy:

  execute: function (model, options) {
    options.originalOptions = _.clone(options); // <=== add this
    options.url = this.policy.getUrl(model, this.method, options);
    options.collection = this.policy.getCollection(model, options);
    options.model = model;
    return this.sync(model, options);
  },

Enable cross-window updates by listening to storage events

WebStorage triggers events in other open windows whenever the storage is changed. This can be used to ensure consistency between tabs/windows. (example: notifications)

Race condition in ReadStrategy

Two requests will be made in the following scenario:

m1: execute
m2: execute
m1: onReadMiss
m1: successful sync
m2: onReadMiss

Improve the build process

Add

• Code coverage
• linting
• jscs
• travis sudo:false

Fix Store/MetaStore inheritance instead of using StoreHelpers

StoreHelpers makes it difficult to override access to all stores

Remove cache expiration

By default, Hoard shouldn't care about cache eviction. In conjunction with #24, this will shrink Hoard's surface area and keep it more focused. Move it to a recipe.

Change default store to `{}`

Hoard accomplishes two things right now: single src of truth and local storage data persistence. I think more applications will need the first than the second. I know that I would not choose to use localStorage in any app that I've made to date. @cmaher, I believe you mentioned that your app also doesn't use the localStorage feature.

The localStorage adapter should be an additional plugin on top of this library, I think.

Hoard.Store should create a metaStore with the provided options

Right now it is creating it with the Store's mergeOptions

Investigate useful places for lifecycle events

It would be helpful to emit events at various stages of the check cache/fetch/set cache lifecycle. This will allow users to more easily hook into certain stages.

Stages that could use events:

• Cache miss
• Cache hit
• Cache full
• Before cache write
• Cache write
• Before cache invalidate
• Cache invalidate
• Before cache read
• Cache read
• Before sync
• Sync

A Marionette style triggerMethod would be helpful here to allow easy hooks into the lifecycle events

EDIT: It's also worth noting that providing these events will allow users to roll their own push notifications, addressing the intent behind #3

Enhance cache eviction flow

As of 0.1.0, cache eviction is terribly basic. When the cache is full, the Store automatically clears all managed cache items and tries to store the data again. This is obviously undesirable.

Goals

• Let the Policy determine which items to evict from the cache
• Ensure that the cache is not modified while evicting items to make room

Possible Later: Smart cache eviction by default

• Use metadata such as last access time, size, etc. to inform the decision of which items to evict
• Don't remove anything if the item is larger than the cache

Expose backend-accessing methods on Hoard.Store as an async API

Store currently directly accesses the backend, particularly in invalidate. Store should expose getItem, setItem, and removeItem as public methods for overriding.

Provide more storage adapters

Hoard is designed to use any in-browser storage system. It would be nice to test this by providing additional Stores making use of indexedDB and simple in-memory storage. Additional adapters should probably go either in additional projects or additional build scripts at the very least.

Gist for in-memory store

Update to use ES6

Using 6to5, people supporting IE8 would have to include a polyfil for es5. This is acceptable, as long as it's documented.

Move entire test suite to karma

Karma only has a slow startup; it's plenty fast at running the tests, and the watcher is pretty good.

More Docs + Existing docs on gh-pages

The README is long, dense, and poorly laid out. Pare it down, moving all content to a more-easily updated gh-pages.

List of things not to forget:

• as per #32, specify that users should overwrite Hoard.sync when modifying Backbone.sync
• specify that weird behavior can result when mixing with jQuery deferrerds

Publish on bower

I am currently only publishing on npm.

Find model collection using model urlRoot property

It's a common use-case for a model that belongs to a collection to be populated outside of that collection. It's reasonable that if the model was modified on the back end, all collections where that model exists should be updated.

On executing a strategy on a cached model if that model does not contain a reference to a hoard collection the model request is not updated on any collection, even if the parent collection is managed by hoard.

However, we can take advantage of a model's urlRoot property. If a collection matching the urlRoot of the model is found we can assume that the model belongs to the same collection.

Provide option to update models when the cache updates

In some cases, it might be desired to have models reflect the state of new data in the cache. When the cache updates for a given key, update models with the same key that have elected to sync their attributes.

Care must be given to not saturate the API of the default strategies to ensure that they're easily swappable. This might be best handled by the Policy.

Manage knowledge of cache size

Neither the WebStorage api nor the QuotaExceededError give any hint as to how much space can be used by localStorage or sessionStorage. The spec throws out a number of 5mb, and most browsers seem to go along with this, so it might be ok to just guess at a 5mb cache size.

Another option is to keep track of the known good size of the available storage space, based on what we've been able to successfully store.

Question about query params

How does hoard manage query paramz?

Wrap Hoard.extend instead of directly proxying on components

Control.extend = function () {
  return Hoard.extend.apply(this, arguments);
};

Makes it much easier to modify Hoard.extend. This will make it easier to use plugins that modify extend (such as backbone.super).

Improve integration tests.

More cases can be tested, starting with the other strategies.

Strategies with decent integration tests

• create
• read
• update
• delete
• patch

Provide a default "cache-bypass" strategy

Bypassing the cache for certain methods is sometimes valuable. This is a basic feature that allows for a standard implementation.