SharePoint Framework

SharePoint Framework (SPFx) is a fantastic development model on top of (modern) SharePoint, for user interface extensibility, and it have evolved tremendously over the last year since it became general available. The framework is based on JavaScript extensibility in a controlled manner, compared to the older JavaScript injection mechanisms we used to extend (classic) SharePoint, that comes with a lot of power. Using SharePoint Framework our JavaScript has access to the whole DOM in the browser, meaning that we can do essentially what we want with the user interface – however, of course, we shouldn’t, only certain parts of the DOM are allowed/supported for modification.

If you are an ISV or SI with multiple clients and are interested in building SharePoint Framework (SPFx) solutions that you would like to re-use you will face a huge issue when it comes to reference SharePoint JavaScript files and reference your SharePoint Framework bundles. All these URL’s are hardcoded into your solution configuration files and requires you to update these files and rebuild for each and every client environment. And not only that even in your own development team this will cause issues if you don’t have a shared development environment.

Let me start with congratulating the SharePoint Framework team on an amazing job and an amazing journey reaching this GA milestone. A Big Thanks from the team here in Redmond to everyone who helped us to get to GA! #SPFx #SharePoint #SharePointFramework pic.twitter.com/czo2Duon7z — Chakkaradeep (@chakkaradeep) February 24, 2017 The SharePoint Framework plays a significant part of the SharePoint future, yes - this is only the first version with a lot of new features on the way, and it is a part of the new SharePoint wave.

One of the key parts of SharePoint Web Parts is the ability to have them configurable using the Web Part properties. This story is still true with client-side Web Parts in the new SharePoint Framework. In this post I will show you one of the more common scenarios; how to populate drop downs (and other fields) in the property pane dynamically. But also show you how what’s wrong with the current implementation.

SharePoint developers - we do like GUIDs, don’t we. We all read RFC4122 both once and twice. And now with SharePoint Framework and the goal to embrace all them Macintosh and open source people - they gotta have their fair share of GUIDs. And to aid with that the SharePoint Framework got some really nice GUID features, although a bit unpolished as you might notice - but this is all preview bits at the time of writing.

I guess that almost every application or solution you ever built has contained some portions of a logging mechanism. And how many of you have written your own - yup, all of you! But what about the SharePoint Framework - yes, it has built-in logging! How to log in the SharePoint Framework Logging is a very convenient and easy way to keep track of events happening, instead of having breakpoints, or in JavaScript even worse - alerts.

Do you write code that potentially can throw an error or an exception? Oh, you don’t - but sure you use a web service or external service or something that can throw an error. Well, it is you responsibility to handle the error and make sure to inform the user in a good way that something bad happened. With that I mean, do not show just a Guid. With the SharePoint Framework being all client side I think it is important to have control of your client side Web Parts and make sure that you properly handle and display error messages in a consistent way.

SharePoint Framework is all about rendering stuff on the client side, avoiding the long overdue ASP.NET Web Forms technology that SharePoint (Online) is still fundamentally based on. When rendering things client side everything is done asynchronously, to avoid locking down the UI threads and having a user experience that is fluent. In order to give the user good feedback that things are happening in the background, you need to have some kind of visual cue that tells the user - hey I’m doing stuff now, gimme a minute.

Summer is over, slacking time is over, it’s time to get up to speed and learn some new stuff. There’s very much to talk about this fall if you’re interested in SharePoint. And this fall I will do a couple of conferences as a speaker, which I very much looking forward to. TechDays 2016, Amsterdam For the first time I will attend and present at the TechDays 2016 in Amsterdam, the 4th and 5th of October.

At the Future of SharePoint event in San Francisco on May the 4th Microsoft announced the new and improved customization option and/or development model called the SharePoint Framework. This is a development model that solely focused on client-side development. There’s been some confusion going on on Twitter and other social medias and podcasts and I thought I should put together an Q&A post for this. This Q&A post is totally unofficial, all of this is currently in private preview and some comes from my (awesome) DevKitchen experiences, so things can and will change and I take no responsibility of any errors in this post or any financial, physical or mental issues caused by reading this.

Today is the day many of us have been waiting for since the big SharePoint event at May the 4th. The highly anticipated SharePoint Framework (SPFx) is here and announced in at the SharePointFest, in this blog post, as well as in the new Github repo for SharePoint. Personally I’ve been waiting for this even longer after being involved by the product team to give early feedback and also attending the first top secret DevKitchen “hackathons” where we could try out very early bits.

The Office Roadmap updates with the new announcements from the Future of SharePoint event has arrived (they arrived May the 4th to be precise). I’m back from the event and San Francisco and I’m full of the energy that the SharePoint team transmitted. You should specifically take a look at the In Development part here. That’s where we got the new and fresh stuff from the Future of SharePoint event.