Использование возможностей Angular. Часть 2

Utility Types или почему я не люблю enum

Добрый день всем читателям и писателям. Меня опять зовут Юрик и я опять сочиняю про Angular. В этой части разговора будет больше про TS, но расскажу зачем вообще использовать utility types.

Итак, на собеседованиях часто спрашивают про utility types, коронный добивающий вопрос по ним связан с infer. О нем расскажу в конце статьи. Только вот интервьюеры в ответ что-то не хотят рассказывать, а как собственно они применяют эти самые utility types, какие задачи или проблемы решают.

Сначала посмотрим, а что нам говорит по этому поводу документация.

Из документации следует, что в TS существую типы, которые проводят модификации других типов. Рассмотрим простой Pick<Type, Keys>

interface Todo {   title: string;   description: string;   completed: boolean; }   type TodoPreview = Pick<Todo, "title" | "completed">;   const todo: TodoPreview = {   title: "Clean room",   completed: false, };

Кто-то сразу догадался, но уверен большинство новичков не сразу или не догадались. Наш Pick<Type, Keys> забирает Keys из типа (интерфейса) Type, результатом которого будет новый тип. При этом, эти типы будут связаны. Изменение интерфейса Todo необратимо изменит константу todo еще до рантайма. Ошибка в определении типов вызовет ошибку сборки бандла. И если в enum изменение запросто может пройти сборку и ошибка в рантайме вызовет красную консоль, то тут нет. В принципе, нет ничего плохого в использовании enum и дальше, но utility types намного технологичнее что-ли. Тем более, что использовать enum надо тоже с умом. Кто может объяснить разницу использования?

export enum Todo {   //someting }  export const enum Todo2 {   //something }

С Pick<Type, Keys> понятно. В документации представлены еще куча подобных types. Но эти utility types не являются частью языка, как enum, например. Они написаны на TS. Давайте разберем как это работает на примере нашего Pick<Type, Keys> В коде это выглядит следующим образом:

/**  * From T, pick a set of properties whose keys are in the union K  */ type Pick<T, K extends keyof T> = {     [P in K]: T[P]; };

Вот тут вот уже намного больше людей скажут:

Вот тут вот уже все написано именно на TS. И таких типов мы можем написать самостоятельно сколько угодно ровно под наши задачи. Например, трансформация JSON camelCase в kebab-case CSS. Дочитайте до конца и это там будет. А как работает, спросите вы? Да очень просто, отвечу я. Разберем с самого начала что, откуда и как интерпретируется интерпретатором и как это потом используется в JS.

type Pick<T, K extends keyof T> = {     [P in K]: T[P]; };

1. Определяется тип Pick с двумя дженериками <T, K>

2. С типом T все понятно — это или тип или интерфейс, в вот с K extends keyof T посмотрим внимательнее. К соответствует ключам T, вот как это будет объяснено, т.е. keyof T имеет тип string и K должен быть строкой и соответствовать ключам типа T. Если мы в K поместим строку не соответствующую ключам T — будет ошибка компиляции. А мы еще до создания самого типа не дошли.

3. Создаем тип. Выражение [P in K]: определяет keys объекта, который будет создан по типу. Поэтому определяется еще один дженерик P и он хранит тип ключа. Получаем что-то вроде typeof P === 'key name' , а т.к. P in K , то оператор in обходит циклом все значения K. Итак, мы получаем тип с ключами, представленными в К, и которые являются ключами T

4. Каждому ключу назначаем его value. Выражение T[P]; прямо нам и говорит, берем value из объекта T по ключу P

Тут я намеренно писал «из объекта» потому что типы не являются объектами, но по ним строится объект. Именно объект проверяется на соответствие типу и именно объект потом уходит в JS. Как мы знаем вся писанина по типам TS останется за бортом конечного бандла JS.

Штош, как он работает мы определились. А как насчет того как его применять? Поехали дальше.

Конкретно Pick<Type, Keys> можно применять для определения strict partial model, т.е. нам нужна конкретная часть определенной модели данных например. Если не строгая модель, то мы имеем тип Patrial<T>

Где еще? Давайте сделаем обещанный camelCase to kebab-case. Для чего он нужен? Когда-то делал очень продвинутый  WYSIWYG-редактор и маппер перевода данных из JSON в SafeStyle был типизирован и обходил ровно то, что относилось к типу, а не то, что прилетело.

Что сначала? Сначала типизируем модель JSON.

type TextStylePropertyType =   | 'fontWeight'   | 'color'   | 'fontFamily'   | 'fontSize'   | 'textDecoration'   | 'letterSpacing'   | 'lineHeight'   | 'textAlign'   | 'fontStyle'   | 'borderRadius';  export type UnionTypeToValue<T extends string> = {   [K in T]: any; };  const textStyle: UnionTypeToValue<TextStylePropertyType> = {   fontWeight: 'none',   color: '#ffffff',   fontFamily: 'Muli',   fontSize: 16,   textDecoration: 'none',   letterSpacing: 'normal',   lineHeight: 'normal',   textAlign: 'left',   fontStyle: 'none',   borderRadius: 0, }; 

Тут все понятно? Имеем union type TextStylePropertyType, на основании которого создаем объект стилизации текста с дефолтными значениями. Теперь делаем тип для kebab.

type ToKebab<T extends string, R extends string = ''>  = T extends `${infer First}${infer Rest}`   ? Uppercase<First> extends First     ? ToKebab<Rest, `${R}-${Lowercase<First>}`>     : ToKebab<Rest, `${R}${First}`>   : R;

и вот тут вылазит наш infer на сцену и начинает мутить воду. Что нам говорит документация. Документация нам говорит, что infer — это type inference, т.е. вывод типа. Мы можем проверить соответствие типа и задать логику. В типах. Логику.??? Выглядит пугающе и запутанно, но оно работает. На тип ToKebab имеет первый дженерик как строку. Далее идет магия. T extends ${infer First}${infer Rest} определяет, что Т соответствует строке где First и Rest — это внутренние дженерики и мы указывает логику if else, указывая что мы будем делать в зависимости от typeof First или typeof Rest. First и Rest мы получили через infer, где First указывает на первый символ строки, Rest — второй. Рекурсивный вызов ToKebab перебирает всю строку модифицируя выходной результат. Итак, как это происходит. Строка 2 и 6. Проверяется на соответствие строки T паттерну ${infer First}${infer Rest} . Строка не должна быть пустой. Если не так — оставляем строку R (она в рекурсии). Если соответствие есть — проверяем первый символ First на uppercase. Если так, определяем тип ToKebab (рекурсивно) и переводим символ в lowercase и ставим перед ним шампур «-«, если нет — оставляем без изменений. Тут важно, что R — в зависимости от уровня вложенности имеет значение отличное от пустой строки.

Трудно понять сначала, согласен. Но ребята из https://github.com/type-challenges/type-challenges решают и не такие задачки, попробуйте и вы. ))

Близится конец статьи, но не близится конец Types. Перевод в кебаб мы сделали, что теперь? Теперь есть проблема с kebab-case, который используется в CSS. Дело в том, что поле fontSize в объекте textStyle имеет тип number. В CSS это не допустимо. Выхода 2. Или добавлять к таким ключам «.px» или преобразовывать number в string и добавлять «px». Мы пойдем первым путем. Определим union type как ключи, которые надо преобразовывать и напишем еще два utility type

type ToStyleKebab<T extends string, S extends string> = T extends S   ? `${ToKebab<T>}.px`   : ToKebab<T>;  export type UnionTypeToStyleKebab<T extends string, S extends string> = {   [K in T]: ToStyleKebab<T, S>; };

ToStyleKebab — это вспомогательный тип для UnionTypeToStyleKebab Тогда выходной объект будет иметь вид

type TextPixelProperty =   | 'fontSize'   | 'letterSpacing'   | 'lineHeight'   | 'borderRadius';  const textProperty: UnionTypeToStyleKebab<TextStylePropertyType, TextPixelProperty> = {   fontWeight: 'font-weight',   fontStyle: 'font-style',   color: 'color',   textDecoration: 'text-decoration',   fontFamily: 'font-family',   textAlign: 'text-align',   fontSize: 'font-size.px',   letterSpacing: 'letter-spacing.px',   lineHeight: 'line-height.px',   borderRadius: 'border-radius.px', };

Заметьте, любое изменение типа или объекта сразу выдает ошибку компиляции. т.е. определив типы мы (или кто другой) не сможет изменить объекты, где очень часто можно получить console.error и это критично. Как теперь перемаппить объект JSON в CSS? тут все просто.

const style = Object.keys(textStyle).reduce((acc, key) => {   acc[textProperty[key]] = textStyle[key];    return acc; }, {});  

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

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

На этом пока закончу.