Introduction to the SharePoint Framework (SPFx)Chris O’Brien - MVP

About me

Independent ConsultantHead of Development, Content and Code (UK)

www.sharepointnutsandbolts.com@ChrisO_Brien http://cob-sp.com/COBLinkedIn

SharePoint dev – state of the nationSubtle shift to client side developmentContent Editor/Script Editor web part + JavaScript – common approachEven on-premises projects using cloud-friendly techniques

Beyond jQuery - developers seeking to use latest techApps/add-ins – Angular, KnockoutRendering – React, HandlebarsCSS – LESS, SASSBuild – Gulp

Still difficult for devs new to SharePoint

What is the SharePoint Framework?

Modern pages and client web

parts

Client side applications (list-based and page-

based)

A new developmen

t model

New deployment possibilities

We’ll focus on these aspects

New “modern” pagesApps, but no IFrames!

Similar to recent Delve blog pages

New page “canvas” – no classic web part zones

Client web partsPure JavaScript implementation

“Baked-in JS injection”

Simplified end-user experience (e.g. web part properties)

Page types/web part types crossoverClassic pages Modern pages

Classic web parts Y NModern web parts

Y Y

Modern web parts can work in:- modern pages (of course)- classic pages

But classic web parts can NOT work in modern pages

A new era for SharePoint developersNot just JavaScript, but TypeScript!Use your preferred JS framework – React, Angular, Knockout, jQuery, or noneGulp for buildYeoman for startupNo need for Visual Studio!

Getting started with development

Starting a new solutionPre-requisites:Node.js, Yeoman Generator, TypeScript, GulpYeoman Generator for SPFx – “yo @microsoft/sharepoint”

Process:Create a folderUse Yo to get starter files

DemoStarting a SharePoint Framework solution

Writing code in SPFxFundamentalsCode is written in the “src” directory

TypeScript is expected (at least, for now) Compile-time checking – find bugs faster!A superset of JavaScript - not just ‘var’, but strings and numbers

Client web partsThe “render” method is top of the chain

TypeScript – top 3 things to know1. Variables and typesVariable types must be declared e.g. var foo: string or var foo: UserProfile var foo: any is the escape route – “I don’t need type-checking”

2. Typings for libraries (e.g. jQuery, CSOM)Typings provide code auto-completion - usually in a d.ts fileMost common libs have typings – add with TypeScript Definition Manager

3. Import a module to use itLike a “using” statement – but also ensures the module is loaded

Client web parts – diving deeperBaseClientSideWebPart provides:

DisplayModeContextDOMElementProperties/Render() etc.

Understanding the folder structureFolder Purpose

config Settings for bundling/deployment

dist Run-time files for your applib Intermediate folder in build

systemnode_modules JS dependencies

src Where you write codetypings TypeScript typings

See cob-sp.com/SPX-Files for more info

DemoCoding in the SharePoint Framework

Showed: Live reload

facility (using Gulp Watch)

Adding libs such as jQuery (e.g. typings)

Coding against SharePoint API

Demo explanation - 1

Showed: Code running in

local ‘workbench’ host

Demo explanation - 2

Showed: Code running in

‘workbench’ running in Office 365 tenant

Demo explanation - 2

Showed: Use of jQuery

AJAX within client web part TypeScript - call SharePoint search API and render results

Simple structure - code all in render() method

Demo explanation - 3

Next stepsRefactor into

separate TypeScript

classes/use new SpHttpClient

class

Implement promises (e.g. ES6) for async

methods

Create class/interface to

represent a search result

public GetResultsAsync(query: string, rowLimit: number) : Promise<ISearchResult>

Final code – separate ‘Search’ utility class. GetResultsAsync returns promise with my TS interface representing a search result (with URL, description & title properties):

Deploying to production

Beyond development modeYour files can be hosted anywhereJavaScript and CSS -> CDN, Azure web app, IIS server, SharePoint library

App packages are the deployment vehicle Upload to App Catalog to make available

Ensure dependencies are bundled OR referencedUpdate config.json if jQuery (or whatever) should be referenced from CDN

Deployment process

Build app in release mode

(--ship)

Upload resources to

CDN

Upload app package

(.sppkg) to app catalog

Add to page

Deployment steps - detail

1. Upload resources to

CDN• Use supplied

Gulp task (“upload-cdn”), or do it yourself

2. Deal with dependencies

• Ensure 3rd party libraries are bundled OR referenced externally

3. Package app

• Use supplied Gulp task (“gulp package-solution”)

4. Add to app catalog

• Administrator drags and drops into catalog

5. Add to page

• Web part can now be added to page

DemoDeploying an SPFx solution to production

Showed: Deployment of files

to Azure CDN App deployed to App

Catalog Client web part

available to be added to pages

Demo explanation - 1

Other considerations

What about on-premises SharePoint?Good news!The SharePoint Framework *is* coming to SP2016 – not just SharePoint Online

Likely to be released in a Feature Pack update, some time in 2017

Client web parts in classic pages

New web part properties “wrapped” in old:

The security modelThere isn’t one!These are client-side solutions – access to anything in the DOMBUT, some operations are blocked e.g. *some* access to Graph

Provider-hosted add-ins/IFrames are still a good choiceApp parts use IFrames for a reason – security! (Isolated on page)

Create a server-side component (e.g. WebAPI) where necessary

Key take-awaysSharePoint dev is changing!TypeScript, npm, gulp and some aspects of node.js are importantLots of framework elements to learn – bundling, APIs, manifest files etc.

SPFx does not replace anythingOffice 365 apps and SP provider-hosted add-ins are still good choices

Start your dev prep now!TypeScript, npm, gulp, and React are good choices

Thank you!Any questions?

www.sharepointnutsandbolts.com@ChrisO_Brien