Setting the JSLink Property of a Field Using JavaScript

In my last post I showed a utility page allowing you to set the JSLink property of a site column. In this post I’m going to dump the code on you, and then explain parts of it. It’s just a SharePoint wiki page with some JavaScript in it using the JavaScript Client-side Object Model (JSOM), so you can just drop it in the Style Library (or any document library really) and click on it to start using it.

And here’s the code:

Initialization (lines 241-243 and 93-117)

First, I need my code to start running after the JSOM client context has been initialized, so I call my init method in a callback to SP.SOD.executeFunc, waiting for SP.ClientContext to be initialized by loading sp.js.

In the init method, I get the client context, and from it the current web. Then I ask it for its list of available fields, which executes asynchronously. When the fields have been loaded, I enumerate them and shove them into a property called options. I also load a unique list of field groups into the group’s property. Then I initialize my DOM elements based on the results.

At this point, the field select contains all available fields, and the group select contains all field groups. If you select a field group, the fields select will be trimmed down to just fields in that field group, theoretically making it easier to find what you’re looking for.

Note that when you select a field, the text box will be initialized with the current value of the JSLink property for that field. If you’ve never set it before, it should be just clienttemplates.js, which is the JavaScript file that SPClientTemplates is in. If you have set a field’s JSLink property to something else, and want to revert back to the default, don’t set it to clienttemplates.js but set it to blank instead. If you reload the page and look at the field again, you will see that it says clienttemplates.js again.

Updating the JSLink Property (lines 204-237)

This is the meat of the utility; the button click event. It gets the field again by name, asynchronously. Once it has it, it sets the JSLink property of the field to whatever you typed in the JSLink text area (sort of).

JSLink can store multiple JavaScript files in a single property, but it doesn’t store them newline separated like the text area. I chose to newline separate them in the UI because it’s easier to read and work with, but when I write them back out I replace the newlines with pipes (|), which is what SharePoint expects to separate multiple files.

And finally, I call updateAndPushChanges asynchronously to persist the changes back to SharePoint.


I love writing little utility pages like this using JSOM and a wiki page. Most of the Client-side Object Model code I see for this kind of job are written in PowerShell. I’ve got nothing against PowerShell, but at many larger organizations, your average SCA isn’t going to have sufficient access to their desktop to add the Microsoft.SharePoint.Client DLLs to it, and it may take an act of Congress to get an administrator to do it for you. Doing it with JSOM on a wiki page makes it more easily accessible to any SCA. And BTW, you do need to be an SCA to run this code (or at least be able to write to site columns, which requires an array of permissions).

And while this code operates on site columns, this same technique works on web scoped columns or list columns as well, in which case you would only need web scoped permissions or list scoped permissions to run it.

Leave a Comment