In my display template I want to render a field in different ways based on the user's group membership. The information about the group membership comes from an async ajax call (jsom or rest)

What I have discovered is that I have to provide a html string or a function that describes the rendering logic. It demands my override immediately. There is no way to make an ajax (jsom) call to server to look up some information and call back the CSR engine.

There is a similar question on stack exchange, but it is viewed from another side of the problem: How to use jsom without async calls

So my question is: What can I do to enable async rendering in CSR, or delay Client Side Rendering until I get a response from my ajax call? If it is not possible what can I use to ensure I have the (a)sync information in place when my list items are rendered by SharePoint.

2 Answers 2


As said on Twitter.

You could first create an empty element with a specific ID. Pass that ID with your ajax call, and once you retrieved the information from your ajax call, you could retrieve the empty element and pass the necessary information in it.

This is probably the easiest and quickest way to achieve it.


As a workaround, you could fetch the information before the user gets to your list view and store it in sessionStorage...

Make the calls to find out if your user is in whatever groups you're trying to look at, then put the result in the sessionStorage object with something like

sessionStorage.isInMySpecialGroup = "true" // sessionStorage only wants strings for values

or if you want to get fancier with multiple groups you could do

sessionStorage.spUserGroups = "Group1;Group2;Group3"

Then you can split the result on ";" if you want an array or something from it afterwards.

When you get to the CSR page, have your CSR script check sessionStorage for your values, I would recommend a default behavior too in case the user circumvents the page that should have loaded things (or you could get crafty and redirect them yourself to force the issue).

There are obviously some caveats here, the biggest of which is that it won't work on older browsers, so you should do something like feature detection before trying to access or write information there:

if (window.sessionStorage && window.sessionStorage.myData) {
    //do stuff with your data

The other really big item is that it's your responsibility to make sure that your site behaves in such a way that the sessionStorage variable gets populated with your data before your users get to your CSR page that will rely upon the information (this can be harder than you might think... users tend to do whatever is convenient, not whatever will make your app work) -- and this is admittedly a tricky dependency to keep track of in an application.

Other things... I noted in the first script example that sessionStorage (and localStorage for that matter) only accept strings for values -- so do something like JSON.stringify(...) to store and JSON.Parse(...) to read if you want to put objects in there.

sessionStorage is only available on the page/tab that loaded the information into sessionStorage and is deleted when you close the tab/browser.

  • Thank you John-M. sessionStorage and localStorage are important techniques to improve performance and it will partly solve the problem with async calls. It doesn't solve the problem completely, though, because you still have to make a call the first time. I am still upvoting your answer because you make a good point in using browser cache techniques. Commented Dec 5, 2014 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.