Closed niieani closed 6 years ago
hey, thanks for posting! :)
I just tried to compare this to ObjectHasKey
for a bit, but somehow that seems to behave similar on those tests for me without needing the Padding
hack. I'm getting the impression that part was failing with it for you and that's where this came from?
on this topic, I also had a ObjectHasKeySafe
, 'toString'
-proof but more complex.
interestingly HasProperty<{}, 'toString'>
passes, unlike ObjectHasKey
, though HasProperty<{ toString: () => string }, 'toString'>
still trips up, unlike ObjectHasKeySafe
. so it seems in-between in terms of complexity and robustness.
it may add a few blind spots with the Padding
keys, but getting toString
right when it's missing without the complexity of ObjectHasKeySafe
is nonetheless quite a feat!
I sympathize on shorter type names, and I hope we soon won't need to distinguish between object and tuple inputs anymore.
Tests are looking better so this should be just about viable now, with ObjectHasKeySafe
passing all 14 tests.
Before doing that I should probably test in how far the types are union-proof though -- just now spent some effort adding docs instead.
Anyway, I'll mark as closed. Hopefully docs should help in discoverability.
Hey @tycho01. I've created a
HasProperty
utility using some TS hacks 😄 .I'd love to know if this is useful somehow!