13

What is the fastest way to wait/check for _spPageContextInfo to be initialized?

I use AdditionalPageHead so my scripts are loaded before _spPageContextInfo is set.

Here are some alternatives, some I have already tried (single specific system, don't use these numbers as references):

  • jQuery(document)ready: 300ms - 400ms.
  • _spBodyOnLoadFunctions.push: 300ms - 400ms.
  • Polling with setInterval: 10ms - 30ms.

Notes: I don't want to use setInterval, even though I use clearInterval. Despite what some sites say, ExecuteOrDelayUntilBodyLoaded, at least with sp.js, can in some instances actually (probably when cached) load before _spPageContextInfo is set. I'm skeptical to defer-attribute, and I believe async-attribute can also load too fast - not very robust.

Improve this question
5
  • 1
    Isn't _spPageContextInfo defined in the main request along with the HTML? In which case you'd need to wait for it to load?
    – Guilherme Sehn
    Feb 19, 2015 at 12:00
  • @GuilhermeSehn it is simply <script>_spPageContextInfo={...}</script>, which is placed later in the markup than my normal <script src=".."></script>, which again means it is evaluated at a later time in the DOM - and yes, I must indeed Wait for _spPageContextInfo to initialize, but what is the fastest and ultimately the best way to do this?
    – eirikb
    Feb 19, 2015 at 12:05
  • I have used the setInterval method sometimes, but not a fan of it. So I'm interested in your outcome here. (PS: @eirikb quak hist ?) :)
    – Anders Aune
    Feb 20, 2015 at 7:34
  • Haha quite the digression, but yes, quak hist and tihlde ;)
    – eirikb
    Feb 20, 2015 at 7:57
  • +1 I asked myself the same question. setTimeout was tempting, but I opted for _spBodyOnLoadFunctions. Interesting to hear that ExecuteOrDelayUntilBodyLoaded is not reliable. Still looking...
    – Christophe
    Apr 4, 2015 at 3:38

2 Answers 2

Reset to default
7 
ExecuteOrDelayUntilScriptLoaded(getPageContextInfo, "core.js");
function getPageContextInfo() {
    console.log(_spPageContextInfo.systemUserKey);
}
Improve this answer
5
  • Can you please add some brief description about your code. What was your issue and how this code help you solve it.
    – Asad Refai
    Aug 7, 2015 at 6:21
  • Did some research, and if you take a look at the /_layouts/15/core.js file you will see the _spPageContextInfo object is build here. After the core.js finished loading, it executes the NotifyScriptLoadedAndExecuteWaitingJobs("core.js") function which triggers all ExecuteOrDelayUntilScriptLoaded functions set to "core.js". This function is the fastest and cleanest way because it executes right after the _spPageContextInfo object is created.
    – pkmelee337
    Feb 8, 2017 at 12:16
  • 1
    @pkmelee337 Are you sure _spPageContextInfo is created in core.js? I can see window._spPageContextInfo is re-assigned, but the initial object seems to be created in the page markup.
    – eirikb
    Sep 4, 2017 at 19:06
  • Yeah you're right. Found that out a few months ago, but forgot about this reaction. In your masterpage it is set right after the SharePoint form is created. You won't see it in your masterpage itself, but you can check this in your browser. Altough I am not sure if al property are set there. I personally think only the ones that come from ASP variables, but haven't checked it. Nevertheless if you want to use this property in a javascript file, it's safer to wait for the core.js to make sure it is set, because the page initialization does not fire any events that I'm aware of.
    – pkmelee337
    Sep 5, 2017 at 15:21
  • 1
    This doesn't seem to work on layout pages like site contents. The _spPageContextInfo loads after that triggers.
    – omega
    Sep 6, 2017 at 14:34
2

Assuming your script is executed before _spPageContextInfo definition in the page markup, I think the easier way is to wait the DOM to be ready to execute your code. jQuery(document).ready does exactly that.

In my own tests, checking if the variable is defined with setInterval ended up being slightly slower than waiting the DOM to be ready almost all the times when using Google Chrome and jQuery 1.9.1.

So for the sake of simplicity and code maintainability I'd stick with the jQuery(document).ready callback.

Improve this answer
6
  • 2
    I have a hard time believing that setInterval is slower, considering jQuery(document).ready will wait until the whole DOM is parsed, while setInterval can "jump in there" instantly after _spPageContextInfo is defined which is way before the whole DOM is done parsed
    – eirikb
    Feb 19, 2015 at 12:34
  • @eirikb here is the code I used to test: jsfiddle.net/4myc8965 - of course I ran it in a SharePoint environment where the HTML markup is a lot heavier. In most times there was a difference of ~10ms between them (e.g. DOM ready = 129ms, interval = 143ms)
    – Guilherme Sehn
    Feb 19, 2015 at 12:49
  • Please note that you have set it to run your demo onLoad
    – eirikb
    Feb 19, 2015 at 12:56
  • Here you go: jsfiddle.net/4myc8965/3
    – eirikb
    Feb 19, 2015 at 12:58
  • Oh, my bad! :) Anyway, in the test I ran inside a SharePoint environment the code was wrapped inside the head tag. Also, in the code you posted b ends up being slightly faster in most of the cases here. Are you getting different results?
    – Guilherme Sehn
    Feb 19, 2015 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.