Protiviti / SharePoint Blog

SharePoint Blog

January 06
Waiting for SP.js: 2010 Client Object Model vs 2013

This year I learned a very humbling lesson about using SharePoint's JavaScript or ECMAScript Client Side Object Model (CSOM) in 2013.  In my case I was simply trying to fetch items from a SharePoint list – a fairly straight forward endeavor. 

 What I had done many times in SP 2010 and O365 was write JavaScript CSOM commands to manipulate data in a list.  As such, I already knew that to make my data fetch calls successful I would have to wait for the “SP.js” library to load. The following snippet has been my go-to call for performing that check:

I felt comfortable enough with my experience using this technique to sign up for a last minute, overnight, high visibility proof of concept project to surface some SharePoint data into a new custom data grid control that I’d never worked with before.  This call had worked flawlessly for me in both 2010 and 2013 environments.  Using it, I even met my goal of completing the POC that same night.  Finally done by 3AM and smiling devilishly at my work, I fired off a "come and get it" email inviting my client and teammates to test the POC.

Fast-forward to the next day (10 minutes before my demo), and I notice that my data grids are not loading.  The demo gods are angry.  "But why?” I questioned.  Soul crushed and endocrine system fully engaged, I began checking the system for any unauthorized edits to the demo page and corresponding JavaScript files.  Finding no evidence, I begrudgingly rescheduled the demo for later in the day to allow myself time for detailed troubleshooting. To my surprise, I found an "Object reference does not exist" message that was being tripped right at the line where I had my trusted snippet (from above) inserted.  The function seemed to be registered fine, and sp.js seemed to be loaded in the browser, so no trouble there.  However, looking more closely at the list of scripts that were loaded with the page, I notice a minor difference between the "sp.js?rev={GUID}" that loaded and my own syntax, "SP.js". "Could it be...?” I asked myself, "...case sensitivity?" "No, that makes no logical sense because this same line of code worked all last night without fail".  Thinking that it wouldn’t hurt to try, I changed the code to the snippet below and, voila, the error went away, and the 'MyCallbackFunction' was finally able to execute and retrieve data.

Thinking, "How bizarre...and…annoying. But, I'm glad I figured it out…” I switched gears into validation, and sanity check mode.  Pressing CTRL+F5 to do a hard refresh of the page - to my dismay - the data in my grids disappeared again!  Shifting into my fingers-to-temple debugging pose (reserved for special occasions), I hit F12 again to load up the browser debug window and checked the registered scripts on the page.  Surprise!  SP.js, or shall we say "sp.js", had not loaded. In disbelief, I hit CTRL+F5 again, and then again, and even switched to using just F5 (for good measure) to refresh the page.  As you can probably guess, sp.js never loaded again for me. 

Feeling like a person waiting 10 minutes at the stop for a bus that is routinely late but never more than 5 minutes, I thought to myself, "Hmm, so I guess sp.js won't be loading for me unless I do something explicit on the page to make it load." Remembering that there were a host of built-in functions at my disposal, I switched into research mode and began exploring MSDN for other commands available to me within the Client Side Object Model.  What I found was that in SP 2013, they have this really cool "Lazy initialization" approach for loading the SharePoint page scripts. This technique helps to improve responsiveness - similar to how developers might use RequireJS to keep things snappy.  Unfortunately, if you’re not aware of this fact it can really throw a monkey wrench in your testing and validation efforts. 

At least the problem was clear, I was waiting for a bus that was not going to arrive, and what I needed was a valet service like Uber or Lyft.  What I found as a replacement for my time-honored ExecuteOrDelayUntilScriptLoaded function was the following snippet:

You can find the technical example for the method call {here}.  This function call works to explicitly load the "sp.js" file before executing any of my code – via the MyCallbackFunction. This turned out to be just the solution I needed to ensure my code would run consistently on 2013.

I hope this little nugget saves you some time and frustration in your client-side coding adventures with SharePoint.

Don’t wait for the bus. Call a ride.

Happy SharePointing!

 ​

Quick Launch


© Protiviti 2019. All rights reserved.   |   Privacy Policy