Populating form data by using AJAX data sources are an excellent way to speed up your website. However, if you are populating multiple data sets each time you open a form, then the application can become so chatty that it actually becomes slower than pre-processing the entire thing! This is especially a problem if you have dependencies of one dataset upon another.
One way to avoid this is by maintaining a root variable of ajax sources that aren’t going to change during the session. Perhaps things like “OrderStatusOptions”, where it’s going to be “Active”, “Inactive”, “Open”, “Closed”,”Cancelled”,”Lost”,”Deleted”, and that’s it. You could put it into a variable in the root scope or some service. However, that can lead to memory bloat as well as a loss of that if the user browses to a page where the application has to be reloaded. In our case, we often are upgrading a large system and users might bounce from an Angular area to a WebForms area to a Classic ASP area, etc… You maintain the session, but the JavaScript variables vanish.
Lately, we’ve had an enormous improvement in speed by using the browser’s local storage features. In the past, we have used cookies to maintain some data, like that OrderStatusOption example. It works, but it is limited in data capacity. An example that we have now is “Offices”. This is simply an ajax call that brings us an array of Corporate Offices. To keep the code as simple as possible, we limit API controllers as much as possible as well as Angular $http Service functions. The goal was to populate a Select box with the corporate office IDs, Numbers, And Name without having to load the entire dataset. Since we have about 80 offices, it was far to big for a cookie and we didn’t want to keep it in a javascript variable. The data DOES change, but infrequently and rarely anything critical. So, we can’t just always keep it in local storage. SessionStorage to the rescue.
Here’s what we do for Offices, and now for almost all data (especially search results so people can page back and forth between pages without having to run the search again)
module Application.Services {
export class ClientService {
public session_id: any = {};
public server:string
$insert = ["$http", "$sessionStorage", "$location", "$q"]
constructor(private $http: any, private $sessionStorage: any, private $location: any, private $q: any) {
this.server = "https://myAPIserver.com"; //(we normally keep this in a config file elsewhere)
this.session_id = "asdfoinasdf09sdgfsdf42323dfdfdf3oasd089123jksd08cjo23d9090sdio" //(this is actually stored in a cookie and maintained in our app script)
}
getOffices(): ng.IHttpPromise {
var deferred: any;
deferred = this.$q.defer();
if (this.$sessionStorage.offices) {
let s = this.$sessionStorage.offices;
deferred.resolve(s);
} else {
let url: string = this.server + "/api/Office?sid=" + this.session_id;
return this.$http.get(url)
.then((resp: any) => {
this.$sessionStorage.offices = resp.data;
deferred.resolve(resp.data);
});
}
return deferred.promise;
}
}
app.service("ClientService", ClientService);
}
So, what’s happening here is that a component or controller is calling for a list of offices. The getOffices() function then checks to see if you have a list in the browser’s session storage. If so, return that. If not, go get it from the server, copy it to the session storage and return it.
Once the user leaves or logs out, we clear out the session and move on.
