Mastering Sharepoint Framework

CHAPTER 1

Getting Started with the SharePoint Framework

SharePoint is evolving over the years. The SharePoint classic experience was introduced in late 2002. Since then, Microsoft continued adding new features on top of it. However, around the year 2017, Microsoft rolled out a new ‘Modern’ SharePoint based on new modern up-to-date web technologies. Modern SharePoint appeals to users with a fresh look and new modern experience, which is designed using modern web technologies. Itworks responsively on mobile devices and provides overall usability features.

Structure

SharePoint Evolution Across Versions

Birth of the SharePoint Framework

Key Features of the SharePoint Framework

Script editor web part vs App part vs SPFx web part

Lightweight Components/Tools Used

ALM of the Client-side Web Part

Setup the Developer Environment for SPFx

Objectives

Get introduced to Modern SharePoint customizations using the SharePoint Framework

Overview of the SharePoint Framework (SPFx)

Understand the SPFx Toolchain

SharePoint Evolution Across Versions

Before we deep dive into Modern SharePoint, let us look back in history to see how SharePoint has evolved over time. SharePoint 2007/MOSS supported the full trust server-side development. Over the years, the focus of development gradually shifted from server side to client side. Server and client-side development have their own advantages and limitations.

The following diagram shows how SharePoint has evolved across the versions:

Figure: 1.1: SharePoint evolution across versions

SharePoint 2007: Full Trust Farm Solutions

In the days of MOSS, custom solutions were developed using ‘Full Trust’ or ‘Farm Solutions’, which supported the packaging and deployment of SharePoint customizations. The development approach was known as the SharePoint solution package, which bundled native .NET code and files with a .wsp extension. It containeda set of custom web parts, web templates, timer jobs, event receivers, etc. written in server-side languages like C#.

The server-side code had full permissions on the SharePoint farm. The SharePoint solution packages were formed using features, which could be turned on and off on SharePoint sites. One or more features were packaged together and deployed to SharePoint at various defined scopes like a farm, web application, site collection or a single site.

Full trust farm solutions enabled developers to customize or extend SharePoint as per business demands. As the code runs directly within the SharePoint server, the poorly designed code can affect the performance negatively, which might affect each and every application running as part of that SharePoint farm.Full trust farm solutions had imposed security concerns and risks as they had full permissions on the SharePoint farm.

SharePoint farm solutions are still supported for all SharePoint on-premises versions from 2007, 2010, 2013, 2016 and 2019. However, from the future compatibility perspective, it is not advisable to build SharePoint farm solutions.

Θ Note

A point to note that SharePoint solution packages (.wsp) are not supported in SharePoint online.

SharePoint 2010, SharePoint Online: Sandbox Solutions

Sandbox solutions are considered a subset of the farm solutions code development model. Sandbox solutions are more targeted to the specific site collection in

SharePoint. It enables an individual site collection administrator to install and maintain custom solutions without the involvement of a farm administrator. Sandbox solutions had access toa limited subset of APIs, name spaces within the server-side object model and Microsoft .NET Framework 3.5 assemblies.

Later, Microsoft introduced the new SharePoint app model and eventually deprecated the use of custom managed code within the sandboxed solution. The app model was commonly used instead of a Sandbox solution managed code scenario. To start with the deprecation cycle, only the declarative markup in the form of XML and JavaScript was allowed in the Sandbox solution, which was famously known as no-code Sandboxed solutions (NCSS).Over time, all types of sandbox solutions were deprecated.

SharePoint 2013, SharePoint 2016, and SharePoint Online: App/Add-ins Model

The app model offers more flexibility and decouples SharePoint from the app runtime. It gives the ability to run the code in the external environment of your choice (e.g. IIS web site or MS Azure Web Apps). It is mainly supported by two types of deployment models, namely, SharePoint-hosted and Provider-hosted.

The SharePoint-hosted deployment type represents a way to deploy client-side, lightweight apps to SharePoint which contains no server-side components. They use SharePoint’s data structure, including the separate subsite (called as AppWeb) and the actual SharePoint site (called as HostWeb). The user interface had to be built using CSS, HTML, and JavaScript. All assets were hosted within AppWeb to avoid cross-site scripting attack, thus providing more security.

Provider-hosted add-inshas server-side components contained within an ASP.NET application and you need to provide a separate environment to host them. This solution provided an approach to run the custom code outside SharePoint.

The add-ins infrastructure is clunky and relies heavily on JavaScript and asynchronous REST API calls/client-side object model calls to interact with the associated SharePoint context. The Add-in runs in a separate iframe. Even as of today, the add-ins model is supported; however, it did not progress much in the past few years.

Birth of the SharePoint Framework

The SharePoint custom development gradually shifted from server side to client side with the introduction of the client-side object model from Microsoft, which allowed you to connect to the SharePoint site remotely. Managed Client-Side Object Model (CSOM), JavaScript object model (JSOM), and REST APIs were being used effectively by SharePoint developers to carry out the customizations.

However, excessive use of JavaScript across the SharePoint sites (inside Script Editor or Content Editor web parts, custom actions) became unmanageable. Modern SharePoint does not support direct injection of JavaScript on the SharePoint site. The customizations are only allowed using SPFx web parts. An introduction to theSharePoint Framework brought in governance around this issue.

Θ MSDN definition

The SharePoint Framework is a page and web part model that provides full support for the client-side SharePoint development, easy integration with SharePoint data, and support for open source tooling.

How SPFx is different?

The SharePoint framework is different from the classic JSOM development in many areas. Here are a few key points on how SPFxisdifferent.

Modern toolchain/Open source tooling

SPFx supports open source tooling and modern toolchain, including Node.js, npm, Yeoman, Gulp, TypeScript, and so on.

Easy integration with SharePoint data

We can implement REST API wrapper classes for easy integration with SPFx.

Available in Cloud and On-Premises

SPFx is generally available in SharePoint Online. It also supports On-Premises from SP2016 onwards. Please note that in order to start using SPFx in the SharePoint Server 2016, you will need to install ‘SharePoint 2016 Feature Pack 2’on the server.On the other hand, for the SharePoint Server 2019, SPFx is supported out of the box, without any installation of any pre-requisites.

Client-side rendering

SPFx does not rely on server side or compiled code written in C#. It is a development-platform agnostic framework. This means that it can be implemented on any operating system, including Windows, MacOS, etc. It natively supports multiple integrated development environments (IDE) like Visual Studio Code, Atom, and WebStorm.

Not dependent on JavaScript injection

Modern SharePoint does not allow injecting JavaScript directly on a page or using the custom action. At the same time, it leaves behind Script editor and Content editor web parts. Which in turn brings governance and more control.

No iframe

SPFxis like an add-in model that does not use an iframe to render. It has direct integration with the page model.

Key Features of the SharePoint Framework

Unlike Add-in/App parts running inside iframes, the SPFx web partruns within the context of the currently logged in user and connection with the browser.

All controls are rendered in the normal DOM enabling faster rendering on the browser.

Controls are responsive.

It does not support the elevation of privileges like in SharePoint in the full-trust code to overcome the permission model.

It has full access to the lifecycle of the SharePoint Framework webpart, i.e. component (In it, render, load, serialize and deserialize, configuration changes, and so on).

It is framework agnostic. Any framework like React, Angular, Knockout, and so oncan be used with SPFx.

It supports open source development tools (npm, TypeScript, Yeoman, webpack, and Gulp).

It can be used with both classic pages and modern pages.

Safe and secure, tenant level access is required to deploy changes to the SPFx webpart.

We can control the visibilityof the web part by deciding who can view in the App Catalog.

Data models are unchanged. Earlier knowledge of CSOM can be transferred to the SPFx development.

It is responsive in nature.

Script Editor WebPart vs App Part vs the SPFx WebPart

Custom development is an integral part of the SharePoint portal. With the increase in the use of the client-side development, JSOM has become the choice of developers. We have been using Script editors to inject scripts on pages or App parts to render themin an iframe.

Script Editor WebPart:

Commonly used practice on classic SharePoint sites for customizing DOM.

Users with sufficient permissions can edit the script.

Sites with the ‘NoScript’ flag set do not support running scripts.

App Parts:

Developed with the App/Add-ins model.

Runs inside an iframe. Due to this, it does not have access to the SharePoint page DOM.

Development and deployment are comparatively complicated.

SPFx WebParts:

Supports modern open source toolchain and JavaScript frameworks.

Works with both classic and modern SharePoint pages.

Provides modern experience, responsiveness out of the box.

Brings in governance to JavaScript injection.

Lightweight Components/Tools Used (SPFx Toolchain)

The toolchain for the SharePoint framework is based on open source tools and ideology. In this section, we will walk you through the necessary tools we should have in our toolchain to implement SharePoint framework solutions and compare them with equivalent tools used in the pastin the server-side object model development.

Figure 1.2: SharePoint Framework Toolchain (Server-side toolchain comparison)

Node.js:

Open source JavaScript runtime

Responsible to build and run the applications

SPFx supports LTS (Long Term Support) version, preferably 8.x

NPM Packages:

Stands for Node Package Manager

Package manager for JavaScript libraries

Maintains an online repository (npm registry) to find and deploy new packages

Installs packages and its dependencies

Packages can be installed globally (-g switch) or locally

Installed packages are available inside the node_modules folder

Gulp:

Automates SPFx development and deployment tasks

Bundles and minifies JavaScript and CSS files

Runs tools to call the bundling and minification tasks before each build

Compiles LESS or SASS files to CSS

Compiles TypeScript files to JavaScript

Compiles, bundles and copies files to the deployment folder for packaging

Yeoman:

Relies on NPM and Gulp

Scaffolding tool for Modern web apps

SPFx solution generator

‘yo’ is the command line utility to build the project structure

The Yeoman generator for creating the SharePoint framework project is available from Microsoft

TypeScript:

Strongly typed language

Adds compile-time syntax and type checking for JavaScript

Gets compiled to JavaScript code

Visual Studio Code:

Free, open source IDE for SPFx solutions

Fast and lightweight

Can work on any operating system, including Windows, Mac OS, and Linux

Offers functionalities like IntelliSense, debugging, source control, and file management

Supports third-party extensions

Automatically updates itself

SharePoint Workbench:

The HTML page served by Node.js on a local file system

It provides a sample canvas to add web parts

The local SharePoint Workbench is available as workbench.html on localhost

On the SharePoint site, it is available as workbench.aspx served from the hive folder

Responsive in nature

ALM of the Client-side Web Part

The Application Lifecycle Management (ALM) involves multiple tasks. The following diagram depicts the flow of the client-side web part from the installation of the needed npm packages for a solution, development of code to implement the functionality, test the solution on the workbench, and packaging and deployment of the solution to the SharePoint site.

Figure 1.3: SharePoint Framework Client-side Web Part ALM

The SharePoint Framework also supports continuous integration (CI) and continuous deployment (CD). We will deep dive into it in the upcoming chapters.

Setup the Developer Environment for SPFx

Perform the following set of commands to get your developer environment ready for SPFx.

Install NodeJS:

Install the latest LTS version from https://nodejs.org.

If you already have NodeJS installed, check the version by running the following command:

node -v

Install Yeoman and gulp:

Run the following command (to install globally):

npm install -g yo gulp

Install Yeoman SharePoint Generator:

Run the following command:

npm install -g @microsoft/generator-sharepoint

If you already have the Yeoman SharePoint Generator installed, check the version by running the following command:

npm ls @microsoft/generator-sharepoint -g --depth=0

Θ Note

You may create a batch file to install all the needed packages with specific versions for your development purpose and distribute it across the team so that everyone in the team has the same platform to start with the development.

Install Code Editor:

Install any of the following code editors:

Visual Studio Code (https://code.visualstudio.com)

Atom (https://atom.io)

Webstorm (https://www.jetbrains.com/webstorm)

Update NPM packages:

Yo, Gulp, and the Yeoman SharePoint Generator get installed as NPM packages. Use the following commands to check and update them.

To update NPM, use the following command:

npmi -g npm

To check the outdated packages, use the following command:

npm outdated –global

This command will report packages that need updates. Use the following command to update the reported packages:

npm update -g

This book targets SPFx features released until 1.8.1 version, which is the latest at the time of writing this book. The SharePoint Framework is ever growing and there will be more versions of it releasing in the future.

Conclusion

In this chapter, we explored how SharePoint had become richer with its every release and eventually, a Modern SharePoint has evolved. The SharePoint Framework plays an important role in customizing Modern SharePoint. At the same time, it also supports classic SharePoint. It uses the modern open source