SKILLS & TRICKS
Yes the heading says it all and i literally mean it. I am actually getting more and more concerned where we are blindly heading with SharePoint Framework without any strategy and common sense. Since its availability it has been released with a number of new versions and i am not sure for how long the developers can keep up with new features and new scenarios. Can we really always use the latest version of SharePoint Framework and keep on changing stuff we have developed? Well this post is all about what needs to be considered, analyzed and thoroughly digested before jumping to new releases.
Which Version - The Risks
Both versions, SharePoint On Premise and Online can be used with SharePoint Framework but with on premise the story is very different. SharePoint On Premise currently has only one version of framework which makes it easy to control through patch updates at farm level. I am not sure if Microsoft will release more versions for On Premise also - i hope they release them with some intervals rather then frequent monthly updates. On the other side SharePoint Online continously recieves updates and though they are compatable with older versions still you do get some nasty surprises.
Since the framework uses a toolchain with dependency tree and also third party inherent using Node based development stack - if you update one package then it could trigger updates on other packages. This can be a pain if it turns out uncompatible with other packages in your solution. I haven't come across much people who have given me a valid reason for updating the solution to latest framework and in most cases i have seen people try to fix messed projects.
Know the SharePoint Framework Solution before Deploying
Usually when you deploy the package to your app catalog, these scripts will be copied to a document library in your tenant.
Developers can specify if the solution requires access to resources with Azure AD and they can use Microsoft APIs or any other third party application being run in the organization. If the solution does not specifically request for access to API then it does not mean its not using them. Please remember permissions granted means, allowing the scripts deployed through SharePoint Framework packages as well as all arbitrary scripts that your users might embed on their pages. This is why you should be very careful what APIs you allowed to be used in your tenant. One scenario which i have come across is regarding scripts which were not included in the solution package by the developers. Meaning, its hosted somewhere else and this leads to a number of additional questions.
Some more point which i feel we should emphasize is to know:
Office 365 CDN and SharePoint Framework - CLIENTSIDEASSETS
If you have the Office 365 CDN enabled in your tenant, files deployed from SharePoint Framework packages, will be automatically served from the CDN, which simplifies the deployment steps even further. By default, the Office 365 CDN is disabled. You can easily enable it using the Office 365 CLI or the SharePoint Online Management Shell.
o365 spo cdn set --enabled true
To see the available origins using the CLI, execute:
o365 spo cdn origin list
SharePoint will create :
Now at times, for some reason the */CLIENTSIDEASSETS origin is not configured, you won't be able to use your SharePoint Framework solutions. Amazingly you will never be prompted for any errors and left wondering why you are unable to add a client side web part. So how to fix it?
To add it using the CLI, execute:
o365 spo cdn origin add --origin */CLIENTSIDEASSETS
SharePoint Framework relies on static assets and optimizing how they are loaded, can help you significantly improve the performance of your application.
With a few lines of code to connect to SharePoint APIs you can do the following and much more - it should be enough to raise some eyebrows: