Best Practices in SharePoint Framework (SPFx) Development The Definitive Guide

Best Practices in SharePoint Framework (SPFx) Development – The Definitive Guide

Table of Index 1. Introduction

2. What is SharePoint Framework (SPFx)?

3. Best Practices for SharePoint Framework (SPFx) Development – Saving dependencies & Lock down dependencies – Use CDN for your file assets – App Package Deployment at Site Collection Level – Stay up to date with the latest SharePoint Framework (SPFx) packages – User Office UI Fabric and Fabric React 4. Conclusion

Quick Summary: With the SharePoint Framework (SPFx), you can incorporate modern development techniques to create fast, responsive components.

Microsoft is giving more and more capabilities with SharePoint Framework and there are a lot of updates that Microsoft is posting on GitHub. SharePoint developers, who are familiar with the development of server-side web parts are now increasingly adapting to this new Page and web part model framework.

Introduction SharePoint Framework is the latest development methodologies used for SharePoint customization and now also used in customization in Microsoft Teams. Microsoft is moving forward with modern experiences and provides greater flexibility and performance for end users and developer with SharePoint Framework. Using these guidelines will avoid for any disparity and will strengthen the performance of the solutions.

Best Practices for SharePoint Framework (SPFx) Development Following best practices which you need to remember for while developing SharePoint Framework (SPFx) projects.

Saving dependencies & Lock down dependencies

Once you have found the package you want to include in your project, you have to install and save it.

The best practice is to install with: npm install –save npm will save your dependencies with the ^ prefix by default. It means that during the next npm install the latest module without a major version bump will be installed.

If you do not save your dependencies, then the situation can easily become problematic for production deployments. It’s possible to have different versions locally than on production. In the meantime, if someone just released a new version, the problem will arise, when this new version has some bug which will affect your production system.