ESPC17 Day 1 – Pre-Conference Workshop ‘Advanced SPFx Development’

Article Series: European SharePoint Conference 2017

1. ESPC17 Day 1 – Pre-Conference Workshop ‘Advanced SPFx Development’
2. ESPC17 Day 2 – Conference Started
3. ESPC17 – Discussions in Between
4. ESPC17 Day 3 – All In

This year I am attending the #ESPC17 the first time (okay I mean you can only attend once the ESPC17 but multiple times the ESPC ;-)) in Dublin. And it is already awesome. Besides the fact, that I arrived on Sunday already, I got myself a renting car with an old colleague living here and we went to Glendalough in the Wicklow Mountains National Park. Anyway back to the main goal of this post.

I attended the pre-conference workshop Advanced SharePoint Framework Development which was hosted by Eric Overfield and Waldek Mastykarz. They gave us a nice overview with the following agenda

1. Optimize your development environment
2. Connect to APIs
3. Building SPFx solutions – past the basics
4. Optimize solutions for performance
5. Application Lifecycle Management – Packaging
6. Application Lifecycle Management – Logging and Team Development
7. SPFx for SharePoint Online vs SharePoint On-premises

I will go over each topic. I will point out topics a bit more, where I was more interested in.

Optimize your development environment

The main problem with npm, nodejs, and all the connected packages is the version-jungle that can exist. You have different environments, different versions with different customer and needs. Furthermore, SharePoint 2016 supports only a subset of functions for SPFx compared to SharePoint Online. An environment for SPFx must be convenient, intuitive and should support multiple version of SPFx.

Docker to the Rescue

You could use Azure VMs, but who wants to pay and maintain all those different VMs? You don’t, right? Me neither!
The main idea is to use docker. What docker can do is to get rid of the OS part. You only care about your tools and which version you want to use. With that, you can switch between versions easily without worrying messing up your dev environment.

Connect to APIs

This chapter was generally more or less explaining how you would connect to the different APIs (Graph API, SharePoint REST API). Eric recommends to use the @microsoft/sp-http npm package to have helper classes to make it easier for you to communicate SP, Graph or any restful service.

Since the local Workbench of SPFx does not have any SP context, you should think about creating interfaces which can be used by mockup data providers and with the productive APIs in your applications.

export interface ISPList {
  Title: string;
  Id: string;
}

They then went quickly over examples of all CRUD operations, which can be reviewed in the official documentation anyway. But since TypeScript is used, every developer should make use of the provided Promise type in TypeScript.

For using Graph, they recommend using @microsoft/sp-http because it has a specific helper class for the Graph. But this is still in developer preview! Or the suggestion that developer could also wait some month since tenant admin driven control of SPFx Graph token is going to preview by end 2017 (which was announced on the 9th of November JS SIG call by Vesa Juvonen).

Especially for LoB (Line of Business) REST services the mentioned class could be useful. This is especially interesting since my current company (Schindler) is planning and building a set of LoB web services and a framework to guide other departments to use our standardized tools. This could make it much easier. There is also a webcast mentioned on calling external APIs securely.

Building SPFx solutions – past the basics

I go only briefly over this since this is a pretty good documented topic. This topic didn’t give you basics but talked mainly about SPFx web part properties and how to use them. More interesting was the fact of indexing web part properties and make them available for search.

“By default, SPFx web part properties are not processed by SharePoint Allow properties to be indexed by overriding propertiesMetadata”

You can also specify the content of the properties (text, link, image or HTML), which then influences how the content is treated. Cool side note:

If you specify the property as “isLink”, “isImageSource” or “isHtmlString” you get automatic link fixes. This means when the linked file (only files saved on SharePoint) is moved or renamed, you don’t need to fix the links in the web parts. This is due to a hidden field that saves the information about all links that go to that file. And when the source file is changed, information gets updated in that field.

Also, they talked about Office Fabric UI and to use it. Yeah, that’s kind of “duh” moment for me. Developers can’t create nice UI. So use this to be able to!

And of course, Extensions was also a topic and how to use them.

Optimize solutions for performance

They mainly talked about using CDNs, externalize libraries in your web parts and cache data. When we talk about referencing libraries outside of your app, this means that you should not include libraries like Angular or React in each web part, but to exclude it in your build and reference it externally. Waldek and Eric had different opinions on those. I would summarize the short discussion, but I can’t memorize the full argument of Eric. So it would make no sense to point that out again.

If somebody remembers both arguments, give it to me and I include this.

Basically, if you use a CDN you have potentially the following options to improve performance of serving files

• Set far-future expiration (eg. 1 year)
• Allow proxies to cache
• Use HTTP/2
• Enable dynamic compression

Unfortunately not all for the public O365 CDN, which limits expiration to 1 hour and does not allow dynamic compression as well as HTTP/2.

Application Lifecycle Management – Packaging

They compared tenant wide SPFx deployment versus non-tenant-scoped deployment. There are advantages and disadvantages for each and it must be chosen wisely.

• Tenant scoped webpart – the webpart is now available across tenant but does not offer ability to deploy anything else, such as a list or other assets
• Tenant scoped extension – is available on each site, but not auto activated. Cannot install other assets. Activated via API, such as pnp PowerShell. Can then set parameters, customizing to each instance.
• non-tenant webpart – must be activated on each site, can also include other components
• non-tenant extension – can be activated via UI now, but parameters are hardcoded to each instance. Could also install additional components

They also mentioned on doing so-called “Structured and repeatable deployment” and talked about deployment possibilities, that will be announced later this week on a keynote by Vesa Juvonen. but I am sure that this is the ALM-APIs they are implementing.

Application Lifecycle Management – Logging and Team Development

This one gives possibilities on how to develop in the real world in respect of best practice ALM. First SPFx and SharePoint Online do have no or very bad logging functionality. What they suggest is to use Application Insights with a provided JavaScript library. For us, there is a general problem. To target the right logging target in Azure, you need to initialize the JS library with the right GUID for AI (Application Insights). We at Schindler want to standardize this so that other departments with their own potentially hired consultancies can still use the logging solution without giving this GUID. So the idea was to wrap the AI REST web service together with the GUID. I discussed this with Waldek and he mentioned that this is not a big problem, since there are not many commands that need to be wrapped. And together with Azure APIs, you are even able to make this API publicly secure and connect it with OAuth and your Azure AD.

Tada, problem solved by having a global centralized logging solution which is secure in Azure. And AI is free for use and saves logging for 3 months. If you need it longer than 3 months, then you create a storage in Azure. With that, you can save it for a longer time and even process stats with Excel or Power BI.

SPFx for SharePoint Online vs SharePoint On-premises

The main point was, that there are some problems in different versions for SPO and SP 2016. Mainly the SPFx supported version, which is in SP 2016 currently the yeoman sp template version 1.1. For SPO it is always the latest published version. But to not confuse companies and to not use different template version, they created one template which includes always both versions. In the project setup, you would then always choose if you plan to use it only online or also for on-premise.

Conclusion

Overall it was a packed workshop. Friends and colleagues of mine who attended other workshops said, that it was pretty lightweight. I mean a lot of the topics I also knew about SPFx, but both presenters managed to make it entertaining and packed their own experience and small tips into the presentation. This made it very worthwhile. the small tips are very useful since you don’t get them usually from a generic tutorial on the official documentation.

So thumbs up!

I gave 10/10 for the presenters and their style and 8/10 for the content. Keep the good work up!