It has been about a week since Microsoft unveiled “The Future of SharePoint” at this event here (note: you have to provide your e-mail and some other info to get access to all the content). The keynote has kind of a general overview of all of the new directions that the SharePoint team is heading with Office 365 and SharePoint Server 2016 and there are a number of breakout sessions that drill down a bit deeper into some of the newer stuff. And of course you can find additional overviews and insights from entires on numerous blogs from both Microsoft and elsewhere
In short, changes are coming to SharePoint and in some cases they’re already here. The keynote from the event above discusses some of the release timelines but users like myself who are signed up for a “first-release” tenant on Office 365 have seen this in action because Microsoft has already rolled out a new document library experience to those using this setup. Typically how it goes is first-release tenants get the new features and functionality pushed out to them first. Certain aspects of these are refined over the course of a number of months or so — with some opportunity for community feedback and/or bug reports — and then once everything is ironed out, the “new stuff” gets pushed out to all tenants. This recent notification appeared in the document library on first-release tenants.
Which, when the button is clicked changes the experience to this…
If you have a first-release tenant, try it out! Activate this new look and click around, upload some docs and absorb the new experience. This article here lays out some of initial thoughts on some of these new implementations and features. The old document library was steady, useful and reliable, but all in all I don’t think many would argue that the new document library isn’t a much sharper and slicker experience. It’s responsive in every sense of the term. It’s responsive in that it scales down for tablet and mobile views which is really nice! It’s also responsive in the sense that the responses to interactions and events (clicks, drag-and-drop, etc) are practically instantaneous making for a very snappy experience. It’s exciting to see the SharePoint team taking things in this direction and we look forward to seeing all the other areas of SharePoint moving to this new UI / UX.
So the new UX and visuals are great but naturally this raises a number of questions from a technical or developer perspective related to what’s going on “under the hood.” How is this new experience put together codewise compared to the “old SharePoint?” If one makes the assumption that this is the direction that Office 365 SharePoint is headed in the future — not just for document libraries but for all other types of sites and pages — what impact will that have on existing 3rd party products and services? What will this mean for custom development on the SharePoint platform on Office 365? Do we still use the old JSOM, CSOM, and REST APIs? Will we be able to brand this new experience? These are all questions that inquiring minds want to know, so we should look under the hood and see what we can find.
The SharePoint Framework
Microsoft has provided some insight on what the future of SharePoint development will look like with the release of their SharePoint Framework a modern toolstack using Node.js, Gulp, Yeoman, and TypeScript which is fantastic news to know that things are gearing towards open and popular technonology stacks that are familiar to many developers. This video here shows an approach used to build a webpart on the new platform. There’s some really cool stuff there. Particularly interesting is that with this toolset you can develop SharePoint web parts locally on your own box by running a localhost server via Node.js. You do not even need a connection to Office 365 to develop for it!
The Yeoman tool, being a project generator, will probably give you an easy way to generate all the necessary boilerplate code needed to create a web part from the new updated SharePoint publishing platform. If you wanted to add only the files you need manually or you wanted to use a different build tool like Grunt I imagine it wouldn’t be too difficult to swap any of that in if you really wanted to. Such is the flexible nature of these tools and it’s really great to see Microsoft and the SharePoint team embracing community driven development projects and tools.
Whatever you decide to use, this is an exciting new aspect to SharePoint development. The SharePoint Framework is targeted for release in the summer of 2016 and we will be looking forward to diving into all that it has to offer when that time comes. But until that time comes we will just have to wait patiently. Fortunately there are many parts of the new developments emerging in SharePoint that we can check out in the meantime.
Looking Under The Hood in the New Document Library
We mentoned earlier the new document library experience probably gives us some indication of what the new SharePoint experience will look and feel like as Microsoft rolls this new functionality out. But I wanted to take a slightly deeper look at this new UI/UX from a more technical examination of how it’s put together. So let’s pop open our developer tools on this new document library page (with the new experience enabled) and type the following in the console tab…
SP
Which gives us…
Uncaught ReferenceError: SP is not defined(...)
Wow! If there was any doubt at all that this new experience wasn’t going to be different, that just went right out the window! SP, the main object which contains basically *all* of the SharePoint JavaScript objects and methods with the current iteration of SharePoint is not present in the new pages! This is a substantial revelation and all things being equal it means that the SharePoint JSOM (the JavaScript Object model for SharePoint) is either a) going away entirely or b) is going to be substantially different than it is right now. We will explore whether we can still harness the SharePoint REST APIs a bit later on. But before we do that let’s dig a bit further under the hood and see how this new page is put together
If we pop open our dev tools and look at the files under what appears to be the SharePoint CDN domain (the CDN that serves up the SharePoint files) we see two very noteworthy inclusions. The popular JavaScript AMD style module loader RequireJS and the MVVM data-bound-to-UI rendering library Knockout.js. So, in similar fashion to the tools described in the SharePoint Framework above, it definitely appears that Microsoft is moving towards a much more modern client-side application implementation using two popular JavaScript libraries toward this end. And as we click through the various JavaScript files being served up from this domain, sure enough we see the “define”” and “require”” initialization functions in the format that that are recognizable fingerprints of RequireJS.
And as we inspect the DOM, we see Knockout templates throughout…
So it seems this new document library page is using client-side rendering and functionality with Knockout.js and RequireJS.
Another notable inclusion is the rendering of CSS directly in the page. This is because, as I discovered on further investigation, that the CSS for the new document library page is also included as a module and loaded via the same mechanism of RequireJS.
It will be interesting to see how this approach to styling SharePoint fits into how we will be able to brand this new experience.
So at this point even though we only have a cursory understanding of the new approach that SharePoint is using for newer pages, from what we have seen so far we can actually possibly say that this probably represents one of the biggest fundamental changes to SharePoint that has occurred for quite some time. SharePoint is getting faster, leaner, and modern in its technology stack. In terms of where we are all starting from when it comes to custom development, there will be an entirely new paradigm in which we’ll all be operating. This is going to have a substantial impact on current 3rd party products and all custom SharePoint development services going forward in the future. When it comes to Office 365, custom master pages (and master pages in general), it seems, are gone and are not coming back. Microsoft has actually been saying this/warning for awhile, but it seems it is finally happening.
So… when it comes to developing for these newer pages all we can do from here is start at square one. To do that we should probably a take a look and see if we can at least get *any* custom scripts and/or CSS to run in this new document library page. So to do that, we need to get set up to see whether we can still run custom scripts in this new page. We can only really do what we know at this point, so for this we will turn to custom actions.
We know that the SP object still works on other pages so let’s see if we can create a custom action via JSOM for our site collection and see if it will still run in the new page. For those not familiar with the term, a “custom action” is a way to tack-on the addition of a script reference in the <head> element of a SharePoint page. This is how you can add custom scripts without having to modify the master page and manually add script references. Pop open SharePoint Designer and connect to the site collection that you’re working with. Click on “All Files” on the left and create a new folder on the filesystem called “scripts”.
Create a scripts.js file by clicking on the “File” tab in the ribbon and choose “JavaScript.” Change the name of the JavaScript file to “scripts.js.” In this newly created “scripts.js” file place the following code…
console.log("We are running custom.js");
So if we can get scripts to execute on the new document library page we should see this message in our console. So let’s add a custom action to our site. Obviously there are different ways to deploy a custom action, but we’ll just do this using JSOM as this is probably the quickest and easiest way to do it. Since we already know that won’t work on the new document library page go to a non-document library page (e.g. site contents, site settings… one that does have the SP object), open up your developer tools and in the console paste in the following.
var setCustomAction = function(name, url) {
SP.SOD.executeFunc('sp.js', 'SP.ClientContext', function () {
var clientContext = SP.ClientContext.get_current();
var web = clientContext.get_web();
var customActions = web.get_userCustomActions();
clientContext.load(customActions);
clientContext.executeQueryAsync(function () {
customAction = customActions.add();
customAction.set_title(name);
customAction.set_location("ScriptLink");
customAction.set_scriptSrc(url);
customAction.set_sequence(100);
customAction.update();
clientContext.executeQueryAsync();
});
});
}
This creates a function expression that we can use to set a custom action. So after this type the following into your console and hit ENTER…
setCustomAction('test', 'https://yourtennantname.sharepoint.com/sites/sitecollectionname/scripts/scripts.js');
where “yourtennantname” is the name of your Office 365 tenant and “sitecollectionname” is the name of the site collection you are working on (the one where you put the scripts folder and scripts.js file earlier).
Now if we refresh the page we can see that our custom script is running because we see the “We are running custom.js” message logged to the console. But this is for the “old pages” and we already knew it would work. Now for the moment of truth, if we go to the new document library, will we still see this message? Drumroll please…
Yes we do! So, even though from the little bit that we do know at this point (that the “new SharePoint pages” are going to be so different that it doesn’t even include the SP object), the infrastructure to run custom actions is still present in the new pages and it still respects the custom actions that are registered to the site. So this gives an entry point to get our scripts to execute on the new document library page. However, I feel that I should point out an indication that this may not remain in place. In this post on the Office blog about the SharePoint Framework in answer to the question “Will new document libraries support customization?” the entry there says as follows…
Solutions that are currently deployed that make use of this mechanism should continue to work as before, with actions appearing in the new command surface in addition to the Ribbon in classic mode. CustomActions that deploy script, JSLinks, and additional web parts on the page are currently not supported. Environments that require these unsupported features should continue using classic mode for the time being. (emphasis mine)
So, this is perhaps an indication that this might not be in place forever… even though from a technical sense it appears that the capability to run custom actions is still there. With all of the accommodation that Microsoft is making towards developers if there is enough demand for keeping script link custom actions in place this may change, or it’s possible that it takes on a different form. We will have to see how it all plays out.
Using the REST API
Now since the SP object is not in place, as we saw earlier, doing JSOM on the new document library page isn’t going to work. However, there are still REST calls that we can make to accomplish similar aspects of functionality that we could using JSOM. Let’s see if this works. In SharePoint designer, paste the following into your scripts.js file…
var SharePoint = SharePoint || {};
SharePoint.CustomUtilities = SharePoint.CustomUtilities || {};
SharePoint.CustomUtilities = {
ajax: function(type, url, successCallback, errorCallback) {
var xhr = new XMLHttpRequest();
if(typeof type === 'undefined') {
type = 'GET';
}
xhr.open(type, url, true);
xhr.setRequestHeader("Accept", "application/json; odata=verbose");
xhr.setRequestHeader("Content-Type", "application/json; odata=verbose");
xhr.onreadystatechange = function() {
if(xhr.readyState === 4) {
if(xhr.status === 200){
if(successCallback && typeof successCallback === 'function') {
successCallback.call(this, xhr.responseText);
}
} else {
if(errorCallback && typeof errorCallback === 'function') {
errorCallback.call(this, xhr.status + ' - ' + xhr.statusText);
}
}
}
};
xhr.send();
}
};
This will create a simple function that will get us info on the pages library in our site. Now on the new document library page let’s refresh the page and then run the following in our console…
SharePoint.CustomUtilities.ajax("GET", _spPageContextInfo.webServerRelativeUrl + "/_api/web/lists/getbytitle('Pages')/items", function(data){ var r = JSON.parse(data); console.log(r.d.results); });
And now when we hit enter there will be another moment of truth. Drumroll (again) please…
And yes we get data back on the pages library logged to our console! So even though JSOM in the new document library is not present in the way that we have known it, REST API calls using the old endpoints are still possible. Really, because of the way that REST works within SharePoint I kinda expected that this would be the case… (though stranger things have happened). Could this be an indication that Microsoft is pushing developers toward using the REST APIs for apps and custom development? Note too that _spPageContextInfo is still around (which is good). It even has a few more properties on it. I’m particularly curious as to what _spPageContextInfo.killSwitches is. But not all changes appear to be entirely innocuous. Another aspect to the reality that REST still works in the new document library page but SharePoint JSOM does not is that not everything that you can you do in JSOM (or CSOM) has a corresponding approach using the SharePoint REST APIs… at least as far as I can tell. Perhaps the most glaring example of this is the managed metadata service i.e. using the term store for any number of purposes within your SharePoint applications. The term store has long been used for many different types of menus and displays within SharePoint. With JSOM gone if the “new pages” don’t have a way to get at the term store from the client side in JavaScript, what does this mean for future development work utilizing the term store? I suspect the same may be true for other aspects of SharePoint as well.
In some sense a number of the points discussed above are speculative and there are a great number of assumptions made with regard to what the future holds. There is no guarantee that anything is set in stone yet. But it’s very clear that a substantial amount of effort has gone into building this new architecture, so in all honesty it seems unlikely that Microsoft would put this amount of effort into engineering this new experience without it being a substantial part of the direction that the SharePoint development team is heading.
After you are done experimenting with the new document libraries pages, you will probably want to remove your custom action if you are not using a throwaway site collection. Here is the code to do that…
var removeCustomAction = function(name) {
SP.SOD.executeFunc('sp.js', 'SP.ClientContext', function () {
var clientContext = SP.ClientContext.get_current();
var web = clientContext.get_web();
var customActions = web.get_userCustomActions();
var customAction;
clientContext.load(customActions);
clientContext.executeQueryAsync(function () {
var customActionEnumerator = customActions.getEnumerator();
while (customActionEnumerator.moveNext()) {
var currentCustomAction = customActionEnumerator.get_current();
if (currentCustomAction.get_title() == name) {
customAction = currentCustomAction;
}
}
customAction.deleteObject();
clientContext.executeQueryAsync();
});
});
}
And you can run it like this…
removeCustomAction('test');
This will remove our sample custom action that we have used to play around on our site collection.
Conclusion
In the preceding paragraphs we have looked at what appears to be the future of SharePoint development. We have seen that if the new document library page indicates the direction that all of SharePoint is moving for the future, it represents a fundamental change in how SharePoint development is done. There’s no doubt that it will impact many existing SharePoint products and service based custom SharePoint development will change rather substantially. In upcoming entries we will look to see how we can harness some of this new infrastructure and “hook in” to some of it to customize our experience with our own functionality and branding. As more of this new SharePoint rolls with the accompanying tools like the SharePoint Framework, we will explore the exciting possibilities that these changes bring. So until next time, happy SharePointing!
Excellent Article.