在SharePoint中调用“SP.ClientContext.executeQueryAsync”的最佳/首选方法 [英] Optimal/preferred way to call 'SP.ClientContext.executeQueryAsync' in SharePoint

问题描述

我一直在学习客户端对象模型并且遇到了方法 executeQueryAsync 。我发现有很多方法可以调用这种方法。我发现的一些是：

I have been learning client-side object model and came across the method executeQueryAsync. I found there are quite a few ways to call this method. Some of the one I found were these:

var context = new SP.ClientContext.get_current();

// Option 1
context.executeQueryAsync(
    function(sender, args){ },
    function(sender, args){ }
);

// Option 2
context.executeQueryAsync(
    Function.createDelegate(this, _onSucceed), 
    Function.createDelegate(this, _onFail)
);

// Option 3
context.executeQueryAsync(
    Function.createDelegate(this, this._onSucceed), 
    Function.createDelegate(this, this._onFail)
);

// Option 4
context.executeQueryAsync(_onSucceed, _onFail);

哪种方式最优/最优？语句 Function.createDelegate 的作用是什么？ 此功能的文档似乎是对我来说非常神秘。

Which of this way is the most optimal/preferred one? Also what does the statement Function.createDelegate do? The documentation for this function seems to be very cryptic for me.

推荐答案

首先我要说的是没有最佳方式，因为这些只是表现得有点不同。第二，我想补充一点，这不是一个特定于SharePoint或executeQueryAsync的东西，因为它通常是JS的东西...

First I would say there is no 'optimal way' as these all just behave somewhat differently... Second, I would add this isn't so much a SharePoint or executeQueryAsync specific thing as it is a JS thing in general...

接下来我们需要了解一下 executeQueryAsync 期望两个函数作为参数：第一个是在 executeQueryAsync 成功时执行的函数，第二个是函数如果方法遇到错误，请执行。这些函数是传递参数（来自 executeQueryAsync ，而不是来自你的JS）表示发送对象以及可以包含一些数据的参数对象（ args .get_message（）和 args.get_stackTrace（）在通话失败的情况下很常见）

Next we need to understand that executeQueryAsync expects two functions as arguments: the first is a function to perform if executeQueryAsync succeeds, the second is a function to perform if the method encounters an error. These functions are passed parameters (from executeQueryAsync, not from your JS) representing the sending object as well as an arguments object that can have some data (args.get_message() and args.get_stackTrace() are common in the case of a failed call)

在你的'选项1'示例中， executeQueryAsync 被赋予两个匿名函数，你将无法在任何地方重用它们，但是如果行为很简单，这可能就足够了。

In your 'Option 1' example, executeQueryAsync is given two anonymous functions, you won't be able to re-use them anywhere, but if the behavior is simple this may be sufficient.

在选项2中，您使用 createDelegate 方法来提供成功和失败回调上下文 - 这说明了JavaScript中的范围;如果你需要引用一个只能在调用 executeQueryAsync 的函数中访问的变量，你需要使用这种模式，这样这个回调中的引用了调用 executeQueryAsync 的函数，而不是您现在所处的成功或失败函数。您可以考虑创建一个委托作为调用其他函数的调用函数，但是说'我希望该函数能够看到我能看到的东西，无论它位于代码中的哪个位置。'这可能看起来有点神秘，但这样做是在范围内JavaScript ......您可以通过引用更高范围级别的变量（例如包含调用方法以及成功和失败方法的函数内部）来完全避免执行此操作的需要。

In Option 2 you use the createDelegate method to give the success and failure callbacks a context -- this speaks to scoping within JavaScript; if you need to reference a variable that is only accessible in the function that calls executeQueryAsync, you'll need to use this sort of pattern so that this within the callback references the function that called executeQueryAsync instead of the success or failure function that you're now in. You can think of creating a delegate as the calling function calling on some other function, but saying 'I want that function to be able to see what I can see no matter where it's located at within the code.' This may all seem a bit arcane, but such is scoping within JavaScript... You could completely circumvent the need for doing this by referencing variables at higher scope levels (say inside of a function that contains the calling method as well as the success and failure methods)

选项3就像选项2一样，除了它只是指定 _onSucceed 或 _onFail 函数应该是那些包含在调用对象中

Option 3 is just like Option 2, except it just specifies that the _onSucceed or _onFail functions should be the ones that are contained within the calling object

Option4与选项1类似，不同之处在于您已命名函数（并且它们在当前范围内可用）并且正在调用他们的名字。

Option4 is just like Option 1, except that you've named the functions (and that they are available within the current scope) and are calling them by name.

我通常使用类似选项2或选项4的东西 - 但我希望你能看到它真的只取决于你如何尝试编译你的代码。

I usually use something like option 2, or option 4 -- but I hope you can see that it really just depends on how you're trying to structure your code.

编辑：
回应关于的评论Function.createDelagate（） - - 它似乎只是ASP.NET脚本资源中的帮手;除了调用 apply（）之外什么也没做（这是标准的JS方式 - 请参阅此处的MDN文档）。它也可能在ASP.NET中的某处提供一些向后兼容性，但我不太确定！

In response to a comment about Function.createDelagate() -- It seems to just be a helper in an ASP.NET script resource; it does nothing other than calling apply() (which is the standard JS way of doing this -- see MDN documentation here). It might also provide some backward compatibility somewhere within ASP.NET, but I'm not really sure!

这是我的脚本资源文件中的函数代码SP环境：

Here is the code for the function from a script resource file in my SP environment:

Function.createDelegate = function(a, b) {
    return function() {
        return b.apply(a, arguments)
    }
};

作为奖励，我在考虑如何使用 executeQueryAsync 我意识到我实际上更常使用它，比如选项1，使用jQuery延迟的promise模式如下：

And as a bonus, I was thinking about how I use executeQueryAsync and I realized that I actually use it more often like option 1, with a promise pattern using jQuery deferreds like this:

function getSPDataAsync(context) {
    var deferred = $.Deferred();
    context.executeQueryAsync(function(sender, args) {
        deferred.resolve(sender, args);
    }, function(sender, args) {
        deferred.reject(sender, args);
    });
    return deferred.promise();
}

那么你可以做一些不那么像意大利面条的东西，比如：

Then you can do things a little less-spaghetti-like, such as:

...
ctx.load(items);
getSPDataAsync(ctx).then(function() {
    //do some stuff with the data when the promise resolves
});

万一有人关心！ ：）

这篇关于在SharePoint中调用“SP.ClientContext.executeQueryAsync”的最佳/首选方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！