RequireJS Arrives in SharePoint Online Build 16.0.4230.1217 (Or Earlier?)

Marc Anderson

by Marc D Anderson on 8/12/2015

Share this:

Article Details

Date Revised:

Applies to:
RequireJS, SharePoint Online

Ever watchful – and talented – guy that he is, my friend Paul Tavares (@paul_tavares) pinged me the other day on Twitter with a question.

Hey. Question. On your O365, did you add RequireJS as a SOD? Noticed it was registered when I looked at the page code the other day.

Paul has a Site Collection in my tenant that we share for R&D and I certainly hadn’t done anything, so we went back and forth on it a bit.

If you do a View Source on a SharePoint Online page, you may well see this line:

<script type="text/javascript">RegisterSod("require.js", "https:\u002f\\u002f16148\u002f_layouts\u002f15\u002f16.0.4230.1217\u002frequire.js");</script>

This tells me that my tenant is on build 16.0.4230.1217. It’s on First Release, so it may be ahead of the build you see in your own tenant.

The net-net of that line is to load RequireJS if it is needed using SharePoint’s SOD (Script On Demand) framework. It’s a little funny to me that this is happening, because RequireJS’s primary purpose in life is to help load script files when they are needed (among other things), which is exactly what SOD does!

RequireJS is a great resource that helps you load files - be they JavaScript. HTML, CSS, or really anything else – intelligently into SharePoint pages (or any other type of Web pages). I’ve used a similar library called LABjs in the past, and when Andrew Connell (@andrewconnell) and I were talking about this, he told me I’m already out of the loop and I should be using SystemJS. Whichever library you choose to use, the basic idea is something like this (borrowing the example from the RequireJS documentation):

First, you add one script reference into your page. I usually do this in the master page.

<script data-main="scripts/main" src="scripts/require.js"></script>
 This one reference can bootstrap your entire application!

Then in main.js, you can build logic to do whatever you want.

requirejs(["helper/util"], function(util) {
  //This function is called when scripts/helper/util.js is loaded.
  //If util.js calls define(), then this function is not fired until
  //util's dependencies have loaded, and the util argument will hold
  //the module value for "helper/util".
 I’ve got a whole little system that I’ve come up with that takes that bootstrapping idea and pulls script files in based on the current URL so that the right script runs on any given page, whether it is a specific list form, any list form, a site home page, etc. This is an entirely different way of thinking about deployment of code to a Site Collection that stays away from the App Add-in model completely.

The good thing here is that if you want to use RequireJS in your applications it’s there for you by default – in SharePoint Online, at least. Paul and I have no idea when it showed up, but it’s a good thing.

I’ve also exchanged some tweets with Jeremy Thake (@jthake) at Microsoft and he tells me that RequireJS is there, but that we maybe shouldn’t rely on that fact. I’m hoping that more information will be forthcoming soon, as offering libraries like this is a great example of the concept I talk about which I call “Functions as a Service” or FaaS. By that I mean that we (Microsoft, software vendors, consultants, companies, etc.) should offer JavaScript functions to the people in our organizations. By making it clear what functions are there and how to use them wisely (yes, there’s a documentation onus here), we can build a more collaborative development ethos as a win-win-win across our organizations.

You can find Mark's original blog post here, plus the comment. Worth a read.

Topic: JavaScript and jQuery

Sign in with

Or register