Friday, March 10, 2017

Perhaps the only SharePoint Framework web part you will ever need

Ok, that’s not entirely true, but it might come in handy for sure…

[Update 2017-03-13]
This post sparked some action over the weekend on twitter and Facebook, and as a response Pat Miller at Microsoft put out one guidance article and one post with thoughts around the web part. The first one, How to block webparts from noscript sites, goes into detail how you today can mark a SPFx in a way so that you cannot add it to non-script sites (Group sites, Delve blog, sites where script is turned off etc.) Once this capability moves from the developer to the IT admin it's way better than any CAS policy we ever had back on-premises. The other is an issue titled General thoughts on a modern script editor webpart, which explains why Microsoft did not deliver this out of the box themselves.

Both of them are must-reads in my opinion to better understand how Microsoft think about governance in SPFx.

[Original post]
Unless you are all new to SharePoint pages, the chance that you have used at least one script editor web part or a content editor web part is pretty high. With the advent of the SharePoint Framework, Microsoft has given developers a way to create JavaScript solutions for modern pages. If you however have some small snippets or existing code, going the whole SPFx route might be a bit overkill.

Which is why I created a script editor web part for modern pages. Simply paste in any script or html, and it is rendered on the page.


Code can be found at the sample SPFx web part github repo from Microsoft. Also a big thank you to Waldek for always being helpful and helping me with how to load a script async in SPFx.

The code works by loading each <script src> in sequence, and then executing any other script block. So if you have script dependencies, simply list them in the right order and it should just work.


  1. Would that this were a simple thing they would put in the product. As it is, sticking to "classic". But I'll try it out!


    1. My view is like this. I created the part to re-use existing bootstrap tour code, as well as some other mini-widget code. Nothing which manipulates the DOM. Using this one part saves dev time as we don't have to re-wrap everything into SPFx. And to be honest, it takes time to new up new parts, package and deploy.

      For larger solutions needing wp props etc, I'm all for isolated parts, but that's not needed all the time. As for people worried about script injection/manipulation, that's governance on any .js solution - being added in a part like this or via a SPFx custom part.

      As long as we're on the page, we need to play ball and stay with the rules. If you want the same weather as an SPFx proper, Waldek has a post on that :)

  2. As I've said elsewhere, so much of what we build has an n of 1. It doesn't make a lot of sense to do all this scaffolding and bundling just to get that [highly valuable] functionality into one page.

    Add to that the IT culture in most organizations of "No", and without a mechanisms like this the very people who use SharePoint get left out in the cold. Oftentimes, it's the business people that hire us to do client side development *precisely* because they can't get IT to give them the time of day, and they have real business needs.


  3. Now........ a content editor web part for the SPFx :) The "content link" property made it the most powerful web part created. Complete freedom.

    1. You can do a PR and add it :) The reason I didn't add is that there are no oob file picker controls available yet.