​TypeScript. Дженерики

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

const foo = function(data: any): any {
return data;
}

С точки зрения TS функция валидная, однако компилятор не может определить, с каким типом данных он работает, поэтому возможны ошибки, которые он не сможет поймать:

foo(10).length;

Чтобы вернуть контроль, нам нужно точнее указать тип. Как минимум, показать, что на выходе будет то же самое, что и на входе - один и тот же тип. Для этого в TS есть дженерики (обобщения).

Дженерик - это способ обозначить тип, не называя его напрямую. Обычно для обозначения типа используют букву T (type), но можно взять и другие буквы.

#typescript #дженерики

Дженерики

То есть в угловых скобках мы указываем, что будем использовать какой-то тип T. Входной аргумент будет иметь этот тип T, и выходное значение тоже. Какой это конкретно тип, пока не известно, будет понятно уже при вызове функции.

Когда мы вызываем функцию с параметром 10, TypeScript берет тип этого параметра и считает, что T теперь равно этому типу. Теперь компилятор может определить, что у выходного значения нет свойства length, и выведет ошибку.

Или мы можем вручную указать тип при вызове функции (в угловых скобках перед списком параметров.

#typescript #дженерики

​TypeScript. Дженерики в классах

Дженерики можно использовать и в классах, нужные типы при этом указываются в угловых скобках сразу после имени класса. Типов может быть несколько, необязательно один.

При создании экземпляра конкретные типы (вместо заместителей) выведутся из входных параметров.

#typescript #дженерики

TypeScript. Декораторы

Паттерн Декоратор широко известен и активно применяется в программировании. Это способ добавить новую функциональность поверх существующей, не изменяя уже написанный код.

Грубо говоря, у нас есть некоторая функция, которая умеет что-то делать, например, складывает два числа:

function add(a, b) {
    return a + b;
}

Мы хотим добавить для нее логирование - фиксацию каждого вызова с указанием его параметров.
Пишем простейший декоратор для этого:

function logger(fn) {
    return function(...params) {
        console.log('Вызов функции', ...params); // регистрирует вызов
        return fn(...params); // вызывает основную функцию
    }
}

Теперь завернем функцию в декоратор и получим декорированную функцию, которая делает то же самое, что и наша основная функция add, но также имеет дополнительную функциональность - логирует свои вызовы.

const addWithLogs = logger(add);
addWithLogs(4, 5); // 9

В этот декоратор можно завернуть и любую другую функцию.

Получается, что у нас тут есть основная функция add, дополнительная функциональность (вызов console.log()) и обертка над всем этим, которая принимает функцию, а затем вызывает ее, не забывая передать параметры. По сути вот так:

function decorate(fn, decorator) {
    return function decoratedFn(...params) {
        decorator(...params);
        return fn(...params);
    }
}

function logger(...params) {
    console.log('Вызов функции', ...params);
}

function add(a, b) {
    return a + b;
}

const addWithLogs = decorate(add, logger);

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

Декораторы в TS - это экспериментальная функция, поэтому для поддержки нужно добавить в tsconfig.json опцию compilerOptions.experimentalDecorators.

#typescript #tsдекораторы

​TypeScript. Декораторы классов

Самый простой вид декораторов в TS - декораторы классов. Они позволяют добавить новую функциональность целому классу.

Хороший пример есть в документации TS: декоратор sealed, который запрещает расширять прототип класса.

Декоратор класса - это простая функция с единственным аргументом constructor - это собственно конструктор декорируемого класса. Через конструктор декоратор может повлиять на определение класса в целом:

function sealed(constructor: Function) {
    console.log('sealed decorator');
    Object.seal(constructor);
    Object.seal(constructor.prototype);
}

Это мы описали "дополнительную функциональность". Чтобы применить ее к любому классу, нужно сделать вот так:

@sealed
class User {
    constructor(public name: string) {}
    print(): void {
        console.log(this.name);
    }
}

Просто пишем @ плюс имя функции-декоратора над объявлением класса User.

Обертка класса в декоратор осуществляется под капотом, а сам класс User уже сразу имеет новую функциональность, добавленную декоратором. Например, мы не можем добавить в него новое свойство:

Object.defineProperty(User, 'age', {
    value: 17
});
// Cannot define property age, object is not extensible 

В скомпилированном виде это все выглядит весьма громоздко

#typescript #tsдекораторы

TypeScript. Декораторы методов класса

Декораторы методов выглядят уже немного сложнее, у них не один, а целых три параметра:

function methodDecorator(
    target: any,
    propertyName: string,
    descriptor: PropertyDescriptor
) {

}

- target - это прототип класса. Для статического метода тут будет находиться функция-конструктор класса.
- propertyName - это название метода.
- descriptor - это дескриптор свойства (метода)

Дескриптор свойства - это объект, описывающий "настройки" свойства. У него есть поля:

- configurable,
- enumerable,
- value
- writable
- get
- set

Таким образом, в декораторе мы можем изменять настройки метода, изменяя его дескриптор. Например, можем сделать метод неизменяемым:

function readable(target: Object, propertyKey: string, descriptor: PropertyDescriptor) {
    descriptor.writable = false;
}

Используется он так же, как и декоратор класса, только над методом:

class User {
    constructor(public name: string) {}

    @readable
    print(): void {
        console.log(this.name);
    }
}

Теперь для экземпляра класса User не получится переопределить метод print:

const john = new User('John');
john.print = function() {
    console.log('Method print has been changed');
}
john.print(); 
// Cannot assign to read only property 'print' of object 'User'

#typescript #tsдекораторы

TypeScript. Декораторы параметров метода класса

Задекорировать можно даже параметры метода, хотя это уже идея посложнее.

Декоратор параметра принимает три аргумента:

- target - прототип класса или конструктор (для статических методов)
- propertyKey - название метода
- parameterIndex - порядковый номер параметра

Например, создадим декоратор, который будет логировать некоторые параметры метода.

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

function logParameter(
    target: any, 
    key: string, 
    index: number
) {
    const metadataKey = `__log_${key}_parameters`;
    const loggedParams = target[metadataKey];
    if (Array.isArray(loggedParams)) {
        loggedParams.push(index);
    } else {
        target[metadataKey] = [index];
    }
}

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

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

function logMethod(
    target: any,
    key: string,
    descriptor: PropertyDescriptor
) {
    const originalMethod = descriptor.value;
    descriptor.value = function(...args: any[]) {
        const metadataKey = `__log_${key}_parameters`;
        const loggedParams = target[metadataKey];

        if (Array.isArray(loggedParams)) {
            loggedParams.forEach(function(index) {
                const arg = args[index];
                console.log(`Метод: ${key}, параметр: ${index}`, arg);
            })
        }

        const result = originalMethod.apply(this, args);
        return result;
    }
    return descriptor;
}

#typescript #tsдекораторы

TypeScript. Декораторы свойств

Функция-декоратор свойства принимает два параметра:

- target - прототип или конструктор (для статических свойств) класса
- propertyKey - имя свойства

С помощью декоратора можно, например, изменить дескриптор свойства, переопределив его геттер и сеттер:

function formatProperty(target: any, propertyKey: string) {
  let _value = target[propertyKey];

  const newGetter = function(): string {
    return `Mr./Mrs. ${_value}`;
  }

  const newSetter = function(newValue: string): void {
    _value = newValue;
  }

  delete target[propertyKey];

  Object.defineProperty(target, propertyKey, {
    get: newGetter,
    set: newSetter
  })
}

Применяется декоратор свойства точно так же, как уже рассмотренные декораторы классов и декораторы методов:

class User {
    @formatProperty
    name: string;

    constructor(name: string) {
        this.name = name;
    }

    print(): void {
        console.log(this.name);
    }
}

let john = new User('John');
john.print(); // Mr./Mrs. John

#typescript #tsдекораторы

TypeScript. Декораторы методов доступа (геттеров и сеттеров)

И последнее, что мы можем задекорировать в TypeScript, - это методы доступа к свойствам класса (геттеры и сеттеры).

Принимает такой декоратор три параметра:

- target - прототип класса или функция-конструктор класса (для статических свойств).
- propertyName - название метода.
- descriptor - дескриптор свойства

Декоратор получает дескриптор метода, а значит, может влиять сразу и на геттер, и на сеттер, поэтому его достаточно указать только над одним из них.

Пример декоратора-валидатора:

function validator(
    target: any,
    propertyKey: string,
    descriptor: PropertyDescriptor
) {
    const originalSet = descriptor.set;

    descriptor.set = function(value: string) {
        if (!value) {
            throw new Error(`Invalid value for property ${propertyKey}`);
        }

        if (originalSet !== undefined) originalSet.call(this, value);
    }
}

Добавляем к сеттеру:

class User {
    private _secret: string = "secret";

    constructor(public name: string){
        
    }
      
    public get secret(): string {
        return this._secret;
    }
    @validator
    public set secret(n: string) {
        this._secret = n;
    }
}

let john = new User('John');
john.secret = ""; // Invalid value for property secret

#typescript #tsдекораторы

TypeScript. Декораторы

В первом приближении с декораторами разобрались. Это простые функции, которые могут добавлять/изменять функциональность

- классов
- методов
- параметров методов
- свойств
- методов доступа к свойствам (геттеров/сеттеров)

В зависимости от типа декоратор получает разные параметры:

- конструктор класса или его прототип
- название свойства/метода
- дескриптор свойства метода

В основном декораторы изменяют свои аргументы, а не возвращают новое значение. Если все же возвращают новое (например, новый дескриптор свойства), то оно заменяет старое.

Мы все время указывали декоратор вот так:

@имя_функции_декоратора

Но на самом деле, вместо имени функции тут может стоять выражение, результатом которого является функция. Например, можно устроить фабрику декораторов:

function decoratorsFactory(param) {
    return function decorator(constructor: Function) {
        //...
    }
}

@decoratorsFactory('custom_value')
class User {

}

#typescript #tsдекораторы

TypeScript. Утилиты (Readonly, Required, Partial)

TypeScript не просто дает возможность указыать типы для переменных и параметров и тем самым отслеживать ошибки. Он еще предлагает большой инструментарий для манипуляций с типами, превращения одних типов в другие с нужными характеристиками. Для этого у него есть множество утилит.

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

Readonly

Делает все поля типа доступными только для чтения.
При попытке перезаписать их возникает ошибка.

Required

Делает все опциональные поля типа обязательными.
Если поле не указано в определении объекта, возникает ошибка.

Partial

Делает все обязательные поля типа опциональными.
Если поле не указано в определении объекта, ошибка не возникает.

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

#typescript

​TypeScript: объединения и пересечения

Объединения в TS - это аналог логического ИЛИ. Означает, что переменная должна быть одного из перечисленных типов.

Пересечения - это логическое И. Берет несколько типов и комбинирует их в один (типа Object.assign).

#typescript

​TypeScript. Ограничения обобщенных типов

Еще немного об обобщенных типах, или дженериках.

Дженерик - это неопределенный тип, который на этапе объявления функции как бы "резервирует" место для настоящего типа, который будет определен только в момент вызова этой функции.

Когда мы указываем обобщенные типы (дженерики), то они буквально означают "любой тип".

1)
Например, в функции getLength1 мы используем дженерик T, который может быть абсолютно любым типом. Даже таким, в котором нет поля length. Компилятор сразу же подчеркивает это.

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

2)
Для этого добавим интерфейс Lengthwise, который предусматривает наличие поля length и расширим его нашим дженериком - функция getLength2.

Ошибка пропала. Теперь компилятор сможет проверять входящие параметры.

3)
Если требуется обозначить только свойство length, в TypeScript есть встроенный интерфейс ArrayLike.

#typescript #дженерики

​Пример ограничения дженериков: обновление значений свойств одного объекта из другого.

Мы ожидаем на входе целевой объект target (свойства которого нужно обновить) и объект-источник данных source (из которого будут браться новые значения). Важно, чтобы у source были те же поля, что и target, ведь из них будут браться данные. По сути, тип source расширяет тип target. У него есть все поля target, а также могут быть свои собственные.

#typescript #дженерики

​TypeScript. Оператор keyof

Оператор keyof в TypeScript принимает любой объектный тип и возвращает новый тип, который представляет собой объединение ключей полученного типа (строк или чисел).

type Point = {
    x: number,
    y: number 
}

type PointKeys = keyof Point; // 'x' | 'y'

Можно даже использовать его с примитивными типами, в этом случае получим набор имен встроенных методов:

type NumberKeys = keyof number; // "toString" | "valueOf" | "toFixed" | "toExponential" | "toPrecision" | "toLocaleString"

Пример использования (ограничение обобщенных типов)

Смотрим на функцию getProperty. Она получает объект, имя свойства и возвращает значение этого свойства у объекта.

Функция работает с двумя типами: T (объект) и K (имя свойства).
При K - существующее у объекта свойство, то есть один из ключей объекта.

K extends keyof T

При вызове функции компилятор получает аргументы и выводит их типы.

getProperty(developer, 'pay'); 

- тип T - это Staff
- тип K - это keyof T, а точнее "name" | "salary"

Компилятор смотрит на второй аргумент. Его тип pay и он не может быть присвоен объединению ключей Staff.

#typescript #дженерики

Асинхронный рендеринг в React 18

Видео (рус.): https://www.youtube.com/watch?v=vRq9UtVhP_8&t=3500s
В видео два доклада, нужный начинается на 58 минуте.

Небольшой доклад (~ 20 мин) о новом (относительно) конкурентном режиме в React. Можно смотреть на увеличенной скорости.

Начинается с краткого вступления о том, как вообще был задуман этот режим, зачем, и как он постепенно внедрялся в библиотеку (React Fiber, хуки - это все этапы долгого пути).

В целом конкуррентный режим - это не треды, не отдельные потоки выполнения кода, а просто "планировщик", который может выбирать, какую из актуальных задач выполнять, ориентируясь на ее приоритет.

Затем на живых примерах разбираются три фичи конкурентного режима: Suspense, useTransition, useDeferredValue. Все это как раз способы указать приоритет различных задач.

В целом доклад очень понятный, позволит составить общее представление о Concurrent React, если еще не.

#ссылки #concurrentmode

Используйте коллбэк-рефы вместо useEffect

Статья (англ.): https://tkdodo.eu/blog/avoiding-use-effect-with-callback-refs

Статья рассматривает и критикует обращение к рефам в React внутри хука useEffect. Например, так мы часто реализуем установку фокуса на поле ввода.

useEffect(function() {
  inputRef.current?.focus();
}, []);

Это рабочий подход, но он имеет и свои минусы, главный среди которых - привязка вызова к рендеру компонента, а не к отрисовке самого элемента. Если поле ввода выводится в компоненте не сразу (условный рендеринг), то это не сработает.

Было бы здорово привязать вызов функции именно к отрисовке самого поля ввода - и для этого приходят на помощь функциональные рефы. На самом деле в проп ref можно передавать не только объект, созданный через React.useRef, но и обычную функцию. Она вызывается как раз в момент отрисовки элемента и получает сам элемент в качестве параметра.

ref={ function(node) {
  node?.focus();
} }

При удалении элемента функция вызывается снова, на этот раз с параметром null.

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

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

Старый пост про коллбэк-рефы: https://yangx.top/react_junior/122

#рефы #хуки #статьи

Визуальный гайд по рендерингу в React

Серия статей (англ.):

- Часть 1. It Always Re-renders
- Часть 2. Props
- Часть 3. useMemo
- Часть 4. useCallback
- Часть 5. Context
- Часть 6. DOM

Вспоминаем, как происходит рендер и перерендер в React.

1) При изменении состояния компонента, он ререндерится.
2) Если ререндерится родительский компонент, ререндерятся и все его потомки, если только они не созданы с помощью React.memo.
3) При изменении пропсов, компонент ререндерится (даже если он создан с помощью React.memo). Важно при этом помнить про ссылочные типы данных (объекты, массивы, функции), которые могут выглядеть одинаково, но не быть при этом равны. Например, если передать в проп дочернего компонента анонимную функцию, то при каждом ререндеринге родителя это будет уже другая функция, поэтому потомок тоже будет перерендериваться, даже если обернут в React.memo. Чтобы этого избежать, используем хуки useMemo и useCallback.
4) Если компонент подписан на контекст, то при изменении контекста он ререндерится.
5) На самом деле при изменении контекста (глобального состояния приложения), перерендеривается корневой элемент приложения, а значит и все его потомки. Чтобы избежать этого, можно оборачивать первого потомка AppContext.Provider в React.memo.
6) Если в провайдер контекста передается ссылочный тип данных, который меняется при каждом рендеринге корневого элемента, то все будет работать как с пропсами в пункте 3. Нужно такой контекст мемоизировать.

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

#статьи #оптимизация #контекст #подкапотом

TypeScript. Преобразование к типу

Преобразование к типу (Type assertion) - явное указание типа значения какого-либо выражения.

Есть два способа сделать это:
1) Тип указывается в угловых скобках перед выражением.
2) Тип указывается после оператора as после выражения.

Пример на картинке.

Если явно не указать тип явно, компилятор будет ругаться, так как результатом работы метода getElementById может быть не только HTML-элемент, но и null.

#typescript

TypeScript. ReadonlyArray

Можно определить массив, элементы которого нельзя изменять (добавлять новые, удалять существующие, перезаписывать).

Определяется как обычный массив с указанием типа.
Кроме того, можно использовать уже знакомую нам утилиту readonly.

У таких массивов нет методов, которые изменяют массив.

#typescript

​TypeScript. Заголовочные файлы

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

console.log(globalVar); // Cannot find name 'globalVar'

Чтобы помочь ему, необходимо объявить эти переменные, то есть описать их для TypeScript.

declare let globalVar: string;

Эта строчка сообщает компилятору, что в коде может встретиться переменная с именем globalVar и типом string. Теперь он сможет оперировать ей.

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

declare function sum(a: number, b: number): number;

declare const user: {name: string, age: number, print: ()=> void};

declare class Person{
    name: string;
    age: number;
    constructor(name: string, age: number);
    display(): void;
}

Эти объявления обычно выносятся в отдельные заголовочные (декларативные) файлы с расширением .d.ts.

Если мы компилируем отдельный файл (tsc app.ts), то компилятор не сможет самостоятельно найти заголовочные файлы, которые используются, поэтому их нужно подключить с помощью директивы reference:

#typescript