Typescript два восклицательных знака

TypeScript. Магия выражений

TypeScript — поистине прекрасный язык. В его арсенале есть все, что необходимо для качественной разработки. И если вдруг, кому-то знакомы секс-драматические этюды с JavaScript, то меня поймет. TypeScript имеет ряд допущений, неожиданный синтаксис, восхитительные конструкции, которые подчеркивают его красоту, форму и наполняют новым смыслом. Сегодня речь о них, об этих допущениях, о магии выражений. Кому интересно, добро пожаловать.

Немного правды

Большинство конструкций и неожиданных находок, изложенных ниже, мне впервые попались на глаза на страницах Stack Overflow, github или вовсе были изобретены самостоятельно. И только потом дошло — это все есть здесь или здесь. Поэтому заранее прошу отнестись с пониманием, если изложенные находки Вам покажутся банальными.

Практическая ценность некоторых конструкций равна 0.

Примеры проверялись под tsc версии 3.4.5 и целевой es5. На всякий случай под спойлером конфиг

<
«compilerOptions»: <
«outFile»: «./target/result.js»,
«module»: «amd»,
«target»: «es5»,
«declaration»: true,
«noImplicitAny»: true,
«noImplicitReturns»: true,
«strictNullChecks»: true,
«strictPropertyInitialization»: true,
«experimentalDecorators»: true,
«emitDecoratorMetadata»: true,
«preserveConstEnums»: true,
«noResolve»: true,
«sourceMap»: true,
«inlineSources»: true
>,
«include»: [
«./src»
]
>

Реализация и наследование

Находка: в секции implements можно указывать интерфейсы, типы и классы. Нас интересуют последние. Подробности здесь

 abstract class ClassA < abstract getA(): string; >abstract class ClassB < abstract getB(): string; >// Да, tsc нормально на это реагирует abstract class ClassC implements ClassA, ClassB < // ^ обратите внимание, на использование implements с классами. abstract getA(): string; abstract getB(): string; >

Думаю разработчики TypeScript позаботились о ‘строгих контрактах’, исполненных через ключевое слово class. Причем классы необязательно должны быть абстрактными.

Находка: в секции extends допускаются выражения. Подробности. Если задаться вопросом — можно ли унаследоваться от 2х классов, то формальный ответ — нет. Но если имеется в виду экспорт функциональности — да.

class One < one = "__one__"; getOne(): string < return "one"; >> class Two < two = "__two__"; getTwo(): string < return "two"; >> // Теже миксины, но в удобном виде: Подсказки в IDE (кроме статических полей) и автокомплит как положено. class BothTogether extends mix(One, Two) < // ^ находка в том, что в части extends допускаются выражения info(): string < return "BothTogether: " + this.getOne() + " and " + this.getTwo() + ", one: " + this.one + ", two: " + this.two; // ^ подсказки от IDE здесь и ^ имеется >> type FaceType = < [K in keyof T]: T[K]; >; type Constructor = < // prototype: T & ; new(): T; >; // TODO: эта реализация на коленке, можно не глядеть. Классная реализация есть на просторах интернета function mix(o: Constructor, t: Constructor): FaceType & Constructor  < function MixinClass(. args: any) < o.apply(this, args); t.apply(this, args); >const ignoreNamesFilter = (name: string) => ["constructor"].indexOf(name) === -1; [o, t].forEach(baseCtor => < Object.getOwnPropertyNames(baseCtor.prototype).filter(ignoreNamesFilter).forEach(name =>< MixinClass.prototype[name] = baseCtor.prototype[name]; >); >); return MixinClass as any; > const bt = new BothTogether(); window.console.log(bt.info()); // >> BothTogether: one and two, one: __one__, two: __two__ 

Находка: глубокий и в тоже время бессмысленный аноним.

const Сlass = class extends class extends class extends class extends class <> <> <> <> <>; 

А кто больше напишет слово класс с 4 extends в примере выше?

// tslint:disable const Class extends class Class extends class Class extends class Class extends class Class <> <> <> <> <>; 

// tslint:disable const сlass = class Class extends class Class extends class Class extends class Class extends class Class <> <> <> <> <>; 

Ну Вы поняли — просто класс!

Восклицательный знак — безграничный оператор и модификатор

Если Вы не используете настройки компиляции strictNullChecks и strictPropertyInitialization,
то скорее всего знания о восклицательном знаке прошли рядом с Вами… Помимо основного предназначения, для него отведены еще 2 роли.

Находка: Восклицательный знак в роли Non-null assertion operator

Этот оператор позволяет обращаться к полю структуры, которое может быть null без проверки на null. Пример с пояснением:

 // Для проверки включаем режим --strictNullChecks type OptType = < maybe?: < data: string; >; >; // . function process(optType: OptType) < completeOptFields(optType); // Мы знаем наверняка, что метод completeOptFields заполнит все необязательные поля. window.console.log(optType.maybe!.data); // ^ - берем на себя ответственность, что здесь не null // если уберем !, то получим от tsc: Object is possibly 'undefined' >function completeOptFields(optType: OptType) < if (!optType.maybe) < optType.maybe = < data: "some default info" >; > > 

Итого, этот оператор позволяет убрать лишние проверки на null в коде, если мы уверены…

Этот модификатор позволит нам проинициализировать свойство класса потом, где-то в коде, при включенной опции компиляции strictPropertyInitialization. Пример с пояснением:

// Для проверки включаем режим --strictPropertyInitialization class Field < foo!: number; // ^ // Notice this '!' modifier. // This is the "definite assignment assertion" constructor() < this.initialize(); >initialize() < this.foo = 0; // ^ инициализация здесь >> 

Но вся эта мини выкладка про восклицательный знак не имела бы смысла без минутки юмора.

Вопрос: Как вы думаете, скомпилируется ли следующее выражение?

// Для проверки включаем режим --strictNullChecks type OptType = < maybe?: < data: string; >; >; function process(optType: OptType) < if (. optType.maybe. ) < window.console.log("Just for fun"); >window.console.log(optType.maybe. data); > 

Типы

Каждый, кто пишет сложные типы открывает для себя много интересного. Вот и мне повезло.

Находка: на подтип можно ссылаться по имени поля основного типа.

type Person = < id: string; name: string; address: < city: string; street: string; house: string; >>; type Address = Person["address"]; 

Когда Вы пишите типы сами, такой подход объявления навряд ли имеет смысл. Но бывает так, что тип приходит из внешней библиотеки, а подтип — нет.

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

class BaseDialog  < show(params: In): Out > // Декларация по-старинке class PersonDialogOld extends BaseDialog  // Повышаем читаемость class PersonDialog extends BaseDialog  

Находка: с помощью системы типов TypeScript возможно добиться комбинаторного набора порожденных типов с покрытием нужной функциональности. Сложно сказано, знаю. Долго думал над этой формулировкой. Покажу на примере шаблона Builder, как одного из самых известных. Представьте, что Вам нужно построить некий объект используя этот шаблон проектирования.

class SimpleBuilder < private constructor() <>static create(): SimpleBuilder < return new SimpleBuilder(); >firstName(firstName: string): this < return this; >lastName(lastName: string): this < return this; >middleName(midleName: string): this < return this; >build(): string < return "what you needs"; >> const builder = SimpleBuilder.create(); // Так мы получаем требуемый объект. const result = builder.firstName("F").lastName("L").middleName("M").build(); 

Пока не смотрите на избыточный метод create, приватный конструктор и вообще на использование этого шаблона в ts. Сосредоточиться нужно на цепочке вызовов. Идея в том, что вызываемые методы должны быть использованы строго 1 раз. Причем Ваша IDE также должна знать об этом. Другими словами после вызова любого метода у экземпляра builder этот метод должен исключаться из списка доступных. Достичь такой функциональности нам поможет тип NarrowCallside.

type ExcludeMethod = Pick>; type NarrowCallside = < [P in keyof T]: T[P] extends (. args: any) =>T ? ReturnType extends T ? (. args: Parameters) => NarrowCallside> : T[P] : T[P]; >; class SimpleBuilder < private constructor() <>static create(): NarrowCallside  < return new SimpleBuilder(); >firstName(firstName: string): this < return this; >lastName(lastName: string): this < return this; >middleName(midleName: string): this < return this; >build(): string < return "what you needs"; >> const builder = SimpleBuilder.create(); const result = builder.firstName("F") // ^ - доступны все методы .lastName("L") // ^ - здесь доступны lastName, middleName и build .middleName("M") // ^ - здесь доступны middleName и build .build(); // ^ - здесь доступен только build 

Находка: с помощью системы типов TypeScript можно управлять последовательностью вызовов, указывая строгий порядок. В примере ниже с помощью типа DirectCallside продемонстрируем это.

type FilterKeys = ( <[P in keyof T]: T[P] extends (. args: any) =>any ? ReturnType extends never ? never : P : never >)Typescript два восклицательных знака; type FilterMethods = Pick; type BaseDirectCallside = FilterMethods T) ? ((. _: Direct) => any) extends ((_: infer First, . _1: infer Next) => any) ? First extends Key ? (. args: Parameters) => BaseDirectCallside : never : never : TTypescript два восклицательных знака >>; type DirectCallside> = BaseDirectCallside; class StrongBuilder < private constructor() <>static create(): DirectCallside  < return new StrongBuilder() as any; >firstName(firstName: string): this < return this; >lastName(lastName: string): this < return this; >middleName(midleName: string): this < return this; >build(): string < return "what you needs"; >> const sBuilder = StrongBuilder.create(); const sResult = sBuilder.firstName("F") // ^ - доступны только firstName и build .lastName("L") // ^ - доступны только lastName и build .middleName("M") // ^ - доступны только middleName и build .build(); // ^ - доступен только build 

Итого

Это все мои интересные находки по TypeScript на сегодня. Всем спасибо за внимание и до новых встреч.

Источник

TypeScript | Double Question Marks (??) – What it Means

The double question marks (??) are also called nullish coalescing operators and they allow to use of a default value set on the right side of the operator in case the initial value from the left side of the operator is null or undefined . To make things simpler, let’s look at an example.

let random; const color = random ?? 'red';

In our previous example, we have two variables: random and color . The random variable is undefined. Therefore, at the moment of declaring and assigning the value to the color variable, it will default to “red”.

Difference Between Logical OR (||) and Nullish Coalescing Operator (??)

If you have been working with JavaScript or TypeScript for a while, chances are you been assigning values to variables using the logical OR (||) operator. If we take our previous example and change operator to use the logical operator, it will look like the following:

let random; const color = random || 'red';

In this case, the value of color variable would be “red”.

You might be wondering: What is the difference between the logical OR operator and the nullish coalescing operator?

The logical OR operator will use the default value if the initial expression is considered falsy. A value is considered falsy because when attempted to convert the value into a boolean, the result will be false . Some of the common falsy values in JavaScript are:

If you are looking to check the complete list of falsy values, I recommend checking this falsy article.

If you attempt to convert all of these values to a boolean, you will always get a false .

console.log(Boolean(false)); // it will log: false console.log(Boolean(0)); // it will log: false console.log(Boolean(null)); // it will log: false console.log(Boolean(undefined)); // it will log: false

This is slightly different from the nullish coalescing operator as the later will use the default value whenever the initial expression is null or undefined . The following example should provide more clarity between the differences of the two operators:

// examples using the logical OR operator console.log(0 || 'default'); // it will log: default console.log(5 || 'default'); // it will log: 5 console.log(-0 || 'default'); // it will log: default console.log(-3 || 'default'); // it will log: -3 console.log(false || 'default'); // it will log: default console.log(true || 'default'); // it will log: true console.log(null || 'default'); // it will log: default console.log(undefined || 'default'); // it will log: default // examples using the nullish coalescing operator console.log(0 ?? 'default'); // it will log: 0 console.log(5 ?? 'default'); // it will log: 5 console.log(-0 ?? 'default'); // it will log: -0 console.log(-3 ?? 'default'); // it will log: -3 console.log(false ?? 'default'); // it will log: false console.log(true ?? 'default'); // it will log: true console.log(null ?? 'default'); // it will log: default console.log(undefined ?? 'default'); // it will log: default

The nullish coalescing operator came up as a solution for many JavaScript and TypeScript developers to prevent unwanted behavior when using the logical OR and not having a clear understanding of all the falsy values in JavaScript.

Not Created By TypeScript

TypeScript didn’t always support the nullish coalescing operator. In fact, this operator was introduced in TypeScript in version 3.7. Remenber, TypeScript compiles code into JavaScript. However, this operator was not always in JavaScript. JavaScript constantly evolves and it is defined by a set of standards defined by ECMA.

You might have heard of ECMAScript. ECMAScript is a general-purpopse scripting language that defines the standards for languages such as JavaScript. This was done with the purpose to support interoperability of web pages across different web browsers. JavaScript is an implementation of those ECMA standards.

TC39 is the technical committee of the ECMA in charge of maintaining and evolving the definition of JavaScript. TC39 proposes new implementations to the language. Only until December of 2019, the implementation of a nullish coalescing operator was proposed and published the following year. Check the list of TC39 proposals if you are interested in checking what future JavaScript features will be.

More TypeScript Tips!

There is a list of TypeScript tips you might be interested in checking out

Did you like this TypeScript tip?

Andrés Reales is the founder of Become a Better Programmer blogs and tutorials and Senior Full-Stack Software Engineer. With the purpose of helping others succeed in the always-evolving world of programming, Andrés gives back to the community by sharing his experiences and teaching his programming skillset gained over his years as a professional programmer.

Источник