Перестраиваться на очень похожий на настоящий ооп в жс с типами

Это обман

Чтобы набрать классы

На первый взгляд кажется что это вносит ясность разделяя названия класса и интерфейса. А я правильно понимаю, что стоит придерживаться таких названий как в документации. Просто мне раз сдели замечание что пишу без I

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

где есть норм ооп

Ждём, когда начнётся холивар про Алана Кея, наследование и Smalltalk

Все это точно так же ок и в случае одного класса без интерфейса

Не ок, у класса состояние и приватные поля есть, интерфейс = контракт

Ну это обсосали уже сто раз, начиная с банды четырёх и далее

Не ок, у класса состояние и приватные поля есть, интерфейс = контракт

Слава богу в тсе типы чуть лучше чем в 90ые в жаве

Эм

Это к чему?

Интерфейс подталкивает к определённому способу кодирования

Как минимум его нельзя new)

Фабрики, di, вот это всё

Типу тоже нельзя new

Так речь вроде про классы вс интерфейсы

Да нет никакого vs.

type в тс классный, кто ж спорит

Да нет никакого vs.

И срача на 20 экранов не было)

И срача на 20 экранов не было)

Не было же.

Не было же.

Ну так я ж сразу так и сказал

На первый взгляд кажется что это вносит ясность разделяя названия класса и интерфейса. А я правильно понимаю, что стоит придерживаться таких названий как в документации. Просто мне раз сдели замечание что пишу без I

А в TS между интерфейсом и типом практически нет разницы. Учитывая мержинг определений.

Я сначала тоже так делал, но потом понял, что это бессмысленно.

В итоге сейчас пишу без префиксов.

А в TS между интерфейсом и типом практически нет разницы. Учитывая мержинг определений.

Вааааааащще нет.

Вааааааащще нет.

Ну давай, расскажи, в чём разница между type и interface :)

Ну давай, расскажи, в чём разница между type и interface :)

Типы выполняются строго, интерфейсы — лениво.

Типы выполняются.

Интерфейсы выполняются лениво.

Кажется, моя остановочка!

(Хотя хоть убей, не понимаю, почему типы они решили выполнять строго.)

Типы выполняются.

Эвалюэйтятся, если тебе так приятней.

Мне это неприятно.

Ну.

И я ничего не понял, если что. Ты про эти новые условные типы?

¯\_(ツ)_/¯

Так там, вроде, всё одинаково выполняется. Нету условных интерфейсов.

И я ничего не понял, если что. Ты про эти новые условные типы?

Нет.

Про то, что интерфейсы можно рекурсивные, а типы — нет.

И последнее делает мне очень-очень больно.

type Foo = { self: Foo; } Сконпелировалось.

А как нельзя?

А, ок, CRTP не рабоотает. type Foo2<T> = { self: Foo2<T> } type Foo3 = Foo2<Foo3>; // Type alias 'Foo3' circularly references itself.

type Foo = { self: Foo; } Сконпелировалось.

type A = B | C; type B = A | C; type С = 'b'; Ща менее юзлес.

Не.

Блч.

А, ок, CRTP не рабоотает. type Foo2<T> = { self: Foo2<T> } type Foo3 = Foo2<Foo3>; // Type alias 'Foo3' circularly references itself.

В противоположность, interface Foo3 extends Foo2<Foo3> { } работает

Да всё, я тебя понял.

type A = B | C; type B = A | C; type С = 'b'; Ща менее юзлес.

↑ хоть и не понял, что ты этим сообщением хочешь донести

↑ хоть и не понял, что ты этим сообщением хочешь донести

Я тоже.

Видимо, что спать по 4 часа в двое суток — вредно.

Я тоже.

Ок, а теперь я понял.

Ты хочешь взаимно рекурсивные определения, чтоб в A можно было использовать B, а в B можно было использовать A.

Но это работает с типами, смотри: type A = { b : B }; type B = { a: A };

Типы выполняются строго, интерфейсы — лениво.

Кароч, это только Y в типах вида type X = Y выполняется строго. В других формах определений (например, интерфейсообразный type X = { y: Y }) он выполняется «лениво». Теперь я тебя окончательно понял и мне кажется, что изначальный тезис не совсем верный (хотя проблема действительно существует).

Кароч, это только Y в типах вида type X = Y выполняется строго. В других формах определений (например, интерфейсообразный type X = { y: Y }) он выполняется «лениво». Теперь я тебя окончательно понял и мне кажется, что изначальный тезис не совсем верный (хотя проблема действительно существует).

Кароч, в3ц-валидный дтд дома описать никак. Кмк.

type A = B | C;

что за или?

это вообще норма?

как это в нормальном языке повторить?

как это в нормальном языке повторить?

нормальный это какой?

"или" - мощная тема тс

Нормальный ™️язык

как это в нормальном языке повторить?

Никак

Джава наверно

ERROR: S client not available

Никак

Ну теоретически и не совсем прям именно так, но через каст к базовому классу, если такой есть. И если я правильно идею понял)

Я не говорю что это хорошо и правильно и удобно, для протокола

В нормальном языке, как мне посаны пояснили, это sum type или discriminated union. А в TS у нас это, типа, unsdiscriminated union — потому что тегов нету, и одинаковые элементы типов могут коллапсировать (undefined | undefined ≡ undefined).

Ну то есть прямой аналогии в «нормальных» языках, кажется, нету?

А где есть?

Кажись, в dotty обещали добавить (ну или там подобный синтаксис будет)?

И срача на 20 экранов не было)

Теперь есть

Ну то есть прямой аналогии в «нормальных» языках, кажется, нету?

Кек

Теперь есть

У меня просто экран маленький. Только тссс

T и булеан несовместимы

А что если ты в качестве наме передашь резулт? А там не т.

сделай type IApiResponse<T> = T & {result: boolean}

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

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

У тебя имя поля для каждого т определённое?

И поле только одно?

сделай type IApiResponse<T> = T & {result: boolean}

и потом делаешь const resp = IApiResponse<{user: User}> = {...}

У тебя имя поля для каждого т определённое?

в принципе да, но я хотел бы оставить тут место для изменений. Поле одно

в принципе да, но я хотел бы оставить тут место для изменений. Поле одно

Вторым тайп аргументом задай имя поля (екстендс стринг), и в индексе Кокок ин ФилдНейм. Но ето ни тощн.

интерфейс на твою апишку или существующую?

на мою

на мою

Тогда тебе посоветуют, например, сделать имя поля константным.

Ну и это самую малость может немножко мономорфизм повысить.

Ну ты и тупой.

А, не, ты хуй.

@mkusher

Всем привет! Кто-нибудь знает, почему у HTMLElement.offsetParent тип Element, а не HTMLElement?

Всем привет! Кто-нибудь знает, почему у HTMLElement.offsetParent тип Element, а не HTMLElement?

Привет. Возможно потому что HTMLElement может быть вложен например в SVGElement

Привет. Возможно потому что HTMLElement может быть вложен например в SVGElement

Ооо, действительно. Спасибо!