5 facts about JSLink in SharePoint 2013 you might not know

SharePoint 2013 has a great JavaScript API to extend the way fields, list forms and views are rendered on the client side. The generic idea is to build up your custom functionality, wrap it up into JavaScript file and, finally, attach to the field, content type or whatever it is via JSLink property.

Well, there is a bunch of the “JSLink how-to” articles over there – for the lists, field and the rest artifacts. I suppose you may have built something cool, but you might not know something I am just about to share with you. Let’s get started!

#1 – JSLink supports multiple JavaScript files

JSLink allows you to attach multiple files. Yes, multiple JavaScript files and I am pretty serious about that. You may set them via “|” separator like this:

“~sitecollection/Style Library/spdevlab/spdevlab.multiple-1.js|~sitecollection/Style Library/spdevlab/spdevlab.multiple-2.js ”

This is pretty useful in case your custom functionality is quite complex and splitted up into several JavaScript files or you may want to use other files and libraries in SharePoint 2013 such as mQuery and the rest.

#2 – JSLink supports (d) tag to specify SOD registration

You may specify “(d)” tag-string at the end of the file link. In that case, your file is not going to be loaded immediately, but will be registered with SOD to be queried later.

So, the following JSLink would produce one script including with “script” tag and two SOD registration:

“~sitecollection/Style Library/spdevlab/spdevlab.multiple-1.js|~sitecollection/Style Library/spdevlab/spdevlab.multiple-2.js(d)|~sitecollection/Style Library/spdevlab/spdevlab.multiple-3.js(d)”

The outcome would be like this:

<script type=”text/javascript” src=”/sites/dev4/style%20library/spdevlab/spdevlab.multiple-1.js?ctag=0$$15.0.4420.1017″></script>

Also, you will get the SOD registration for the two other files:

<script type=”text/javascript”>RegisterSod(“~sitecollection/style library/spdevlab/spdevlab.multiple-2.js”, “\u002fsites\u002fdev4\u002fstyle\u002520library\u002fspdevlab\u002fspdevlab.multiple-2.js”);</script>

<script type=”text/javascript”>RegisterSod(“~sitecollection/style library/spdevlab/spdevlab.multiple-3.js”, “\u002fsites\u002fdev4\u002fstyle\u002520library\u002fspdevlab\u002fspdevlab.multiple-3.js”);</script>

That’s interesting, but the SOD key for your JS file would be exactly like the original file name. Even with the tokens such as “~site” or “~sitecollection”.

#3 – You can’t overwrite JSLink for some of the fields

Overriding JSLink property via field xml definition or c# code is a nice way to link your JavaScript file to the particular field. However, not all the fields could be overwritten this way.

For example, Taxonomy field has the following JSLink definition:

// Microsoft.SharePoint.Taxonomy.TaxonomyField
public override string JSLink
{
	get
	{
		return "SP.UI.Taxonomy.js|SP.UI.Rte.js(d)|SP.Taxonomy.js(d)|ScriptForWebTaggingUI.js(d)";
	}
}

This means you cannot modify the look and feel for your Taxonomy field. Also, you can’t do that for Taxonomy, Related Items or Task Outcome field. All of these fields return particular JSLink which can’t be changed.

Frankly saying, you still may change look and feel of these fields, but you need to register your JavaScript file on the site collection level and make sure it gets loaded on every page. It could be done with custom action or any other methods to deliver JavaScript file within the site collection scope.

#4 – There are several JavaScript files with client render templates

You may have already seen and explore “clienttemplates.js” file as it has most of the client render definitions for the SharePoint fields. However, there are several JavaScript files with different fields templates. Here they are:

• clienttemplates.js – for the most of the fields
• Geolocationfieldtemplate.js – for SPFieldGeolocation
• sp.ui.relateditems.js – for RelatedItemsField
• choicebuttonfieldtemplate.js – for OutcomeChoiceField
• SP.UI.Taxonomy.js – for the Taxonomy field

These files could be useful for exploring and learning out of the box API or other tricky stuff for the field rendering in SharePoint 2013. Enjoy!

#5 – There more than ~site/~sitecollection tokens supported by JSLink

In fact, internally, JSLink comes to the ScriptLink web control to register all JavaScript files. As an outcome, JSLink also supports the following tokens:

• ~site
• ~sitecollection
• ~layouts
• ~siteLayouts
• ~siteCollectionLayouts

This is quite cool as, for example, ~layouts token depends on the current compatibility level of the target site and could be either “_layouts/14″ or “_layouts/15″. This might be not critical for the custom field rendering, but for something else.

Conclusion

SharePoint 2013 has a lot of client side improvements. JavaScript object model is quite large and yet to be explored. I recently wrote about mQuery and some interesting things about “Quick Edit” mode for the custom fields. Well, that’s just the top of the iceberg.

I hope you enjoyed reading and get some new, really valuable information about JSLink and its hidden power and flexibility. Stay tuned!