In my end-user focused companion post Overview of the new SharePoint – modern team sites, pages, web parts and applications, I talked about the overall set of changes coming to SharePoint, but here I’m focusing on the new development model. I spent time with Microsoft engineers building the framework at a fantastic “dev kitchen” event earlier in the year, and have been playing with bits and forming thoughts since. I’ll cover an overview of the framework, and talk specifically about new building blocks – we’ll focus on client web parts, but will also touch on full page client applications that are also coming. To get started, even developers are visual people so take a look at what you’ll be working with in code terms in the editor (and note this is Visual Studio Code, the lightweight/free code tool that Microsoft now have):
Whoah, that looks pretty different to SharePoint development as you’ve seen it before! A couple of quick observations before delving deeper:
- The project structure is different – the “src” directory is where you edit your files, the “config” directory holds a bunch of config files (that we’ll walk through later) and so on.
- We have lots of new files. There’s a new web part manifest file (the new equivalent of a .webpart file), new config files to control how bundling works, what happens in the build process, how the solution gets packaged and more.
This is SharePoint development, but not as you’ve known it before!
Key aspects for developers
I’m condensing a lot of information into this list, but I think these are the key takeaways:
- Client web parts and client-side applications are the new building blocks. As discussed in the last post, these go along with the new page model.
- The packaging of artifacts is different! There are new manifest files to learn about (e.g. a web part manifest), and other files such as bundle.json, package-solution.json, upload-cdn.json and more. Gulp tasks are used for packaging.
- Files for your web part or app can live anywhere (e.g. a CDN, or a website you host) - they don’t have to live in SharePoint. Anywhere that can be accessed on a URL by the end-user basically.
- The “local development” model is very different – Gulp and node.js are used to host files locally, so you don’t need to use IIS on your local machine. A special “workbench.aspx” page is used to support this.
- You should consider learning TypeScript – at least the key parts such as modules, the type system and so on.
- You no longer NEED to work in Visual Studio - if you prefer another tool (e.g. because you’re not a “career” SharePoint developer), that’s fine. Other lightweight code editors such as Visual Studio Code or Sublime are now 100% viable options because the packaging of artifacts is different. Even I (as a 10 year SharePoint developer) have started to prefer using VS Code, even if some bits are slightly painful initially.
- SharePoint Webhooks – these are the new “event receivers”. This is a move towards a more standards-based approach to responding to changes in SharePoint/Office 365.
- The App Catalog is used as a packaging and registration method – both client web parts and client-side applications are packaged in this way (moving away from the web part gallery we’re used to)
- Page security needs some consideration – because anything on the page can theoretically access anything else (e.g. by scraping the DOM), that could raise some interesting questions when the user’s mail is shown (for example) and web parts from different sources/vendors are present. To counter this, some operations are blocked in the new framework but other governance may be required. More on this in the future.
The driver for the changes on the dev side is the new page and web part model. As discussed in Overview of the new SharePoint– modern team sites, pages, web parts and applications, the user experience of working with SharePoint pages and web parts has never been the slickest, and there was a lot of baggage from earlier SharePoint versions. So, since Microsoft were making big changes to the page model it also makes sense to move to modern web development approaches too. Yep, it’s interesting that things aren’t wholly based on MVC, but I’d argue most developers are choosing client-side approaches instead these days.
Client web parts – a simple example
I’ll provide a detailed walkthrough of files outside of the “src” directory and their purpose in a post coming very soon. The main code files in my example are:
|CobRecentDocsWebPart.ts||The core web part implementation (in TypeScript). Has a “render” method which is called by the page framework.|
|Search.ts||Encapsulates the code needed to call the search REST API with the right parameters.|
|SearchResult.ts||A simple class to represent the core properties of a search result that I’m interested in here – Title, Description, URL and file icon.|
- The TypeScript side of things
- Referencing other TypeScript modules
- The web part framework – interfaces and methods, how rendering can work etc.
- Understanding context – whether the code is executing in the test workbench page or a real environment
- How to define web part properties
But remember! This is preview code only, and some of these files and the surrounding “dev toolchain” may change between now and when the framework becomes generally available – all discussion at this point is partly just for illustrative purposes!
Once I’m ready to test/debug my code (and usually you’d do this WAY before you’ve added so much of your own code), you can see what things look like on your own machine by running “gulp serve” at the command line in the folder where your files are:
This does a couple of things, all taken care of by the developer “toolchain” that Microsoft give you (so long as you have the prerequisites such as node.js installed):
Your web part will then appear on the page and you can use browser tools for debugging etc:
You can edit web part properties in the new property pane (I’ve added some custom ones for my web part here):
But I need “real” SharePoint!
Of course, the local workbench page helps you get up and running and build presentation code, but sooner or later you’re probably going to need to see your web part in the context of a real SharePoint environment (e.g. so you can access data, call search/user profiles/taxonomy, or whatever). As you might have noticed, it’s possible to write code to detect the host environment and use dummy data if you’re running on localhost. The Workbench.aspx file provided by the toolchain can simply be uploaded to an Office 365 tenancy though, and again, so long as your files are being served you can add your web part to that page. This time, you can interface with real SharePoint things such as search and test your web part with real data – now my web part finds files in my Office 365 sites:
Deploying to production (e.g. deploy to CDN)
The preview developer tooling I’ve been playing provides some support for deploying to CDN – this is in the form of a Gulp task, which deploys to Azure BLOB storage/CDN based on a config file. Your manifest files need to be updated to point to your CDN URLs, but things basically are straightforward in terms of deploying assets to a production-ready location.
I’ll delve deeper in other blog posts, but remember that the framework isn’t available yet. You’ll be able to get your hands on things later this summer.
- Page-based apps – an alternative to provider-hosted apps (which remember, are implemented with server-side code).
- List-based apps – think of these as an alternative to JSLink for transforming the display/edit/new experience around list items
Summary and other resources
So, we now have a page and web part model that’s fast, lightweight, simple for end users, and nice to develop on. There are also new ways of solving common requirements around building mini-applications, but in a way which moves away from the very SharePoint-y building blocks such as JSLink and display templates that we had in the past, to a way where the implementer can choose how to build the UI using the approaches of their choice. Additionally, we now have an open development model more in line with the rest of the world, and great support for quick development without the need for Visual Studio and where much can be done without even having access to a SharePoint environment. Kudos Microsoft!
In future posts I’ll provide a more detailed walk-through of the framework and it’s key files.
- My general/end-user focused summary - http://cob-sp.com/ModernTeamSitesAndMore
- From Microsoft:
- VIDEO: Open and Connected Platform: The SharePoint Framework - https://youtu.be/T_bGyqKwT4g
- OFFICIAL BLOG - https://blogs.office.com/2016/05/04/the-sharepoint-framework-an-open-and-connected-platform/