Creating Hybrid Angular and JSLink SharePoint Add-Ins

Scot Hillier

by Scot Hillier on 7/31/2015

Share this:

Article Details

Date Revised:

Applies to:
Angular, JSLink, REST-based API, SharePoint add-ins, SharePoint lists, SPA

Like a lot of developers these days, I am a big fan of the Angular framework. Single-page apps (SPA) provided a beautiful experience for end users, and the Angular framework is a pleasure for developers. As an Office 365 and SharePoint developer, however, I am not always able to fully utilize the SPA approach when creating add-ins. Because Office 365 and SharePoint offer rich, robust REST-based APIs, the theoretical approach is to create SPA add-ins that use service-layer components to call the APIs. In this way, you divorce the add-in from the elements in Office 365 and SharePoint that would otherwise interfere with the flow of a SPA add-in. In reality, however, such an approach would require a significant amount of additional development.

As an example for this article, I’ll focus on the use of lists to manage data in SharePoint add-ins. Lists are great for maintaining simple data, but the out-of-the-box (OOB) user interface is not built as a SPA. So, if you are using the Angular framework for your add-in, then your user will exit the SPA environment whenever they interact with a SharePoint list. You could avoid this situation by making REST calls to perform create/read/update/delete (CRUD) operations against the list, but then you would have to write your own SPA-based user interface to support CRUD operations for every list in the add-in. While that is a perfectly valid option, it also represents a lot more development work for you.

If you want to avoid the extra development work, you may choose to create a hybrid architecture that utilizes the Angular SPA framework for the most part, but tolerates the fact that users must leave the SPA to interact with lists. In this case, however, you are stuck with the look and feel of the OOB user interface. In the SharePoint world, you could alter the OOB forms by using JSLink to implement special controls and validation, but uploading and applying JSLink files is not easily integrated into the Angular framework, which might mean additional coding outside of the framework. A true hybrid solution should allow creating a SharePoint add-in based on the Angular framework and also support applying JSLink files to lists within the add-in. In this article, I’m going to address this challenge by introducing a custom Angular provider that can automatically apply JSLink files to lists in a SharePoint add-in. I’ll assume a basic understanding of SharePoint and Angular development, and you can download the article code from the IT Unity GitHub repo.

Creating a custom Angular provider

Factories are a common component in Angular applications that are used to provide shared functionality accessible across controllers. Factories return object literals that can subsequently be injected into controllers. As an example, Listing 1 shows a simple factory used to wrap the toastr library to create a notification service.

Listing 1, A notification service

angular.module("myApp", []).factory("toastService", [function () {
    var info = function (message) {
        toastr.options = { "positionClass": "toast-bottom-right" };;

    var success = function (message) {
        toastr.options = { "positionClass": "toast-bottom-right" };

    var error = function (message) {
        toastr.options = { "positionClass": "toast-bottom-right" };

    return {
        info: info,
        success: success,
        error: error


Initially, it might seem promising to consider creating a factory to apply JSLink files to SharePoint lists, but factories are not available during the configuration phase of an Angular application. The configuration phase allows an application to register modules and perform configurations before the main processing of controller functionality begins. The configuration phase is the logical place to apply JSLink files because the application is not really “running” yet.

A more generic version of a factory that is available during the configuration phase is called a provider. A provider is similar to a factory, but it returns a special $get function when injected. The provider can also contain additional custom methods. Listing 2 shows the structure for a provider named jsLinkService that will support applying JSLink files to lists. You can review the complete code by downloading the project from the GitHub repo.

Listing 2, The jsLinkService provider

var Jslink = window.Jslink || {};
Jslink.App = angular.module('jsLink', []);

Jslink.App.provider("jsLinkService", {
    isSiteAdmin: function () {
      //checks to see if current user is a site administrator
    set_jsLink: function (listName, formType, filePath, skipUpload) {
      //uploads and applies JSLink files to lists
    $get: function () {
        return false;

The isSiteAdmin function tests to see whether the current user is a site administrator because only a site administrator can apply JSLink to SharePoint lists. Once applied, however, the JSLink customizations will remain in place. Therefore, a site administrator must run the add-in before anyone else, but that’s not a problem since a site administrator is the only one who can install an add-in in the first place. The set_jslink function actually uploads and applies the JSLink. The function takes the name of the list, the form view to modify (NEW, EDIT, DISPLAY, or VIEW) and the path to the JSLink file. An optional parameter indicates that the upload process should be skipped, which is useful when applying the same JSLink file to multiple lists.

Using the provider in an add-in

In order to use the jsLinkService in an add-in, the corresponding library must be referenced, and the provider injected into the configuration function. Referencing the library is straightforward; simply include the jsLink.js file from the GitHub repo in your add-in project. Listing 3 shows how to inject the provider into the configuration function.

Listing 3, Injecting the provider

angular.module('myApp', ['jsLink'])
    function (jsLinkProvider) {
        jsLinkProvider.isSiteAdmin().then(function (admin) {
            if (admin === true) {
                    function () {
                    function (message) {

The module containing the provider is registered when the new Angular app is created. In the configuration function, the provider is injected using the identifier jsLinkServiceProvider. Inside the configuration function, the isSiteAdmin method is called first. If the method returns true, then JSLink file is applied. In the sample code, a task list is added to a SharePoint-hosted add-in. A JSLink file containing a progress bar is applied to the list. Figure 1 shows the resulting view of the task list.

Figure 1, JSLink progress bar applied to a task list


When using the Angular framework to build SharePoint add-ins, you can choose to either rewrite existing SharePoint list functionality or make use of the OOB functionality. Rewriting list functionality allows your user to stay within the SPA framework, but results in significantly more development effort. Using the OOB functionality cuts development time, but may require the application of JSLink to support desired display modifications and data validations. Using an Angular provider to apply JSLink files to lists makes it easy to cut development time while providing the desired list functionality.

Topic: Development

Sign in with

Or register