SharePoint SPWidgets v3.0.0 (Beta)

Its been a long time since I have dedicated some love to SPWidgets – my SharePoint focused reusable widget library.  Well this post is evidence that I have not forgotten about it and continue to improve it so long as I continue to work with SharePoint.  This new version started back in 2016 (yeah, I know… this post is WAY late) and I have been using several of the new widgets included in version 3 on personal projects.  As the version implies (its a major number bump), these are not backwards compatible with v2.

Here is a quick list of all of the major changes included:

  1. This was a complete rewrite. Some widgets were dropped from the library as they were really not SharePoint specific.
  2. No more jQuery or JQuery UI. This means modern browsers only. In my usage, it works with IE11 as well, but that could go away in the future.
  3. The widgets are written in pure JavaScript, and embrace ES6 (transpiled down to ES5 in built version)
  4. No more use of requireJS and AMD pattern. The library is now using ES6 modules
  5. The development and build flow was moved to webpack (no more grunt)
  6. Utilizes Office UI Fabric for its style (CSS) and component markup (HTML)

The project is missing several things before I would consider it “stable” and ready to be released (drop the beta tag). Mainly, there are no test cases or documentation, thus my reluctance to make an official release at this time. This means that unless you are OK with digging into the code itself, you probably should stay away for now.  Also, the interactions with SharePoint are still using the old SOAP API interface, which although it is deprecated with no timeline for removal, it really should be upgraded to use the newer REST interface.

That being said, I am currently using all of the widgets in this new version in production projects and they are holding up well against (my) real world use cases. Note however, that in my usage, I bring in individual widgets as dependencies instead of attempting to load the entire library. Example:

import PeoplePicker from "SPWidgets/src/widgets/PeoplePicker/PeoplePicker"

const picker = PeoplePicker.create({...});


You can also play with some of the widgets here:  jsbin – but again, remember: there is no documentation, thus you should look at each widget for how to initialize it.  The quick tutorial is: all widgets expose a static create method to initialize an instance.  All Widgets have their supported input options defined at the end of the source file.  Sorry – the best I can do at this time 😦


What I learned

When I started this major version, back early 2016, my goal was to move towards using the newer features of JavasScript (ES2015, aka ES6) while at the same time move towards more modern toolset and build pipeline.  This was my first time working with Webpack, and soon after seeing how easy it was to integrate with and how it improved the overall development workflow, I was determined to convert all of my project to it. Doing so also removed several tools from the workflow, which in turn decreased complexity and streamlined development.

This rewrite effort also required that a new style library be selected for the new widgets – jQuery UI is just no longer the answer. Office UI Fabric was still in its infancy and sounded like the obvious choice for solutions being developed for SharePoint. v3.0.0 of SPWidgets is built on top of:

  • Office UI Fabric Core (link) – the CSS style library, and
  • Office UI Fabric JS (link) – The styles for the pure JavaScript components (only the styles are used out of this library)

This is where I have some regrets, at least the way I chose to go about implementation. First, Office UI Fabric JS seems to now be dead – there is no effort ongoing into making pure JS components out of Microsoft – React components seems to be their path forward.  I used this library to grab the HTML (markup) for each of the widgets currently in v3.0.0 and then added my own JavaScript controller to them. The styles, however, I did not bring in and instead assume that a user of my widgets will instead load the styles sheet on to the page.

The second mistake I made was to introduce the dependency of requiring that the above CSS libraries be loaded onto the page and available globally, thus incurring the cost of loading a large set of CSS just to use one single widget. What I should have done was to ensure that each widget’s Styles were self-contained and thus free of external dependencies.


What’s Next

I’m not really sure if I will put in the time to work on test cases and documentation in order to make this an official release. As Web Components seem to now be picking up steam, I think the more logical path forward will be to move these widgets (yet again) to Custom Elements, thus truly supporting a declarative (as opposed to the current imperative) approach utilizing the native web platform. This will truly realize the vision I have for this library: to be truly and transparently supported across any framework or library.

If you follow this project on Github, check back in every once in a while to see if I have pushed through a feature branch. 🙂

And, as always, if you would like to get involved, reach out to me directly.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s