Глядя на документацию Ramda для transduce , приведено два примера, каждый из которых приводит к тому, что компилятор Typescript выдает различную ошибку.
Пример 1:
test('ex. 1', () => {
const numbers = [1, 2, 3, 4]
const transducer = compose(
map(add(1)),
take(2)
)
const result = transduce(transducer, flip(append), [], numbers)
expect(result).toEqual([2, 3])
})
Typescript выдает следующее исключение для flip(append)
:
Argument of type '(arg1: never[], arg0?: {} | undefined) => <T>(list: readonly T[]) => T[]' is not assignable to parameter of type '(acc: ({} | undefined)[], val: {} | undefined) => readonly ({} | undefined)[]'.
Types of parameters 'arg1' and 'acc' are incompatible.
Type '({} | undefined)[]' is not assignable to type 'never[]'.
Type '{} | undefined' is not assignable to type 'never'.
Type 'undefined' is not assignable to type 'never'.
Если я изменю flip(append)
на flip(append) as any
, код будет работать как положено.
Пример 2:
test('ex. 2', () => {
const isOdd = x => x % 2 === 1
const firstOddTransducer = compose(
filter(isOdd),
take(1)
)
const result = transduce(
firstOddTransducer,
flip(append) as any,
[],
range(0, 100)
)
expect(result).toEqual([1])
})
Typescript выдает следующее исключение для firstOddTransducer
:
Argument of type '(x0: readonly any[]) => Dictionary<any>' is not assignable to parameter of type '(arg: any[]) => readonly any[]'.
Type 'Dictionary<any>' is missing the following properties from type 'readonly any[]': length, concat, join, slice, and 16 more.
То же, что и выше, если я изменю firstOddTransducer
на firstOddTransducer as any
, код будет работать как положено.
Во-первых, что вообще означают эти конкретные ошибки?
Во-вторых, как лучше всего справляться с такого рода проблемами с помощью функциональной машинописи? Очень часто, просматривая различные учебные ресурсы для машинописи, пользователи предупреждаются против использования any
или против использования // @ts-ignore
, как будто это то, что вы никогда не должны делать, но чем сложнее становится моя кодовая база, и тем функциональнее мой стиль программирования становится, тем больше таких заклинаний непонятных ошибок я получаю за вполне приемлемый код. Я не против потратить немного своего времени на улучшение типов, но я не хочу тратить слишком много времени на отладку проблем с типами, когда я знаю, что код хороший.
В-третьих, есть ли какие-нибудь советы, которые могут помочь в ситуациях, когда вы не совсем уверены, есть ли проблема с типами или с машинописью, как указано выше, или если есть проблема с кодом JavaScript, например, методы для определения того, где на самом деле проблема, чтобы вы могли либо исследовать, либо игнорировать?