A new beast in SharePoint Framework development: library component

SharePoint Framework 1.8 is out and gives us a lot of new things. Check out SPFx 1.8 release notes to learn more. Among different generally available features, we also received some items in "beta" mode. One of them is a library component type.

Library component currently is in preview and most likely will be generally available in SharePoint Framework 1.9

Let's find out what is that library component, when and how to use it. This post is not a step-by-step tutorial (you can find tutorials in the links section of the post in the very bottom), but rather an explanation of why and when we should use library components, why they were added to SharePoint Framework. The original entry in SharePoint User Voice received a lot of votes, thus this feature is long awaited. More...

SharePoint Framework development tips: prettify your imports

The source code with samples from this post is here at GitHub.

Have you ever found yourself writing something like this in your SharePoint Framework web parts: 

import { Customer } from '../../../../../../models/Customer';
import { Utils } from '../../../../../../common/Utils';
import { Api } from '../../../../../../services/Api';

import User from '../../../user/User';
import GreenButton from '../../../ui/green-button/GreenButton';
import Grid from '../../../../../../shared/components/grid/Grid';

Above code has a few issues: 

  • Readability of such code is not at the best level. A lot of parent relative paths like "../../../" don't look good
  • It looks ridiculous to import "Grid" from "...components/grid/Grid". It's pretty obvious that we want to import Grid from components/grid. No need of one extra word "Grid". The same also applies to other imports
  • When you add a new import or refactor your code by moving into different folders, you will have troubles figuring out how many "../../" you need :)

What if I tell you that with some webpack and typescript magic we can make it look like this: 

import { Customer } from '@src/models';
import { Utils } from '@src/common';
import { Api } from '@src/services';

import User from '@hello-world-components/user';
import GreenButton from '@hello-world-components/ui/green-button';
import Grid from '@components/grid';

This code is a lot cleaner and doesn't have all mentioned issues. 

Let's figure out how to do it! More...

SharePoint Framework development: some gotchas and how to solve them

This post is mostly for Googlers, who experience unexpected issues with SharePoint Framework (like I did). 

Whether you like it or not, sometimes shit happens.

Issue

Usually, I don't use spaces in paths to my projects, however, one day for some reason I decided it was a great idea (probably I was trying to be more creative). And I paid for it.

If you have created a SharePoint Framework project, and the path to that project contains spaces, you are in trouble. gulp serve will work, gulp bundle gulp package-solution will work. However as soon as you upload your app to App Catalog, you will see an app package error: 

Invalid SharePoint App package. Error: Part URI is not valid per rules defined in the Open Packaging Conventions specification. More...

SPFx webpart with MS Graph and PnPjs: step by step guide

So you want to build an SPFx webpart which uses MS Graph API through PnPjs. Here is step by step guide on how to do that.

A few months ago I wrote a similar post, however, things were changed, some things were simplified a lot, that’s why this is a revisited guide. Also, I’ve addressed some additional steps here. The source code is available on the official SharePoint/sp-dev-fx-webparts GitHub repository.

Prerequisites

  • SPFx >= 1.6
  • PnPjs >= 1.2.4

1. Scaffold SPFx webpart solution with React

This step is pretty self-explanatory, simply run yo @microsoft/sharepoint, select React, give your webpart a name, do not change other defaults asked by yeoman.

More...

Stylelint with SPFx integration

Are you TypeScript developer? I bet you use tslint in all your TypeScript projects! If not – start using it. SharePoint framework has tslint step which validates your code against tslint rules, which is awesome. More and more web developers today also use stylelint. Stylelint can be easily explained in just three words – linter for css/scss. Modern web developer (and of course modern SharePoint developer) has to write a lot of css or scss code. So why don’t we lint css code as well? Checkout increasing interest in stylelint at npmtrends:

SharePoint Framework in current version doesn’t have built-in stylelint support. However we can easily fix it with custom gulp subtask. Let’s do it right away! More...

You might experience errors when first trying new SPFx 1.6 features

SPFx 1.6 was released recently with new features which support secure connection to Azure AD protected APIs. During upgrade some things in your tenant and Azure AD were changed. For some users migration didn’t go smoothly and they saw strange errors in different places. I’m in the group of users who experienced errors and had to fight with them. Fortunately really smart guys from Microsoft and community resolved everything. There are a few issues on GitHub related to SPFx 1.6 errors. It might be difficult to go through all comments and find an answer on your concrete problem. I see that more and more people struggle with the same types of errors, I sum up potential errors and their resolutions in a separate post.

Basically there are two types of errors you might see when trying SPFx 1.6 features. They are described at GitHub SPFx The user or administrator has not consented to use the application with ID and SPFx suddenly stopped working; experimental feature error. More...

Calling MS Graph API from classic SharePoint pages

- Classic pages you said?

- Yes! You read it right. MS Graph API from classic SharePoint page. However please read it first:

That’s not an official or recommended way. That’s just a proof of concept, which uses some tenant features introduced with SPFx 1.6. That’s something I decided to try out when SPFx 1.6 was out. Use it on your own risk.

When to use it? On classic pages if you don’t have an option to execute SPFx code.

So what if you want to call some MS Graph APIs from your classic SharePoint page? No problem then.

Before doing actual coding, we should check that we meet all prerequisites:

  • You have SPFx 1.6 features, which work without issues in your tenant. You can test it by creating a simple SPFx web part, which uses MS Graph. Upload it to the app catalog, approve the request to MS Graph and see it actually returns MS Graph data

If above works, you have everything needed for our experiments. More...

Using PnPjs to send requests to MS Graph with SharePoint Framework 1.6

SPFx 1.6 was released recently and a lot of new and interesting features were introduced. AadTokenProvider, AadHttpClient, MSGraphClient  went to GA, which are my favorite features. One of the common thing in SPFx development is accessing other resources, protected with Azure AD. For example you might have your LOB API with Azure AD protection and you want to consume that API from SPFx web part (extension). Before SPFx 1.6 it was a bit challenging, because you have to deal with cookies attached to your asynchronous http request or with custom “patched” adal.js implementation. SPFx 1.6 features mentioned earlier drastically simplify the task to access Azure AD protected resources. Now you can access Azure AD APIs (including Microsoft APIs like MS Graph) from SPFx with ease!

I’m pretty sure you know about PnPjs library. It has a lot of cool features, among them a fluent interface to SharePoint and Graph API. WIth SPFx 1.6 release you can use PnPjs as your Graph client without hassle. Read further to find out how. More...

Web Components in SPFx world: Vue vs Stencil

This year I hear “Web Components” term from here and there more frequently. What exactly is Web Components?

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

In other words, web components are reusable pieces of HTML and JavaScript, which can be used in modern browsers, and what is even more important, can be consumed by JavaScript frameworks. Today we have a few web frontend libraries for building web interfaces and SPAs. All of them uses concept of components, however components from one library can’t be easily ported to another one. It looks weird, because in the end that’s just portion of html + styles + logic (JavaScript). However today, in 2018 we can’t reuse building blocks from one library in another. It’s a shame. Web components solve that issue. They can be reused across JavaScript frameworks. Check out webcomponents site for more information.

Web components is a set of W3C standards, which describe how everything fits together in browser. Not all browsers fully supports all web components’ specifications. Google Chrome has full support, Firefox is developing a few remaining things and Edge has the worst support: More...