Implement Client Caching For SharePoint Properties

SharePoint Pages are intended to act asa data presentation layer to the end users for the data stored in SharePoint List. In the rich interactive clientcentric Applications, it is expected to have quick response to different user actions, like Read Data from or Save Data to SharePoint List.

Any delays due to read/write operations to SharePoint can negatively impact the User Experience and could lead to denial of acceptance on developed features.

Using HTML5 Local Storage API, Web Applications can store data locally in the user’s browser. Local storage is more secure and large data can be stored without impacting overall Web Application performance.

This new API allows large amount of data (approx. 5 MB) to be cached locally which is far larger than the cookies which were commonly used for caching data.

Local storage is maintained per domain & protocol (Origin of Request) and all web pages of the same origin can use the same cache.

In this article, we will see HTML5 Local Storage API in action and utilize it to cache SharePoint Properties of primitive data types like String, Integer, Boolean; and in one of the upcoming articles in the same series, I will explain the caching of some of the complex SharePoint Objects.

Let’s kick start this demo with a new SharePoint App Project in Visual Studio 2013.

Choose “App for SharePoint” Project Template.

Specify SharePoint Site URL (On Premise or Online). Here, I am using SharePoint Online Site to go with this demonstration.
Select hosting model as “SharePoint-Hosted”.

Enter SharePoint Online account credentials.

Wait till Visual Studio configures the project for you.

I have added HTML code to default.aspx page that will display the following elements to the UI.

Result Panel
This is a div that will display the output of the operations performed.
Get Web Title
This HTML button will retrieve the title of the Host Web and add it to the cache on click event.
Clear Cach
This HTML button will clear the local cache whenever needed on click event.

Add little CSS to App.css to make UI elements more intuitive.

With this, our UI is a go.

Now, let’s explore the code that we have added to App.js.

Step 1

Hooking up the event handlers to the click event for “Get Web Title” & “Clear Cache” button.

Step 2

This function first checks if Local Storage API is supported in the current browser and if it is supported, then clear the specific key by specifying the key name or all the keys from local cache by calling Clear() methods that you can see as commented in this function.

Step 3

This is the helper method that checks if current browser supports the HTML5 Local Storage API traditionally, by querying JavaScript “window” object.

Step 4

This method is a helper function that helps to retrieve Query String Parameters out of the requested URL.

Step 5

Verifying if the current browser supports the HTML5 Local Storage API.

Step 6

Verifying if the current browser supports the HTML5 Local Storage API by utilizing Feature Detection capabilities of Modernizr.js Framework. For more details on Modernizr.js, you can visit here.

Step 7

Instantiate the local storage object.

Step 8

Reading web title value out of local storage cache, by specifying the key.

Step 9

If the web title exists in the local cache, then the value is retrieved out of it without any need of issuing a call to SharePoint; else we call another helper method “getWebTitle()” that will issue the request to SharePoint and get the Web Title, display it to result Panel, and add the value to the Local Cache so as to make it available to serve any subsequent request.

Step 10

In this method, we are making CSOM call to SharePoint in usual way, once the call gets succeeded, the Web Title will get displayed in the Results Panel and also, add the value to local storage by calling setItem() method. This value will be available to serve from cache in response to any future request for Web Title.

With this, we are done with the code.

Before we start execution, we need to allow Read Permission to the App on Site Collection.

Launch AppManifest.xml.
Go to “Permissions” Tab.
Select “Site Collection” from Scope Dropdown.
Select “Read” from Permission Dropdown.

Run the app.
Enter the SharePoint Online credential when prompted.

Trust the app when prompted.

When the app lunches, we can see the UI based on the HTML we have added earlier to the default.aspx page.

We can see the Result Panel where we will see the results of the operations and “Get Web Title”, “Clear Cache” buttons as well.

Now, when we click on “Get Web Title” button, we can see two actions performed & logged in the Result Panel as follows-

Since the Web Title is not available in the Local Cache, it is retrieved from SharePoint and saved back to the local cache
Displaying Web Title in the Result Panel.

If we investigate the Client – Server Request cycle using Fiddler, we can see that there is actually a request issued to SharePoint and the response received from the server in form of requested data.

When we click “Get Web Title” button again, we will see the following two actions performed and logged in the Result Panel.

Since the Web Title is available in the Local Cache this time, no call has been issued to SharePoint for data and Web Title has been retrieved from the Local Cache
Displaying Web Title in the Result Panel retrieved out of Local Cache.

If we look into Fiddler again, we can see that no request has been issued to SharePoint since we got the requested data available in Local Cache.

That’s it for now.

In the upcoming article on Client Caching, I will explain the caching scenarios related to more complex SharePoint Objects like “SPListItemCollection” which is a quite common return type when we query data from SharePoint Lists, and deserves special attention as long as the caching is concerned.

I hope you find it helpful.