Be Careful with SharePoint Framework

​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

​SharePoint Framework solution only contains JavaScript code which runs on the browser and they are deployed through the app catalog just like SharePoint Add-ins but we must always remember that they run unrestricted. This means, SharePoint framework solutions have unrestricted access to the information and APIs in your tenant - wherever the user has access so does the solution. Make sure all the documentation and details you have received with the solution are up to date and take the liberty of verifying it as i am sure you will find some stuff missing from it. Depending on the nature of your solution and organizational requirements you might have to adjust or change the deployment of the solution on certain sites. There are so many JavaScripts libraries available on the internet, that developers can use in their solutions. While using an existing library enhances developer productivity, it comes with issues and risks for the organization using the solution. Another aspect is to know if anyone else in your company is familiar with the specific Java Script library and if so then how long do you think this library will exists? 

• Where is it hosted and where is the server?
  
• Are all webparts working correctly?
  
• Who has access to files and can they be changed?
  
• Whats our agreement with the vendor? etc.
  

Usually when you deploy the package to your app catalog, these scripts will be copied to a document library in your tenant. 

Read More