Всем привет. Друзья, подскажите пожалуйста почему не рекомендуется именовать интерфейсы с префиксом I?

Потому что это не несёт абсолютно никакого профита

Эта странная необходимость вызвана лишь тем что тс не различает импорт типов и объектов и первые захотелось выделить хоть как-то

Но это всё равно в такой форме не работает

Но это всё равно в такой форме не работает

А чисто визуально понимать тип объекта это или интерфейс ?

Да, но это днище же

Да, но это днище же

Что вы такое вообще несёте?

Традиция тянется откуда то с до диеза

+ можно создать интерфейс ICircle и реализацию Circle + когда начинаешь писать имя интерфейса для реализации в классе в подсказке будут только интерфейсы?

Всем привет. Друзья, подскажите пожалуйста почему не рекомендуется именовать интерфейсы с префиксом I?

Обозначайте через I это best practices

Зачем мне в подсказке ВСЕ интерфейсы?

Не релевантные от слова вообще

Не релевантные от слова вообще

А зачем в подсказке классы когда нужен интерфейс?

Лол

Обозначайте через I это best practices

Здесь https://angular.io/guide/styleguide#interfaces говорится что так делать не надо, со ссылкой сюда - https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines

А там просто сказано что это плохо и всё

Код должен быть связан по смыслу, в том числе семантически

Зачем мне в подсказке ВСЕ интерфейсы?

Имел в виду когда выводит с минимум двух букв типа IC

Так идёт поиск по тому что ты вводишь а не по тому что ты подумал

Хотя в имени очевидно что это интерфейс.

Хотя в имени очевидно что это интерфейс.

Это и есть днище

Это и есть днище

Очевидность того что ты работаешь с интрфейсом - есть днище?

Чем плохо IHero или HeroInterface?

Да

Эта странная необходимость вызвана лишь тем что тс не различает импорт типов и объектов и первые захотелось выделить хоть как-то

То что нет import type это и есть дно

Но программисту то что делать?

А при чем тут тс, это общая практика для многих языков

И это не повод форсить уродливый нейминг

Нужно же как-то обозначить интерфейс, иначе может быть банально конфликт имён с классом или тем что он должен декларировать.

А давайте все переменные называть с V

А классы с C

А чо нет то

А давайте все переменные называть с V

с $

А давайте все переменные называть с V

Ну не перегибай.

Ок.

ЗАТО ПОНЯТНО ВСЕ ПОДСКАЗКИ ЕСТЬ

и убрать эти var let и const, они не нужны

Во во)

То что нет import type это и есть дно

нет)

Объясни как ты назовёшь интерфейс для класса Hero?

Hero

Я не буду плодить сущности

А конфликта не будет?)

Конкуренция названия?

Объясни как ты назовёшь интерфейс для класса Hero?

Зачем вообще для класса интерфейсы делать?

Во во

Кек

А конфликта не будет?)

У меня нет

Зачем вообще для класса интерфейсы делать?

Не для класса. Для объекта, аргумента ф-ции. Чего цепляться к словам?

Потому что это важно

Ну как бы да, это абсолютно разные вещи)

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

А там просто сказано что это плохо и всё

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

То что нет import type это и есть дно

он же различает, если импорт используется только как тип то он дропается. Или я что то путаю?

он же различает, если импорт используется только как тип то он дропается. Или я что то путаю?

это да

Да и вообще это не дно, это норм, как по мне))

Да и вообще это не дно, это норм, как по мне))

мне тоже кажется отдельный импорт для типов нинужен

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

пусть тогда были бы import const, import сlass

абсурд же

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

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

зочем

зачем интерфейс? почему не сделать абстрактный класс

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

Абстрактный класс?

зачем интерфейс? почему не сделать абстрактный класс

В Js вообще этого ни чего не будет, останутся лишь классы, тогда зачем такой надрыв? Правильно - незачем, пишите почти все на классах

Нет,наоборот абстрактные классы нужны крайне редко, интерфейсы и то чаще

Абстрактный класс?

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

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

Но ведь может и не иметь

И да как сказано выше, назначение у абстрактных классов другое

Но ведь может и не иметь

Если нет не одной реализации то какой смысл в абстрактном классе? Получается интерфейс, не? Или я что-то не понимаю

В общем друзья я понял мысль. Проверил, действительно конфликтов имён не может быть.

По этому вполне разумно.

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

??

В общем друзья я понял мысль. Проверил, действительно конфликтов имён не может быть.

В плане?

В общем друзья я понял мысль. Проверил, действительно конфликтов имён не может быть.

Так сразу было сказано, что конфликтов не будет, это просто бест практикс из др языков

В плане?

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

Если в одном файле есть импорт и класса и интерфейса с одинаковым названием Box, при объявлении переменной типа Box не будет конфликта?

Если в одном файле есть импорт и класса и интерфейса с одинаковым названием Box, при объявлении переменной типа Box не будет конфликта?

Воспроизведи если есть время. Самому интересно.

Воспроизведи если есть время. Самому интересно.

Сейчас нет возможности, но я думаю конфликт будет уже на стадии импорта

Сейчас нет возможности, но я думаю конфликт будет уже на стадии импорта

Проверил. Есть конфликт.

Duplicate identifier 'A'.

Если что-то импортнуть а что-то объявить, тогда не бдует конфликтов.

А если попытаться импортировать 2 сущности с одинаковыми именами, то разумеется будет конфликт и это логично.

Можно ли сейчас как-то настроить ts/tslint, чтобы неиспользуемые переменные подсвечивались в vscode, но не прерывали компиляцию?

Укажи тип у одной интерполяции

А тип для темы как указывать чтобы подхватывалось после одной интерполяции? Добавил в тип пропсов поле theme (по сути повторил вручную тип ThemedStyledProps) с типизацией для темы и вторая интерполяция не подхватывает тип пропсов.

А тип для темы как указывать чтобы подхватывалось после одной интерполяции? Добавил в тип пропсов поле theme (по сути повторил вручную тип ThemedStyledProps) с типизацией для темы и вторая интерполяция не подхватывает тип пропсов.

https://www.styled-components.com/docs/api#typescript

https://www.styled-components.com/docs/api#typescript

facepalm

Типизируются SC всё же отстойно, фактически никак

То что они называют "Caveat" это банально огромная проблема их подхода самого по себе

Типизируются SC всё же отстойно, фактически никак

не идеально, но если разобраться то нормально

Далеко от идеала

Потому что template literal functions это совершенно особый кейс в жс со своим типом, что накладывает ограничения и вызывает проблемы само по себе, как ни крути

С этим можно жить, но это по прежнему отстойно и такие вещи замалчивать нельзя)

Далеко от идеала

какие проблемы например? может я с ними еще не встречался.

Глава Caveat with Stateless Components вкратце формулируется как "наши компоненты не имеют вывода типов от слова вообще, deal with it"