Porting REST calls to SharePoint Framework

The SharePoint Framework (SPFx) is a powerful technology for developing web parts that run on both classic and modern SharePoint pages. SPFx is 100% client-side, and it’s often possible to reuse client-side JavaScript (from Script Editor or Content Editor Web Parts) in SPFx. This is usually straight forward if the original JavaScript targeted a single HTML element, since SPFx does the same thing: it hands you an HTML element and you inject your web part in there.

I was recently porting a JavaScript widget to SPFx and it all came over more or less as expected, except that the REST calls to SharePoint failed. All of them. Failed. Miserably. This article will show you the fix.

Continue reading

New Release of Widget Wrangler

When you’re writing a widget in Angular 1.x, it’s possible to pass configuration information into the widget using the ng-init directive, as shown in this example. (Angular 2 isn’t ready for widgets yet since there’s no way to put multiple copies on the page; Microsoft is working with Google on a fix. Here’s a sample.)

That works fine in Angular, but what if you’re using some other framework? The Widget Wrangler has a feature, the ww-appBind attribute, that allows you to bootstrap your own widget; this allows pretty much any JavaScript framework. But then how can you pass in configuration information?

The answer came from colleague Brian McCullough, who contributed a new feature to the Widget Wrangler. I have to admit I’ve been kind of swamped at work lately; he submitted the pull request more than a month ago! Well today Brian’s new attribute, ww-appConfig, is released in version 1.02 of the Widget Wrangler.

Here’s an example:

<div>
<h1>Knockout Widget 1</h1>
<span data-bind="text: textboxLabel"></span>:
  <input data-bind="textInput: message, event: {keyup: messageChanged}" />
  <i>
    <span data-bind="text:messageLabel"></span>:
    <span class="secret" data-bind="text: message"></span>
  </i>

  <script type="text/javascript"
          src="pnp-ww.js"
          ww-appName="MyWidget"
          ww-appBind="myWidget.Load"
          ww-appConfig='{"textboxLabel":"Enter a secret message",
                         "messageLabel":"The secret message is"}'
          ww-appCss='[{"src": "style.css"}]'
          ww-appScripts='[{"src": "https://cdnjs.cloudflare.com/ajax/libs/knockout/3.4.0/knockout-min.js", priority":0},
                          {"src": "script.js", "priority":1}  ]'>
  </script></div>

In this example, two labels are passed into ww-appConfig in JSON format.The Widget Wrangler passes the appConfig value to the appBind function, myWidget.Load(), which parses the JSON and makes it available to the Knockout application.

var myWidget = myWidget || {};

myWidget.Load = function (element, config) {
  myWidget.Config = JSON.parse(config);
  ko.applyBindings(new myWidget.vm(), element);
}

You can see the whole thing in action in this Plunk.

Thanks Brian, this is a great addition and your contribution was clean and ready-to-go!

ALM for Widget Solutions

Colleague and fellow SharePoint developer Brian McCullough asked a great question on Twitter:

tweetfrombrianc

This is such an important topic I thought it was worth more than a 140-character reply; hence this article. Whole books have been written on Application Lifecycle Management,and there are many facets beyond simple software deployment, but this article will focus on the baseline needs of a typical “widget” project:

  • Allow reliable and repeatable movement from a development environment to test and ultimately into production potentially across dozens or thousands of SharePoint sites
  • Support this not just once, but repeatedly as project versions are developed and released. If the project includes persistent data, this should be preserved (and perhaps enhanced) as part of the upgrade process

In a widget project, each “environment” may just be a couple of site collections; for example you could have site collections for dev, staging, and production all in the same tenant on farm. Since widgets run on the client side, there’s no need for them to interfere. If you’re on Office 365, you might want a First Release tenant to test your code with forthcoming updates to the platform while keeping your main staging and production environments on the standard release schedule.

Continue reading