Presentation deck – Pitfalls in SPFx development

This is post 1 of 2 to publish the slide decks for presentations I’ve given recently, in particular at the European SharePoint Conference 2017 held in Dublin. See also:

Presentation deck – Best bits of Azure for the Office 365 Developer

Unfortunately, I never think the slide deck alone conveys all of the information of a conference session, since it’s the demos which are often the most valuable part. Still, I try to assemble slides which have useful reference information, so hopefully this will be useful to someone. The full slide deck is embedded from SlideShare at the bottom of this post. The main topics I discuss here are:

• Versioning and dependency issues
• The need to ensure you use --save or --save-exact when adding libraries with npm install (so that they are recorded in your package.json file, and other developers on the team can successfully build from source control)
• Semantic versioning, including caret and tilde symbols in version numbers
• The need to run npm shrinkwrap for each release of your code
• [NOTE – some of this changes in npm 5, which automatically does a --save when doing an install, and also automatically generates a package-lock.json file (similar to npm-shrinkwrap.json. But for now, npm 5 is not officially supported in the SharePoint Framework (SPFx) and so these points remain important)
• Re-use of existing JavaScript code
• You might choose to wrap such code in a module if it is not already – this provides a more formal method in TypeScript/JavaScript of sharing code (e.g. library code)
• Once you have a module, you can look at options such as npm install [filepath], npm link or using a private hosted npm repository provided by npm private packages or Visual Studio Team Services Package Management
• Office UI Fabric
• Use of Fabric Core and the Fabric React components – using the Core styles is much simpler in version 1.3.4 onwards of SPFx, where the sp-office-ui-fabric-core package is referenced and the SCSS styles use mixins to reference the styles in your custom styles
• When using the Fabric React components, you should typically ensure you use static linking in your import statements e.g. import { Button, ButtonType } from 'office-ui-fabric-react/lib/Button';
• See Using Office UI Fabric Core and Fabric React in SharePoint Framework for more information on this
• Calling the Microsoft Graph and/or custom APIs (e.g. an Azure Function)
• All of these resources are likely to be secured with AAD
• GraphHttpClient is currently of limited use..
• ..so you will most likely need adal.js if calling from the client side, or ADAL.NET if calling from the server side
• An alternative to adal.js for a custom web API/Azure Function, is the approach which leverages the SharePoint Online authentication cookie to pass credentials to your API (using the “credentials”: “include” header to pass across domains) – I think this is a useful approach and one of my demos covered this (video at https://www.youtube.com/watch?v=Nz9Q8TDgYtk&t=5s)
• I use this slide to give an overview of the two approaches:
  
  
  
• Also note that soon, it will be possible to call your custom APIs by specifying additional AAD app registrations that can be called from SPFx without additional consent. This will simplify things significantly, and mean that your SPFx web parts/extensions will no longer need a sign-in button/process just to be able to call downstream resources
• Deployment
• Remember that the default SPFx behaviour is for any 3rd party libraries you add to be bundled into your web part – this increases your bundle size, and can be a particular problem when you have multiple web parts/extensions all using the same library (and Office UI Fabric can be a big culprit here!)
• Another “by default” thing to remember is that each web part/extension you build gets it’s own bundle – the config.json file is what controls this
• Where possible, 3rd party libraries should be externalised to a CDN..
• ..and if that isn’t possible, consider SPFx component bundles as a way to avoid having a library duplicated amongst all your web parts. In the case where you have 5 web parts on a page all using the same library, if you don’t externalise or use component bundles performance will suffer for first-time page loads

Hopefully there’s some useful information in here, and I’ll most likely expand on some of these points in future articles. Here’s the slide deck:

Slide deck:

Chris OBrien - Pitfalls when developing with the SharePoint Framework (SPFx) from Chris O'Brien