SharePoint Development with SharePoint Framework

This is a four-part blog, and we will be exploring SharePoint Development with SharePoint Framework.

• Overview of SharePoint Development
• SharePoint Framework (SPFx)  Development Environment Setup
• Your First SPFx WebPart
• Developing apps for Teams using SPFx

PART ONE

Overview

Previously in SharePoint, we had the content editor webpart, which was used to inject scripts or HTML Content on the pages. But the content editor had a problem; if you inject scripts or HTML directly, it will change the code you entered, or sometimes it would not even run, and sometimes it would give an error.

Due to these issues, two advancements were released; first, the  Script Editor, which allows developers to add scripts into a page in SharePoint. You can as well add HTML Content and link your styles, scripts, or images from the Site Assets.

But the Script Editor has its challenges, which can primarily affect development time. For instance, the Script Editor interface is tiny text-area; therefore, looking for a specific section of code to edit is a huge problem. Additionally, you might get an issue with the Script Editor web part not showing or is missing in SharePoint Online Office 365, and one is required to change some settings at the tenant level; this can be a hustle. Lastly, code re-using is difficult, and one ends up with long lines of code that could have been achieved with just a few lines.

Secondly, SharePoint Add-ins. One most useful advantage of SharePoint Add-ins is that it has no access to the current DOM or connection. Also, it is external to the system. Because of this advantage, the End-user can easily install the “Add-ins” on the No-script sites and use it. SharePoint Add-ins runs in the iFrame. Iframes are slower than the Script Editor WebPart. IFrame has more robust security, which can be very useful for the end-users. That means the control has no access to their connection to office 365.

To overcome these issues, Microsoft comes with the SharePoint framework development model. And in SharePoint Online modern experience, we can use only the SharePoint framework for SharePoint web part development.

SharePoint Framework

SharePoint Framework (SPFx) is a page and a webpart model that provides full support for Client-Side development, amazingly comfortable, and smooth integration with SharePoint data and excellent support for open source tooling/ plugins/ libraries. It supports the use of modern web technologies and tools such as ReactJS, Angular, KnockoutJS, or Just JavaScript without any Framework. You can work on your preferred development environment such as Visual Studio Code to build responsive applications faster and quicker. SPFx works for both the SharePoint On-Premises and SharePoint Online.

Key Features

1. JavaScript is embedded directly into the page; therefore, there is no need for the use of iframes.
2. SharePoint Webparts can be added to both modern Pages and the classical Pages.
3. SPFx is Framework-agnostic, giving the developers the ability to use any JS Framework, common ones being ReactJS, AngularJS, and KnockoutJS. 4. It runs in the context of the current user and the connection in the browser.
4. End users that are approved by the tenant administrator can use SPFx on all sites, including Teams Site, Group/Personal sites, etc.
5. Develop for Teams

Benefits of using SharePoint Framework

1. SPFx is safer

SharePoint Framework development is based on JavaScript running on the browser, making REST to SharePoint and Office 365 backend workloads, and does not touch the internals of SharePoint.

2. Modern Development Tools

You have a broad category of tools to choose from, such as NodeJS, Angular, ReactJS, KnockoutJS that make development fast and more accessible. JavaScript is embedded directly to the page, and the controls are rendered in the standard page DOM. SharePoint is JavaScript framework-agnostic, and the toolchain is based on standard open-source client development tools such as npm, Typescript, Gulp, Yeoman, and webpack

3. Mobile-First Design

Because SharePoint Framework customizations run in the context of the current page (and not in an IFRAME), they are responsive, lightweight, accessible, and mobile-friendly. Mobile support is built-in from the start. Content reflows across device sizes and pages are fast and fluid

4. Simplified Development

There is some work to do at the beginning of a new project to set up the SPFx structure to support reading from a remote host. An App Catalog must be created, as well as generating and uploading a manifest file. If the hosted content is connected with a CDN (Content Delivery Network), that will also require setup. However, once those structural pieces are in place, deployment is simplified to updating files on the host location. It does not require traditional code deployments of server-side code, with its attendant restrictions and security review lead time

5. Smoother integration with external data sources

With SPFx, calls to data from external sources may be more comfortable since it’s web content hosted outside of SharePoint

This marks the end of Part 1. I hope the overview of SharePoint Development has been informative, and you will be ready to setup your SharePoint Framework Development Environment in the next post.