Extending Field Types With Client-Side Rendering In Sharepoint 2013
The Need for Custom Field Rendering
Out-of-the-box field rendering options in SharePoint 2013 have limitations that can constrain solutions built on the platform. Specifically, the lack of flexibility in displaying and editing field values on forms can hamper user experiences and adoption. As a result, developers often find the need to customize how fields are rendered to meet user requirements.
Fortunately, SharePoint 2013 introduced the ability to use client-side rendering for enhanced control over field rendering Logic. With client-side rendering, custom JavaScript code executes on the user’s browser to define how field values are displayed in forms and pages. This approach is generally preferred over server-side custom field rendering as it allows for faster responses and richer interactivity.
Limitations of Out-of-The-Box Rendering
SharePoint form fields have built-in rendering templates that define how the field appears on the New, Edit and Display forms. However, these templates limit options for formatting, layout, and interactivity. For example, lack of support for conditional logic makes it difficult to show or hide other fields based on a value. Without customization, types of fields are restricted to simple text boxes, drop downs, and dates without rich widgets.
Why Client-Side Rendering is Preferred
Customizing field rendering on the server has significant drawbacks that client-side rendering addresses. Server-side changes require deploying updated field definitions and edit form pages. Round trips to the server reduce interface responsiveness. Browser-based custom code solves these issues by executing on the client for faster performance. Client logic also keeps solutions portable for easier distribution.
Client-Side Rendering Overview
How Client-Side Rendering Works
Client-side rendering utilizes JavaScript and jQuery to override how fields render without changes to servers or schemas. Custom render functions intercept field rendering before values display. The functions tell SharePoint to allow JavaScript code to handle rendering instead of default logic.
Contrast with Server-Side Rendering
Server-side custom rendering involves changing field definitions and edit form page layouts in SharePoint. This requires manual deployment of updated field XML schemas and ASPX pages. Client rendering uses reusable JavaScript code loaded on-demand to handle rendering tasks.
Example Custom Field Type Benefiting Client-Side Rendering
A scenario where client-side help is a Project Intake Request field. The requester selects a Project Type like CRM or ERP from a dropdown. Conditional logic then shows relevant questions for the type selected. Dependent data expands dynamically so user only sees what applies to their choice.
Implementing Client-Side Rendering
Steps to Implement
High-level steps for add client-side rendering are:
- Author rendering template JavaScript functions
- Register rendering templates with list field definition
- Read field value and provide as parameter to renderer
- Output rendered markup from template function
Rendering Template Code Sample
function projectIntakeRenderer(fieldValue) {
var output='';
if(fieldValue=='CRM') {
output = '<div>Show CRM Questions</div>';
}
else if if(fieldValue=='ERP') {
output = '<div>Show ERP Questions</div>';
}
return output;
}
Explanation of Rendering Template Code
Within renderer function, conditional logic checks field value to determine output. Literal strings or markup can be constructed and returned. FieldValue parameter gives access to associated field content. Usage similar to regular list rendering but allows full control over rendered output from browser.
Connecting Template to Field Type
Registering Rendering Template
After authoring rendering template, next associate with field in list definition. Template function name is supplied as the render attribute. This tells SharePoint which client rendering function to execute.
<Field
Name="ProjectIntake"
Render="projectIntakeRenderer"
/>
Passing Field Value to Template
Field values from forms post to servers as usual. But with client rendering specified, read logic passes the value to the defined renderer function instead of rendering natively.
Considerations and Best Practices
Limitations of Client-Side Rendering
Considerations when using client rendering:
- JavaScript must be enabled on all browsers accessing field
- Limited types of validation logic available client-side
- No server compute support for complex rendering tasks
Performance Optimization Tips
Some ways to optimize client rendering:
- Minimize DOM updates by batching template modification
- Throttle events that trigger re-rendering logic
- Use field caching to reduce overhead
Ensuring Cross-Browser Support
For consistent behavior across browsers:
- Follow web standards closely including HTML5 and ES5 JavaScript
- Feature detection rather than browser detection
- Extensively test across target desktop and mobile
