Build SharePoint Framework solutions for on-premises SharePoint with ANY version of React, TypeScript or Office UI Fabric React

Any version?

-Yes, any.

Including the latest versions of React, TypeScript, etc. ?

-Yes.

The problem

SharePoint Framework is supported not only by SharePoint Online but by on-premises SharePoint as well (2019 and 2016 with Feature Pack). SharePoint Framework Yeoman generator has different options for different SharePoint versions and it generates different project templates depending on the environment selection.

On-premises SharePoint is always behind SharePoint Online in terms of features and codebase. And the same issue applies to SharePoint Framework. If you generate a "Hello world" SharePoint Framework web part for SharePoint 2019, you will see that it uses React 15.6, TypeScript 2.4 and Office UI Fabric React (OUIFR) 5.21. The most recent versions (as of today, August 2019) are React 16.8.6, TypeScript 3.5.3 and OUIFR 7.21.0.

Now you see the issue - you always have to work with an older version of packages. You miss a lot of potential features, bug fixes, and other things. Additionally, from a developer perspective, it's not exciting to work with outdated technologies or frameworks. The situation will be even worse in 2020 when we see React 17, TypeScript 4 and OUIFR 8. Will Microsoft update yeoman generator for on-premises to add support to the most recent version of packages? I don't think so. On-premises are not in the priority list today. 

For those who want to jump and explore the code right away - the full source code for this post is here at GitHub. More...

SharePoint Framework development tips: even more easily debug production version of your SharePoint Framework solution

Almost a year ago Waldek Mastykarz posted a great article on how to debug your SharePoint Framework solution in production, where all the code is minified and source maps are not available. While it works, there is a manual step of uploading source maps in google chrome's dev tools, which isn't very convenient. I extended Waldek's solution with fully automated implementation without any complexities. 

The problem

When you package your SharePoint Framework solution, spfx build pipeline minimizes and optimizes all your TypeScript code. It's not a problem for development, because in "serve" mode spfx build pipeline generates source maps for you. Source maps allow you to open original TypeScript source files in browser developer tools with full debugging experience. 

This is something not possible for "ship" or "production" mode of SharePoint Framework solution. When you run bundle and package-solution with "--ship" flag, spfx pipeline doesn't generate any source maps for you. Instead, you have minified and performance optimized javascript code without any notion of source maps. 

Here is your approximate production code revealed in Chrome dev tools (prettified): 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...

Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials")

Call Azure AD secured API from your SPFx code series:

  1. Call Azure AD secured API from your SPFx code. Story #1: Azure Functions with cookie authentication (xhr "with credentials")
  2. Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials") <—you are here
  3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js
  4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

In the previous post, I showed an example on how to call Azure Functions API protected with Azure AD (using EasyAuth setup). Described approach has a few limitations, one which is the most important is an inability to send HTTP POST or PUT requests. This issue can be fixed by using regular ASP.NET Web API application with custom authentication layer. More info about this approach you can find here - Access the API by leveraging SharePoint Online authentication cookie. This post describes required steps to make it work:

  1. Add new app registration in Azure AD
  2. Create new ASP.NET Core application and setup authentication with Azure AD.
  3. Enable CORS for your web application with credentials support (so we can send CORS AJAX and attach credentials to our request, auth cookie in our case)
  4. Create simple SPFx webpart, which gets data from our web app via authenticated HTTP request (GET and POST).

The source code for this article available on GitHub here.

Let’s get started. More...