We’re starting to write production code on the SharePoint Framework now. Should you?

I’ve been writing and speaking on the SharePoint Framework (SPFx) for a while now, but in many ways it’s all been a bit theoretical so far. After all, SPFx is still in preview at the time of writing (early December 2016) with General Availability expected soon. However, I’ve started to realize that some web parts we are specifying and building for clients now actually need to be done in the Framework. The principal reason for this is that we need them to work in modern pages – and web parts developed using previous approaches way will not work there. On this, I’ve been using this slide recently to explain what works where:

Essentially, a modern (SPFx) web part can work in both modern and classic pages. But a classic web part can only work in classic pages.

Let’s be clear on what we mean by that:

Modern pages use modern web parts

Modern pages cannot use any “classic” web part, including the Content Editor web part, Script Editor web part, Content Search web part, Content Query web part, or any custom web part based on one of these. This means that all the out-of-the-box web parts we’re used to in SharePoint cannot be used in these pages. Microsoft provide a new family of OOTB web parts which meet many common needs, and also address newer scenarios too (e.g. a Power BI web part to embed a Power BI report).

 

It also means that any “cloud-friendly” custom web part which uses the common “Script Editor/Content Editor web part + JavaScript” embed approach will not work in it’s current form – however, I’d expect Microsoft to at least provide an equivalent way to easily add JS to a page e.g. a new Script Editor-like web part). Maybe they’ll even go further and provide a zero-friction way of migrating such web parts?

So, this is kind of a big deal. Of course, the other aspect to consider is how much of a problem all this is..

How prevalent are modern pages? Which pages are modern?

As I mentioned in my previous article Modern SharePoint pages and team news pages - how to query/search for them, the new team news feature uses modern pages and it’s now the default when a new page is created. A more complete list of modern pages might be:

• Any new page created with the “Add page” menu item (from now)
• Any team news page
• Modern list/library pages (but currently not extensible – web parts cannot be added)
• The Office 365 profile page (but currently not extensible – web parts cannot be added)
• Delve blog pages, though these are a slightly different (earlier) flavour

You can identify a modern page quite easily – it has the site logo displayed, slim toolbar and then the tall banner containing the page title:

Of course, Microsoft might update this look and feel at some point, but that’s how it is for now.

The new web part picker

At the heart of the matter is the new web part picker. When you edit a modern page and go to add a web part, you’ll see this and it’s a much simpler experience than before – no wrestling with the ribbon, no navigating through lots of categories of web parts you never use:

Of course, where I’m getting to with this is that only Microsoft’s new web parts and our web parts developed in the SharePoint Framework will show up here. It’s worth becoming familiar with these web parts because they are the new building blocks – but note that more will be added soon, such as the Power BI web part (which might just be awesome, if authentication works in a simple or automatic way). Consider also the new Highlighted Content web part – this is a modern version of something approaching the Content Search web part, but it doesn’t quite have the same power. It *is* easier to use though (much), and based on my experience with end-users I think it really is the direction Microsoft had to head in.

Another thing to think about is that with a new web part picker, the previous requirements of needing web parts to be added to the web part gallery of the current site collection doesn’t necessarily still need to be the case. In the SharePoint Framework, the requirement is currently that the app package must be installed to the App Catalog and for the app to be installed to the site – nothing goes in the web part gallery. But SPFx is still in preview, and Microsoft have some options here - it will be interesting to see where things end up once it hits General Availability.

Summary

So, a new page and web part model. We’re seeing new pages mainly be applied to SharePoint team sites so far, but I think it’s clear that publishing sites will receive similar updates in the future. At that point, it’s fair to expect that, again, only Microsoft’s new web parts and SPFx web parts will work in those pages. The main message here is that modern pages are starting to become prevalent (and the default), and users are using them – so if you’re customizing SharePoint or adding new functionality based on web parts, you might run into problems soon if your web part will not work here. This is driving us to create new web parts using SPFx, and maybe it should for you too. Just make sure you have a fall-back plan in case timelines don’t align – for example, you need to make your web part available in full production mode (and be fully supported) before Microsoft get to SPFx General Availability in non-First Release tenants.