от этих типов больше проблем, чем пользы

От тайпскрипта да

И от углового тоже

¯\_(ツ)_/¯

от этих типов больше проблем, чем пользы

noImplicitAny: false и не ставь нигде типы

Конструктор покажи

+

noImplicitAny: false и не ставь нигде типы

плохой совет)

ну так если у человека от типов проблемы)

Я бы не юзал ангулар 5+

Без типов тем более

Ребят, кто как ts node дебажит ? Говорят есть для этого расширение в вс коде, может есть более удобные решения ?

Сорсмапы

Так там же хромовский дебаг протокол

И в каком смысле более удобные? Там точки останова есть, просмотр значений есть, чего надо-то ещё? Проблема в чём именно?

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

Ну в вскоде он такой же

Так там же хромовский дебаг протокол

не знал

Благодарю

Ну как, это ж нода предоставляет инфраструктуру для отладки, а редактор уже можно любой прикрутить

Так там же хромовский дебаг протокол

Ну там любой дебаг, ts-node норм сорсмапы подключает. Только на 10ой ноде вроде еще не релизнули с новыми сорсмапами

Ну там любой дебаг, ts-node норм сорсмапы подключает. Только на 10ой ноде вроде еще не релизнули с новыми сорсмапами

Омг, я только сейчас понял что речь про какой-то отдельный нацуцульник

И я никак понять не могу зачем он >.<

И я никак понять не могу зачем он >.<

Чтобы самому не подключать сорсмап-саппорт. И вообще не транспайлить в деве например

Чтобы самому не подключать сорсмап-саппорт. И вообще не транспайлить в деве например

Всё равно ничего не понял. Сорсмап парсит иде, генерирует tsc, при чём тут тулза эта? Не транспайлить - это как? Нода не может бежать тс напрямую же, нет?

Всё равно ничего не понял. Сорсмап парсит иде, генерирует tsc, при чём тут тулза эта? Не транспайлить - это как? Нода не может бежать тс напрямую же, нет?

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

Всё равно ничего не понял. Сорсмап парсит иде, генерирует tsc, при чём тут тулза эта? Не транспайлить - это как? Нода не может бежать тс напрямую же, нет?

Не транспайлить заранее, а сразу в рантайме

tsc —watch?

Более-менее понял, спасибо.

Здравствуйте, такой вопрос, в названии интерфейсов в TypeScript бывают вроде ElementSet, а в C# я видел вроде IElementSet. Подскажите пожалуйста практикуются ли такие названия в TypeScript?

практикуют, но не все

хз зачем

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

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

Как в проекте принято — так и пиши. Ваще в жиесе редко интерфейсы помечают I, афаик.

да, такие решения принимаются на уровне проекта

Хорошо, спасибо большое!)

Здравствуйте, такой вопрос, в названии интерфейсов в TypeScript бывают вроде ElementSet, а в C# я видел вроде IElementSet. Подскажите пожалуйста практикуются ли такие названия в TypeScript?

Ангулар-тим наоборот категорически против префиксов

Имхо все эти префиксы растут с тех времён, когда редакторы были тупыми

Имхо все эти префиксы растут с тех времён, когда редакторы были тупыми

Да-да, и не показывали тип по ховеру.

Сейчас я скорее против

Сейчас вообще не понимаю, да.

Префикс — лишняя сущность по сути.

А если у вас есть interface IEmailSender с методом Send и вы создаете класс EmailSender реализовав метод Send интерфейса IEmailSender

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

interface EmailSender {} class EmailSender implements EmailSender {}

гуд стори не юзать префикс i для интерфейсов

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

Не надо интерфейс так называть

Это прям самое ужасное что можно сделать имхо

interface EmailSender {} class RealEmailSender implements EmailSender {} class FakeEmailSender implements EmailSender {}

ох щи ))

сравните interface CanSendMail {} interface ICanSendMail {} очевидно второй круче

сравните interface CanSendMail {} interface ICanSendMail {} очевидно второй круче

Да надо дальше пойти

т.е. использование в классах префикса Real лучше, чем использовать префикс i для интерфейсов ?)))))

intertface EmailSenderInterface {} abstract class EmailSenderAbstract implements EmailSenderInterface {} class RealSenderImplementation extends EmailSenderAbstract {}

т.е. использование в классах префикса Real лучше, чем использовать префикс i для интерфейсов ?)))))

Тем, что реализаций может быть несколько, и они отличаются, в названии класса это видно

intertface EmailSenderInterface {} abstract class EmailSenderAbstract implements EmailSenderInterface {} class RealSenderImplementation extends EmailSenderAbstract {}

О господи

Опять таки, Real это как пример, там может быть например SystemEmailSender, который использует системный вызов какой-нить

Тем, что реализаций может быть несколько, и они отличаются, в названии класса это видно

тогда ок, пожалуй соглашусь.

interface FakeEmailSenderInterface {}

А если у вас есть interface IEmailSender с методом Send и вы создаете класс EmailSender реализовав метод Send интерфейса IEmailSender

Тогда я спрошу себя зачем мне интерфейс, когда а меня только 1 класс

ERROR: S client not available

Сейчас религиозная война начнется))

Тогда я спрошу себя зачем мне интерфейс, когда а меня только 1 класс

Хороший вопрос, да

ну или получше взять пример есть logger - interface и от него уже всякие fileLogger, dbLogger, memoryLogger, etc..

ну или получше взять пример есть logger - interface и от него уже всякие fileLogger, dbLogger, memoryLogger, etc..

Ну вот да

ChainLogger

Тогда я спрошу себя зачем мне интерфейс, когда а меня только 1 класс

just for fun

or just for test + mock\stub

хотя в жс и моки не нужны

interface Sender<T> {}

class EmailSender implements Sender<Email> {}

as any и ок

Для тестов полную имплементацию накладно делать обычно

1 метод замокаешь и ок

А если у вас есть interface IEmailSender с методом Send и вы создаете класс EmailSender реализовав метод Send интерфейса IEmailSender

Зачем так делать?)

тоже хороший вопрос

жс и тс это ж не ооп

жс и тс это ж не ооп

смелое заявление

юзаешь прототипы и ты ок посан ?

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

опять же повторюсь, смысл одной реализации в том, что можно прикрутить ioc/di и потом легко писать тестируемый код

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

И в случае без классов тоже ок

опять же повторюсь, смысл одной реализации в том, что можно прикрутить ioc/di и потом легко писать тестируемый код

class FakeClass inplements RealClass {} всё ещё можно же?

интересно как это вы собрались имплементировать класс ))))

class FakeClass inplements RealClass {} всё ещё можно же?

Создать мок в js вообще проблем быть не может

ну а если я допустим заядлый бекендщик на шарпе

интересно как это вы собрались имплементировать класс ))))

Его интерфейс.

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

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

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

Это обман