не норм

там много чего сделано, но он не работает полностью

вроде их наработки юзают в pr для babylon, но я не смотрел код еси честно

чтоб бабилон мог парсить тс?

что такое babylon?

парсер

https://github.com/babel/babylon

оно?

Да

чтоб бабилон мог парсить тс?

да

тут завезли внезапно

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

само

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

а для php было ещё в прошлой версии

сорян, мне говна в жс-е хватает )

сорян, мне говна в жс-е хватает )

Везде говно

угу (

парни

а почему не рекомендуется I префикс ставаить?

для интерфейсов

Ну вот смотри, function handleSomething(something: ISomething) - какой здесь смысл в I? Это может быть как тип, так и интерфейс, так и класс

Грубо говоря, есть название сущности: Something. Всё остальное - лишний мусор вокруг

ну вот у меня импорт идет import {AppStore} from "features/FormBuilder/reducer";

Точно также можно сказать про префикс Abstract например для абстрактных классов

я пока не посмотрю как используется я не могу сказать что это — интерфейс или класс

IItem

я пока не посмотрю как используется я не могу сказать что это — интерфейс или класс

А тебе зачем это знать?

Ну вот смотри, function handleSomething(something: ISomething) - какой здесь смысл в I? Это может быть как тип, так и интерфейс, так и класс

эм как это возможно, где I там интерфейс, остальное -классы

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

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

да ну?))

А тебе зачем это знать?

да вот хз

да вот хз

Вот и ответ )

да ну?))

Ну да

сформулирую щас

Ну не в этом смысле же

я пока не посмотрю как используется я не могу сказать что это — интерфейс или класс

а какая тебе разница?

Всмлысе типов

Короче, проблема нейминга интерфейсов-реализаций должна решаться (на мой взгляд) так: Интерфейс/тип описывает общий кейз применения сущности, например: Mailer. А вот класс, реализующий интерфейс, должен в названии содержать уточнение, например: SmtpMailer, FakeMailer, MailerLogger и так далее

Всмлысе типов

а

тупняк =(

Короче, проблема нейминга интерфейсов-реализаций должна решаться (на мой взгляд) так: Интерфейс/тип описывает общий кейз применения сущности, например: Mailer. А вот класс, реализующий интерфейс, должен в названии содержать уточнение, например: SmtpMailer, FakeMailer, MailerLogger и так далее

ну может

Короче, проблема нейминга интерфейсов-реализаций должна решаться (на мой взгляд) так: Интерфейс/тип описывает общий кейз применения сущности, например: Mailer. А вот класс, реализующий интерфейс, должен в названии содержать уточнение, например: SmtpMailer, FakeMailer, MailerLogger и так далее

все так

I, Interface, Abstract в названии - признак того, что чувак не подумал при написании хорошо

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

класс можно делать номинальным через модификаторы доступа)

к - костыли

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

но это наверно после джавы

Оно подразумевает ровно то же, что и в джаве

только структурное

Оно подразумевает ровно то же, что и в джаве

но там то поля константы

а тут это просто сахар для чекинга

Чет ничего не понял

Там есть отличия, но суть одна и та же

это субъективно просто, в голове есть некий диссонанс когда задумываешься о реализации интерфейса в свойствах, а не в методах

ну точнее не только в методах

ну так-то в жаве это такой же сахар для чекинга

I, Interface, Abstract в названии - признак того, что чувак не подумал при написании хорошо

смотрел код от майкрософт и в их ts линтер конфиге рекомендуют использовать I в начале

смотрел код от майкрософт и в их ts линтер конфиге рекомендуют использовать I в начале

Пусть рекомендуют, я не рекомендую :)

В symfony тоже советуют писать Interface, Abstract

Но там нет ответа на вопрос "зачем?"

мы кстати используем I для всяких IPropsState, IPropsDispatch, IProps - в рамках файла с компонентом быстро глаза цепляются

в остальных случаях по названию сущности

мы кстати используем I для всяких IPropsState, IPropsDispatch, IProps - в рамках файла с компонентом быстро глаза цепляются

+

ERROR: S client not available

вообще от тайпскрипта ощущения двоякие, особенно после того как тебе в рантайме выпадает moment is not a function и ты потом обнаруживаешь тысячу способов подключить момент в тс, при этом каждый пишет свой

это вы allowSynteticDefault сделали?

ну т.е. вы компилятору сказали "пацан, я это сам похендлю" и не похендлили)

да нет, не сказали

Такие же мысли постоянно

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

Ну вот это описане структуры данных по сути

Наверное поэтому хочется отделить

Ну вот это описане структуры данных по сути

не, это описание объекта, методы там все дела

а что должна возвращать async функция которая возвращает массив строк?

промис

Promise<string[]>

да

да, так заработало

Но почему так

async возвращает промис, по стандарту

Потому что асинк должна возвращать промис

потому что async-функция не может сразу вернуть значение по определению

соответственно, возвращает промис

Я понял, спасибо)

а тут как обойти?

а все

вижу

const axiosMock = new (jest.fn<AxiosMock>());

ну и конструкция

нормальная

const axiosMock = new (jest.fn<AxiosMock>());

const axiosMock: AxiosMock = new jest.fn() Или что там возвращается

не, там сложнее

function fn<T>(implementation?: Function): Mock<T>; … interface Mock<T> extends Function, MockInstance<T> { new (): T; (...args: any[]): any; }