Introduction

The SharePoint Framework (SPFx) is a page and extension model that enables client-side development for building SharePoint experiences. It facilitates easy integration with SharePoint data and provides support for the open Source tooling development.

Why SharePoint Framework?

Since the inception of SharePoint in 2001, a large community of the developers has extended and customized it in many ways. For the most of the part, the developer community used and followed the same patterns and practices like SharePoint XML, web parts, REST API and many more. Some features were written in C#, compiled to DLLs, and deployed to on-premise farms.

This type of Architecture works flawlessly in Environments with only one enterprise, However, it is not scalable enough to the cloud, where multiple tenants run side-by-side. That is the main reason why Microsoft has launched the SharePoint Framework (SPFx).

Key Features of the SharePoint framework include the following

• It runs in the context of the current user and connection in the browser. There are no iFrames for the customization (JavaScript is embedded directly to the page).
• The controls are rendered in the normal page DOM.
• The controls are responsive and accessible by nature.
• It enables the developer to access the life-cycle in addition to render, load, serialize and deserialize, configuration changes, and more.
• It is framework-agnostic. You can use any JavaScript framework that you like: React, Handlebars, Knockout, Angular, and more.
• The tool-chain is based on common open source client development tools such as npm, Typescript, Yeoman, webpack, and gulp.
• Performance is reliable.
• End users can use SPFx client-side solutions that are approved by the tenant administrators (or their delegates) on all sites, including self-service team, group, or personal sites.
• SPFx web parts can be added to both classic and modern pages.

Pros and Cons of the SharePoint Framework

Pros:

• Client Side: As discussed above, the server-side solutions can damage a site collection to an entire SharePoint farm when not used wisely, whereas the risk eradicates when using the client-side
• Fast, Lightweight and Responsive: SPFx uses NodeJS and is completely client side so makes it fast and mobile-ready. Also, SPFx is fully compatible with Office Fabric UI, which makes it responsive as well. Altogether, the framework is consisting of all the latest web development technologies.
• Run on User Context: Since the complete framework runs on user context, so only permissible item to a user will be shown.
• Works in Classic as well as Modern Pages: The advantages of SPFx is that it works on both modern as well as the classic page. So, either your online tenant is running on old SharePoint 2013 site collection with classic mode only or you upgraded to latest tenant feature, be relaxed, SPFx covered these.
• Custom Properties: Earlier when a user had to write client-side code, they need to create extra variables and makes fetch calls to get those configurations. But now, with SPFx this comes in a very handy way, where a user can create properties for client-side web parts and configure it as per need.
• Deployment Mechanism: With SPFx, finally SharePoint provides a deployment mechanism. The deployment mechanism consists of bundling the app, packaging the app, shipping the app to store (or to local SharePoint App Catalog) and with proper permission, one can deploy it to their tenant. This provides a better way to manage the client-side
• Scalable: As mentioned above, SPFx is not limited to SharePoint, a user can take advantages of NodeJS (the backbone of SPFx) and can use any of the component available in NodeJS by community (not SharePoint but NodeJS community). Also, with the development of Microsoft Graph API, a user can make their web part interact with rest of the Office365 including Azure, One Drive, Outlook etc.
• Remote Development: I hate most was the development environment. One must have a Windows Server OS running with SharePoint configured on it and the only development tools available was Visual Studio. This environment requirement bothers me a lot. SPFx comes with a fully client-side development approach, i.e. you can develop the component on any machine wither it runs on a Windows, Mac or Linux. And of course, you don’t need to have Visual Studio even to develop SPFx web parts, all you require is a simple text editor of your choice and you are good to go (obviously, we must install the environment though i.e. NodeJS, Gulp and Yeoman template of the framework)
• Local Workbench: Even if you are not connected to the internet, don’t worry, you can still develop on SPFx as it comes with a local workbench. The local workbench is capable of developing and testing the client-side web part.
• Security: The client-side web parts code is secured and one cannot easily extract your business logic or code using browser inspect or a page source.

Cons:

• Everything is client side: Since everything is client side, creating business-critical web part using SPFx is not what one must prefer. The client-side web parts are easy to reverse engineered and one can easily extract your business logic as its all JavaScript at the end of the day.
• New Environment: For classic SharePoint developers (i.e. majorly worked on Farm Solution, C# client object model only), it’s a completely new thing. Starting from NodeJS to Typescript to Webpacks, to gulp everything will be new to classic developers.

Introduction of web parts and Extension

There are mainly two types of the SharePoint Framework Development approach, which are given below.

1. SPFx Web Parts
2. SPFx Extension

SPFx Web Parts

SharePoint framework client-side web parts are controls that appear inside a SharePoint page but run locally in the browser. We can build client-side web parts using modern script development tools and the SharePoint workbench (a development test surface), and we can deploy our client-side web parts to modern pages and classic web part pages in Office 365 tenants.

In addition to plain JavaScript projects, we can build web parts with common scripting frameworks, such as AngularJS and React. For example, we can use React along with components from Office UI Fabric React to quickly create experiences based on the same components used in Office 365.

SPFx Extensions

SharePoint Framework Extensions enable us to extend the SharePoint user experience within modern pages and document libraries, while using the familiar SharePoint Framework tools and libraries for client-side development. Specifically, the SharePoint Framework includes three new extension types, which are powerful enough to extend the SharePoint functionalities.

• Application Customizers: Add scripts to the page, and accesses well-known HTML element placeholders and extends them with custom renderings, they are the Content Editor and the Script editor of the Modern sites.
• Field Customizers: Provides modified views to data for fields within a list with this solution we can build some extensive services like the data or fields view and modify the existing views.
• Command Sets: Extends the SharePoint command surfaces to add new actions and provides client-side code that you can use to implement behaviors.

We can build extensions alongside common scripting frameworks, such as AngularJS and React, in addition to plain JavaScript projects. For example, we can use React along with components from Office UI Fabric React to create experiences based on the same components used in Office 365 and lot more.

If you want to know more about SPFx part 2 please follow below link:

https://blog.dodhia.co/sharepoint-framework-spfx-custom-branding-for-modern-sites/