3 ms·
I like this but I think it's generally preferable to have something like "unsafe" in the name, e.g. objectKeysUnsafe. Reason being it's very easy for a new dev
by hn_throwaway_99 3y ago
I like this but I think it's generally preferable to have something like "unsafe" in the name, e.g. objectKeysUnsafe.
Reason being it's very easy for a new developer to come along and see "objectKeys" being used all over the place, and then assume it's safe to use everywhere without realizing the problem it could cause. Putting "unsafe" in the name (unsafe actually feels a little strong for me, maybe something like "lax" or something else would be better?) makes it a lot more likely that a new dev is at least going to look up the doc on the function to see why it's unsafe.
- jitl 3y agoI think the unsoundness hazard here is more scary in NPM library code where you can't trust your caller too much. In our application, we generally don't create objects with extraneous properties or use subtyping/inheritance. I did a quick survey of the 316 occurrences of `objectEntries` in our codebase and found very few (like 15-ish) that weren't obviously on a Record type like `Record<ThingyID, Thingy>` or a static, constant configuration object like `{ [T in Foo["type"]]: HandleFooVariant<T> }`.