SPServices Futures: Moving to jQuery’s Deferred Objects and More

As I gear up to work on the next release of SPServices, I want to make some pretty fundamental changes/improvements to the internal plumbing. What I’m hoping to do with this post is to gather any ideas and feedback that the user community has about the implementation before I go too far with things.

SPServices

Deferred Object and Promises

In all prior versions, we’ve relied on the completefunc (which I made up) to process the results we get back from a Web Services operation call. In the meantime, jQuery has moved forward significantly.

In jQuery 1.5, we got the first deferred object capabilities. I was loathe to change the internal workings of SPServices at the time because we had a substantial user base, even then.

Now the user base is significantly larger (as of this writing, there have been almost 75,000 [!] total downloads), but I think it’s time to add the deferred capabilities into the core SPServices function. More and more people have been exposed to deferred processing capabilities in script at this point, so it will be less of a shock to existing SPServices users (I hope!).

Oddly, I’ve only had one request (at least that I can remember) to add deferred processing into SPServices. It came from a Codeplex user named MgSam in a thread s/he titled JQuery Deferred compatibility, and I’ll admit that I blew it off a bit when he raised it as a possibility.

My strongest impetus for considering this fundamental architecture shift is having seen Scott Hillier talk several times about Utilizing Promises in SharePoint 2013 Apps. In actual fact, his talk applies to JavaScript (and thus jQuery) development more than it applies to SharePoint 2013 development. We can use the deferred methodology even if we’re running our scripts on SharePoint 2007. It’s a way to manage requests in the script and has little to do with the version of SharePoint.

In doing this, my goal will be to keep full backward compatibility so that all existing code continues to function with no changes, but I may deprecate the current completefunc focused methodology, either in this next release or shortly thereafter.

in the simplest form, it will look something like this (borrowing from MgSam’s example in the thread above):

function myCode(someOtherListId) {
    /* Ideally, I should be able to do this call SPListNameFromUrl asynchronously
     * as well, perhaps add an optional "async" parameter
     * which, if used, returns the jqXHR object and invokes
     * a callback upon completion rather than blocking until
     * the data returns. This is not the main point of this code though.
     */
    var currentListId = $().SPServices.SPListNameFromUrl();

    //Call 1
    var a = $().SPServices({
        operation: "GetListItems",
        async: true,
        listName: currentListId,
        completefunc: function(xData) {
            //Do something useful
        }
    });

    //Call 2
    var b = $().SPServices({
        operation: "GetList",
        async: true,
        listName: currentListId,
        completefunc: function(xData) {
            //Do something useful
        }
     });

     //Call 3
     var c = $().SPServices({
        operation: "GetListItems",
        async: true,
        listName: someOtherListId,
        completefunc: function(xData) {
            //Do something useful
        }
     });

     /* Now I want to do something once all 3
      * asynchronous calls have completed. Under the current
      * model, there's no easy way to do this.
      * I either have to hand-roll some ugly code,
      * or contort my completefuncs so that they work with
      * jQuery's Deferred.
     */
}

Moving toward the deferred object approach will also mean that I’ll replace the simplistic caching mechanism I put into place using the .data() function in v0.7.2. There will be no visible difference in the way it works, but the underlying mechanism will be deferred promises instead.

SharePoint 2007

I’m also considering finally ending development specifically for SharePoint 2007. I’ve continued to use WSS 3.0 as my development environment since the first release of SPServices so that I can “test up” rather than down *and* up.

I still have a lot of people contacting me with questions who are using SharePoint 2007. In fact, some of my best clients are still on SharePoint 2007. It’s still a great platform that works well for many people who are still using it.

That said, there are some capabilities in SharePoint 2010 and now SharePoint 2013 that I haven’t tried to take advantage of because they aren’t there in SharePoint 2007. It isn’t that I want to abandon the SharePoint 2007 folks, but I’m considering making the main focus SharePoint 2010.

I’m very interested in hearing people’s thoughts on that. There’s no easy way for me to know what versions everyone out there has, so chime in.

Version Numbering

These changes will definitely merit a more significant version bump than just going from 0.7.2 to 0.7.3, of course. Is it finally time to ship a 1.0.0? Or maybe I should just decide to go to 5.3.8 or something. The numbers mean nothing, of course, as long as they go in a consistent direction. I’m even toying with 2013.01. Any thoughts on this?

Thanks to everyone out there who uses SPServices, especially those of you who have contacted me to let me know how it has helped you accomplish your business goals. If you have a story to tell, please consider writing it up for my SPServices Stories series. I’m planning to keep that series going as long as there are good stories to tell.

Similar Posts

12 Comments

  1. I had a long post typed up then closed the tab.

    Long story short, I had a real need for this just these past 2 weeks as I had a mix of SPServices and CSOM (external list) that I needed to use and the only good solution to mix them was deferred. I ended up coming up with a solution using wrapper functions which returned promise objects and calling resolve inside the complete.

  2. Hey Marc.
    I think your plans to introduce Deferreds into SPServices is a great one. As my comment stated in the referenced post, I already wrap multiple SPServices calls into Deferreds methods so that I delay UI processing until all data (from multiple locations) is retrieved and data model created.
    It seems that just about all code I develop now a days I try to use Deferreds – special for UX type of behaviors. I have also, in some cases, refactored some of my functions to include the return of a Promise. In these cases, as you stated in your approach, I kept backwards comparability. I did so by introducing a new input parameter: promise: true | false. When true, I return a deferred promise.

    Re: SP2007
    I’m still heavily using 2007 at my company, but that’s going to change very soon. I’m an advocate of you no longer coding for 2007. Sometimes we just need move on. I think you will still support existing functionality on 2007, correct? It’s just new features that will be targeted at 2010, 1013, right?

    Thanks again for this great library. It has enabled me to build some awsome customizations in order to make my teams more productive.

    Paul.

    1. Paul:

      I certainly don’t intend to stop supporting 2007. I can just see how that might work:
      Me: What version are you running?
      You: 2007.
      Me:

      I knew you’d be for Deferred Objects; you’re always a few steps ahead of me. If you have any thoughts about specific implementation, let me know. I’m thinking I’ll return the promise regardless, but I’ll have to see if that introduces too much overhead.

      M.

      M.

  3. Marc,
    I think it would be a great step forward to bake in jQuery’s deferred object and I completely agree with MgSam. I’ve had many SPServices based projects that require either custom wrappers or nested callbacks to coordinate processing. This either gets messy quickly or runs everything in serial. Improving the ability to handle dynamic content would add value to the library for me.

    In regards to continuing platform agnostic development, my vote is to draw the line and target SP 2010/2013 as we go forward. I still have one customer using 2007 but they’ve seen the writing on the wall and will be upgrading in the near future.

    SPServices is an incredible resource and between it and your scattered forum discussions, I’ve really learned a lot. Let me know if there’s ever something that I can do to help.

    –Scott

  4. Hey Marc !

    That post is great news for the future of middle tier development in SharePoint 2010 ! That feature will clearly increase the quality of those solutions.

    I was wondering what was your plan with the REST API and SharePoint 2013 ? Knowing that the Web Services are on deprecation list, what kind of future SPServices will have in 2013 ?

    Thanks !

    Sébastien

    1. Sébastien:

      I’m curious what sorts of functionality you think should exist due to the REST capabilities. While the SOAP Web Services are deprecated, my guess is that they will be around for a while.

      Also, CSOM gives you ways to call the REST services. So what could SPServices do better?

      M.

      1. I find the way SPServices works (as a jQuery plugin) is way easier than writing my custom wrapper for CSOM. I understand that Microsoft wants us to go there, but I find the learning curve a bit heavy for an unexperienced developer. With SPServices, everything is abstracted and keeps you focusing on the job that got to be done, not the internal plumbing (SharePoint 2013 and OAuth will bring a lot of issues there…).

        I would find it useful that SPServices continue its work at simplifying life of the middle tier developers… With all of its features of simplifying forms (cascade lookups, etc.), it would be great to keep the tool around SharePoint 2013!

        Sébastien

  5. Marc, just a side comment as I see you’re linking to Scott Hillier’s post: as I told Scott a couple weeks ago, deferreds are built in jQuery ajax calls, so you don’t need to explicitly create and resolve them (contrary to what the sample code shows on his post).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.