ROBERT SCHOUTEN

As posted in my previous blog post, I have been playing around with the PnP starter kit. For a client I wanted to use some of the web parts and extensions as a basis. I particularly mention basis, because the PnP starter kit guidance documentation states the following:

Notice that this script also adds tenant level settings like themes, site designs, taxonomy term sets, and other adjustments. Therefore, it is recommended to test the script in an isolated test tenant and not immediately execute it within your production environment. Nevertheless, a cleanup script will come shortly.

Next to this the starter kit solution requires your tenant to be a Targeted release tenant. My client doesn’t have their production tenant in a Targeted release option, so using the solution as is, is not an option.

Kick start

The PnP starter kit can give your project a good kick start. The solution addresses common scenarios and tasks you may encounter when introducing customizations, and provides examples and guidance on how you might address them including:

• Automated provisioning of simple demo content within a communication site
• Automated provisioning of the whole solution to any tenant within minutes
• Automated configuration of Site Scripts and Site Designs at the tenant level using the PnP Remote Provisioning engine
• Implementation of different customizations for SharePoint Online
• Usage of Office UI Fabric and reusable PnP SPFx controls within the customisations

Optimisation

The different customisations within the solution gives you good insights in the different configuration options you have. For instance how to hold list data within your web part, instead of using a SharePoint list. Both options have their pros and cons, so it is alway good practice to change it to your own needs. If your list data needs to be secured for certain editors, who don’t have permissions to edit the page where your web part lives, a SharePoint list could be a better option. So optimising your customisation is always a good consideration.

Next to this, having several web parts and extensions within your solution, also means you have to look into your bundle sizes it produce when bundling and packaging the solution. There is some good documentation on the Microsoft docs site on how to implement this within your SPFx solutions and what to consider.

When I was using some of the starter kit web parts and building my own, I followed the above documentation. Using the Webpack bundle analyzer within your bundle process, will give you an output html file with statistics about all the bundles your solution contains. It will give you the as well the normal output size and the Gzipped size as will be served within your browser:

Above image shows the 4 bundles within my solution. The Feedback button application customizer bundle output size is almost 390 Kb big. A big chunk of the bundle is taken by the @PnP and the Office UI Fabric React packages. The @PnP (PnP-js) is used in the Navigation links web part too. Both customisations will be used together on a page pretty often, so having the @PnP package within both bundles isn’t a very good choice.

Externals

The SharePoint Framework (SPFx) has the opportunity to load packages as an external package, instead of bundle them within your customisation itself. The config.json within the config folder in your SPFx solution contains an externals section:

"externals": {

"@pnp/sp": "https://cdnjs.cloudflare.com/ajax/libs/pnp-pnpjs/1.1.0/pnpjs.es5.umd.bundle.min.js"

},

I have put the @pnp/sp package in the Externals section pointing to a CDN location. During the bundling process the @PnP package will excluded from our bundles and the CDN location will be used. Doing this will almost takes half of the bundle package size:

Next to the @PnP package, the Office Ui Fabric React and @uifabric packages take up a big chunk of our packages. I haven’t found a good way to load those packages as external packages. If you have any good suggestions here, I would be very grateful if you could leave a comment below!

Tree shaking

Webpack, which is used in SharePoint Framework solutions for packaging and bundling your solution, has build-in support for tree shaking. Tree shaking will detect which parts of used packaged should be included into the output bundle. This will shrink the eventual bundle size. Next to tree shaking it is a good practise to only import the parts of packages you would like to use within your customisations. Consider below imports:

import * as _ from 'lodash';

This will add 527 Kb to your package. When you only want to use the at module of lodash, you should only load this module:

const at: any = require('lodash/at');

This will only add 45 Kb to your bundle.

Summary

Using the PnP starter kit as is on your production tenant isn’t a very viable option. At this moment it requires a tenant with Target release option. Most production environments I see, doesn’t have the Target release option. Next to this it is always a good practice to reconsider customisations, if you get them from open source projects. It could be that it won’t fit exactly to what you want to aim with your customisation. Further more it is good to optimise the output bundles of your solution package. Loading certain used packages from an external CDN location could be a good option in certain circumstances. Certain when you use the same package in other customisations in your solution and use them at the same page. I haven’t found a way to load the Office UI Fabric React as an external package yet. I have read some blog posts stating it isn’t possible in the way the package is build up at the moment. If you have any suggestions on this, please leave a comment below!