These are chat archives for madglory/backbone-fetch-cache

7th
Jan 2015
Lior Chen
@liorch88
Jan 07 2015 08:36

I still think the mixin is a good idea. To avoid the context issue, maybe just avoid nesting it. Maybe the API for instance methods should be different then the public fetchCache API anyway - I mean, it does offer different functionality (always passing the instance).
It should be documented that using the mixins means that the methods will only work for the model/collection's instance, and they will assume the key is either the default or under a model's getCacheKey method. If they want something else - use the global methods, not the mixin's.
The API I am thinking of is something like this: prefixing all the methods by "cache" and only including some of the functionality - the functionality I think is needed for models.

Backbone.fetchCache.mixins = {
    cacheSet: function (opts) {
        return Backbone.fetchCache.setCache(this, opts);
    },
    cacheGet: function (opts) {
        return Backbone.fetchCache.getCache(this, opts);
    },
    cacheClear: function (opts) {
        return Backbone.fetchCache.clearItem(this, opts);
    },
    cacheLastSync: function (opts) {
        return Backbone.fetchCache.getLastSync(this, opts);
    }
};

Notice that I didn't include getCacheKey, as I think it will only confuse, and not needed in model context.
What do you think?