Introduction
When we start working with SharePoint, it does not take a single minute for us to recognize the capabilities of the web app that we use. These web apps are not just for making the UI attractive, but they are full of capabilities which allows you to improve or enhance the efficiency as well as the capabilities of your SharePoint Environment as well.
While talking about webpart you must have also heard about SharePoint Framework or SPFx along with it. And that’s because SharePoint Framework is a page/model which is used for building customizations or client-side development on the SharePoint platform. The SharePoint Framework or SPFx provides full support for client-side SharePoint development, easy integration with SharePoint data, and extending Microsoft Teams along with the capabilities of integration with third party apps and sites with the help of various web services. With the SharePoint Framework, you can also use modern web technologies and tools in your preferred development environment to build productive experiences and apps that are responsive and mobile-ready.
Going forward in this blog we will have a small introduction with the SharePoint Framework.
What is the SharePoint Framework?
The SharePoint Framework or SPFx is a development model that is currently recommended by Microsoft for the customization and extensibility of the clients SharePoint environment. It is a framework SDK and API contract for developers who want to customize their SharePoint implementations by creating webpart, extensions, application customizers, etc. Now we are going to look into some of the key features of the SharePoint framework or SPFx.
Key features of the SharePoint Framework
Client-side customization framework
The SharePoint Framework model is entirely client-side, this means that all customizations are implemented in JavaScript (TypeScript) and CSS and therefore are executed in the browser which the client is using. Previous development models which were used to create webapps, extensions, etc. usually relied on server-side component these not only became obsolete from their usefulness but were also a reason for customers to face issues and extra efforts while migrating to new versions of SharePoint and from on-premises to SharePoint Online.
JavaScript injection
SharePoint provides one of the most popular web parts named as the Script Editor. In this webpart you can add JavaScript to the Editor and have that JavaScript execute when the page renders. It is simple to use and implement yet very effective. It runs in the same browser context as the page, and is in the same DOM, so it can interact with other controls on the page.
But using the Script Editor webpart there are a few downsides as well. First, while you can package your solution so that end users can drop the control onto the page, you cannot easily provide configuration options. Also, the end user can edit the page and modify the script, which can break the web part. Another significant problem is that the Script Editor web part is not marked as "Safe for Scripting". Most self-service site collections (my-sites, team sites, group sites) have a feature known as "NoScript" enabled. Technically, it is the removal of the Add/Customize Pages (ACP) permission in SharePoint. This means that the Script Editor web part will be blocked from executing on these sites.
To overcome these downsides SPFx comes into limelight and overcoming them all. You can exclusively add these webpart to your page without facing the issue of JavaScript disabled or the security downside of users editing and breaking these webparts.
SharePoint Add-in model
The NoSript implementation creates an iFrame on the SharePoint page where the actual experience resides and executes. A huge advantage of this is that because this is external to the SharePoint or the system it has no access to the DOM/Connection so it is easier to deploy and provide access to and the End users can install add-ins on NoScript sites.
The downside to this approach is that they run in an iFrame and the iFrames are slower than the Script Editor web part because it requires a new request to another page. Then the page must go through the complete authentication and authorization, make its own calls to get SharePoint data, load various JavaScript libraries, and more. A Script Editor web part might take a fraction of time which an app part might take. Additionally, the iFrame boundary makes it more restrictive when it comes to creating responsive designs and inheriting CSS and theming information. But iFrames have stronger security, which can be useful for you and for the end user.
But using the SPFx we can create the web parts which can be added to the page as an app, and just like an app all the processing is done in the background without many hassles of the authentication as it will use the user’s context to execute which makes it secure in its own ways.
Conclusion
The SharePoint Framework has been introduced by Microsoft to allow users customizability and more control over the efficiency and the SharePoint environment that they use. This framework also can overcome all the shortcomings of the previous option that Microsoft introduced to create and add custom solutions to the SharePoint. We can use the SharePoint Framework (SPFx) to our benefit and the benefits of our users.