-
Notifications
You must be signed in to change notification settings - Fork 316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(findKey): add findKey #755
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -0,0 +1,31 @@ | |||
# findKey |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually generate documents in an automated way; you don't have to manually create them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@raon0211 Oh, I see... I guess I won't have to write docs from next time.
src/object/findKey.ts
Outdated
export function findKey<T extends PropertyKey, K>( | ||
obj: Record<T, K>, | ||
predicate: (value: K, key: T, obj: Record<T, K>) => boolean | ||
): T | undefined { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export function findKey<T extends PropertyKey, K>( | |
obj: Record<T, K>, | |
predicate: (value: K, key: T, obj: Record<T, K>) => boolean | |
): T | undefined { | |
export function findKey<T extends Record<any, any>>( | |
obj: T, | |
predicate: (value: T[keyof T], key: keyof T, obj: T) => boolean | |
): keyof T | undefined { |
I guess this type signature is more accurate than the original one.
Note that foo
is inferred as number | string
in the first one, but is accurately inferred as number
in the second one.
Old interface
declare function findKey<T extends PropertyKey, K>(
obj: Record<T, K>,
predicate: (value: K, key: T, obj: Record<T, K>) => boolean
): T | undefined
findKey({ foo: 1, bar: '1' }, (val, key, obj) => {
// foo is string | number here
obj.foo
})
New interface
declare function findKey<T extends Record<any, any>>(
obj: T,
predicate: (value: T[keyof T], key: keyof T, obj: T) => boolean
): T | undefined
findKey({ foo: 1, bar: '1' }, (val, key, obj) => {
// foo is number here
obj.foo
})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, thank you for the kind review.
In the case of the old interface, the type inference of the object's key and value is inferred independently, so accurate type inference is not possible.
I will commit again, reflecting your review!!
This will help a lot! 😃 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution!
Related issues: #715
Before implementing findKey in the compat layer, I preemptively worked on es-toolkit's findKey.
Hi!, @raon0211
There is something that needs your opinion.
There was a point where I was focused while implementing it, and that was how strictly to keep the type.
In the case of lodash's findKey, if an object is received as the first argument of findKey, the return value is a simple string.
However, in the case of findKey that I implemented, the key value of the object is specified as the return value.
Since this is not a compat layer, I think it is right to follow the principles of es-toolkit rather than lodash, so I need your opinion on that.
I believe that in order for TypeScript to be used meaningfully, it is right to strictly manage types.
As a maintainer, please tell me your opinion!
I have one more question.
After this work, I would like to implement the compat layer's findKey, findLastKey, and compat layer's findLastKey in that order. Is that okay?