I could be way out in left field, but still looking at this particular problem. I don’t have the lesson, just your code and scenario as described. Looking at a way to utilize the keys array.
Testing on the Object.keys()
array means we don’t have to check for own property.
> r = {}
<- {}
> (Object.keys(object)).forEach(key => r[key] = !! object[key])
<- undefined
> r
<- > {one: true, two: true, three: false}
The question always has been, does the key exist, or is that the objective of the function. The name would suggest the key does exist, but may be undefined. If the key may have any of the falsy values discussed earlier then a specific comparison will be needed else there could be some errant outcomes.
I still don’t know the context of this problem but that is what has made it fun to explore.
If we know that the key exists (it has been captured in a for key in object
loop) and wish to see if it has a value that is not falsy,
has (object, key) { // truthy value
return !! object[key];
}
If we wish to confirm the presence of a key,
has (object, key) { // key
return object.hasOwnProperty(key);
}
Now, if we need to narrow the selection down to just undefined
, then,
has (object, key) { // value
return object[key] !== undefined;
}
> const _ = {
has (object, key) {
return object[key] !== undefined;
}
}
<- undefined
> _.has({one: true, two: true, three: false}, 'three')
<- true
> _.has({one: 1, two: 2, three: undefined}, 'three')
<- false
> const _ = {
has (key) {
return this[key] !== undefined;
},
one: 1,
two: 2,
three: undefined
}
<- undefined
> _.has('three')
<- false
Aside
Earlier I touched on undefined
but felt it went over the line and was incorrect, so I edited it out. undefined
bears examining a little further because of its unique nature.
undefined
Note that in an object, we cannot leave a key value pair hanging like we can with var.
var a;
console.log(a); // undefined
If we write a key that has no corresponding value, then we get this,
Uncaught SyntaxError: Unexpected token }
if it’s the last key in the object, or an unexpected identifer if somewhere else in the object. Values must be defined, else the variable undefined
must be used.
Again it goes back to context, which I have not as yet sought out. Still fudging with the concepts and getting the kinks out of my thinking.
Which value is better to assign? undefined
or null
?
null
is the top of the prototype chain. Like undefined
it is just a primitive glued to the global object. But it turns up in a lot of places where undefined would be a poor fit.
Bottom line, JS has no problem binding something (undefined) to a declaration, but it is powerless in binding to key. We have to have something there. Let logic dictate whether we use null or undefined. null
, by the way, bears some investigation, as well.
For my own satisfaction, I see undefined
as generated by the interpreter in a variety of cases. null
, on the other hand is usually an assignment, which can be interpreted as something arbitrarily set on a return value of a method or function. undefined
cannot be interpreted thus. Therein lies the distinction.
var user = prompt("Click `Cancel` or press `Esc`")
console.log(user) // null
Note that this is a value that can be tracked. We can use this as a control flow reference that has a distrinct meaning. The user cancelled the prompt and we should therefore handle that response rather than let the program continue along its normal path.
Yes, there are cases where undefined would offer this logical leverage, but in this case, I agree with the JS developers who opted to use null
in this circumstance. These questions do come up in a complex problem. The right choice is often very gray.