Telegram Web
Не забывайте про реакции 🌚
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳13🔥10🌚9🍌95👍2👀2🎄2
Что такое структурная типизация

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

У нас есть два типа 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
21👍5🔥5🐳1
let a = { name: 'progway' };
let b;

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


@prog_way_blogчат#quiz
🐳51
Что будет в консоли?
Anonymous Quiz
20%
progway
72%
denis
5%
undefined
2%
ReferenceError
🙏9🐳7🤷‍♂11
В чем заключается разница между интерфейсом и типом?

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

Тип — обозначается ключевым словом 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
👍48🔥87🐳2
Сужение типов и уточняющие тайпгарды

Часто в TypeScript коде можно столкнуться с тем, что типы недостаточно точны. Это бывает в случаях, когда мы определяем типы, например, через unionstring | 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
🔥20👍127🐳2🎄1
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
🐳6🗿4🔥3😎1
Что такое 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
👍16🔥11🐳54
let progway;
progwya = {};
console.log(progway);


@prog_way_blogчат#quiz
🗿12🐳2
🐳11🤬5🤓4👍1
Псевдоселекторы в 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
👍306🔥4🐳1
Что такое семантика?

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

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

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


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

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

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

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

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

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


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

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

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

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

@prog_way_blogчат#theory #web #useful
🔥69👍8🐳6
Зачем нужна семантика?

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

Чаще всего о семантике говорят со стороны SEO, и не зря:

1. Поисковые роботы, прежде чем добавить ваш сайт в выдачу, открывают вашу страницу и прогружают весь её контент. Чем лучше свёрстана страница, тем больше “баллов” она наберёт — лучше определится категория контента, его содержимое, ключевые запросы. Чем больший рейтинг набирает страница, тем вероятнее она появится в выдаче при поиске. А посещения почти всегда конвертируются в доход.

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

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

Пример работы скринридера в видео


Так вот, скринридеры завязываются как раз на эти самые семантические теги и семантические атрибуты типа alt у тега image.

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

3. Множество предустановок
Как я и говорил в прошлом посте, есть категория семантичных тегов, которые имеют дополнительные свойства "из коробки", типа тега <button>. Использовать такой тег в разы удобнее, чем сделать кнопку из тега <div>

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

🌐 Также советую доклад Вадима Макеева на тему семантики. Вадим — амбассадор доступности, у него шикарные материалы на эту тему.

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

@prog_way_blogчат#theory #web #useful
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥247👍6🐳3
Управление фокусировкой

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

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

Начнем с того, у тега 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
👍4213🔥5🐳4🤩2
Определяющие тайпгарды

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

Определяющие тайпгарды — это функции, которые позволяют уточнить тип 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
👍175🔥4🤔1🐳1
Что такое 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
29👍19🔥5🐳2🤝1
2025/07/09 02:29:31
Back to Top
HTML Embed Code: