Creating Reusable React Components for SharePoint Framework Solutions

Lessons Learned from the #SPShire Project

This is the one of my lessons learned from the Shire Hub Intranet project, based on the forthcoming SharePoint Communication Sites.

The lessons in this blog series are:

  1. Previewing and Opening Office Documents from the SharePoint Framework
  2. Using the OneDrive File Picker in SharePoint Framework Solutions
  3. Creating Reusable React Components for SharePoint Framework Solutions
    (this article)

This project on github contains the sample solution for all three articles.

Continue reading

Using the OneDrive File Picker in SharePoint Framework Solutions

Lessons Learned from the #SPShire Project

This is the one of my lessons learned from the Shire Hub Intranet project, based on the forthcoming SharePoint Communication Sites.

The lessons in this blog series are:

  1. Previewing and Opening Office Documents from the SharePoint Framework
  2. Using the OneDrive File Picker in SharePoint Framework Solutions
    (this article)
  3. Creating Reusable React Components for SharePoint Framework Solutions

This project on github contains the sample solution for all three articles.

Continue reading

Previewing and Opening Office Files from the SharePoint Framework

Lessons Learned from the #SPShire Project

SPShire

I’m thrilled to be part of an early adopter project building a new intranet for Shire Pharmaceuticals based on the forthcoming SharePoint Communication Sites. Shire is an exciting and innovative company, and the team includes a number of my fellow Microsoft MVP’s as well as teammates from BlueMetal. Last week Microsoft broadcast a webinar from the Boston MTC featuring a cross-section of the development team. Microsoft’s Mark Kashman promised we’d post some of the lessons learned in the project, and this is one of those postings.

The lessons in this blog series are:

  1. Previewing and Opening Office Documents from the SharePoint Framework
    (this article)
  2. Using the OneDrive File Picker in SharePoint Framework Solutions
  3. Creating Reusable React Components for SharePoint Framework Solutions

This project on github contains the sample solution for all three articles.

Continue reading

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

Calling SharePoint CSOM from Azure Functions (Part 3)

Now that a skeleton the Azure function is written and registered in Azure Active Directory, it’s time to add code to call the SharePoint Online Client-Side Object Model (CSOM). Much of CSOM is generated from SharePoint’s server-side API, making it by far the most complete API for SharePoint Online.

In this article you will complete a simple example of calling CSOM from an Azure Function. The completed code is in a gist here.

Continue reading

Calling SharePoint CSOM from Azure Functions (Part 2)

This article will show you how to register an Azure Function as an application in Azure Active Directory so you can call other web services under the application’s identity. This allows you to securely authenticate the Azure Function, and to elevate permissions (i.e. the Azure Function can do things that its caller doesn’t have permission to do.) You can think of this as the cloud equivalent of a service account: it’s an identity that represents an application instead of a person.

Continue reading

Calling SharePoint CSOM from Azure Functions (Part 1)

In old-school SharePoint, if you wanted to run some custom code in a web part, workflow, form, or event handler, you wrote either a sandboxed or a farm solution. Neither of these are supported in SharePoint Online. So what are developers supposed to do when they need to run some code somewhere other than the web browser? How can they run code in the background, elevate permissions, or fill gaps in the “out of the box” configuration options?

The modern answer is Azure Functions. It’s a much better sandbox than SharePoint used to have, yet, like a sandboxed solution, you don’t have to worry about where to put it. Just choose what will trigger your function, such as a web service request, web hook, Service Bus message, or a time schedule. Then pop in your code and you’re good to go. They call it “serverless” computing, but there are servers somewhere! You just don’t need to worry about it.

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!

HTML Templates and CSS in SharePoint Framework Apps

“The time has come,” the Walrus said,
“To talk of many things:
Of template files, cascading styles,
And bundles made of strings,
And why SharePoint is boiling hot,
And whether pigs have wings.”

Like many SharePoint developers of late, I’ve been exploring the SharePoint Framework (SPFx), doing experiments, and porting code over to the new web part model. Something that perplexed me at first is how to handle HTML templates.

On the client side, I mostly work in AngularJS 1.x (Angular 2 isn’t ready for web parts yet since it only allows one instance of an app to run on a page at a time). And we Angular developers just love our templates! So how to manage them in the SPFx development environment? This article will show you how, and it will also clarify the mystery of CSS modules, which end up being related to HTML templates.

Continue reading

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