Recently we had the pleasure of hosting a webinar about “Building Client-Side Web Parts with the SharePoint Framework” with Andrew Connell, Microsoft MVP and Founder of Voitanos and our own Waldek Mastykarz, MVP and Product Owner for Customization Quality at Rencore.
The SharePoint Framework is a new model for building SharePoint customizations. Unlike other SharePoint development models available to date, the SharePoint Framework uses open source toolchain and focuses on client-side development.
This webinar followed our previous introduction webinars from autumn 2016 by Bill Baer and Vesa Juvonen of the Microsoft SharePoint Product Group to dive deeper into the development techniques and challenges of the SharePoint Framework.
Andrew and Waldek shared tips and tricks on how you can use the SharePoint Framework to build client-side web parts in an efficient and secure way – whether you have already tried the SharePoint Framework or are investigating its capabilities for your organization.
You can re-watch all three webinars among others in our webinar section
- Andrew Connell/ Waldek Mastykarz: Building Client-Side Web Parts with the SharePoint Framework
- Vesa Juvonen: Deep-Dive to development using the SharePoint Framework
- Bill Baer: Introduction to development using the SharePoint Framework
During the webinar we received plenty of questions from the attendees that we want to answer for all of you in this Q&A summary:
Questions & Answers
1. Features & Capabilities
Q1.1: Are there any plans for the SharePoint Framework to become available in SharePoint 2013 on-prem?
At this moment Microsoft announced only support for SP2016 coming somewhere in calendar year 2017
Microsoft said they were going to include it as part of a feature pack… there’s no specific time table other than “CY2017” but I’d expect it to be sometime in the second half. Also, it will only apply to SharePoint 2016, not previous versions of SharePoint.
Q1.2: Will SharePoint Framework support connecting to the Microsoft Graph?
Currently you can connect SharePoint Framework web parts to the Microsoft using ADAL JS which has its limitations (see the guidance at https://dev.office.com/sharepoint/docs/spfx/web-parts/guidance/call-microsoft-graph-from-your-web-part). Microsoft is considering simplifying connecting to the Microsoft Graph in the future.
Q1.3: Is it possible to customize the layout of modern pages?
At this moment it’s not possible although Microsoft is considering providing different layouts for modern pages in the future.
Q1.5: Is it possible to nest SharePoint Framework client-side web parts, for example to build a web part with some properties like title and subtitle and a ‘zone’ to include other web parts like a video web part?
No, just like it isn’t possible to next two classic web parts. Because it’s all just HTML at the end of the day, you could always resort to DOM manipulation but that isn’t a reliable solution as it can be impacted by changes to the elements on the surrounding page.
Q1.6: Is it possible to brand modern pages in SharePoint using master page or layouts similarly to what we can do with the classic SharePoint experience?
At this moment modern sites and pages don’t support branding. Microsoft is considering adding support for branding in the future.
Q1.7: Where are the SharePoint Framework client-side web part properties values saved?
SharePoint Framework client-side web part store their configuration in the page.
They are persisted the same way the old web parts were persisted. SPFx does that for you automatically as long as they are public properties on the web part like I showed with the interface.
Q1.8: Is there going to be some kind of server side adaptation of SPFx client-side web parts, similar to provider hosted add-ins, for cases such as elevating user’s privileges?
In cases when you require server-side code such as elevating user’s privileges or implementing long-running operations, Microsoft recommends combining SharePoint Framework solutions with server-side components built using the add-in model. Communication between client-side web parts and such server-side components can be done using web APIs.
I read this as two questions. First, there is no server-side option with SPFx. Second, if you need to do something that includes elevation of privileges, protecting your IP or something else, you should consider taking that part of the logic and hosting it elsewhere server side. Your SPFx customization could then call this logic as a web service or something similar.
Q1.9: Are SharePoint Framework client-side web parts similar to SharePoint provider hosted add-ins?
Not quite, and here are a few main differences between the two. SharePoint Framework client-side web parts execute as a part of the page whereas add-in parts are isolated using iFrames. Also provider-hosted add-ins are implemented using server-side code, whereas client-side web part run exclusively in the browser. With regards to permissions, add-ins are granted a specific set of permissions that they can never cross. Client-side web parts on the other hand always execute in the context of the currently authenticated user.
Similar only in the sense they are 100% client side & can be packaged up for deployment to SharePoint. But only SharePoint Hosted add-ins have application permissions and are limited to living within classic pages and app webs. SPFx solutions don’t have specific identities or individual permissions; they operate within the context of the page and thus have the same permissions as the current user.
Q1.10: Is it possible to deploy client-side web part to a whole site collection rather than only to a specific site?
At this moment, you can only install web parts to specific sites. Deployment to a complete site collection is not possible at this moment.
Not at this time. Think of the deployment options as being similar to what we have within the SharePoint classic web parts (ie: those built as farm or sandboxed solutions).
Q1.11: For client-side web parts, wouldn’t SharePoint hosted add-ins that deploy an add-in part to the host web be a more robust solution?
It depends on the scenario. If you want your web part’s code be isolated from other elements on the page, then using add-in parts is indeed a better approach. On the other hand, if you want to build customizations that work on modern sites and across the different devices including the SharePoint app, then using the SharePoint Framework would be a better choice.
Q1.12: Do client-side web parts support personalization?
At this moment, client-side web parts don’t support personalization natively. You would need to implement it in your code.
Q1.13: What are the options for composing modern dashboard pages: can we only use web parts built using the SharePoint Framework or can we also add ad-hoc web parts using script injection and embedding?
With the SharePoint Framework Microsoft is promoting a more structured and manageable approach to building and deploying SharePoint customizations. Embedding scripts and styles on pages is discouraged in favor of building SharePoint Framework solutions that can be centrally managed.
At this time there is no API for adding client-side web parts to pages.
Q2.1: Is it necessary to learn Node, Yeoman, Gulp, Webpack and TypeScript to work with the new SharePoint Framework?
SharePoint Framework uses open-source toolchain that works the same way across the different operating systems. While it’s not necessary for you to have extensive knowledge of the tools used by the SharePoint Framework, having a basic understanding will help you be more productive when building solutions on the SharePoint Framework. To learn more about the skills and technology you should learn to get the most out of SharePoint Framework see https://www.spcaf.com/blog/learn-prepare-developing-solutions-sharepoint-framework/.
In my opinion the only things you really need to learn is how to manage your packages with NPM, how get a lists of available gulp tasks and run one and TypeScript. You can completely ignore Yeoman, Node.js and Webpack. While you can learn more about them and dig deeper, just like you can learn how to build Visual Studio extensions, it’s not necessary to be productive.
Q2.2: How can we add custom gulp tasks?
SharePoint Framework uses gulp in a different way than what you might know from other projects, yet it supports adding custom tasks to the build pipeline. For more information see the official guidance at https://dev.office.com/sharepoint/docs/spfx/toolchain/integrate-gulp-tasks-in-build-pipeline
Yes, refer to the guidance “Integrate Gulp Tasks in the Build Pipeline” document by Microsoft. The engineering team does not use Gulp in a common way, however it is possible to create your own tasks.
Q2.3: What is required to run npm in PowerShell?
After installing npm it registers itself in the global path in your operating system and you can use it as any other executable from PowerShell or even the regular command line.
Node.js has a concept of local & global packages (utilities). These packages / utilities are managed by NPM, Node’s package manager. The way it’s done is you always have access to a utility in the same current working directory (as Node.js will look within in the current folder’s node_modules folder). Global packages are placed in a special folder that is listed in your environment’s PATH variable which is what makes it available everywhere. This is true for all terminals / consoles on all platforms (not just PowerShell / Windows / MacOS / Terminal).
Q2.4: What version of TypeScript can you use with the SharePoint Framework?
The latest version of the SharePoint Framework uses TypeScript v2. While SharePoint Framework projects are scaffolded with a few old typings the majority of the solution is based on TypeScript v2.
You can ignore the typings folder that’s added as part of the project scaffolding. It’s a carryover from some stuff that Microsoft hasn’t migrated to @types. Focus on TypeScript v2.x… it added support for the scoped @types packages which is what we rely on.
Q2.5: Are there any plans to include testing frameworks within SPFx?
For each created web part the SharePoint Framework Yeoman generator scaffolds a baseline for building tests using Mocha and Chai. In the future we should see more guidance from Microsoft related to testing SharePoint Framework client-side web parts.
Q2.6: Can I use Visual Studio for building SharePoint Framework solutions?
The current recommendation is to use a code editor such as Visual Studio Code for building SharePoint Framework solutions. While you could use Visual Studio, at this moment it doesn’t offer you any specific tools that you could use for building SharePoint Framework solutions.
Visual Studio offers nothing to SPFx above what you get from an editor. There is no tooling, wizards or anything like that. So you can use Visual Studio, but you’re only leveraging the text editor window & Solution Explorer window for file management.
Q2.7: How can you add icons to files in VSCode to make them easier to distinguish?
Starting from v1.5 Visual Studio Code natively supports file type icons. For more information on how to enable them see https://code.visualstudio.com/blogs/2016/09/08/icon-themes
You saw from my demo that’s what I do. Visual Studio Code supports some included icons. I use icons from this extension: https://marketplace.visualstudio.com/items?itemName=robertohuertasm.vscode-icons. This extension added icons to VS Code before VS Code added OOTB support for them. It’s very popular (with nearly 1.4M downloads so far and a 5-star rating).
Q2.8: Is it possible to have a F5-like debugging experience in VSCode?
Elio Struyf wrote an article about how you can setup Visual Studio Code for debugging SharePoint Framework solutions. For more information see https://www.eliostruyf.com/how-to-debug-your-sharepoint-framework-web-part/
Absolutely! In addition to what Waldek said, check out this page for more information on setting up debugging with Visual Studio Code: https://code.visualstudio.com/docs/editor/debugging
What Visual Studio Code extensions would you recommend when working with SharePoint Framework solutions?
Q2.9: Is there any additional configuration required for the intellisense to work correctly in VSCode?
Intellisense for SharePoint Framework projects works based on TypeScript typings and doesn’t require any specific configuration other than installing typings for the particular library that you’re using. If you’re not seeing intellisense, then the first thing you should check if you have typings installed.
Q3.1: Are there any examples of custom property pane controls for use with SharePoint Framework client-side web parts available?
Olivier Carpentier did a great job building a set of custom property pane controls which is available at https://oliviercc.github.io/sp-client-custom-fields/. If you’re interested in building your own controls check out the official guidance at https://dev.office.com/sharepoint/docs/spfx/web-parts/guidance/build-custom-property-pane-controls.
Q3.2: Having to reference the different pieces of projects using relative paths, is there a way to make it more manageable?
One way to do this, is to abstract away the file structure using barrels (see explanation at https://angular.io/docs/ts/latest/glossary.html#!#barrel). If you’re reusing a particular set of code across multiple solutions, then you could consider building a separate package and the code from that package.
There is no recommendation. Microsoft uses ReactJS for their customizations in SharePoint. The only one that doesn’t work well is Angular 2 because of the way Angular 2 is architected (see below for more detail). Use what is most comfortable to you.
Q3.4: When using third-party js libraries like Angular v1.x in the SharePoint Framework, is there an easy way to pass “this.context.pageContext” object into Angular?
Yes you can and the exact way to do that differs per library. In Angular v1.x you could pass the context information using an Angular constant or, if the information could change, such as the values of web part properties, by raising an event on the root scope.
Q3.5: Does SharePoint Framework support Angular 2?
At this moment it doesn’t. There are issues when trying to add multiple instances of the same web part to the page. This is caused by the way Angular is built.
There are issues with Angular (what is also known as Angular 2) + SPFx. The issue is due to how Angular2 was architected. It works with one web part, but not multiple ones on the page. This isn’t something MSFT can fix… it’s an Angular “issue”. This was a deliberate design decision by Google to make Angular MUCH faster than previous versions & ReactJS.
Q3.6: What is the easiest way to use Office UI Fabric components in SharePoint Framework solutions?
4. Provisioning & deployment
Q4.1: Are automated tools for deploying assets and app packages included in SPFx? Are there external tools for this purpose?
At this moment there are no APIs that support automated provisioning. Microsoft is considering it for the future though. See the SPFx roadmap at https://dev.office.com/sharepoint/docs/spfx/roadmap
Q4.2: Can SharePoint Framework solutions be deployed to other locations than Azure? If so, how can we do it?
Yes, in fact the only requirement for hosting web parts code is that the URL where the web part is located is accessible by the currently authenticated user. For example see the following article to see how to deploy a SharePoint Framework client-side web part to the Office 365 public CDN: https://rencore.com/blog/publish-sharepoint-framework-client-side-web-parts-office-365-public-cdn/
Q4.3: Is it possible to publish SharePoint Framework solutions in the public app store?
At this moment, the public Office store doesn’t support SharePoint Framework solutions.
In case this hasn’t answered all of your questions, we have four more posts with Q&A from the previous webinars that you might want to check out
- Part 1: SharePoint Framework Basics
- Part 2: SharePoint Framework Capabilities
- Part 3: SharePoint Framework Developer Tooling
- Part 4: SharePoint Framework Guidance
Also make sure to check out our blogpost section about everything you need to know with the SharePoint Framework.
If you found our webinar and re-cap help, make sure to check our our other previous and upcoming Rencore webinars with SharePoint and Office 365 experts from all around the world.