SharePoint Client-Side Rendering and Office UI Fabric

SharePoint Client-Side Rendering is a rather vaguely documented functionality of the product. Yes, when you start looking for help you will find few examples here and there, but don’t count on well documented JavaScript libraries. Yet again, this is the case for most of the JavaScript code in SharePoint and that never stopped people creating amazing solutions. The closest you can get to a documentation, and should include if you decide to use TypeScript, is probably this. The final resource is always the browser developer tools though.

How is this post different than the rest then?

Most samples you will find are split into three categories:

Modifying how a field is rendered in a form.

1

2

3

4

5

6

7

8

9

options.Templates.Fields={

"Title":{

"NewForm":titleFiledTemplate,

"EditForm":titleFiledTemplate

}

};

SPClientTemplates.TemplateManager.RegisterTemplateOverrides(options);

Modifying how different sections of the forms or, a bit advanced – entire form, is rendered.

1

2

3

4

5

6

varoptions={};

options.Templates={};

options.Templates.View=formViewTemplate;

SPClientTemplates.TemplateManager.RegisterTemplateOverrides(options);

Modifying how a field is rendered in the list view.

1

2

3

4

5

6

7

8

options.Templates.Fields={

"Title":{

"View":titleFiledTemplate

}

};

SPClientTemplates.TemplateManager.RegisterTemplateOverrides(options);

The above probably covers majority of the cases, but you do need to create a separate JavaScript file for every list, modify it based on the field (internal) names, and apply it to this list only. Sooner or later, you might even find yourself copying code between files, just so you have more places to update later…You can see where this is going. What if you want a solution that can be reused without maintaining a lot of files?

Where Office UI Fabric comes into play

I like Office Fabric UI from since the release of the initial version. Having spend years copying SharePoint server controls to custom _layouts pages and, where not possible, entire HTML blocks I thought finally – a solution that would make everything easy. So let’s see how easy it is to replace how some of the field types are rendered in SharePoint forms, using the JavaScript version of the library.

Prerequisite, in case you decide to play with the code, is to add the Office UI Fabric JavaScript and CSS files. Using a CDN or deploying them locally is a matter of personal choice.

Step 1 – Set up using OnPreRender

The only event I will hook up to is OnPreRender. This gives me enough control to handle each field differently, based on its type.

1

2

3

4

5

6

7

8

9

10

varAtos=Atos||{};

Atos.FormRenderSetup=function(){

varoptions={};

options.Templates={};

options.OnPreRender=Atos.FormOnPreRender;

SPClientTemplates.TemplateManager.RegisterTemplateOverrides(options);

};

Step 2 – Attach type-based render methods

In OnPreRender event I check the field’s type and attach a render function to the ones I want to handle. For the rest I just walk away and let the default render method handle it.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

Atos.FormOnPreRender=function(ctx){

varfieldName=ctx.ListSchema.Field[0].Name,

fieldType=ctx.ListSchema.Field[0].FieldType;

switch(fieldType){

case"Boolean":

ctx.Templates.Fields[fieldName]=Atos.BooleanRenderer;

break;

case"Text":

ctx.Templates.Fields[fieldName]=Atos.TextRenderer;

break;

case"Choice":

ctx.Templates.Fields[fieldName]=Atos.ChoiceRenderer;

break;

default:

// Let the default function handle it

break;

}

};

Step 3 – Implement a Render method

Below is an example of the three field types I decided to play with. Each handler implements:

registerGetValueCallback – so I can get the value from the correct place.

registerValidationErrorCallback – so I can show an error in the correct place.

Each render method is returning a newly formatted HTML using Office UI Fabric blocks. I am also attaching a Message at the end of each control, used for displaying errors. The error message will come from SharePoint so no need for custom validation. Can do that too, but remember that every field type will be using it and this might not be what you had in mind.

Step 4 – Some helper methods

Below are a couple of helper methods to attach the JavaScript events used by Office UI Fabric and a common handle error method, used by each registerValidationErrorCallback.

Step 5 – Wrap it all up

At the end of the file, attach the custom templates and the Office UI Fabric helper function to the array that will be executed by SharePoint when the page loads.

1

2

3

4

5

/* Execute start ups */

_spBodyOnLoadFunctionNames.push("Atos.AttachFabricEvents");

Atos.FormRenderSetup();

Result

A few screenshots of the final result

Summary

As you can see, I only implemented three field types and these are more or less easy ones. Would I replace the default people picker with a search field? Depending on how much time you have to spend, maybe. Also you need to consider that people get used to certain UI controls and might not find your changes very friendly. A simple control like a text box, yes, why not.

Lastly, a lesson learned while playing with the above – do not try to extend the Array object. Adding the below might cause you major headache caused by the validation methods used by SPClientTemplates. The fun you can have with prototype…