Optional TypeOverides

[JoshRosenstein]

Hello, i am currently learning Typescript and i an rewriting my utility library (I created as i was learning javascript) with types. I struggled to even know where to begin, and after realizing a lot of my functions are just too flexible in order to produce good typings (i.e: my reduce fn accepts [],'',{},maps,sets). So my first step is breaking these flexible functions down and have reduceArr, reduceObj etc.
After I get that down the next issue ive came across was being able to have the flexibility of optionally assigning types in the overloads, and i wanted to get your opinion of this:

I'll use your take method for example:
currently with the overload export function take<T>(n: number): (array: T[]) => T[]
would yield {}[] for take(3)([1, 2, 3, 4, 3, 2, 1])
and within pipeconst e = pipe( [1, 2, 3, 4, 3, 2, 1], take(3)) yields number[]

But if I were to do const take3 = take(3) and pipe( [1, 2, 3, 4, 3, 2, 1], take3) would yield {}[]
In order to get the correct type, i would have to strictly assign the input type const take3Strict = take<number>(3).

A simple solution would be moving the generic export function take(n: number): <T>(array: T[]) => T[],
but now loses the flexibility if i wanted to create a take3Strict . So i tried to think of a way of how to make the overloads a bit more flexible and did this:

export function take<T0 = never>(n: number,): <T extends [T0] extends [never] ? any : T0>(array: T[]) => T[]

I know take is a little too simple, but wanted to share this if it may inspire you in any way.

[lstkz]

Hi @JoshRosenstein
"Generic higher-order functions" are problematic in TypeScript, and they don't work in many cases.

In TypeScript 3.4 (released 1 week ago), there are improvements microsoft/TypeScript#30215, but I haven't tried it yet.

Thanks for your suggestion, it seems like a good workaround 😄

[JoshRosenstein]

@BetterCallSKY - Oh nice, I need to get in habit of exploring open issues and PR's for this type of stuff 😆 . Thanks for the reference! I got another question for you, I do like the lazy evaluation but i was wondering if there would be a way to trigger it. maybe a similar way of how your implementing map.indexed, having map.lazy and map.lazy.indexed? Only bringing this up because i was thinking of times it may be needed to be skipped. I was going to post an example as such, but when i tested the following out I got an even different output than expected:

// Get first 3 unique values
const arr = [1, 2, 2, 3, 3, 4, 5, 6];

const result = R.pipe(
  arr,
  R.map(x => {
    console.log('iterate', x);
    return x;
  }),
  R.uniq(),
  R.take(3)
); // => [1, 2, 3]

/**
 * Console output:
 * iterate 1
 * iterate 2
 * iterate 2
 * iterate 3
 * /

If I do:

const result = R.pipe(
  arr,
  R.map(x => {
    console.log('iterate', x);
    return x;
  }),
  R.take(3),
  R.uniq(),
);  // => [1, 2, 2]

/**
 * Console output:
 * iterate 1
 * iterate 2
 * iterate 2
 * /

Edit:
After digging around a bit more, is the purpose _toSingle is to act like a lazy breakpoint in a way for certain methods ?

[lstkz]

It's a bug, thanks for catching it!

I do like the lazy evaluation but i was wondering if there would be a way to trigger it

Lazy evaluation is implemented inside the pipe method. Probably you can have pipe and pipe.lazy or pipe.notLazy versions.