feat(differenceBy): add differenceBy in compat

[mass2527]

resolve #481

Since lodash is testing difference, differenceBy and differenceWith in difference-methods.spec, i have also included difference test case from our difference.spec.ts.

I am not sure about the type of values; it would be helpful if you could suggest a more appropriate type if one exists.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
es-toolkit	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 3, 2024 5:53am

[raon0211]

For types, we might refer to @types/lodash.

@types/lodash provides several overloadings to differenceBy, could you reference it?

[mass2527]

@raon0211
Thank you for the review. I plan to add function overloading based on @types/lodash.

However, I have one question to clarify my understanding. I initially thought that our compatibility functions should have the same types as @types/lodash to ensure 100% compatibility with Lodash.

However, I noticed that some functions, like difference, don't exactly match in type.

For example:

• @types/lodash: difference<T>(array: List<T> | null | undefined, ...values: Array<List<T>>): T[];
• es-toolkit: function difference<T>(arr: readonly T[], ...values: Array<readonly T[]>): T[]

This difference has me a bit confused. Could you clarify what needs to be the same and where it's acceptable to have differences?

[raon0211]

We initially aimed to keep changes to the original es-toolkit's signature to a minimum, only referring to types from @types/lodash to address any type errors in the compatibility tests.

However, I'm wondering whether we should match our types more closely with those from @types/lodash to make the migration smoother.

For example, readonly T[] could be updated to readonly T[] | ArrayLike<T> (which is List<T>). If we go this route, we might need to add some additional null checks, and wrap arguments with Array.from(...) to ensure they're converted to arrays where necessary.

[raon0211]

We recently launched a Discord channel to help address these types of issues—feel free to join us! :)

[mass2527]

It would be great if I could work on this after we decide on the direction. I will join the Discord community. Thanks!

[mass2527]

@raon0211

I updated the PR based on @types/lodash. Please review this when you have some time.

Here’s a key point to note: While @types/lodash defines the iteratee parameter using ValueIteratee<T>, I changed it to ((value: T) => unknown) | PropertyKey because i think these are the only valid cases supported by Lodash's differenceBy function. ([PropertyName, any] | PartialShallow<T> doesn't seem to be valid type)

For reference, here are the type definitions from @types/lodash:

type ValueIteratee<T> = ((value: T) => unknown) | IterateeShorthand<T>;

type IterateeShorthand<T> = PropertyKey | [PropertyKey, any] | PartialShallow<T>;

type PartialShallow<T> = {
  [P in keyof T]?: T[P] extends object ? Partial<T[P]> : T[P];
};