Web Parts Are Back at the Center of SharePoint Development!

Wictor Wilen

by Wictor Wilen on 5/5/2016

Share this:
Print

Article Details

Date Revised:
5/5/2016

Applies to:
Node.js, NPM, SharePoint 2016, SharePoint Framework, TypeScript, Web Parts, Workbench, Yeoman


Today at The Future of SharePoint event, Microsoft announced the next iteration in SharePoint development—the SharePoint Framework. As one of the old ones who started with the Digital Dashboard Resource Kit, to the COM+ event handlers in SharePoint 2001, over to custom built DDFs, to WSPs to apps and add-ins—this new framework is a very welcome change.

For years, SharePoint developers have been forced to walk in shame in the outer rims of the developer guild. It's been so hard to get over the threshold and once you were over it, there was very few who actually returned to a normal life. I've been struggling for years to get ASP.NET or web developers to get on over to SharePoint development with no luck. The Add-in model did not help in any sense here and just introduced new pitfalls and confusions.

Introducing the SharePoint Framework

Last year at the MVP summit we were informed by Jeff Teper (I'm so glad that he's back on the team) that Microsoft had some cool things cooking in Redmond. He, and the team, told us that they were here for the long run and that they were building something new that would supersede the current existing extensibility model. And in February this year, I went to Redmond to try this out with my own set of hands at an event called the DevKitchen. This event, where we all were introduced to this new model, is one of my top moments in my Microsoft developer career, and the interaction we had with the engineers was just phenomenal. I am looking forward to the next one, Dave! I do believe that our trial and errors and feedback made the end result so much better.

What we got our hands at that DevKitchen was the new extensibility model, now called the SharePoint Framework. In my opinion, this is an evolution of SharePoint, adapting to a more modern way of building applications. It's not replacing Add-ins, and they are not replacing WSPs and server-side code. It's another tool in our toolbox—albeit it might be the one I will use first from now on.

This new SharePoint Framework consists of a couple of different parts. You can read more about it in Bill Baers post: The SharePoint framework - an open connected platform.

Web parts are back!

The one thing that excites me the most about this new SharePoint Framework is that web parts are back, with a bang! Web parts are what brought me into SharePoint. In the previous millennium, we built our web parts using VBScript and they were pure client-side code, until they appeared in SharePoint as a server-side component, and then adopted in ASP.NET as a standard feature. Unfortunately, web parts have had some very dark times, and that was when the apps/add-ins entered the scene and introduced app parts—an abomination.

Well, let's forget the past and look at the new client-side web parts. Web parts are back as a client side thing. Client-side web parts are now built (preferably and initially) in TypeScript. They are very similar in their construct as web parts; they can be initialized, persisted, have properties, and of course a way of rendering them. These new client-side web parts will live side by side with the old and traditional web parts.

Fun fact: I think I was the one person, external from Microsoft, that actually built a client-side web part that worked.

Using client-side technologies isn't something new; the only new thing here is that we now have a proper and supported framework for it. Client-side technologies are not perfect either, with access to the DOM we are given great powers, but we do this all the time today.

The SharePoint Framework is all built on open technologies and you can use whatever platform you prefer. The initial release of the SharePoint Framework will be built for TypeScript, Node.js, Yeoman and npm. These are four technologies that you should read up on before the SharePoint Framework starts to roll out this summer. All you need to build you solution is a command prompt and Visual Studio Code.

Since this is all client-side rendering (i.e., JavaScript) you can use any framework of your choice; Knockout, Handlebars, jQuery, React, Angular 1.x and 2; you name it.

The very first client-side web part

Just to give you an example on how these client-side Web Part work and so that you can see how similar they are to the web parts we are familiar with building, here's how you would create a simple, client-side web part.

Disclaimer: Things below here can most certainly change until GA of the SharePoint Framework.

To prepare your environment, you need to install Node.js and npm and the Yeoman generator, which will take care of the project scaffolding for you. Then you download the specific SharePoint generator using Yeoman and start the scaffolding (exact command to be determined; hopefully yo sharepoint).

What you get is a set of files, just like when creating a new project in Visual Studio. All code files are TypeScript files and the Yeoman generator will create one specific file for your web part TypeScript class. This TypeScript class will inherit from a base class as follows:

export class FutureOfSpWebPartWebPart
   extends BaseClientSideWebPart<IFutureOfSpWebPartWebPartProps>{
    ...
}

As you can see, my client-side web part extends the BaseClientSideWebPart abstract class. The generated code also includes overrides of some of the methods. Also notice how there's an interface definition passed in as a template argument to the base class:

export interface IFutureOfSpWebPartWebPartProps {
    description: string
}

This interface is used to define the properties of your web part; in this case only a description property of the type text.

In the generated file there are, by default, three overrides; the constructor, the render method and a property called propertyPaneSettings. For this post, let's just focus on the rendering of the web part.

public render(mode: DisplayMode, data?: IWebPartData) {
    this.domElement.innerHTML =
       `The Future of SharePoint is <b>awesome</b>!`;
}

This method is responsible for rendering the client-side web part, and in order to do that we have access to the actual DOM element, through the this.domElement object. With that we can manipulate the DOM as we like, and in this case just insert HTML directly into the element. We can also, in this method, setup any bootstrapping we want for our favorite framework, we can check the mode to see if we're in edit mode or not, and we can get properties using the data argument.

Once we're done building our client-side web part, we, of course, would like to take it for a test ride. And now over to something really cool. Remember that when building web parts, you need either your own virtual machine or an Office 365 subscription with internet connection. No more! You can sit on an airplane (like I do now) and just run the gulp task called serve. This task will wire everything up, start your browser and open up the Workbench, which is a local offline canvas for the new page model and you can work with your client-side web part. If you need any changes to it, just modify the TypeScript file and the task will take care of compilation and reload your browser. Can't be easier.

Of course this method has no access to SharePoint data or the Graph, so you need to work with mock data—which generally is a good idea anyway!!

Then, when you're ready to go, test with live data you can use the Workbench that will be present in SharePoint (not available until later this summer, I'm told) and there's also gulp tasks for packaging it properly so that you can either upload and host your client-side web part script files in either a CDN or in SharePoint itself.

I think this is more or less exactly what I've been longing for in this area. SharePoint team—you nailed it!

Make sure to check in this video by Daniel Kogan in which he walks through the new framework, page model and how to build a client-side web part.

Client-side applications

There's also a concept called client-side applications. This is the new way of customizing lists and libraries. In a nutshell, you register a client-side application for a list or a library and then you are solely responsible for rendering the user interface, in a similar fashion as above. I can't wait to see what awesome stuff people build with this. But, that's for someone else to write about, or me at another time.

Impressed?

How do you feel about this? I think this is a fresh re-start of the SharePoint oil tanker and I welcome all the new thinking in this space. Yes, we have to re-learn quite a lot of stuff, but I love that. And honestly people, SharePoint developers have been the laziest group of developers out there (except for some Cobol veterans) and they have been very afraid of changes (remember when all people screamed for their life when the App model came?). Get out of your comfort zone, learn new stuff, build cool stuff and enjoy SharePoint land once again.

SharePoint is back and web parts are back!

You can see Wictor’s original post here: http://www.wictorwilen.se/web-parts-are-back-at-the-center-of-sharepoint-development

Learn more about the topics in this article and more at Unity Connect Online, June 20-23, 2016. Sign up today!


Topic: Development

Sign in with

Or register