Month: April 2016

An Introduction to Client Side Rendering

theChrisKent Client Side Rendering, SharePoint , , ,
Applies To: SharePoint 2013, 2016, Office 365

List View Client Side Rendering Primer: 1 of 5

About This Series

This series provides a brief overview of Client Side Rendering for List Views (often referred to as JSLink). Basic extension points and examples are included. The goal of this series is to get developers unfamiliar with this programming model quickly up to speed.

Introduction

Client Side Rendering (CSR) is a technology that provides extension points (templates) that use JavaScript to render the data to a SharePoint page. CSR is often referred to as JSLink in reference to the list view web part’s JS Link property. However, CSR can be used for far more than just rendering list views (although this is the most common use and the focus of this series).

Client Side Rendering was introduced with SharePoint 2013 and is fully supported in SharePoint 2016 and Office 365.

A Selective History of Drawing Data in SharePoint

sp-drawing-data-history

SharePoint 2007 incorporated the use of XSLT 1.0 to render list views through XML based web parts such as Content by Query web parts (CQWP) and DataView web parts (DVWP). This allowed developers to customize the display but required specialized knowledge, was very difficult to troubleshoot, and was very poorly documented. This approach is still available in all current versions; however, the usage is not generally recommended.

SharePoint 2010 brought several improvements to XSLT support and Microsoft embraced community sourced documentation. The most important introduction was the new XSLTListView web part that simplified individual list view display and provided a simpler (single stylesheet) usage of XSLT. The XSLTListView web part is still the recommended approach in 2010 and continues to be valid in all current versions.

SharePoint 2013 introduced Client Side Rendering. The primary focus of Client Side Rendering was on pre-defined display templates but an additional property was added to the XSLTListView web part, JS Link, that allowed the easy incorporation of JavaScript files wherever the list view was rendered. This allowed a more web standards based approach and opened the technology up to non-traditional SharePoint developers.

SharePoint 2016 (and Office 365) have not brought much more for Client Side Rendering. XSLT performance was improved illustrating their understanding of the wide usage of that technology still going forward. However, with the introduction of the new SharePoint Framework (SPFx), many use cases for CSR may be replaced. However, only the web part customization piece of SPFx has been released and only in Office 365 at the time this post was written. However, Microsoft has indicated that the framework will cover many of the other traditionally display template focused areas as well.

JSLink vs Display Templates

At a high-level, CSR can be broken down into two categories: JSLink and Display Templates. Although it is a bit of a misnomer to refer to them separately, the general usage of these terms can be defined as:

  • Display Templates
    • Templates used in Web Parts using Search
  • JSLink
    • Property on XSLTListView web parts
    • JavaScript files used for CSR

Display templates actually refers to predefined JavaScript associations with fields, lists, views, contenttypes, forms, and search results. In practical use, however, you’ll generally see these referred to as JSLink even though JSLink is only for the property association.

The focus of this series is on the use of JSLink in XSLTListView web parts.

Continue?

Now that you know the basic terms and have an idea of what this CSR/JSLink stuff are, it’s time to find out why you should use it. Check out the next post in this series: