Что такое структурная типизация

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

У нас есть два типа Fireman и Programmer, а также функция, принимающая объект типа Fireman:

type Fireman = {
 name: string
}

type Programmer = {
 name: string
}

const fireman: Fireman = {
 name: "Alex"
}

const programmer: Programmer = {
 name: "Denis"
}

const foo = (person: Fireman) => { ... }

Номинальная типизация:

foo(fireman) // OK
foo(programmer) // Error

Но почему во втором случае ошибка? Потому что разные типы: функция ожидает на вход Fireman, а получает Programmer. Сравнение происходит только по самому типу.

А вот пример со структурной типизацией:

foo(fireman) // OK
foo(programmer) // OK

В этом случае всё отработает корректно, но только потому что Programmer и Fireman абсолютно идентичны по своей структуре.

Также будет работать и в случае, если один из типов будет являться подмножеством другого:

type Fireman = {
 name: string;
}

type Programmer = {
 name: string;
 age: number
}

const fireman: Fireman = ...
const programmer: Programmer = ...

const foo = (person: Fireman) => { ... }

foo(fireman) // OK
foo(programmer) // OK

Даже тут ошибки нет, а всё потому что тип Fireman полностью включен в тип Programmer и при вызове функции объект типа Programmer полностью удовлетворяет типу ожидаемой структуры, а следовательно и ошибки не будет. Для языка не важно, что у Programmer есть какие-то дополнительные поля. Главное, чтобы присутствовали все из типа Fireman и имели такой же тип.

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

Спасибо за прочтение, это важно для меня ❤️

#web #theory #typescript

let a = { name: 'progway' };
let b;

b = a;
a.name = 'denis';
console.log(b.name);

@prog_way_blog — чат — #quiz

В чем заключается разница между интерфейсом и типом?

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

Тип — обозначается ключевым словом type — представляет собой либо описание структуры (объекта, функции…), либо набор других типов или структур:

// набор типов
type Identifier = string | boolean;

// описание структуры
type Person = {
 name: string;
 age: number;
}

// набор типов или структур
type Foo = Person | string;

Интерфейс — обозначается ключевым словом inderface — может описывать только структуры:

interface Props {
 title: string;
 visible?: boolean;
}

Особенности типов:
1. Только типами можно создать типы-объединения (они же union type):

type Identifier = string | number
type Animal = Dog | Cat

2. Только типами можно создавать кортежи, фиксируя тип элемента массива по индексу и длину массива:

type Cortage = [string, number, boolean]

3. Только с помощью типов можно создавать псевдонимы (они же alias):

type Name = string
type Author = Name

4. Типами проще и красивее создавать описание функций:

type Foo = (a: string) => number

interface Foo {
 (a: string): number
}

Особенности интерфейсов:
1. Только интерфейсы имеют перегрузку типов:

interface Person {
 name: string
}

interface Person {
 age: number
}

const kate: Person = {
 name: "Екатерина",
 age: 24
}

2. Только интерфейсы могут быть имплементированы:

interface Person {}

class Fireman implements Person {}

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

Спасибо за прочтение, это важно для меня ❤️

#web #theory #typescript

Сужение типов и уточняющие тайпгарды​

Часто в TypeScript коде можно столкнуться с тем, что типы недостаточно точны. Это бывает в случаях, когда мы определяем типы, например, через union — string | number и других подобных случаях. Рассмотрим пример:

const value: string | number = ...

parseInt(value) // ошибка

В таком случае мы получим TypeError , а всё потому что переменная value имеет более общий тип, чем тот, что ожидает parseInt — эта функция ожидает первым аргументом на вход только строку. В таком случае нам может помочь сужение типов, которое нам дают дополнительные проверки — тайпгарды.

Тайпгарды — Type Guards — это языковые конструкции, проверки, которые позволяют определить или уточнить тип переменной средствами JavaScript. Тайпгарды бывают двух видов — уточняющие и определяющие.

Уточняющие тайпгарды — проверки, которые позволяют вывести более узкий тип из общего типа, например вывести string из типа string | number | boolean | null.

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

Есть несколько способов сузить тип:

1. Через оператор typeof

const value: string | number = ...

if (typeof value === 'string') {
  // ошибки не будет, т.к.
 // тип value в этом условии
 // строго равняется "string"
 parseInt(value)
}

2. Через ключевое слово in или метод hasOwnProperty

const value: any[] | number = ...

if ("map" in value) {
 // value === array
 value.map(...)
}

const animal = Cat | Dog = ...

if (animal.hasOwnProperty('meow')) {
 // animal === Cat
 animal.meow()
}

3. Через ключевое слово instanceof

const person: Fireman | Programmer = ...

// при условии что Programmer - класс
// а person - инстанс класса
if (person instanceof Programmer) {
 person.code()
}

4. Через встроенные в язык функции проверки типа

const value: any[] | number = ...

if (Array.isArray(value)) {
 value.map(...)
}

5. Через existed check, например, для null и undefined

const user: User | null = ...

if (user) {
 console.log(user.name)
}

Также подобные проверки можно выносить в отдельные функции, которые обычно именуются по следующему шаблону — is + <название типа или интерфейса> , например, для типа User будет логично создать тайпгард isUser, вот небольшой пример:

type Account = User | Admin | Manager

const isUser = (account: Account): account is User => {
 return account.type === "user"
}

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

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

Если более просто, то мы знаем, что если account.type === “user” , то перед нами ни что иное как User. В этом случае тип аккаунта является предикатом, на основе которого можно делать выводы о типе аккаунта без дополнительных проверок.

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #code #typescript

let x = 5;
let y = new Number(5);
let z = 5;

console.log(x == y);
console.log(x === y);
console.log(y === z);

@prog_way_blog — чат — #quiz

Что такое Fullscreen API

Fullscreen API — это интерфейс для работы с полноэкранным режимом в веб-браузерах, который позволяет элементам HTML-страницы разворачиваться на весь экран.

Яркий пример использования Fullscreen API — это видеоплееры. Когда вы нажимаете кнопку для просмотра видео на весь экран, используется именно этот API. Но его возможности далеко не ограничиваются видео: он может быть применен к любым элементам страницы, будь то изображения, модалки и любые другие блоки страницы.

Пример использования следующий:

// получаем элемент, который хотим открыть на весь экран
const element = document.getElementById('target');

// открыть элемент на весь экран
element.requestFullscreen()

// получить элемент, который открыть в полноэкранном режиме
document.fullscreenElement

// выйти из полноэкранного режима
document.exitFullsreen()

Также методы requestFullscreen и exitFullscreen являются промисами, что позволяет проще работать с ними и обрабатывать ошибки их вызова.

И ещё важно знать, что из полноэкранного режима можно выйти по нажатию клавиши ESC по умолчанию, а также некоторые браузеры дают собственные сочетания клавиш. Чтобы обработать и такой случай, можно отслеживать отдельное событие:

document.addEventListener('fullscreenchange', () => {
 // как-то обрабатываем изменение состояния
 
 // можно завязаться на
 // document.fullscreenElement
})

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #code #javascript #web #useful

let progway;
progwya = {};
console.log(progway);

@prog_way_blog — чат — #quiz

Псевдоселекторы в CSS

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

Псевдоселекторы бывают двух видов:
1. Псевдоклассы — применяются к элементам на основе их состояния или взаимодействия с пользователем
2. Псевдоэлементы — позволяют стилизовать определённые части элементов

Примеры псевдоклассов:

1. :hover — применяется, когда пользователь наводит указатель мыши на элемент

a:hover {
    color: red;
}

В этом примере цвет текста ссылки изменится на красный при наведении курсора

2. :nth-child(n) — выбирает элементы на основе их позиции среди братьев и сестёр

li:nth-child(2) {
    background-color: yellow;
}

Здесь каждый второй элемент списка li будет иметь жёлтый фон

3. :focus — применяется к элементу, когда он получает фокус (например, при клике или переходе по табуляции)

input:focus {
    border-color: blue;
}

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

Конечно же, это не все псевдоклассы, которые существуют в CSS. В этом посте рассмотрим только часть для примера

Примеры псевдоэлементов:

1. ::before — вставляет содержимое перед элементом

p::before {
    content: "Note: ";
    font-weight: bold;
}

Этот стиль добавит текст "Note: " перед каждым параграфом p

2. ::after — вставляет содержимое после элемента.

p::after {
    content: " ->";
    color: grey;
}

В этом примере текст "->" будет добавлен после каждого параграфа

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

li:nth-child(odd):hover {
    background-color: lightblue;
}

Этот код изменит цвет фона каждого нечётного элемента списка на светло-голубой при наведении на него курсора.

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #web #useful

Что такое семантика?

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

Семантических тегов множество, однако, самые используемые из них:

<header> - заголовок секции или документа
<nav> - навигационное меню
<article> - независимая часть контента, например, статья, пост...
<section> - определяет раздел конкретного документа, статьи, поста...
<aside> - содержит контент, связанный с основным содержанием страницы, но не являющийся его частью
<footer> - представляет нижний колонтитул секции или документа

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

Важнее сказать, что семантические теги делятся на 2 категории значимости:
— Первая категория, по сути, имеет те же свойства и вид, что обычный div. Их особенность заключается лишь в том, как эти теги будут обрабатываться парсерами и служат они в основном для SEO.
— Вторая категория — когда тег имеет дополнительные уникальные свойства и поведение, а, возможно, и внешний вид.

Давайте сразу на примере:

<header> - по сути, тот же <div>, но просто парсится иначе

<button> - тоже семантический тег 

Но, помимо особой семантической значимости, этот тег также имеет и другие свойства:
- встроенные обработчики событий для взаимодействия с клавиатуры
- иной внешний вид
- верная HTML-роль по умолчанию

На самом деле, семантический тег — это всё, что не <div>. Только этот тег не имеет особого назначения и нужен лишь для группировки других тегов. Остальные же теги несут в себе какой-то дополнительный семантический смысл.

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

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #web #useful

Управление фокусировкой

Часто на собеседовании могут спросить об управлении состоянием фокуса. Обычно вопрос подаётся в контексте следующей задачи:

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

Начнем с того, у тега input есть прекрасный атрибут autofocus, который и был придуман для решения таких задач:

<input id="login" name="login" autofocus />

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

Тогда мы приходим к решению этой задачи через JavaScript:

document.getElementById('login').focus(); 

Ведь есть не менее прекрасный метод focus, после вызова которого, фокус перенесётся на конкретный элемент. Его поддержка уже значительно лучше, а самое главное — весь контроль за происходящим на странице лежит в наших руках, что, в целом, достаточно удобно.

О методе focus знают уже многие, но знаете этот вопрос может развиться: как посмотреть, на каком элементе мы сейчас сфокусированы? Такой вопрос уже может поставить многих в ступор, потому что с этим далеко не каждый день работаешь. Но, на самом деле, всё просто:

document.activeElement

У документа есть свойство activeElement, на которое мы и можем завязаться.

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #javascript #web

Определяющие тайпгарды

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

Определяющие тайпгарды — это функции, которые позволяют уточнить тип unknown переменной. Сразу рассмотрим пример и рассмотрим следующий интерфейс:

interface User {
    name: string;
    age: number;
    roles: string[];
}

И представим, что в коде у нас есть некоторая переменная с неизвестным типом, которую мы хотим обработать:

const foo: any = ...

if (isUser(foo)) {
 // обработать как пользователя
} else {
  // обработать как что-то иное
}

Определяющие тайпгарды любую переменную воспринимают как unknown, это их ключевая особенность. Каждое свойство мы проверяем отдельно и таким образом, чтобы однозначно убедиться в его типе. Для интерфейса из примера, хороший тайпгард будет выглядеть так:

function isUser(value: unknown): value is User {
    const user = value as User;

    return user !== null 
        && typeof user === 'object' 
        && typeof user.name === 'string'
        && typeof user.age === 'number'
        && Array.isArray(user.roles)
        && user.roles?.every(role => typeof role === 'string');
}

Это может выглядеть очень некрасиво, но главное, что работает)

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #code #typescript

Что такое Git Flow?

Git Flow — это модель ветвления для Git, основная идея которой заключается в использовании отдельной ветки для каждого этапа разработки. Обычно выделяются следующие ветки:

1. Основная ветка — чаще всего это master
Эта ветка содержит стабильную версию продукта, которая готова к выпуску. В ней всегда должен быть работающий и протестированный код. Каждый коммит в master обычно соответствует одной версии продукта

2. Ветка разработки — чаще всего это develop
В этой ветке происходит активная разработка. Все новые фичи и изменения сначала попадают сюда. После тестирования и проверки они будут слиты в master

Также есть вспомогательные ветки, которые маркируются своим префиксом — чаше всего это feature/*, release/*, bugfix/*, hotfix/*:

1. Ветки для разработки новых функций — feature/*
Они создаются от develop и после завершения работы сливаются обратно в develop. Нужны такие ветки для организации разработки отдельной фичи.

2. Ветка для фикса багов — bugfix/* и hotfix/*
Почти то же самое, что и feature/*, только эти ветки нужны для фикса багов. hotfix/* — для фикса багов в мастере или релизе. bugfix/* — для фикса багов в ветке develop

3. Ветка для подготовки версии продукта — release/*
Создаются от develop, когда разработка новых функций завершена и нужно подготовить релиз. После завершения сливаются в master и develop

Чаще всего процесс разработки выглядит таким образом: берём задачку → делаем отдельную ветку → вносим изменения → сливаемся через код ревью в нужную ветку

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

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #useful