The SharePoint Framework is a rather new approach to implementing and customizing SharePoint. We use the term customization quite loosely in this chapter, meaning mostly all types of custom implementations that organizations typically request as part of their SharePoint projects.

In order to understand the essence of the SharePoint Framework, we'll start with extensibility.

Ever since SharePoint was introduced, and the add-in model was introduced, the thinking from Microsoft for SharePoint extensibility has been that a supported model must exist, and it should be in the long term. Now, you might be thinking that after the previous chapter, where we had a brief encounter with many different approaches--where is the long-term thinking? Granted, some of those models, such as sandboxed solutions, should maybe have been more refined and possibly even not released in their past forms. But at the same time cloud computing, together with a Platform as a Service (PaaS) thinking, has surged and is constantly evolving.

The qSharePoint Framework aims to mitigate the past mistakes and challenges of SharePoint customization models in two major areas.

First, the SharePoint Framework aligns very closely with current industry standard frameworks and models. As such, Microsoft is not introducing yet another framework from zero and planning to spend...

The philosophy of the SharePoint Framework takes many cues from past missteps of the add-in model and full-trust solution model. As developers have been moving to a more lightweight approach using script injection, embedded HTML within a script editor web part, and similar models, the SharePoint Framework aims to provide a unified and consistent way to create customizations in SharePoint.

All development for the SharePoint Framework is modern client-side development. This does not imply that nothing can be implemented on the server side. It merely means that most SharePoint customizations tend to be functionality that can be encapsulated on the client-side quite easily. For those features that require server-side logic, it can be implemented outside SharePoint; typically using a serverless platform such as Microsoft Azure Functions, Azure API apps, or similar concepts.

The modern approach also means that the SharePoint Framework will evolve over...

As the SharePoint Framework is not a fixed set of functionalities that Microsoft chooses to release once, and then update at leisure years later, the types of projects it supports varies.

At the time of writing this book, the SharePoint Framework supports the following capabilities and project types:

• Client-side web parts: These are equivalent to your typical SharePoint web parts, or client-side web parts you could build with the add-in model. This is the most common requirement for any SharePoint project: to build a widget or element on a page that can be configured and parameterized to provide new functionality on a given page.

Client-side web parts are, as the name implies, implemented using assets the client browser understands; namely Cascading Style Sheets (CSS) for element branding and positioning, HTML for structure, and JavaScript for logic and functionality. You are free to include your preferred JavaScript frameworks inside...

Besides the types of projects the SharePoint Framework supports, there are other key aspects of the approach that developers need to be aware of.

First, and foremost, the SharePoint Framework-based customizations and custom code runs in the context of a logged-in current user and connection with the browser.

Elevation of privileges, which would often be a way for developers to circumvent the permission model of SharePoint in full-trust code, are not used with the SharePoint Framework. As no IFrames are used, all code that you deploy that is based on the SharePoint Framework always executes with the permissions, privileges, and access of the current user. Keep this in mind when implementing your solutions, as you might need to store additional data elsewhere and the user either must have access to that location, or you need to resort to external code to shield your data or make it harder to access directly.

Each solution that you choose to make...

The toolchain for the SharePoint Framework is based on open source tools and ideology. This section will walk you through all the necessary tools you will have in your toolchain when implementing solutions using the SharePoint Framework.

These tools aid you in managing your projects, building and deploying your code for test and production environments, and running your code locally when doing initial debugging and testing. If you've been already building solutions for SharePoint before the SharePoint Framework was available, you'll see that a lot has changed from the earlier SharePoint development models.

In Chapter 3, Getting Started with the SharePoint Framework, we will be using the toolchain to build our first SharePoint Framework package.

npm is a package manager for JavaScript. It includes a command-line tool, coincidentally called npm, and it uses an online repository known as the npm registry to find, retrieve and deploy new packages your code might need. The SharePoint Framework uses npm packages in the base template you'll typically be using. In addition, new SharePoint Framework templates and functionality will be published as npm packages.

Think of npm as the tool that allows you to interact with a vast library of pre-made packages, that in turn will aid you in building SharePoint Framework packages. The rough equivalent of npm in the .NET world would be NuGet.

For example, the package named @microsoft/sp-client-base is a base package that the SharePoint Framework uses in the base project template, and the latest stable version will be automatically fetched from the npm repository at https://www.npmjs.com/package/@microsoft/sp-core-library.

Yeoman is a generator tool, helping developers create new project and solution directories. You'd use npm to get individual packages, and you'd use Yeoman to generate a new SharePoint Framework project, which in turn would fetch the correct npm packages and other dependencies.

Microsoft has published a Yeoman generator for SharePoint, which includes all the necessary workflow actions to create the SharePoint Framework base project. This way, developers do not have to start each project from line 0, trying to figure out what goes where. As things evolve and change, the Yeoman generator for SharePoint will be updated and new projects will simply get updated project structures and updated npm packages.

Think of Yeoman as a tool that provides you with access to a pre-defined checklist and build file for constructing your project base. You will typically install Yeoman with npm, as Yeoman is published as an npm package.

Yeoman is used with the...

Gulp is yet another tool that you will find highly useful, and a required tool in your overall toolchain for SharePoint Framework development projects. Whereas you will use npm to fetch the necessary packages and Yeoman to generate your projects, you will use Gulp to build your projects with all the necessary parameters and dependencies.

Gulp automates and allows you to enhance your build workflow. This is done with a configuration file called gulpfile.js, which allows you to add custom actions and tasks when building your project.

With .NET development, where you typically use Microsoft's Visual Studio development environment, you would typically just select the Build menu from the top toolbar, and then click on Build solution. This would compile and build your full-trust solution for SharePoint.

However, when using Gulp, you type gulp <action>, such as the package, to start packaging your code into a re-distributable and deployable package.

With previous SharePoint frameworks, such as in the add-in model and the full-trust models, a developer would use Visual Studio to build and package everything in the project. As the code editor, this would often be a version released around the same time as the SharePoint version, such as Visual Studio 2013 together with SharePoint 2013.

For the SharePoint Framework, Microsoft envisioned that as things evolve rapidly and open source frameworks shift constantly, then the main development environment does not follow the pace set by Visual Studio. Visual Studio Code is a free, open source alternative to Visual Studio commercial editions from Microsoft, and it is the preferred integrated development environment for SharePoint Framework based projects.

Compared to a full and commercial version of Visual Studio, Visual Studio Code (or VS Code for short) is lightweight and quick to install. You can download the latest version of VS Code at https://code.visualstudio.com/,...

As an invaluable tool in your toolchain, a proper browser developer toolset is required. You are free to choose whichever browser you feel most comfortable with; it can be Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, or similar.

Developer tools within a browser are typically accessed with F12 while a page is open in the browser. This provides a toolset that is highly useful for debugging the SharePoint Framework issues and problems.

The last, and probably one of the most often used tools in your SharePoint Framework toolchain, is the SharePoint Workbench. This HTML page is served from a local filesystem by Node.js and loaded in a browser instance when you run gulp serve.

By default, SharePoint Workbench is dynamically loaded as workbench.html locally and is only accessible from your localhost. In addition, SharePoint Workbench also exists in SharePoint and can be used against a real Office 365 tenant or SharePoint 2016 to see how your code truly works.

In a typical development workflow with the SharePoint Framework, you'll mostly use the locally hosted workbench.html to test and see how your code works. When you're ready to package and test your code against SharePoint, you'll be using the hosted version from SharePoint 2016 or Office 365.

It's worth pointing out that the local version of SharePoint Workbench (workbench.html) does not require SharePoint installed locally....

Ever since SharePoint Portal Server 2001 was released at the start of the millennium, developers and businesses have tried all types of approaches to customize and bend SharePoint, one way or another.

SharePoint, after a default installation (which in itself is a discussion for a whole other book!), is referred to as an Out-of-Box (OOB) SharePoint. In its history of 15 years of releases for on-premises versions, and more than 5 years of updates with SharePoint Online, developers have always found ways to modify, change, or even remove built-in SharePoint functionality. This could be because of business requirements, usability reasons, or simply that a developer feels that he or she can implement a better implementation of a SharePoint feature.

This has resulted in numerous issues and headaches for both Microsoft, ISVs, Microsoft partner companies trying to make a living providing SharePoint-based solutions, businesses and their IT departments...

For this particular reason, with a few driving forces within Microsoft and the community, the Office Developer Patterns and Practices emerged some years ago. Office Dev PnP, for short, is a massive project aiming to provide a centralized hub for most of the issues listed earlier.

The project currently has the following subcategories for SharePoint:

• YouTube videos help developers understand how things can be built for SharePoint and SharePoint Online. You can find the videos at https://aka.ms/sppnp-videos.
• MSDN help guidance providing a guidance on all things relating to SharePoint development. You can find the guidance at https://aka.ms/sppnp-msdn.
• The Microsoft Tech Community forums, for community discussions, peer-to-peer help, and announcements. You can find the forums at https://aka.ms/sppnp-community.
• A Twitter account at OfficeDevPnP.
• Dev.office.com documentation for an overview and additional information on the SharePoint Framework...

As so many people rely and depend on the Office Dev PnP efforts and results, it's worth considering contributing back to the community. As all content within the PnP effort are essentially free of charge and open source, it only works if others who benefit from this work contribute back for the greater good. As someone wise once said, sharing is caring!

You are not obligated to ask for permission if you wish to contribute. You can simply follow the guidance on what makes a good contribution, and what the technical approach to performing a commit back to a given repository is. The updated guidance can be found here: https://github.com/SharePoint/PnP-Guidance/blob/master/CONTRIBUTING.md, which includes information on how to make a copy of a repository and submit pull requests using GitHub.

One of the key elements that all developers need to think about the long-term is life cycle management for your solutions. Application lifecycle management, or ALM, is a huge topic in itself, but we feel it's important to underline the aspects of ALM as it touches the SharePoint Framework.

One of the larger missing pieces with the add-in model since 2013 was that it mostly lacked a proper model for managing the life cycle of your deployments and solutions. The act of life cycle management involves multiple tasks within any given development project, including:

• Managing source code and assets
• Versioning source code
• Building solutions
• Testing code
• Deploying solutions
• Retracting solutions
• Managing solutions
• Updating solutions

ALM for the SharePoint Framework is still at a fairly nascent, but evolving stage. This does not mean that managing the life cycle of the SharePoint Framework project is impossible or a complex...

Source code should be versioned so that changes to your code can be undone, should you run into unforeseen issues. We should also have clear visibility on who did what, when, how, and why. With classic SharePoint solutions, such as full-trust code projects, the versioning system was typically Microsoft's Team Foundation Server (TFS), an on-premises service that could be deployed locally. It would provide a portal for accessing different team projects, managing tasks, bugs, project schedule, and resources. TFS is still widely used, but it's fairly complex to deploy and configure, and numerous version upgrades in past years have proven that such services can also be provisioned as cloud-based services.

For the SharePoint Framework-style projects, you should typically choose either GitHub.com (a third-party cloud service), which allows you to store your project data and code in a private or public repository, or Visual Studio Team...

GitHub.com allows for cloning of existing repositories (such as the Office Dev PnP repos), or creating your own empty repositories.

You can then either edit projects and code copied from someone else's repository or commit your own code back to your own empty repository.

For efficiently working with GitHub, we recommend you to install the GitHub Desktop from https://desktop.github.com/. This small tool allows you to browse and modify the repositories easily with a rich desktop client.

As such, GitHub is typically the primary tool for open-source projects with needs for project management tools. There is also a commercial option for closed-source projects within GitHub.

VSTS is a service company typically prefer using, as it's more private, and lacks the community-style approach to sharing and publishing your code. VSTS builds upon the older TFS style, but at the same time, it's a modern and fresh take on performing the whole ALM process and Agile project management tooling within a single service.

You can provision a new VSTS account at https://www.visualstudio.com/. The basic service is free for up to five users, which typically is sufficient for smaller SharePoint Framework projects.

If you own a Visual Studio subscription, you can also access the basic services of VSTS.

VSTS has an amazing selection of tools and services, which can be easily configured to support your ALM process, big or tiny.

Initially, you can just use VSTS as a place to store your code and not worry about much else. Later, when your project grows larger, you can involve additional aspects of VSTS, such as automated testing, user load testing...

Now that you have your code managed through VSTS or GitHub, you'll need a way to manage your SharePoint Framework customizations in SharePoint. Once again, there are multiple approaches to this task and you're free to choose the one that most fits your own development workflow and experience.

As all the SharePoint Framework solutions are packaged with Gulp to a separate package, it's very easy to move one or more files to SharePoint for testing and deploying to production. Each SharePoint Framework package is a file with the extension .sppkg, and they work distantly, similarly to SharePoint add-ins.

A centralized approach for this would imply you would use the application catalog, which is a special type of SharePoint site that includes the mechanisms for storing add-ins and SharePoint Framework Packages, and then deploying those through your SharePoint via site collections.

You can have multiple solutions in the application...

In this chapter, we took an initial look at the SharePoint Framework and its capabilities. As we saw, the framework is constantly evolving and currently supports several core features SharePoint developers are used to having when implementing solutions for SharePoint and SharePoint Online. We can expect the SharePoint Framework to rapidly evolve, and extend beyond client-side web parts and basic extensions.

For writing code, Visual Studio Code is the recommended editor, as it is lightweight, free, and has native support for the SharePoint Framework solutions. The majority of the orchestration for the SharePoint Framework project is done outside Visual Studio Code, from Command Prompt, or via an embedded command window within Visual Studio Code.

The toolchain includes npm, for managing packaging, Yeoman for generating the necessary project structures and templates, and Gulp for packaging and serving the actual project. Additional tools that we recommend include browser developer...