Ошибки типов машинописного текста в Ramda Transducers и как справляться с запутанными ошибками типов в хорошем коде - PullRequest
1 голос
/ 27 мая 2019

Глядя на документацию 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, например, методы для определения того, где на самом деле проблема, чтобы вы могли либо исследовать, либо игнорировать?

...