Typically we use setCallback() to invoke apex methods from components like so

var call1 = cmp.get("c.myServerSideAction_1");
call1.setCallback(this,function(res)) {
    if(res.getState()=='SUCCESS') {
          // ... some logic here

The documentation in the Aura Sourcecode suggests to use this as scope.

Now in the context of a different question I found that I'm passing in most cases null instead of this because I moved all invocations to a static resource where I have no meaningful this context to feed into setCallback().

Unfortunately I can't figure what the meaning and reason for this super strange scope parameter is at all. It feels just useless and as an obstacle to me and I passed null out of frustration. Surprisingly it worked with no difference. Now in the context of a differnt question here Lightning Components: why are subsequent invocations of $A.enqueueAction() so super SLOW? about nested apex invocations I have performance issues and @CasparHarmer guessed the scope parameter could have an impact on performance.

I would like to understand scope

Can anyone point me to where I can read more about this scope or explain to me it's purpose? I can't find more background information on it.

This question is similar to this Scope of server callback in aura action but has actually received a better and more detailed answer.

  • This is about as good as I could find: In non-strict mode, this cannot be null, so it's replaced with the global object instead. Try setting your javascript to strict and see what you get. – Caspar Harmer Aug 21 '17 at 20:59
  • In fact, if it's not replaced by a Locker Service Secure version, then you'll have escalated yourself outside of the Lightning sandbox and may have exposed a bug – Caspar Harmer Aug 21 '17 at 21:00
  • could this be related Scope of server callback in aura action ? – glls Aug 21 '17 at 21:01
  • @CasparHarmer I'm in a v36 compo, so no LockerService or at least not the angry version of it... – Uwe Heim Aug 21 '17 at 21:02
  • @glls I think that is it exactly! Thanks! If I got it right, then if I dont't use this in my callbak at all, scope does not make any difference at all, correct? This is so irritating and there should be a scopeless version of setCallback() especially because this is different in controllers and helper and people move code around between the two of them... – Uwe Heim Aug 21 '17 at 21:11

The scope parameter used by the callback is supposed to provide your helper context to the callback so that you can continue to have access to other helper functions (which are available via the this scope in the helper). The framework does this by invoking your callback using Function.prototype.call and passing your scope as the this argument. For why this is important consider the following:

function main() {
    try {
    catch(e) {
        console.log('Secret unavailable!');

function other() {

function secret() {
    console.log('You found a secret.');

// Call main with the top-level "this"
console.log('-- Calling Window version --');

var scope = {
    other: function() {
        console.log('Scoped Other');

// Call the main and pass a custom scope
console.log('-- Calling scoped version --');

This will print out:

-- Calling Window version --
You found a secret.
-- Calling scoped version -- 
Scoped Other 
Secret unavailable!

As you can see here, using call to invoke a function provides an important level of encapsulation for the framework. When you pass this to your callback you are propagating your helper state down to the callback. I am not sure exactly what the use case is but you could pass a different object there if you wanted your callback to have access to a different scope.

| improve this answer | |

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