Since the release of SharePoint Framework, it is receiving a warm reception all around. 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. Microsoft is giving more and more capabilities with SharePoint Framework and there are a lot of updates that Microsoft is posting on GitHub.
While there are many articles online which provide best practices and coding guidelines for developing server-side web parts, the idea behind this blog is to come up with some best practices during set-up and deployment of web parts created using SharePoint Framework.
Always upgrade to latest SharePoint Framework packages
As we know SPFx is still evolving and during this process, some of the releases by Microsoft come with some potential bugs which can cause major problems. Microsoft is quick to respond to such issues and they release patches with fixes. It is important to stay up to date with the latest SPFX packages.
Example of this is a recent release 1.4 which has induced a potential bug that web parts are not appearing to add within subsites. There was some buzz on GitHub about this issue and Microsoft has released 1.4.1 to resolve this issue, if you do not keep an eye for the latest releases, you end up burning midnight oil trying to understand the root cause of such issues.
Follow this link and keep your packages updated:
Find and remove the outdated packages:
If you have followed the above link then you might have observed that by running the command: ‘npm outdated’, you can see all the packages or extensions which are outdated. You should ensure that you have a plan to replace such outdated packages.
Example: SP.js is widely used by developers in the client-side code to perform various actions on SP sites. However, Microsoft suggests against its usage.
Target your App Packages Judiciously
Microsoft has given the capability of deploying app packages at tenant level, however, that might not be a good idea if you have only one tenant for the entire organization. Normally on the server side, developers tend to have different farms: one for development, one for QA and another for production. However, in SharePoint Online, it might be cost effective to have so many maintain tenants. So, you could have a different site collection for each of Development, QA, and Production. In such cases, it is still worthwhile to have App catalogs at site collection as you can leverage this feature to upgrade changes across environments.
However, if there are different tenants for dev, QA, production environments then you might choose to deploy at tenant level directly. Also, this approach should be done for third-party apps which are specifically targeted for tenant level.
User Property Pane for Configurations
Since MOSS, SharePoint gave the capability to make the web parts configurable using web part properties. In SPFx it not only supporting web part properties but allows further customizations to the property panes. Now there is an ability to add controls like dropdowns, radio buttons.
Example: You want to add a dropdown listing down all the lists/ libraries inside the site collection, it is possible to do that using SPFx.
User Office UI Fabric and Fabric React:
Although Office UI Fabric is the official front-end framework for User Interface experiences, most of the developers are used to Bootstrap. That is because Office UI Fabric is in early stages. However, below are the important benefits that one will get when moving towards Office UI Fabric:
- The experience the users get on their SharePoint customizations will be in line with User Interface of Office 365.
- There will be more and newer experiences as Microsoft is heavily investing in this.
- There are possibilities to extend this Framework and create customizations that suit the requirements of end users.
For more details: