What is the difference between Reflect.ownKeys(obj) and Object.keys(obj)?
Solution 1:
Object.keys()
returns an array
of strings, which are the object's own enumerable properties.
Reflect.ownKeys(obj)
returns the equivalent of:
Object.getOwnPropertyNames(target).
concat(Object.getOwnPropertySymbols(target))
The Object.getOwnPropertyNames()
method returns an array of all properties (enumerable
or not) found directly upon a given object.
The Object.getOwnPropertySymbols()
method returns an array of all symbol
properties found directly upon a given object.
var testObject = {};
Object.defineProperty(testObject, 'myMethod', {
value: function () {
alert("Non enumerable property");
},
enumerable: false
});
//does not print myMethod since it is defined to be non-enumerable
console.log(Object.keys(testObject));
//prints myMethod irrespective of it being enumerable or not.
console.log(Reflect.ownKeys(testObject));
Solution 2:
First, an example (ES6Fiddle):
// getFoo is property which isn't enumerable
var my_obj = Object.create({}, { getFoo: { value: function() { return this.foo; } } });
my_obj.foo = 1;
console.log(Object.keys(my_obj)); // console ['foo']
console.log(Reflect.ownKeys(my_obj)); // console ['getFoo', 'foo']
Here, Reflect.ownKeys()
returns an array of the target object's own property keys. Namely, an array of all properties (enumerable or not) found directly upon the given object concatenated with an array of all symbol properties found directly upon the given object.
Object.keys()
will only return the enumerable properties.
Enumerable properties are those that can be enumerated by a for...in loop, with the exception of properties inherited through the prototype chain. See the MDN description for more details.
Summary:
Reflect.ownKeys() is the equivalent of Object.getOwnPropertyNames(target).concat(Object.getOwnPropertySymbols(target))
which will return both enumerable and non-enumerable properties
whereas
Object.keys() returns enumerable properties but does not return non-enumerable properties (which is a characteristic of Object.getOwnPropertyNames()).
Solution 3:
-
Object.keys
returns only enumerable string keys;Reflect.ownKeys
returns both string and symbol keys regardless of their enumerability. Both operate on own properties only. -
Object.keys
returns an empty array if the argument is not an object and notnull
orundefined
(e.g.Object.keys(1)
), whereasReflect.ownKeys
throws aTypeError
. -
Reflect.ownKeys
was introduced with ES6 and is not supported in older JavaScript engines.
Solution 4:
In addition to what the other answers have already mentioned, Reflect.ownKeys
is also guaranteed by the specification to return keys (and symbols) in the following order:
- Integer numeric keys, in ascending order (0, 1, 2)
- String keys, in the order they were inserted onto the object
- Symbol keys
This order is required by the internal [[OwnPropertyKeys]]
method which is invoked by Reflect.ownKeys
.
In contrast, Object.keys
calls EnumerableOwnPropertyNames
, which requires:
- Order the elements of
properties
so they are in the same relative order as would be produced by the Iterator that would be returned if the EnumerateObjectProperties internal method were invoked with O.
Where EnumerateObjectProperties explicitly does not specify any order in which the properties are returned:
The mechanics and order of enumerating the properties is not specified
So, if you want to be absolutely certain that, while iterating over object properties, you iterate in insertion order for non-numeric keys, make sure to use Reflect.ownKeys
(or Object.getOwnPropertyNames
, which also invokes [[OwnPropertyKeys]]
).
(All that said, while Object.keys
, its variants, for..in
loops, and JSON.stringify
all officially iterate in an unspecified, implementation-dependant order, environments generally iterate in the same predictable order as Reflect.ownKeys
anyway, luckily)