`Object.allKeys(object)`?

💡 Ideas
1

We already have Object.keys for own, enumerable string keys. Can we have something similar to get both string and symbol keys with similar constraints?

Pardon if there's already a proposal laying around for this.

2 Likes
2

You can do something like this I guess:

for (const strOrSymKey of [...Object.getOwnPropertySymbols(obj), ...Object.keys(obj)]) {
}

But I'm not sure if mixing string and symbol keys is a good practice

3

Reflect.ownKeys() returns both string and symbol keys.

4

Object.getOwnProperty{Names,Symbols} returns non-enumerable properties as well. I want those omitted like they are for Object.keys.

5

Reflect.ownKeys includes enumerable keys. Here's the matrix I'm looking at:

  • Strings only: all: Object.getOwnPropertyNames, enumerable: Object.keys
  • Symbols only: all: Object.getOwnPropertySymbols, enumerable: none currently (but could be worth adding)
  • Strings and symbols: all: Reflect.ownKeys, enumerable: my Object.allKeys proposal here
6

Ah, I see. A workaround currently would be to spread/assign first as they only copy own enumerable. But these definitely seem like fillable holes in the current set and I haven't gleaned any existing proposals that intends to fill them.

7

So this would just be a built-in Reflect.ownKeys(o).filter(x => Object.prototype.propertyIsEnumerable.call(o, x))?

8

Pretty much, in the same way that Object.keys is if you replace Reflect.ownKeys with Object.getOwnPropertyNames.

I don't have much use for an Object.symbols that goes off of Object.getOwnPropertySymbols, though, so it's not proposed.

9

Enumerability is kind of a strange property when it comes to symbols. Enumerability is primarily relevant to for-in, JSON.stringify, Object.keys, etc, all of which ignore symbols regardless of their enumerability.

Why are you thinking about the enumerability of symbol keys in the first place?

2 Likes
10

Object.assign and object spread/rest copies enumerable symbols, but not non-enumerable ones.

2 Likes