Ребята, подскажи плз. Интересно мнение комьюнити. Почему в ТС типы

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

Типы и интерфейсы это по сути одно и тоже, если на проекте все уложено в типы, то все будет в типах. Может на уровне психологии как-то работает. Типа парень выучил js и знает что такое интерфейс. И так как юзер хорошо затипизирован (важная инфа же), то кодер как бы говорит: «Теперь я точно знаю этот интерфейс!» и гордо именно эту диррективу

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

Там разница немного сложнее, интерфейс - это такая штука которая пришла из C#, которая там выполняла важные функции для реализаций методолгий ООП, в ТС она приехала потому что была супер очевидна. Но со временем её стало просто не хватать, по этому сделали более резиновую штуку как type, когда ты можешь иметь тип Key, который является по факту числом, но при этом имеет в своей основе семантику. К примеру есть в базе записи id, key (они обе цифры, принадлежат к одной записи в базе и не важно зачем они нужны в данном примере). Часть методов работает с id, другая с key (просто потому что прошло много времени жизни проекта), вот чтоб их различить - интерфейс не покатит, а тип даже очень. простые записи типа type Id = number; type Key = number; уже начинают убирать много проблем. Примитив, просто, но очень эффективно. Короче и то и другое нужно. Они не равнозначны, хотя умеют делать почти одинаковые вещи, но тайп более гибок в этом всём.

Интрефейсы были приудманы ещё раньше в тех же плюсах

Ну вот я и не понимаю зачем interface из TS сравнивать с интерфейсами из ООП.

Они исполняют ту-же функцию что и интерфейсы из C#

Наверняка и в других языках тоже, ООП - это методология же.

К сожалению, нет. interface A { a: number } interface A { b: number } - это уже дикость с точки зрения ООП так расширять фривольно. Это как вообще?)

после js и это схавают

НУ это полезный инструмент для расширения типов библиотек. Или window того же. Но все равно, я к тому что сравнивать нельзя. Нет тут связи, кроме названия.

Соглашусь - это дичь. Удивлён что нету подсветки ошибок в стрикт моде. Ну такое писать - в ногу себе стрелять.

ну это как dog.prototype.say = poop тоже полезно, наверное, где-то

это способ расширять библиотечные интерфейсы

А значит в своём коде такое писать точно не надо, а то будет бо-бо и пиздык-пиздык на ревью. Я бы именно такое и устроил)

А как вы будете расширять window. если нужна глобальная переменная __state для SSR? При инициализации приложения?

Интерфейсы ни к какому шарпу отношения не имеют. Никакие функции он в контексте ООП не выполняет. Интерфейс - это просто подъём на уровень языка vtable, которую придумали тысячи лет назад. Почему везде бегают с этими интерфейсами? Потому как когда копипастили из цпп не осилили множественное наследование и пришлось сужать всё до старой сишной vtable. Само ооп про инкапсуляцию, которой интерфейсы не являются. Потому что таблицы - массивы указателей. Конечно это как-то пришлось неявно натягивать на this, но обсуждается не это. Никакой резиновой штуки как "type" не существует. type - это просто типовый алиас. То, что какой-то синтаксис внутри интерфейса не работает - это не проблема интерфеса и ничего не мешало там это реализовать. Все типы в тс структурные, а значит анонимные. Интерфейс же именованная сущность - она не может существовать без имени. Теоретически можно было добавить анонимные интерфейсы, чтобы ты писал const x: interface {}, но это слишком страшно. Поэтому основными стали литеральные типы, которыми в том числе являются массивы/объекты. Вот как следствие всего этого появились литеральные типы объектов. 1) нужно писать в аннотациях, 2) нужна бы та самая кастомная семантика. Потому как навешивать её на условный Array/Object убого(но расту это не мешает, кстати). Пытались вводить ключевые слова типа object, правда это не масштабируется и function/array уже не случилось. Ну потому что function-ключевое слово уже занято. А то, что там разное поведение - причины этого частично указаны выше. В компиляторе ts не какой-либо системности/универсализации. Там всё - несвязная adhoc-лапша, где каждая сущность реализована своим костылём и не связана друг с другом. Поэтому чтобы что-то добавить в интерфейс - нужно 2 раза писать одно и тоже, а ещё как-то интегрировать в написанную лапшу для интерфейса. Они пытаются это починить - вон недавно enum латали. Но воз и ныне там(в опе). Твои выводы в результате вполне себе правильный. Литеральный тип он куда более универсальный, но интерфейс "другой" просто по причине того что старый, в него не добавляли новые фичи. А его фичи не добавляли в литеральные типы(ну и понятно почему - потому как одна из основных его фишек связана с именем, которого там нет). Самое type - это типовый алиас и его имя к типа отношения не имеет.

Ну кресты кроме самого ооп создали ещё эту одр-религию. В чём проблема такое писать? Никто не скажет. В том же цпп есть основания, что там типа сишнкая днище-линковка, видимость сверху вниз(не всегда) и изменения снизу не будут видны сверху. Всё это не какие-то преимущества, а недостатки(хотя про видимость можно поспорить. По крайней мере о том как оно работает в js/ts). Таких проблем в ts нет. Самое смешное, кстати. Что цпп что-то может именно потому что основная фича вопреки всему нарушает эти шизо-правила. Так случайно вышло, но до сих пор смешно.