Олег, можно сделать такой хак: interface BaseHtmlComponentProps { onBlur: (e: Event) => void; } export interface ReplacedProps extends BaseHtmlComponentProps { onBlur: any } interface ComponenetProps extends ReplacedProps { onBlur: (value:string, e: Event)=>void }

жесть

прослойка с any)

кидаю вариант на type, нет надо хакнуть)

Олег, можно сделать такой хак: interface BaseHtmlComponentProps { onBlur: (e: Event) => void; } export interface ReplacedProps extends BaseHtmlComponentProps { onBlur: any } interface ComponenetProps extends ReplacedProps { onBlur: (value:string, e: Event)=>void }

Не надо any

Олег, можно сделать такой хак: interface BaseHtmlComponentProps { onBlur: (e: Event) => void; } export interface ReplacedProps extends BaseHtmlComponentProps { onBlur: any } interface ComponenetProps extends ReplacedProps { onBlur: (value:string, e: Event)=>void }

это считаем хаком

interface BaseHtmlComponentProps{ onBlur: (e: Event) => void; } interface ComponenetProps extends BaseHtmlComponentProps{ onBlur: (value:string, e: Event)=>void } вот так экстендить нельзя, тайпскрипт ругается

Реализуйте во втором интерфейсе первый interface ComponenetProps extends BaseHtmlComponentProps{ onBlur: (e: Event) => void; onBlur: (value:string, e: Event)=>void }

http://www.typescriptlang.org/play/#src=type%20BaseHtmlComponentProps%20%3D%20%7B%0D%0A%20%20onBlur%3A%20(e%3A%20Event)%20%3D%3E%20void%3B%0D%0A%7D%0D%0A%0D%0Atype%20ComponentProps%20%3D%20BaseHtmlComponentProps%20%26%20%7B%0D%0A%20%20onBlur%3A%20(value%3Astring%2C%20e%3A%20Event)%20%3D%3E%20void%0D%0A%7D%0D%0A%0D%0Aconst%20p%3A%20ComponentProps%20%3D%20%7B%7D%0D%0A%0D%0Ap.onBlur('string'%2C%20%7B%7D%20as%20Event)%0D%0Ap.onBlur(%7B%7D%20as%20Event)%0D%0A

p.onBlur('string', {} as Event) p.onBlur({} as Event) -> не похоже на нормально, что он это хавает

p.onBlur('string', {} as Event) p.onBlur({} as Event) -> не похоже на нормально, что он это хавает

где

я просто Event сделал через as

а можно просто добавить второй аргумент в базовый интверфейс

и не велосипедить

ну ты перегруженую функцию вызываешь с сигнатурой исходной

втф как бы

а можно просто добавить второй аргумент в базовый интверфейс

лучший вариант, согласен

пока самое чистое - отказаться от наследования

ну ты перегруженую функцию вызываешь с сигнатурой исходной

так две перегрузки

пока самое чистое - отказаться от наследования

не стоит

так две перегрузки

все, затупил

наследование — гиблое дело

Не гиблое

гиблое дело, видя ошибку не исправлять ее

а искать пути обхода

Просто здесь пытаются добавить телеге пятое колесо

Здесь нет наследования как такового, это два равноправных интерфейса, разных

Здесь нет наследования как такового, это два равноправных интерфейса, разных

контекста нет

стоило хотя бы задуматься "почему мне это не разрешают"

Что человек дал — по тому и сужу

По данным интерфейсам видно что отражают они одну идею, но наследования между ними никакого нет

Что человек дал — по тому и сужу

Я поясню свою позицию, меня такой подход тоже не очень радует

type мощнее, хз зачем интерфейсы нужны

Типы не умеют в мерж описаний

type мощнее, хз зачем интерфейсы нужны

type нужно применять там, где они нужны по смыслу

interface ComponenetProps extends BaseHtmlComponentProps{ onBlur: (e: Event) => void; onBlur: (value:string, e: Event)=>void } пишет дупликейт идентифаер )

короче я пока нашел способ только через прослойку с any

остальные предложенные порождают ошибки компиляции(

Типы не умеют в мерж описаний

это что

interface ComponenetProps extends BaseHtmlComponentProps{ onBlur: (e: Event) => void; onBlur: (value:string, e: Event)=>void } пишет дупликейт идентифаер )

interface BaseHtmlComponentProps { onBlur(e: Event): void; } interface ComponenetProps extends BaseHtmlComponentProps { onBlur(e: Event): void; onBlur(value: string, e: Event): void; }

а так?

а так работает...

type нужно применять там, где они нужны по смыслу

везде нужны

а ведь тоже на хак смахивает

везде нужны

не везде

не везде

где не нужны?

а ведь тоже на хак смахивает

и есть хак, я пока не особо понимаю зачем, так как нет контекста

где не нужны?

там где описывается структура, как минимум

это что

https://www.typescriptlang.org/docs/handbook/declaration-merging.html

Типы не умеют в мерж описаний

Деклараций мб?

А

Понял

Ну ок, единственный кейс)

и есть хак, я пока не особо понимаю зачем, так как нет контекста

да есть компонент реактовый пропсы которого экстендят стандартные html-ные от, например, input-а но вот onBlur ему нужен другого типа не как в input-е никак не мог нормально заоверрайдить

Ну ок, единственный кейс)

interface Animal { name: string; } type Animals = Animal[];

interface Animal { name: string; } type Animals = Animal[];

type Animal = { name: string }

да есть компонент реактовый пропсы которого экстендят стандартные html-ные от, например, input-а но вот onBlur ему нужен другого типа не как в input-е никак не мог нормально заоверрайдить

я с react не знаком)

type Animal = { name: string }

некрасиво же

да есть компонент реактовый пропсы которого экстендят стандартные html-ные от, например, input-а но вот onBlur ему нужен другого типа не как в input-е никак не мог нормально заоверрайдить

Спреды

Нужны спреды, когда уже смержат Spread type от sandersn

https://www.typescriptlang.org/docs/handbook/advanced-types.html One difference is that interfaces create a new name that is used everywhere. Type aliases don’t create a new name — for instance, error messages won’t use the alias name. A second more important difference is that type aliases cannot be extended or implemented from (nor can they extend/implement other types). Because an ideal property of software is being open to extension, you should always use an interface over a type alias if possible.

Второе уже не актуально

И зачем мне смотреть на имя типа, когда структура важнее

В подсказках вскода etc

type мощнее, хз зачем интерфейсы нужны

Интерфейсы для наследования и структур, типы для алиасов и mapped types

Второе уже не актуально

можно сделать type A = ... type B extends A = ... ?

можно сделать type A = ... type B extends A = ... ?

не

type B = {} class A implements B {}

type B = {} class A implements B {}

речь про расширение

type A = B & {}

type A = B & {}

опять таки, больше на хак похоже

Не похоже

Потому что он и есть)

не хак, мы это во всю используем ;)

не хак, мы это во всю используем ;)

Да жесть же)

class Fake {} ... потом & с ним

class Fake {} ... потом & с ним

Вот это хак)

А & для типов обычных ок

А & для типов обычных ок

Да, но не там где можно использовать интерфейсы

Да, но не там где можно использовать интерфейсы

С чего это?)

https://www.typescriptlang.org/docs/handbook/advanced-types.html One difference is that interfaces create a new name that is used everywhere. Type aliases don’t create a new name — for instance, error messages won’t use the alias name. A second more important difference is that type aliases cannot be extended or implemented from (nor can they extend/implement other types). Because an ideal property of software is being open to extension, you should always use an interface over a type alias if possible.

.

С новым именем уже не совсем так

А второй абзац совсем ни о чем, ведь типы можно расширять

А ocp вообще не про это Оо

опять таки, больше на хак похоже

.

там по ссылке есть же примеры

.

Мы тут не пикасо обсуждаем

думаю дальше про монорепки: дано: монорепа с пакетами, хочется писать нормальные интеграционные тесты (т.е. кросс-пакетные) задача: (цитата): While integration tests are now easier, they still have a major issue: packages requiring other packages (after npm linking them) will use their main entry point specified in the package.json, which will point to the compiled dist/ directory in the case you use a build step. This is super awkward: these files are meant for consumers, not for your tests. Running tests in watch mode while changing code of multiple packages now implies that some tsc watch task would have to continuously compile those dist/ directories. Additionally, you’ll probably want to test the src/ files when testing a package directly. So you actually have two simultaneous sources of truth: src/ for tests that directly import the package, dist/ for indirect imports. Maybe I’m not seeing something, but this sounds like a mess. :) возможно, как-то в тестовом окружении можно подменять импорты, чтобы использовать код из src/ кто-то еще думал над этой проблемой? как вы решаете ее у себя в проекте?

у меня много сабпроектв которые инклюдят кроссово части друг друга. Я хочу когда-нибудь навести в этом порядок

хм, наверняка ты тоже об думал ^ как у вас это организовано?

я всё подрубаю исходниками

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

я всё подрубаю исходниками

спасибо, да, я так не смогу сделать( буду думать в сторону того, чтобы подменять импорты, чтобы они указывали на src/ в тестовом окружении и гуглить/гитхабить конечно же :) для jest, например, можно препроцессор мутануть, который это сделает

кстати, от ms есть какая-то штука для монореп https://github.com/Microsoft/web-build-tools/blob/master/apps/rush/README.md, не пробовал, только увидел, они ее для шейрпоинта (о ужас) делали

Новая гифка про diving into javascript https://cs6.pikabu.ru/post_img/2017/09/16/4/1505534468181426494.gif

Я так и не понял, что за проблема у тебя с монорепами