[WIP] fix(propEq): improve propEq typings

[Nemo108]

• remove unnecessary constraint from propEq value: the function should receive any type values of object, no matter what parameter it received;
• add additional types to use with placeholder

[Harris-Miller]

@Nemo108 I finally got around to re-checking and merging #71. Rebase this one for me and I'll recheck it

[Nemo108]

@Harris-Miller done

[Harris-Miller]

${number} is a neat trick! Allows strings that only contain number characters, very cool

[Harris-Miller]

We don't want to WidenLiterals<U[K]> here. When we know the type of U, we want to constrain val to U[K]

typeObj={prop: 'foo'|'bar'};// we want to disallow strings other than `'foo'` and `'bar'` here for `val`propEq('biz','prop',obj);

WidenLiterals<U[K]> is needed for the curried versions before of how typescript infers types

constdoesEqualFoo=propEq('foo','prop');// without `WidenLiterals<U[K]>`, the type would be `Record<'prop', 'foo'>`, but obj is `{prop: 'foo' | 'bar' }`, which is too wide for just `'foo'`.// with `WidenLiterals<U[K]>`, the type would be `Record<'prop', string>`, so `obj` is alloweddoesEqualFoo(obj)

Typescript doesn't support currying like this that well in general, but we do the best we can with what we have

[Harris-Miller]

Instead of the ternary, we do 2 overloads

exportfunctionpropEq<Kextendsnumber>(__: Placeholder,name: K): {// ...}exportfunctionpropEq<KextendsExclude<PropertyKey,number>>(__: Placeholder,name: K): {// ...}

[Harris-Miller]

I don't think const U in needed here. U should be find.

You need to constrain U and K here though. If typeof U[K] as well. Turns out you don't need WidenLiterals here at all, in fact, it would actually break if U[K] was string | number but you passed a string to val: V.

See here: https://tsplay.dev/m3KbAm

[Nemo108]

V extends U[K] ? U : never creates too strict constraint: it fires an error on any string I pass there

https://tsplay.dev/wOXozN

But I think I came up with a better solution

[Harris-Miller]

@Nemo108 I'm having to revert the other propEq we collaborated on together: #74 (see: #99)

This MR is actually of of develop before that merge, so after the revert happens there should be no more merge conflict.

The additions made to #74 solved a different problem about propEq. I pretty sure the changes in this MR are find to merge without those changes. I'm also pretty sure that the specific change of #74 that broke it (argument possibly being never) not present in these changes, so we shouldn't have that problem again

[Harris-Miller]

Suggested change

	import{Placeholder}from'ramda';
	import{WidenLiterals}from'../util/tools';
	import{Placeholder,WidenLiterals}from'../util/tools';

[Harris-Miller]

Ah crap, I missed this when I left that other comment about this MR not being a problem

array: V extends U[K] ? V[] : never 

This is the thing we can't have. It breaks combining with other functions, egR.filter(R.propEq('type', 'something')). The predicate type signatures don't match because of the : never