Open pbeshai opened 3 years ago
FWIW, when the types work though, it's magical.
Yeahhhh I know, this is why I tried so hard to get it working. But I actually started getting max call stack errors running tests due to the inference, not the actual code. And when it doesn't work, it's really hard to override since many functions take multiple generic arguments. I'm not really sure the best approach to move forward, and it's not particularly enjoyable work to do. Also, to make tooltips more readable I threw in ts-toolbelt as a dependency (which is the real reason for the call stack overflows I think).
For future reference, if you're failing to get types to work and the tidy function is yelling at you, you can nuke it with by casting the function itself as any: e.g. tidy(data, (mutate as any)({ ... }))
Another issue with the complex types is it increases the barrier for contribution. I know JS devs that would happily add a function here or there to the repo, but the types stop them :(
Could be worth setting up test types with tsd: https://github.com/SamVerschueren/tsd
Actually, losing types and casting is an antipattern when using typescript. I was actually going to propose that some functions like desc and asc used keyof instead of simply Key.
like:
declare function desc<T>(key: KeyOrFn<T> | ((d: T) => any)): Comparator<T>;
instead of:
declare function desc<T>(key: Key | ((d: T) => any)): Comparator<T>;
It gets very annoying when the type inference is wrong. Perhaps we can mitigate this by stopping trying to be clever with keyof and other crazy generics and just make whatever comes out of tidy be opaque. At the end of tidy flows, users can cast their outputs to their expected types. Currently you have to fight the type system and guess where to override things and it is just crazy.