SharePoint Framework & Angular Elements : Mocking your data

You now have access to data directly in your browser! It's amazing and that will make you successful building great experiences to your connected data within SharePoint! Though, I really think that one of the most amazing pieces of the SharePoint Framework is to be able to test and execute it in a local environment. To support those scenarios, it is important to be able to give a representation of your data to simplifying the development experience. This blog post is all about mocking your data using the Angular mechanisms.

Angular Elements and SharePoint Framework are still in their developments. This codes is based on pre-release of Angular Elements and a very "rough" integration with the SharePoint Framework. I am still pushing those samples so you can start playing with the technology. Please don't use any of this in production as of today. I will update the posts and code when better support will be offered by both Angular and SharePoint Framework.

This post is part of a series of post on integrating the SharePoint Framework with Angular Elements

Build the Service(s)

A concept that is important in Angular is the ability to inject Services in several Componets. Those services may have the responsibility drive the connection with external data. It keeps all the data layer logic within it and acts like a proxy to your data. This service will be the key to our mocking (and real data) implementation.

We will deploy two different instances of that service. One that will connect to actual data and the other one will generate a set of predefined data for testing / development purposes.

At the root or your src folder, create a folder called services and create 2 sub-folders; One named interfaces and the other one mock. The first file to build is the interface that will instruct all the different services what are the necessary options and actions available on that service.

Then we will create the actual data service that will connect to the SharePoint data. We will use the exact same method we used in our first sample where we connected to SharePoint to get the set of lists available on the site but we will wrap this call in a simple method. We will make sure it inherites from IListsService so all calls will be standard. Note the @Injectable decorator on the class: This will be the key to inject it wherever we want, when we need it in our Angular application.

To finish with the services, we will build another service that will inherit from the same IListsService but will return dummy / static data.

Injecting the service

In our main Component class, we will need to tell Angular that we will want an instance of the Service on every new instance of the Componet. By leveraging dependency injection, we will be able to add a new parameter to our class constructor and magically, this service will be available in the methods of our class!

Switching from real data to mock data

In our scenario, we see that the code will always refer to the ListsService class. This simplifies a lot the code so we don't have to switch everywhere based on context. To enable the MockListsService to be loaded when we are in development / testing mode, we will use a provider that will dynamically bootstrap the appropriate Service based on the context. In our case, if we are running in the local SharePoint Workbench, we will use the MockListService and for any other use case, we'll use the real implementation.

Run your webpart

Once your Web Part is ready, you can finally run it using gulp serve and see the result directly in your SharePoint Workbench! Test is by comparing it using the local SharePoint Workbench and the hosted SharePoint Workbench. You will see the difference right away!


Now that you can run your webpart using the local SharePoint Workbench in a fully offline mode, you will be able to move on and build more complex scenario!