там Error всегда any?

там он всегда Error. А нет. действительно any

там Error всегда any?

её нужно писать в константу с утверждением типа: const err = error as Error;

НО!

у меня в catch есть функция которая принимает handleErrors(error: Error)

и всё ок)

у меня в catch есть функция которая принимает handleErrors(error: Error)

у тебя типа декларирован явно

типа он неявно кастует any в Error?

типа он неявно кастует any в Error?

я не до конца понимаю, как as работает, но похоже, что да

Кстати, как относитесь к синтаксису в некоторых новых языках (Swift, Kotlin) инстанциировать классы без new, просто вызывая Pascal-case конструктор? Пользуетесь ли этим в ts, cоздаёте фабрики, чтобы не писать new? Ещё в старых книгах по js были такие кейсы

Кстати, как относитесь к синтаксису в некоторых новых языках (Swift, Kotlin) инстанциировать классы без new, просто вызывая Pascal-case конструктор? Пользуетесь ли этим в ts, cоздаёте фабрики, чтобы не писать new? Ещё в старых книгах по js были такие кейсы

А в свифте и котлине для такого сахара фабрики создаются?

А в свифте и котлине для такого сахара фабрики создаются?

нет

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

так-то можно фабрику фабрик создать и в одну строчку создавать их

в некоторых ML new юзают как дополнительный индикатор создания инстансов неуправляемых ресурсов (IDisposable). в тс такого нет, поэтому пишу new, когда нет прямой необходимости в фабриках ?

Чат, как отрефакторить данный код? export class A { constructor( public id: string, public number: string, public concludedOn: Date, ){} } export class B { constructor( public id: string, public number: string, public concludedOn: Date, public sum: number, ){} }Полагаю, что это можно отрефакторить через B extends A, но не раскопал, как это будет по синтаксису в данном случае.

бля

именно так

class B extends A {}

пздц

я подозреваю что вопрос в дублировании аттрибутов конструктора

я подозреваю что вопрос в дублировании аттрибутов конструктора

Именно

вроде никак

Жаль

а зачем писать в конструкторе public: ?

Кстати, как относитесь к синтаксису в некоторых новых языках (Swift, Kotlin) инстанциировать классы без new, просто вызывая Pascal-case конструктор? Пользуетесь ли этим в ts, cоздаёте фабрики, чтобы не писать new? Ещё в старых книгах по js были такие кейсы

@ZeroBias

type ConstA = (public id: string, public number: string, public concludedOn: Date, ): void написать можно

типа сразу в переменныек инстанса?

но от наследоваться никак

а зачем писать в конструкторе public: ?

двачую вопрос

а через super перетечет кстати поведение такое?

а зачем писать в конструкторе public: ?

это же this.param = param;

о, не знал что как в кофе работает

Чат, как отрефакторить данный код? export class A { constructor( public id: string, public number: string, public concludedOn: Date, ){} } export class B { constructor( public id: string, public number: string, public concludedOn: Date, public sum: number, ){} }Полагаю, что это можно отрефакторить через B extends A, но не раскопал, как это будет по синтаксису в данном случае.

а какие проблемы? Обычное наследование замути

а зачем писать в конструкторе public: ?

Чтобы было доступно не только внутри этого класса. Либо я не совсем верно понял принцип доступа к свойствам класса...

sum инициализируй в derived конструкторе

это же this.param = param;

ааа ну так и подумал с плюсов стырено

Чтобы было доступно не только внутри этого класса. Либо я не совсем верно понял принцип доступа к свойствам класса...

когда ты пишешь, как в примере, ты используешь сахар конструктора

вы ребята сильно превередливые, если это сахар

вы ребята сильно превередливые, если это сахар

в спецификации указано, что сахар. К других языках это сахар

только в плюсах было class Name { Name(int foo, bool bar): m_bBar(foo), m_IFoo(bar) {} }

Уточню. Я юзаю классы с конструктором вместо интерфейсов(из-за херового принципа именования интерфейсов).

Потому и public

Уточню. Я юзаю классы с конструктором вместо интерфейсов(из-за херового принципа именования интерфейсов).

какого ещё принципа именования?

какого ещё принципа именования?

видимо IName

ты используешь классы вместо интерфейсов, потому что не знаешь ооп

какого ещё принципа именования?

export interface ISomeinrefaceName

export interface ISomeinrefaceName

в исходниках TS это именование не применяется

ты используешь классы вместо интерфейсов, потому что не знаешь ооп

Дико плюсую!!!

ты используешь классы вместо интерфейсов, потому что не знаешь ооп

Блять.

Есть соглашения

в исходниках TS это именование не применяется

Тоже не юзаю такое именование Кстати интерфейсы выношу в файлы module-name.h.ts получается довольно мило import { ModuleRestrictor } from '../module-name.h'

Есть соглашения

соглашения в C# отражены в языке

У меня не C#

Есть соглашения

покажи мне документ этих соглашений или конвенций

У меня не C#

В исходникакх C# отражены соглашения, значит пишем IInterface, в TS нет этого. Но от себя добавлю что не воспринимаю интерфейсы без I

https://github.com/basarat/typescript-book/blob/master/docs/styleguide/styleguide.md#interface https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Interfaces.md

И считаю это лучшей практикой

это просто привычка, не более того, лет 7 писал на шарпе с .net 1.0, не юзаю в ts префиксы для интерфейсов

А какой-то чувак предлагал половину js не использовать

https://github.com/basarat/typescript-book/blob/master/docs/styleguide/styleguide.md#interface https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Interfaces.md

ООооо, спасибо буду теперь линку кидать

А какой-то чувак предлагал половину js не использовать

всмысле, где?

покажи мне документ этих соглашений или конвенций

https://angular.io/guide/styleguide#!#-a-id-03-03-a-interfaces

всмысле, где?

я про соглашения. Есть соглашения, которые полезны, есть, которые радикальны. В любом случае, если посмотреть исходники серьёзных библиотек, там видно, что это не догмы

А чем не нравится I в интрефейсах писать?

https://angular.io/guide/styleguide#!#-a-id-03-03-a-interfaces

>Consider naming an interface without an I prefix.

эм

ERROR: S client not available

ну вот да)

да на шарп становится похож

https://i.gyazo.com/2e20d4cadcfcc39ef0b4a654094030ca.png

эм

Why? TypeScript guidelines discourage the I prefix.

в пин!

Why? TypeScript guidelines discourage the I prefix.

ну

https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines

в пин!

может он про Consider using a class instead of an interface

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

я тоже юзаю I для интерфейсов и префикс _ для приватных полей

я тоже юзаю I для интерфейсов и префикс _ для приватных полей

_ просто обязателен для автогенерации аксессоров

я тоже юзаю I для интерфейсов и префикс _ для приватных полей

ну ты извращенец

в ts и так есть private

нахрена ещё этот недосахар

нахрена ещё этот недосахар

причём здесь private?

ну

В общем, в Angular Team вместо интерфейсов рекомендуют юзать Классы с конструкторами, чтобы не идти вразрез с Typescript styleguides. Пруф сейчас не дам(копать долго). Это упоминалось в гитхабе.

ты просто на другой пост отвечал

В общем, в Angular Team вместо интерфейсов рекомендуют юзать Классы с конструкторами, чтобы не идти вразрез с Typescript styleguides. Пруф сейчас не дам(копать долго). Это упоминалось в гитхабе.

классы предлагают юзать не из-за typescript guidelines, а из-за DI

ты просто на другой пост отвечал

нет я всё правильно ответил

нет я всё правильно ответил

поля типа $name $age тебе больше нравятся?

нет я всё правильно ответил

это он про то, что бы вебштор мог намутить автоматически геттеры и сеттеры на поле

у них будет одно и то же имя

и чтобы не было конфликта

называют их с _ префиксом

да, у backing field'ов имена с префиксом _

у методов естественно такой херни нет

это он про то, что бы вебштор мог намутить автоматически геттеры и сеттеры на поле

Бля. Вебшторм решает какие должны быть конвенции?

вы серьезно?

я в шоке, что кому-то это надо объяснять