Sharepoint Framework

notes from MSDocs

what developers will need and how to create custom SharePoint Framework solutions. Once you’ve created the custom solution, you’ll then learn how to deploy your components into different environments and various hosting options for your components

Node.js

Node.js is needed as it’s the runtime for the development and build tools previously covered. The SharePoint Framework doesn’t require you to become a Node.js developer, but you need to install it so the apps in the development and build toolchain will run.

When compared to the server-side toolchain, Node.js serves the same role as the .NET Framework.

NPM: Node Package Manager

NPM is a package manager for Node.js-based projects and is included with the Node.js installation. It’s one of many package managers that can download and install packages from the npmjs.org registry.

When compared to the server-side toolchain, NPM serves the same role as NuGet.

Yeoman

To simplify project creation, Yeoman is used to create the project. Visual Studio Code doesn’t have New Project wizard experience. Yeoman is a scaffolding engine that runs generators. A generator defines the set of questions and understands how to scaffold a new project or modify existing projects. Microsoft provides a generator to scaffold SharePoint Framework projects, both new projects and to add components to existing projects.

Gulp

Gulp executes tasks that are written in JavaScript. You’ll use gulp to do things like building your project and transpiling the SAAS files to CSS and TypeScript to JavaScript. You’ll use other tasks to combine the resulting files into bundles and package the resulting files into a SharePoint package file used for deployment.

TypeScript

TypeScript is the language to write your SharePoint Framework projects with

SharePoint Framework project structure

The Yeoman generator for the SharePoint Framework creates the scaffolding (folders and files) for a new SharePoint Framework project. After building the project the first time, you’ll see even more folders and files present.

  • .vscode: This folder contains Visual Studio Code specific files.
  • config: This folder contains configuration files used by the project’s various build tasks. You’ll edit these files as necessary depending on the types of components you’re creating and for specific situations, such as the site to test extensions or adding references to external libraries.
  • dist: This folder, created automatically when you bundle the project, contains the JavaScript bundle and manifest created by the build process that will be used in deployment.
  • lib: This folder, created automatically when you build the project, contains the temporary files generated from the compilation and transpilation of TypeScript to JavaScript and SCSS to CSS files.
  • node_modules: This folder is created automatically when installing package dependencies using the npm install command.
  • src: This folder contains all the source code for your project.
  • temp: This folder, created automatically when you test the project, contains files used by the local development web server.
  • .vscode: This folder contains Visual Studio Code specific files.
  • config: This folder contains configuration files used by the project’s various build tasks. You’ll edit these files as necessary depending on the types of components you’re creating and for specific situations, such as the site to test extensions or adding references to external libraries.
  • dist: This folder, created automatically when you bundle the project, contains the JavaScript bundle and manifest created by the build process that will be used in deployment.
  • lib: This folder, created automatically when you build the project, contains the temporary files generated from the compilation and transpilation of TypeScript to JavaScript and SCSS to CSS files.
  • node_modules: This folder is created automatically when installing package dependencies using the npm install command.
  • src: This folder contains all the source code for your project.
  • temp: This folder, created automatically when you test the project, contains files used by the local development web server.
  • .vscode: This folder contains Visual Studio Code specific files.
  • config: This folder contains configuration files used by the project’s various build tasks. You’ll edit these files as necessary depending on the types of components you’re creating and for specific situations, such as the site to test extensions or adding references to external libraries.
  • dist: This folder, created automatically when you bundle the project, contains the JavaScript bundle and manifest created by the build process that will be used in deployment.
  • lib: This folder, created automatically when you build the project, contains the temporary files generated from the compilation and transpilation of TypeScript to JavaScript and SCSS to CSS files.
  • node_modules: This folder is created automatically when installing package dependencies using the npm install command.
  • src: This folder contains all the source code for your project.
  • temp: This folder, created automatically when you test the project, contains files used by the local development web server.

Developing and testing solutions

Microsoft provides developers two options to test SharePoint Framework projects. The workbench is a special SharePoint page that contains a single canvas that developers can add their web parts to. There are two different workbench options: local and hosted.

Workbench Hosted or Local

The local workbench is served up from a local web server included in each project. It runs on https://localhost that has no SharePoint context. It’s simply an HTML page that loads the SharePoint Framework in the browser. For web parts that need SharePoint context or work with live SharePoint data, you’ll need to mock data requests to test your web part in the local workbench.

he SharePoint-hosted workbench is hosted by a real SharePoint site, located at https://{your-sharepoint-site}/_layouts/workbench.aspx. The hosted workbench is unlike the local workbench in that because it’s hosted by a real SharePoint site, it has SharePoint context. This means that your web part can access data in SharePoint lists and libraries in the same site as the hosted workbench.

SharePoint Framework deployment artifacts

different things required for SharePoint Framework solutions to work in production.

There are two different kinds of files:

  • Installation and registration: The installation and registration files are included in SharePoint packages deployed to the SharePoint App Catalogs. These files make SharePoint aware of the components included in the packages.These files include an app manifest file, feature framework files, and other files that SharePoint needs to provision the components. It doesn’t include files that make the application run.
  • Component runtime files and dependencies: These are the files that are needed to run the SharePoint Framework component once it’s been deployed and installed in a SharePoint environment. Any dependencies your component uses, such as third-party web framework libraries, can optionally be included in the component’s bundle or loaded at runtime from an external CDN. The component’s manifest file defines all dependencies the component requires to be present on the page before it’s loaded and runs. These files include JavaScript bundles of your components, images, CSS files, and JavaScript libraries or assets your component depends on.

Deploying Sharepoint Assests

After creating the SharePoint package, the next step is to deploy it to a SharePoint environment. There are two ways to deploy SharePoint packages. Both options are SharePoint App Catalogs. After package is created the package, the next step is to upload the package to one of the SharePoint App Catalogs. Part of this process is to also trust the package, indicating to SharePoint the app within the SharePoint package are safe to run in your environment.

Tenant Scoped App Catalog

The tenant App Catalog is managed by the SharePoint tenant administrators. All SharePoint packages deployed to the tenant’s App Catalog are available to all site collections throughout the entire tenant.

Site Collection Scoped App Catalog

The site collection App Catalog is only available in SharePoint Online. The site collection App Catalog works just like the tenant-scoped App Catalog, except SharePoint packages deployed to it are only available to that specific site collection. a good option when you have a component that intended for a subset of site collections and not an entire tenant.

Install the app from the site collection’s Site Contents page

The last step is to install the app from the package into a site collection. This is done from the New > App menu in the Site Contents library in a site collection.

Single Part App pages

Single part app pages provide a capability to host SharePoint Framework web parts or Teams applications in SharePoint Online with a locked layout. End users can’t modify or configure the page, which is using the Single Part App Page layout.

Isolated Web Parts

To allow your SharePoint Framework solutions to securely access APIs secured with Azure AD, you can use the API management to specify which APIs can be accessed by scripts in your tenant and with which permissions. all scripts in the tenant to obtain an access token for any of the approved APIs, not just specific SharePoint Framework solutions. Isolated web parts introduce a new way to isolate access to APIs secured with Azure AD and ensure that only specific SharePoint Framework web parts are allowed to obtain an access token for the particular API.

Office UI Fabric

SharePoint use Office UI Fabric (Fluent UI) and Office UI Fabric React as the default front-end framework for building the new experiences. These options are selected in Yeoman which will provision the correct version allowing for direct importing Fabric components in the react components

Incorporate enterprise data with APIs

The SharePoint Framework offers developers multiple API options to incorporate data from external systems in their custom components. The following sections list some of the endpoints the SharePoint Framework API natively supports in custom solutions.

SharePoint REST API

The SharePoint REST API is the primary API for accessing data in a SharePoint site. Client-side solutions mean it’s available to SharePoint Framework components and server-side solutions are those that run on a server but external to your SharePoint environment, such as an Azure Function or web app. The SPHttpClient extends the HttpClient API, which is a wrapper to the Fetch API included in all modern browsers and includes a polyfill for older browsers that don’t support the Fetch API. The HttpClient is also included in the SharePoint Framework API. Developers can use it to submit HTTP requests to any REST API.