Тебе не нужен весь класс в дженерике для того чтобы обратиться к полю parent

Структурная типизация

вообще лютая фигня получается

Опиши просто тип с реально используемыми тобой полями

я типизацию последний раз видел в универе в плюсах :)

ну так они реально используются

Кто они

я тут один? :)

эти поля. Parent например

а, я понял, туплю

Без например

Во)

ну все равно хрень получается. Если мне в будущем у потомку нужно будет использовать какой-то метод, определенный в нем, этот метод нужно будет выносить в тип

Ты его уже вынес, вопрос лишь в том как это адекватнее всего типизировать

я думал, может есть какой-то тип типа "класс и его потомки"

потому что T по идее будет работать, но только для BaseComponent-а

ладно, спасибо, буду курить доки

я думал, может есть какой-то тип типа "класс и его потомки"

этот тип называется класс)

убери T, из addChild

о

магия

addChild<U extends BaseComponent<T»(child: U) {

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

работает?

вроде да. правда в другом месте полезли ошибки

тепер еще понять бы как оно работает )

я ток не уверен что тип правильный будет)

у парента наверно другой T

теперь в других местах, после импорта BaseComponent ругается

ну да

укажи тип)

у тебя T еще где-то юзается чтобы типизировать что-то?

нет

тогда зачем генерик)

ну, я изначально задал вопрос не про то :))

-- Двач, ем с ножа, постоянно порезан рот, как лечить? -- Не ешь с ножа -- НЕ УЧИТЕ МЕНЯ ЖИТЬ Я ПРОСТО ЗАДАЛ ВОПРОС

ладно, пасиба, пойду сначала

-- Двач, ем с ножа, постоянно порезан рот, как лечить? -- Не ешь с ножа -- НЕ УЧИТЕ МЕНЯ ЖИТЬ Я ПРОСТО ЗАДАЛ ВОПРОС

Заскриньте с контекстом в мемесы.

вы ж мне сами и посоветовали дженерик заюзать )

тут он был уже

-- Двач, ем с ножа, постоянно порезан рот, как лечить? -- Не ешь с ножа -- НЕ УЧИТЕ МЕНЯ ЖИТЬ Я ПРОСТО ЗАДАЛ ВОПРОС

Дефолт в чатиках

Ребят, кто подскажет, можно ли смешивать в webpack проекте и js и ts код?

Да

есть какие нюансы? просто немного не могу, как это сделать

пишу допустим класс в ts, к нему же хочу обращаться из js кода

пишешь типы для жс кода

а

Дефолт в чатиках

Каждый раз актуально же))

ну то есть это уже будет не класс, а функция-конструктор

в другую сторону)

ну то есть это уже будет не класс, а функция-конструктор

компиль в ес6

Бля, а вообще есть ещё смысл транспилить стрелки, консты и классы?

компиль в ес6

допустим какой-нибудь js модуль хочет заимпортить модуль с ts-классом

я пишу типа const classA = require('....')

вот а что внутри require?

скомпиленный модуль

либо делай монорепозиторий

так допустим модуль ещё не скомпилен

и разложи по разным пакетам тс и жс файлы

вот же гемор

ERROR: S client not available

https://github.com/lerna/lerna

наверное легче всё на es6 написать

легче жс в тс импортить, а не наоборот

жесть, ещё какую-то тулу надо юзать, ох уж этот мир js)

легче жс в тс импортить, а не наоборот

да, понимаю

спасибо за помощь)

жесть, ещё какую-то тулу надо юзать, ох уж этот мир js)

ща бы не юзать 2030293023+ пакетов

ща бы не юзать 2030293023+ пакетов

как по мне, так это не есть хорошо)

ждём-с когда всё стабилизируется и не придется изучать новые пакеты, пока скачиваются старые

Классический способ при работе с тайпингами: ставишь версии начиная с последней и идешь вниз пока не пойдет

Версионирование в тайпингах вообще как-то хреновато работает, на самом деле. Неужели ничего лучше мы не можем придумать? Как-то отдельно вести версию модуля и версию самого тайпинга, например?

Версионирование в тайпингах вообще как-то хреновато работает, на самом деле. Неужели ничего лучше мы не можем придумать? Как-то отдельно вести версию модуля и версию самого тайпинга, например?

Пихать тайпинги в репозиторий проекта

Пихать тайпинги в репозиторий проекта

Это решает другую проблему, а не ту, которую я обозначил. Твоя проблема решается также лок-файлами, например.

У меня почти нет проблем с твйпингами

Подскажите, если у меня есть некий код типа enum Type { TypeA, TypeB } interface { type: Type; data: ITypeA | ITypeB; } притом data будет иметь интерфейс ITypeA если type === Type.TypeA и анаогично для других типов. WebStorm и/или компилятор будут подсказывать правильный тип data?

нет

или проверять на этапе компиляции? код будет вида switch (item.type) { case Type.TypeA: ... case Type.TypeB: ... } м.б. это как то объявить можно?

Подскажите, если у меня есть некий код типа enum Type { TypeA, TypeB } interface { type: Type; data: ITypeA | ITypeB; } притом data будет иметь интерфейс ITypeA если type === Type.TypeA и анаогично для других типов. WebStorm и/или компилятор будут подсказывать правильный тип data?

Дисджоинт юнион.

Дисджоинт юнион.

Спасибо! Именно это и искал!

или проверять на этапе компиляции? код будет вида switch (item.type) { case Type.TypeA: ... case Type.TypeB: ... } м.б. это как то объявить можно?

enum TypeEnum { TypeA, TypeB } interface TypeBase { type: TypeEnum; } interface TypeA extends TypeBase { type: TypeEnum.TypeA; data: string; } interface TypeB extends TypeBase { type: TypeEnum.TypeB; data: number; } type Type = TypeA | TypeB; function something(item: Type): void { switch (item.type) { case TypeEnum.TypeA: console.log(item.data.startsWith); break; case TypeEnum.TypeB: console.log(item.data.toFixed); break; } }

это сейчас и пишу! спасибо!

enum TypeEnum { TypeA, TypeB } interface TypeBase { type: TypeEnum; } interface TypeA extends TypeBase { type: TypeEnum.TypeA; data: string; } interface TypeB extends TypeBase { type: TypeEnum.TypeB; data: number; } type Type = TypeA | TypeB; function something(item: Type): void { switch (item.type) { case TypeEnum.TypeA: console.log(item.data.startsWith); break; case TypeEnum.TypeB: console.log(item.data.toFixed); break; } }

Имхо базовый тип можно не объявлять

имхо енум не нужен

И это тоже, да

нужен же общий признак

дискриминатор

ща бы дискриминировать по общему признаку

Структурная типизация же

ну да, струкурная типизация, никто не спорит)

никто случаем не пытался впилить элм в тайпскрипт проект?

nevermind

лол