Как исправить ошибку при декомпозиции кортежа?

Question

[Роман]

Начал постигать TypeScript и столкнулся с проблемой, которую не смог решить.

И так, есть код

// нужно чтобы возвращало тип функции с последовательно указанными параметрами
type EventReceiver<T> = (...params: T ) => void; 

// тестируем
type FeatureOptions0 = EventReceiver<[string, number]> 
// возвращает то что нужно - type FeatureOptions0 = (params_0: string, params_1: number) => void

Но vscode подсвечивает ошибку


При этом в FeatureOptions0 лежит именно то что надо


В общем вопрос такой, как исправить эту ошибку (тип EventReceiver) и получить конечный вариант (тип функции)?

Что пробовал:
- явное преобразование кортежа (T) к массиву (ошибка остается)
- прямую подстановку кортежа [string, number] вместо (Т) (ошибки нет, на выходе правильный тип функции, но нужен именно автоматический тип для фанки, зависящий от переданного из вне кортежа с типами)

Буду благодарен за решение вопроса, даже без пояснений (пояснения сам погуглю))))

Comments

[WbICHA]

T extends unknown[]

[Роман]

WbICHA, большое спасибо, вы меня выручили.

Не подскажете еще один момент. Очень хочется использовать EventEmmiter, нашел такую реализацию обертки https://rjzaworski.com/2019/10/event-emitters-in-t...

Вот в принципе ее и дорабатывал до состояния, когда можно указать обработчикам событий несколько параметров разных типов. Благодаря вам все получилось


Но возможно так делать не принято и сейчас предпочтительнее принципиально другой подход. В общем буду благодарен если просветите по этой теме.

[Роман]

WbICHA, ну и при наличии у вас желания и возможности был бы рад фидбеку по коду (как можно делать, и как лучше не делать). Сам я пока еще не вижу нюансов.

import ExtendEventEmitter from '../libs/class.extend.event.emitter'

type EventMap = Record<string, any>;
type EventKey<T extends EventMap> = string & keyof T;

type EventReceiver<T extends unknown[]> = (...params: T ) => void;
type FeatureOptions0 = EventReceiver<[string, number]>

interface Emitter<T extends EventMap> {
    on<K extends EventKey<T>>
        (eventName: K, fn: EventReceiver<T[K]>): void;
    once<K extends EventKey<T>>
        (eventName: K, fn: EventReceiver<T[K]>): void;
    off<K extends EventKey<T>>
        (eventName: K, fn: EventReceiver<T[K]>): void;
    emit<K extends EventKey<T>>
        (eventName: K, ...params: T[K]): void;
}

export class MyEmitter<T extends EventMap> implements Emitter<T> {
    private emitter = new ExtendEventEmitter();
    on<K extends EventKey<T>>(eventName: K, fn: EventReceiver<T[K]>) {
        this.emitter.on(eventName, fn);
    }
    once<K extends EventKey<T>>(eventName: K, fn: EventReceiver<T[K]>) {
        this.emitter.once(eventName, fn);
    }
    off<K extends EventKey<T>>(eventName: K, fn: EventReceiver<T[K]>) {
        this.emitter.off(eventName, fn);
    }
    emit<K extends EventKey<T>>(eventName: K, ...params: T[K]) {
        this.emitter.emit(eventName, params);
    }
}

const emitter = new MyEmitter<{
    data:  [string, number];
    end: [undefined];
}>();

emitter.on('end', () => {}); // ok

emitter.on('data', (a: string, f:number) => {}); // ok
emitter.on('data', (a: string) => {}); // ok
emitter.on('data', (a: string, f:string) => {}); // error
emitter.on('data', (a: boolean) => {}); // error

emitter.emit('data', 'aaa', 1); // ok
emitter.emit('data', 'aaa'); // error
emitter.emit('data', 'aaa', 'bbb'); // error

[WbICHA]

Роман,

Но возможно так делать не принято и сейчас предпочтительнее принципиально другой подход.

Не знаю, я подобное не делал и вообще не встречал, но выглядит вполне легально.

, ну и при наличии у вас желания и возможности был бы рад фидбеку по коду (как можно делать, и как лучше не делать).

Вкусовщину я трогать не буду, но что точно стоит сделать, это либо убрать бесполезный в данном случае интерфейс, либо подтягивать из него нужный тип, чтобы не копипастить:

on: Emitter<T>['on'] = (eventName, fn) => {
        this.emitter.on(eventName, fn);
}

Учитывая убогость интерфейсов для классов, лично я их вообще не использую для этих целей. Имхо, они усложняют код, увеличивают объёмы кода и создают больше мест для потенциальных ошибок.

И ещё, почему тут не пустой массив?
end: [undefined];

[Роман]

WbICHA, спасибо за уделенное время.

Всего второй день втыкаюсь в TS, так что многое для меня сейчас воспринимается по принципу "не понимаешь как работает - не трогай"))))

end: [undefined];
WbICHA, да в массив обернул для стандартизации, а убрать undefined не сообразил, другое в голове крутилось)))

За мысль про интерфейс спасибо, пока больше плаваю чем работаю, понемногу разбираюсь в хитросплетениях TS и по мере обретения понимания что и за чем исправляю/дорабатываю/перерабатываю.

PS: В общем у меня пока по TS впечатление больше негативное, тем позитивное. Весь TS воспринимается как попытка воткнуть еще один JS с альтернативным синтаксисом, который перемешан с основным кодом и выковыривается из него на стадии транспиляции, преобразовывается в нативный js и выполняется до сборки. (интерфейс тот же объект, type - обычная переменная с объектом, описывающим тип, и т.д.) А так как цель этого альтернативного JS - простая проверка типов, перемешанная с кодом. Не пойму почему то же самое нельзя было сделать отдельным файлом, на подобии d.ts, с синтаксисом обычного JS слегка расширенного механиками проверок. Получили бы что человек знающий js без проблем писал бы проверки типов на том же js)))

Например как то так

Этот пример конечно убогий,но суть идеи демонстрирует

aaa.header.ts

declare type EventName = 'string'

declare type EventKey = function(initType, itemType){
   // обычный js работающий с обычными переменными initType, itemType и формирующий результат
}

declare type EventReceiver = (initType, itemType)=>{
   // обычный js работающий с обычными переменными initType, itemType и формирующий результат
}

declare type ListenerParams = (initType, itemType, itemIndex,...,eventName)=>{
   // обычный js работающий с обычными переменными initType, itemType, itemIndex, eventName и формирующий результат
}

declare type EmiterEvents = {
    data: [string, number],
    end: []
}

aaa.ts

export class MyEmitter{
    private emitter = new ExtendEventEmitter();
    on(eventName: EventName, fn: EventReceiver) {...}
    emit(eventName: EventName, ...params: ListenerParams(eventName))  {...}
    ...
}

const emitter = new MyEmitter: EmiterEvents ();

[WbICHA]

Роман, ну, можешь попробовать пройти это, чтобы примерно понять на что способен тс.)
https://github.com/type-challenges/type-challenges

[Роман]

WbICHA, спасибо. Пока освоил ну очень поверхностное описание, но в нем очень многого нет, так что type-challenges как раз в тему.

[Роман]

WbICHA, приступил к тайп челенжу. Первое же задание сломало мне мозг))))

написал ответ
type HelloWorld = string
и полез разбираться как работают вот эти штуки

import type { Equal, Expect, NotAny } from './test-utils'

.

Сломался на самой первой и простой конструкции

export type IsAny<T> = 0 extends 1 & T ? true : false

Благо в коде test-utils, была дана ссылка https://stackoverflow.com/questions/49927523/disal..., в которой все разжевано.

В общем такой вопрос возник, стоит ли по вашему мнению на этапе прохождения челенджа загоняться и для более глубокого погружения ковырять все эти файлы с утилитами и прочим из состава type-challenges или в процессе прохождения челенжа все эти моменты будут раскрыты в самих заданиях?

[Роман]

WbICHA, и вот еще момент. Подскажите если не сложно.

export type IsAny<T> = 0 extends 1 & T ? true : false

правильно ли я понимаю:
1. 0 extends 1 extends здесь не расширение нуля еденицей а проверка является ли ноль подмножеством множества единица? (Все что нашел про extends в TS https://metanit.com/web/typescript/3.2.php, но оно немного не вяжется у меня в голове с вышеуказанным применением)
2. что у extends приоритет меньше чем у &? (где можно почитать какие операторы и используются в объявлении типов и о правилах их применения)

[WbICHA]

Роман,

В общем такой вопрос возник, стоит ли по вашему мнению на этапе прохождения челенджа загоняться и для более глубокого погружения ковырять все эти файлы с утилитами и прочим из состава type-challenges или в процессе прохождения челенжа все эти моменты будут раскрыты в самих заданиях?

Раскрыты не будут (разве что отчасти), поэтому загоняться или нет не знаю, но то, что это в любом случае надо будет изучать и понять – это точно.
Так же замечу, что там довольно условное распределение сложности, некоторые задачки куда сложнее своих соседей и наоборот. Ну и не забывай, что внизу всегда есть ссылка на ответы.

1. 0 extends 1 extends здесь не расширение нуля еденицей а проверка является ли ноль подмножеством множества единица? (Все что нашел про extends в TS https://metanit.com/web/typescript/3.2.php, но оно немного не вяжется у меня в голове с вышеуказанным применением)
2. что у extends приоритет меньше чем у &? (где можно почитать какие операторы и используются в объявлении типов и о правилах их применения)

Что-то меня смущает этот сайт, там как-то мало инфы и всё об классах, хотя это меньшая и далеко не самая главная часть тса.
Что же касается вопроса, то экстендс всегда берёт всю левую часть и всю правую часть (до знака вопроса). По сути да, это наименьший приоритет. Грубо говоря это примерно как 0 = 1 + Т. Ну и проверка эта на эни, потому что всё, к чему прикасается эни, становится эни, а если попробовать запихнуть любой другой тип, там уже будет не эни. В целом, единицу можно заменить вообще на что угодно, кроме нуля. И эни. И анноун. И невер. И намбер. Короче, что угодно, кроме того, от чего может наследоваться 0. Да и нуль тоже можно заменить.)

И да, пожалуйста, давай на "ты".) А то начинаю чувствовать себя мудрым старцем.)

[Роман]

Спасибо за развернутое пояснение.

И да, пожалуйста, давай на "ты".) А то начинаю чувствовать себя мудрым старцем.)

WbICHA, да не вопрос))))

А вопрос ... он сейчас вот в чем :))

Есть задачка

Last of Array

Implement a generic Last that takes an Array T and returns its last element.

For example

type arr1 = ['a', 'b', 'c']
type arr2 = [3, 2, 1]

type tail1 = Last<arr1> // expected to be 'c'
type tail2 = Last<arr2> // expected to be 1

Мое решение

type Last<T extends any[]> = [any,...T][T['length']]

и то как ее решали другие
https://github.com/type-challenges/type-challenges...

типовое решение

type Last<T extends any[]> = T extends [...any, infer R] ? R : never;

Я пока еще очень поверхностно все понимаю и не вижу минусов своего решения, но гложут сомнения, ведь миллионы мух не могут ошибаться))))

В общем чем плохо мое решение? И почему преимущественное большинство решают типовым способом?

[WbICHA]

Роман, интересное решение. Не то, чтобы оно плохое или неправильное, просто оно не самое очевидное. Возможно оно хуже по производительности, а может и лучше, но вряд ли есть какая-то существенная разница.
"Типовое" решение более популярно тупо потому, что оно более очевидно для большинства.