"0" is read as undefined, not a value

epicdave commented 11 years ago

pretty much what the title says. this bit of JSON:

    {
        "id":"engage",

        "hub":"home",

        "color":"#8e55c4",          
        "icon_path":"M15.5,2.833c-3.866,0-7,3.134-7,7c0,3.859,3.945,4.937,4.223,9.499h5.553c0.278-4.562,4.224-5.639,4.224-9.499C22.5,5.968,19.366,2.833,15.5,2.833zM15.5,28.166c1.894,0,2.483-1.027,2.667-1.666h-5.334C13.017,27.139,13.606,28.166,15.5,28.166zM12.75,25.498h5.5v-5.164h-5.5V25.498z",

        "position_offsets": {
            "buttonX": 0,
            "buttonY": 120,
            "iconX": -15,
            "iconY": -15
        }
    }

is read by this SpahQL command:

var buttonX_offset = itemObj.item(i).select("/position_offsets/buttonX").value();

as "undefined". If I change the value of 'buttonX' to 1, everything works fine. In this case the change from 0 to 1 doesn't much matter, but there will be cases where I (and probably others) really do need the number 0 to be read as the number 0.

julesfern commented 11 years ago

I'll get this rolled out to NPM very shortly.

julesfern commented 11 years ago

0.7.6 pushed to NPM - this bug was really simple, and I'm pretty embarassed about it. The QueryRunner was actually passing around your values just fine, but when we went to convert them from the internal representation (an array of primitive objects) to the public return type (a SpahQL object wrapping an array of primitive objects) the SpahQL constructor method was duck-typing the arguments by checking for a truthy value on a property, rather than checking for hasOwnProperty.

So yeah, sorry about that. I've added regression tests to make sure this one doesn't resurface.

epicdave commented 11 years ago

no worries - and thanks for the quick turn around!!

julesfern / spahql

"0" is read as undefined, not a value #20