Using a SharePoint Framework Extension With Classic SharePoint

We’re coming up on a year since Microsoft first released the SharePoint Framework (SPFx) to the general public and it’s starting to pop-up in a lot of people’s main tenancies. The framework, together with modern team sites, simplifies a lot of SharePoint’s quirks and brings in modern development practices. We’ve been using it here at itgroove Studios for a lot of different projects and having a lot of fun with it.

However, SPFx currently has a huge drawback: No classic support. Without it, established tenancies (with their hundreds or thousands of older sites) can’t make full use of the out-of-the-box framework, creating a hard decision to be made between features and compatibility when starting a new SharePoint project. With Masthead, we didn’t want to choose. We knew that any organization-wide mega menu had to support both classic and modern sites. If we couldn’t make it work with one app, how could we get around writing two?

Taking a Step Back

Our breakthrough came when we realized SPFx is just a wrapper for normal SharePoint methods. We figured out that by maintaining a level of abstraction between SharePoint and our React app, we could reuse 95% of our code between classic and modern. React is, after all, just JavaScript. The SharePoint side is the only part that needs to change.

When we figured this out, we had to take a step back and look at the way Masthead worked. There were numerous props and information being passed around the React app that, in reality, didn’t need to be there. It took a lot of work and abstraction, but eventually we were able to break Masthead into two distinct parts, and found in the process that a lot of stuff we were using (like type definitions for SharePoint classes) could be cut out entirely. We also noticed that our bundle size became significantly smaller once we started cutting out the SharePoint part.

Are You an Admin?

I wrote a simple app to show off our React/SharePoint separation technique. The app itself lets you know if you’re an admin or not when you visit a SharePoint site. While the visual layer is 100% React/Typescript, the important part is how the app checks whether or not you’re an admin.

Each version of the app has its own file for launching the React layer and providing it with data. In “ModernVersion.ts”, I use SPFx to check the admin status and render the app in a specific spot. In “ClassicVersion.ts”, I instead use an object only present on classic sites (“_spPageContextInfo”) to check if a user is an admin, and render the app using Microsoft’s own navbar.

The two files also act as different entry points for the modern and classic bundles. Because Yeoman generated apps only provide modern build tasks, we had to add our own task to the example app. Mirroring Microsoft’s gulp tasks was harder than I thought it would be, so for anyone having trouble with this part, I’ve commented the gulp and webpack files with instructions. With slight modifications, the task should work with any SPFx app out there that has a similar separation. When you run the task (“gulp build-classic”), the framework creates a JavaScript file that can we be added to any classic site, giving them a modern feel.

This is how Masthead works, and how anyone can use their modern app in a classic SharePoint site. The key is that separation and abstraction (and that handy gulp task) on the SharePoint layer. Without it, we wouldn’t be able to offer a true tenancy wide mega-menu.