Yes, you can use Modern React on SharePoint 2016

Audience: developers.

While we are following the Microsoft 365 buzz in conferences and on social media, many organizations are still on an older platform, such as SharePoint 2016. I expect that many of you in this case are looking to migrate to the Cloud, in particular government agencies with the return of the JEDI contract.

SP 2016 site owners have been relying on the Content Editor Web Part (CEWP) or the Script Editor Web Part (SEWP) for page customization. Neither is available in modern SharePoint Online, and a transition roadmap is needed.

Let’s start with the good news. In recent years, the Microsoft 365 platform has embraced JavaScript, bringing in its own typed flavor called TypeScript. It can be used on SharePoint of course but also in Teams, Outlook, Power Apps or Power BI. In SharePoint and Teams, the points of entry are called the SharePoint Framework (aka SPFx, version 1.12 expected in February) and the Microsoft Teams Toolkit. Since 2019, Microsoft has also embraced React as the main engine for its client side frameworks, and consolidated its UI library under the Fluent UI brand.

That’s very exciting news for SharePoint Online users, but what if you are still on SharePoint 2016?

Microsoft included SPFx in a SP2016 upgrade back in 2018. That made the migration to the cloud straightforward:

Now the not so good news: in 2019 and 2020, Microsoft kept upgrading the SPFx in the Cloud, but didn’t bring any improvement to the 2016 platform. That makes the migration more challenging than it used to:

Hugo Bernier has an excellent compatibility matrix that shows us SP 2016 is restricted to v1.1 and SP 2019 is restricted to v1.4.1, while SP Online has skyrocketed to v1.11. In practice, it means that neither 2016 nor 2019 can leverage the recent versions of React with hooks.

While the above diagram describes the standard roadmap, I’d like to offer another perspective. Instead of getting stuck on premises with old React, here is a different roadmap I suggested in a recent project:

Instead of SPFx 1.1, the idea is to simply leverage the Content Editor Web Part (CEWP) or the Script Editor Web Part (SEWP), which can host any script including modern React. It means that developers can already build , on premises, solutions that leverage modern scripting such as hooks or Fluent UI. In a migration the code can then be transferred to SPFx 1.11.

There’s a number of challenges with this approach and, although it worked in my case, it won’t fit every scenario.

  • First, SPFx comes with a Yeoman scaffolding tool that sets up the dev environment for you. Without SPFx you’ll have to find another way. Fortunately React offers a number of options, including the Create React App toolchain that I used. Version 4 was released on 10/23/2020. Compared to SPFx, it doesn’t come with SharePoint integration, such as no publishing or workbench. Also, there is no built-in property pane. It is not completely foreign to the Microsoft 365 universe though: the Microsoft Teams dev team has chosen Create React App as the foundation of the Microsoft Teams Toolkit.
  • Because you are leveraging the CEWP/SEWP, it also means that site owners will have access to the underlying code. SPFx does a better job at encapsulating the code.
  • As it is the route less travelled, you’ll also have difficulties finding code samples. But to be fair, recent SPFx samples won’t work on SP 2016 either.

If you are still developing on SharePoint 2016, hopefully this article will encourage you to get off the beaten path, and get better prepared for both SharePoint Online and Microsoft Teams. Feel free to share in the comments your challenges and successes!

Back to blogging!

It’s been almost 6 years since my last blog post…

There are many reasons for the long silence, let me just expand on one.

The period from 2015 to 2017 marked a shift for Office 365, with the move to modern and an explosion of new apps. We found ourselves in a long transition period, with Office 365 promising a lot but not delivering so much initially. Remember the one-column template for modern SharePoint home pages? Surely, because that was the only option 🙂 Remember the shift of SharePoint calendars from classic to modern? Certainly not, because it never happened (we finally got a modern calendar view a few weeks ago, in Microsoft Lists). Loops in Microsoft Flow? Not an option initially. The list goes on.

From a development and customization perspective, there was also some back and forth (who remembers Client Side Rendering?) which left me wondering where to invest next. A side effect of modern + open source was to kill my SPELL initiative. The modern development tools were very different from traditional JavaScript, with the rise of TypeScript. The PnPjs library did exactly what SPELL did – abstract the 365 REST API – except that it was backed by Microsoft and a very strong community. Sure, SPELL had its own strengths and was especially powerful with older SharePoint versions, but who is still on SP 2010 or 2013 today? (oh! The workflows, sure, but that’s a different story).

Fast forward to 2020. Microsoft 365 has come a long way. It reached maturity 2-3 years ago and has become the ubiquitous platform it was meant to be. The past 3 years have been exciting, although they didn’t give me much time to breathe, even less take a week of vacation. Finally I feel I have caught up on (almost) all fronts. That is, until the new wave of announcements next week at the MS Ignite conference

The bright side for me is that both client side development and the “maker”/”citizen developer”/”fusion dev” paths I was promoting 10 years ago, along with a few folks (yes, Marc Anderson was already a community pillar at the time!), those paths have now gone mainstream, and it has become easier to convince people that they just work 🙂

12 years ago I started this blog to share my SharePoint tricks, such as the “HTML Calculated Column” and the “Easy Tabs”. Today we have new technologies, and I have some new tips that I am ready to share. An upcoming topic will be “Property Pane Portals”, a technique I recently came up with to set up SPFx property panes.

Still on SharePoint 2016 and distant from the 365 buzz? I’d love to hear from you. The SPELL product itself is not relevant anymore on modern cloud, but works on SP 2016. More importantly, now is a good time to bridge the gap between classic and modern before you move to the Cloud. Actually one of my first new posts will be about client side solutions built on SP 2016.

Stay tuned! And as an appetizer, if you haven’t checked it out yet, take a look at the Power BI demo I published to the Microsoft Power BI data stories gallery. I’ll have a similar report ready to track MS Ignite next week!