使用Azure平台访问数组位置返回的JavaScript中未定义

Question

I have the following JavaScript object:

var payload = {
    "data": {
        "title": item.title,
        "time": item.time,
        "location": item.location,
        "latitude": item.latitude,
        "longitude": item.longitude,
        "invites": item.invites,
        "encodedImage": item.encondedImage        
    }
};

item.invites is a big string separated by commas. I use a function to split the string into an array based on the commas:

var userIdArray = splitArray(item.invites);
userIdArray.pop(); //last element is empty

//further down...
function splitArray(str) {
    var array = new Array(); //explicitly declared out of despair
    array = str.split(",");    
    return array;
}

and then I iterate it like so:

for (var i = 0; i < userIdArray.length; i++) {
     request.execute({
         success: function() {
            console.log("User: " + userIdArray[i]); //prints undefined...

But even though console.log(userIdArray); prints the array normally, I get undefined if the array is only 1 in length, but if it's 2 it prints the 2nd element... Why is this happening?

Answer 1

I'm not familiar with Azure, but going by the general pattern of the code, it seems that success is a function which will execute in the future and is not tied to the loop scope: therefore it will see a bad counter variable [i] value when the handler executes.

(Also, it may not pose a problem, but a counter variable declared and initialized in the loop header is a code smell, and possibly problematic.)

Without looking at the complete code, I can't tell if [i] is a global or local to a wrapping function, but I think it is global since you didn't get a ReferenceError.

The loop executes without waiting for all the future success calls (which are are async-stacked and not synchronous with the loop body), and so the last [i++] is evaluated at array.length, which will always be undefined since we're indexing past the array.

request.execute is synchronous and will be dispatched as expected from within the loop body, but the success handler is surely not.

As for the expressing the intention correctly in code, I think that an IIFE might fix this: (I have zero idea what request.execute does and if calling execute on the same object time and again is ok, hence I say it might ):

for (var i = 0; i < userIdArray.length; i++) {
     request.execute({
        success: (function (counter) {
            return function () {
                console.log("User: " + userIdArray[counter]);
            }
        }(i))
    });
 }

I'm throwing a reasonable guess here. That aside, I think the code needs significant re-thinking and refactoring. Callbacks in loops usually indicate a major logical flaw.