ES7 Proposal, specs, and reference implementation for Object.values/Object.entries
Spec drafted by @ljharb.
- TC39 meeting notes
- esdiscuss:
- https://esdiscuss.org/topic/object-entries-object-values
- https://esdiscuss.org/topic/es6-iteration-over-object-values
- https://esdiscuss.org/topic/object-values-and-or-object-foreach -> https://esdiscuss.org/topic/iteration-was-re-object-values-and-or-object-foreach
- https://esdiscuss.org/topic/object-entries-in-2015
- https://esdiscuss.org/topic/providing-object-iterators-beyond-just-object-keys
It is a very common use case to need the own values of an object - for example, when using an object as a hash filter. Many libraries have a “values” function: lodash/underscore, jQuery, Backbone, etc.
It is also useful to obtain an array of key/value pairs (what the spec calls “entries”) from an object, for the purposes of iteration or serialization. With the advent of the Map constructor accepting an iterable of entries, and its associated entries iterator (WeakMap also accepts iterable entries in its constructor), it becomes very compelling to want to quickly convert a plain object to a Map, via passing an array of entries into new Map.
We already have the precent of Object.keys returning an array of own keys, and matched triplets of keys/values/entries iterators on Map/Set/Array. As such, per discussions on es-discuss and in at least one previous TC39 meeting, this proposal seeks to add Object.values and Object.entries to ECMAScript. Like Object.keys, they would return arrays. Their ordering would match Object.keys ordering precisely, such that the indices of all three resulting arrays would reflect the same key, value, or entry on the object.
You can view the spec in markdown format or rendered as HTML.
Note: there's been a small bit of spec refactoring to ensure that Object.{keys,values,entries} share the same key ordering.
Consistency with Object.keys is paramount in this proposal‘s opinion. A follow-on proposal for an iterable, however, could likely be Reflect.ownValues and Reflect.ownEntries, which would complete the triplet with Reflect.ownKeys, providing an iterator over both string-valued and symbol-valued properties. However, this proposal is focused on Object.values/Object.entries, and the existence of either the Object or Reflect forms should not preclude the existence of the other. In addition, the current precedent for returning iterators from keys/values/entries currently only applies to methods on prototypes - and in addition, “Object is special” seems to be something many accept.