Single-Page Applications (SPAs) in SharePoint Using SPServices – Part 1 – Introduction
- Single-Page Applications (SPAs) in SharePoint Using SPServices – Part 1 – Introduction
- Single-Page Applications (SPAs) in SharePoint Using SPServices – Part 2 – GetListItems
- Single-Page Applications (SPAs) in SharePoint Using SPServices – Part 3 – GetListItemChanges
- Single-Page Applications (SPAs) in SharePoint Using SPServices – Part 4 – GetListItemChangesSinceToken
Single-page applications (SPAs) are nothing new on the Web. However, like Responsive Web Design (RWD), SPAs are gaining favor as a way to enable real work with an improved user experience (UX).
From the Wikipedia definition of SPA:
A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.
SPAs first started popping up regularly – at least based on my experience – in creative contexts on public Web sites. A post called 40 Inspiring Single Page Websites from Gisele Muller shows some great examples of the SPA approach. Most of the sites Gisele highlights are marketing sites: they are primarily publishing content in a one-to-many context. Also note that the date of her post is early 2010. These sites have been out there for a while and are becoming more prevalent.
We see many more examples of SPAs all the time, whether we think about them this way or not. The most obvious and prevalent examples are the Facebook and Yammer News Feeds. In the News Feed examples, we tend to stay on that single page until we see something scroll by or some content change that makes us want to drill into the details, taking us away from the SPA intentionally based on an action – usually a mouse click – we take. Other full-scale applications that enable us to do real work, like Trello, are good examples of the SPA concept. We also see the SPA idea in apps on our phones, phablets, tablets, and even showing up in Windows 8 world. In other words, this is the wave of the future for apps.
Since the idea with SPAs is that one need not leave the single page to accomplish some high percentage of the tasks at hand, it’s a great concept to apply in a SharePoint context. With SharePoint, we are trying to fundamentally change the way people work, moving from a hierarchical to a more collaborative work style. While this work evolution has been progressing well over the last dozen or so years of SharePoint’s existence, SharePoint itself has changed a lot, as should the way we consider building our applications within it.
The days where a clunky postback-ridden application was acceptable is fading into the rear view mirror. The SharePoint Product Group has taken steps toward giving SharePoint itself an SPA “feel” with the introduction of the Minimal Download Strategy (MDS) in SharePoint 2013. See Wictor Wilén‘s (@wictor) excellent post SharePoint 2013 – Introduction to the Minimal Download Strategy (MDS) for details on how MDS works. MDS doesn’t give us a true SPA per se, but the goals for MDS get us a much more fluid, SPA feel for SharePoint.
But what if you are using older versions of SharePoint? Maybe 2007 or 2010? Or even 2003? (Yes, I still run into a few people using 2003 from time to time.) Well, there’s no need to despair, because the tooling to create SPAs is there for you to use anytime you want it. With AJAX available for use as the data transport mechanism, we can fetch content from the SharePoint server anytime we choose without a page refresh. In the past, I’ve taken various different approaches to this, like Refreshing a Page Section with a User-selected Interval Set with jQueryUI’s Slider or Refreshing a Web Part Without a Postback Using jQuery’s AJAX Function. You’ll also see a few SPA examples in my SPServices Stories series, like SPServices Stories #13: Durandal SP3: Developing SharePoint SPAs Made Easy from Rainer Wittman (@RainerAtSpirit).
My friend and SPServices co-conspirator, Paul Tavares (@paul_tavares), and I have been discussing several Lists Web Services operations of late that I’d never paid much attention to: GetListItemChanges and GetListItemChangesSinceToken. Together with the simpler GetListItems – the true workhorse of the SPServices toolkit – we have three variations on a theme: fetching content from a list. Using those three “get” operations, along with the UpdateListItems operation to write changes back to the list, we can build our own SPAs in SharePoint.
We could choose to use some of the fancy frameworks out there, but in this series, I’m going to keep it simple. I’m going to limit myself to jQuery and SPServices only to see what I can come up with. (I may sprinkle in a little fairy dust using jQueryUI for fun.) While frameworks like Knockout or AngularJS can be extremely helpful tools, I find that in many cases simplicity works better for me – it keeps me closer to the data and lets me control what goes on. I also think that I can keep the examples more straightforward by avoiding other plugins.
Let’s get to work…
Thanks for the mention Marc.
Funny you mentioned Trello. In refactoring my persistence module I’m actually trying to mirror a Trello like app on SharePoint. My intent is to make it a SPA able to run on SP2010 and then package it as a 2013 app.
Marc, I just want to say thank you for your ongoing unselfish sharing of SharePoint knowledge. You have what Dave Ramsey refers to as “the mind of a teacher” and your willingness to share puts you in the top rung of humanity in my opinion. I want to be like you when I grow up!
Keith:
Comments like yours make it all worthwhile, my good man. I’m glad you find my ramblings helpful.
M.
This is great, simply great. Can’t wait to hear more.
I’m currently working on an AngularJS project for SharePoint that relies heavily on promises returned from SPServices. Each list is defined in an Angular service (model) and data is asynchronously fetched/cached based on the requirements of the active controller. The project currently relies on 19 unique lists to feed 5 loosely coupled apps along with their supporting views. We’ve had an incredibly positive response from our users and at this point the demand for additional apps far exceeds our ability to produce.
Just wanted to say that this wouldn’t be possible without the work you’ve done with SPServices and I can’t wait for the rest of this series.
Scott:
What you’ve built sounds amazing. I’m truly glad that SPServices has proved to be a valuable part of your toolkit.
It sounds like what you’ve done would probably be a far better series than anything I can come up with!
M.
Great post Marc. I think while the govmt is shut down, I will explore this as my topic of learning today :-)
Fabian:
Maybe you can get the government to operate on the same page. ;+)
M.
Thanks for your work!
Marc,
First, phablets — that’s a new one that I haven’t seen before! Thanks for adding to my knowledge of pop-culture.
Second, I have recently uncovered a few clients that are building multiple SPA’s on top of SharePoint. I have a feeling we will see many more of these coming down the road as more and more users realize how much you can actually accomplish with JavaScript and the multiple ways developers can interact with the data (SPServices, REST, CSOM). With the introduction of TypeScript, it is becoming easier to manage these SPA apps as well. Looking forward to seeing what you build.
Glad that I taught you something, Chris. I’m not wild about made up words, but sometimes I need to conflabulate them into my vocabulary.
Anything you’d like to see as an example?
M.
Nothing specific. I would say that it would be a good time to showcase promises. One of the solutions I recently saw made use of promises, but it was done by further wrapping SPServices. I believe this is now built into SPServices, so I would love to see it utilized.
Chris
Indeed they are, Chris, as of v2013.01. Take a look at this post for some info and a link to a demo page:
http://sympmarc.com/2013/05/01/comparing-spservices-2013-01-calls-with-async-vs-promises-methods/
M.
Thanks so much for the link!
Marc,
I know that in this series you are going to keep it simple, and although not using knockout.js is find, I would recommend that you use a URL state library – something like Sammy.js or path.js. These libraries allow SPA’s to have page representation URL’s by using the Hash portion of a URL… It really completes the SPA model.
Also,
Here is an example of my SPWidgets SPA – https://github.com/purtuga/SPWidgets/blob/master/demo/demo.about.md
I provide it in the project as a means for users to quickly play with the widgets as well as a means for me to quickly test in multiple environments with little/no setup… This particular one does not use a URL state library, but you can see how I have included all dependent libraries into one aspx page… including the use of a private jQuery instance, case the parent page already has jQuery loaded but not the correct level (which now a day with popularity of jQuery could be a problem).
The trick is going to be having this series be useful for someone just getting started with the SPA concept as well as seasoned pros like you. Before you understood that state libraries were needed…
M.
Paul, like the work you’ve presented. It seems like a great place to get started if you already have a lot of understanding of javascript. However, for someone that is just getting started or has done a lot of server side development using C# or VB.Net, the code is a bit difficult to follow. However, it did send me down the road to start learning jQuery’s promise implementation.
Marc, I think this should be a series focused on those of us that have done very little with SPA’s. While tooling and frameworks are important, a common set of easily learned and accepted tools can be very beneficial. I think your plan of limiting yourself to jQuery, jQuery UI and SPServices will fit most scenarios for someone that is getting introduced to SPA’s.
I would also draw from people like Paul who seem to have a pretty strong background in JavaScript to point out optimizations or better coding practices since JavaScript can quickly become difficult to maintain. The last thing we want to do is develop SPA’s that actually increase code churn and make debugging more difficult!
Looking forward to the series!