Re-implementing caching when browsers are capable of handling it, doesn't sound like a good idea.

But then why have a sourceCache at all? Irregardless of caching the current issue is this: A stacktrace with a depth of 30 makes 30*2 network requests (1 for the js, 1 for the map per line). This is madness, even with proper server caching the latency is excessive (even more so for anyone on a low-bandwidth connection). If you make this.ajax() return a promise then you can just cache the promise in the sourceCache until it is resolved, so any future invocations of _get() just wait for that single in-flight AJAX request to resolve and use the response, rather than each issuing their own and hoping it all works out.

All this could be done with a small fix to _get() (untested, just to illustrate):

if (this.sourceCache[location]) {
    if (this.sourceCache[location] instanceof Promise){
        this.sourceCache[location].then(resolve).error(reject);
    } else {
        resolve(this.sourceCache[location]);
    }
} else if (opts.offline && !isDataUrl) {
    ...
} else {
    if (isDataUrl) {
        ...
    } else {
        this.sourceCache[location] = this.ajax(location, function (source) {
            this.sourceCache[location] = source;
            resolve(source);
        }.bind(this), reject);
    }
}

After the future is resolved the sourceCache is updated with the content, so any future invocations just use that response.

This way as long as the sourceCache is passed from stacktrace.js multiple calls to stacktrace-gps will share the cache, thus share in-flight requests, and so only need to make perhaps 2 or 3 (depending on how many different URL's you have to fetch) requests instead of 60.

getSource does not always use browser cache when it should #19

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions