Pavel Osin

Webstorm, как исключить из поиска папки

2025-12-09T09:05:12.909Z

На новом проекте WS активно искал по файлам, которые относятся к результатам билда nx-репозитория. Искал как решить, поэтому зафиксирую здесь.

Чтобы отключить поиск по файлам, которые Git игнорирует (например, в директории node_modules или dist), нужно настроить WebStorm, чтобы он не индексировал эти директории как часть проекта, а не отключать сам .gitignore (он нужен для Git), делая это через Settings/Preferences > Directories, добавив папку как "Excluded" (Исключенная). Это предотвратит их участие в поиске, рефакторинге и других операциях IDE, сохраняя .gitignore для Git.

Шаги для исключения папки в WebStorm:

File (Файл) -> 
Settings (Настройки) -> 
Preferences (Предпочтения)

- В левой панели кликаем по Project Structure (Структура проекта).
- Находим папку, которую хотите игнорировать (например, node_modules, dist, build), клик по ней правой кнопкой мыши и пометить как Excluded (Исключенная).

Centi Conf. Frontend Day

2025-12-08T20:11:17.110Z

Посетил конференцию по разработке на Angular от Centicore. Один поток, шесть докладов. Рассказывали о новом и хорошо забытом старом во фронтенде.

Отмечу, что запомнилось и сухой текст разбавлю парой фоточек.

1) Computer Science во фронтенде

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

Что интересно освежил:

Битовые маски

Используются для хранения множества булевых признаков в одном числе:
- экономия памяти
- быстрые проверки (&, |, ^)
- удобно для наборов флагов (права доступа, возможности, состояния)

Примерно так же работают feature flags — только привычнее, когда флаги строковые, а не побитовые.

Двунаправленные связные списки

Актуальны там, где:
- много вставок/удалений в середине коллекции
- порядок элементов важен и часто меняется

В JavaScript списки есть только абстрактно (Array ≠ linked list), поэтому, когда нужен реальный O(1) на вставку — без собственной структуры не обойтись. Полезно помнить, что не всё должно быть массивом, если требуется производительность.

TypeScript Transformers

Это вмешательство в процесс компиляции TypeScript:
- переписывание типов и кода
- автоматическое добавление полей, проверок, метаданных
- снижение дублирования
Использование трансформеров позволяет: формализовать архитектурные правила генерировать код там, где он предсказуем и однообразен

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

2) Сигналы в Angular

Олег Щеголев рассказал, что нового принесли сигналы в Angular. При сухом чтении документации не возникает желания их использовать, особенно когда давно пишешь на RxJS. На примерах же становится сильно понятнее, что сигналы позволяют экономить ресурсы, перерендеры и открывают дорогу в прекрасное будущее без Zone.js :)

Заметки:

Resource для асинхронных данных
debounce для сигналов через toSignal → уже можно использовать

и закончу докладом Глеба Михеева.

3) Генеративный пользовательский интерфейс

Доклад о будущем, которое скоро наступит. А возможно уже наступило.
Пока мы по-старинке верстаем компоненты и пишем логику систем, все вокруг бежит так быстро, что ИИ делает просто нереальными попытки остающих зацепиться за реальность. Завернул.

Доклад о формировании интерфейса на основе данных и контекста. Основная идея — UI может не быть жёстко заданным, а строится динамически. Технически звучит перспективно для систем с большим количеством вариативных экранов и пользовательских сценариев.

Смысл подхода: UI не верстается вручную заранее, а формируется автоматически в момент использования — на основе данных, бизнес-правил и контекста.

В основе лежат БЯМ (большие языковые модели), которые обучаются на описанной логике, моделях данных, сценариях, ограничениях и данных о пользователе. Все остальное генерируется автоматически. Разработчик становится по-сути оператором нейросети, чтобы задавать правила построения UI, а не расположение кнопок и форм. Тут риторический вопрос, нужны-ли разработчики в этой цепочке, когда такой интерфейс может построиться бизнес-аналитиком.

Фактически для нас, как разработчиков смещается фокус.

Было:

сверстать экран → внедрить бизнес-логику → править по запросу бизнеса

Становится:

описать правила → настроить компоненты → обеспечить совместимость

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

Немного жалею, что торопился и не остался на афтерпати)

performance() в браузере

2025-12-05T07:12:11.016Z

Когда речь заходит о производительности веб-приложений, большинство разработчиков вспоминают Lighthouse, Web Vitals и профайлеры в DevTools. Но в современном JavaScript есть ещё один мощный инструмент, который часто недооценивают — Performance API. Это встроенный интерфейс браузера, который позволяет точно измерять время выполнения операций внутри веб-приложения: от загрузки страницы до конкретных участков кода. Он даёт доступ к высокоточным временным меткам (DOMHighResTimeStamp) и системам метрик.

Я использовал его для отладки интервалов и таймеров. Надеюсь, ни для кого не секрет, что в js interval(1000) - это далеко не 1 секунда.

Например, задача

Имеется временное отклонение t при работе таймеров в системе. Ожидаем, что таймер выполнится через 1000 мс, и проверяем реальное время:

const interval = 1000;
let ticks = 0;
let last = performance.now();

const id = setInterval(() => {
  ticks++;
  const now = performance.now();
  const drift = now - last - interval; 

  console.log(
    `Тик #${ticks} — задержка: ${drift.toFixed(2)}ms, текущее время: ${(now - start).toFixed(2)}ms`
  );

  last = now;

  if (ticks >= 5) {
    clearInterval(id);
    console.log('Интервал остановлен');
  }
}, interval);

const start = performance.now();

В реальности получил от 920мс до 1100. Иногда больше - иногда меньше. В зависимости от загруженности EventLoop или процессора ПК, активности вкладки и так далее.

Шпаргалка по Conventional Commits

2025-11-29T11:11:55.060Z

Система Conventional Commits помогает писать единообразные коммиты, которые легко читать, анализировать и автоматически использовать в релизах.

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

Основная идея

Каждый коммит должен отвечать на три простых вопроса:

Что изменили? — тип (type)
Где? — область (scope) — необязательно, но очень рекомендуется
Зачем и что именно?» — короткое и понятное описание (subject)

<type>[optional scope]: <subject>
[optional body]
[optional footer]

1. Типы коммитов

feat (новый функкционал).

feat(auth): добавить refresh token механизм

fix (исправление ошибки, дефекта)

fix(profile): корректно сохранять изменения аватара

docs (изменения в документации)

docs(readme): обновить раздел по установке проекта

style(изменения, не влияющие на логику — форматирование, пробелы, точки с запятой.

style(ui): выровнять отступы в модальном окне

refactor (перереписывание кода без изменения поведения)

refactor(api): упростить структуру сервисов

perf(Оптимизация производительности)

perf(table): ускорить рендер на 20%

test (добавление или исправление тестов)

test(cart): покрыть логику пересчёта сумм

build(изменения в сборке, CI, зависимостях)

build: обновить Webpack до версии 5

chore(Прочие изменения, не затрагивающие код приложения)

chore: почистить скрипты в package.json

2. Scope

Всегда, когда это помогает локализовать изменение. Хорошие примеры областей:

auth
live
ui
api

Некорректные примеры:

misc
stuff
temp

3. Subject

Короткий принцип:

Пишем в повелительном наклонении, как будто даём команду коду.
Не ставим точку в конце.
Максимум ясности, минимум слов.
Если в команде принято соглашении о привязке задач к коммитам, можно указать номер задачи

Примеры хороших subject:

перенести логику в сервис
добавить debounce при вводе
исправить ошибку валидации номера

4. Body

Используем только если нужно объяснение:

почему так сделано;
какие альтернативы рассматривались;
есть ли побочные эффекты.

refactor(order): вынести расчет скидки в отдельный модуль
Чтобы упростить дальнейшую поддержку и подготовить почву для многоуровневой системы скидок.

5. Footer

Closes #123

BREAKING CHANGE:

Если коммит ломает обратную совместимость, обязательно указываем:

feat(api): изменить структуру ответа метода /users

BREAKING CHANGE: метод возвращает объект вместо массива

Перенос файлов между ветками git

2025-11-24T08:57:53.077Z

Иногда в Git нужно не переключаться полностью на другую ветку, а забрать из неё один или несколько конкретных файлов. Git позволяет сделать это в одну команду — git checkout (в новых версиях — git restore). Это существенно упрощает работу, особенно если нужно подтянуть изменения коллеги, а они разбиты по нескольким коммитам

Находясь в текущей ветке (например, develop):

git checkout <имя-ветки> -- <путь/к/файлу>

Пример

Мы хотим взять файл config.yml из ветки develop:

git checkout origin/develop -- config.yml

После выполнения команда не переключит нас на ветку develop, а просто заменит файл config.yml в текущей ветке версией из develop.

Если файлов несколько, пути можно указать через пробел (или просто указать директорию)

Signal forms в Angular

2025-11-24T06:52:07.682Z

Angular продолжает движение в сторону чистой реактивности без RxJS, и сигналы стали первым большим шагом. Теперь к ним добавились сигнальные формы — экспериментальный API, появившийся в Angular 21.

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

Первое, что бросается в глаза — состояние формы мы объявляем через обычный сигнал без Observable и без подписок:

formData = signal({
  username: 'btomer',
  firstName: 'Tomer',
  lastName: 'Bill',
  age: 35,
});

Далее создаём саму форму:

form = form(this.formData, (user) => {
  required(user.username);
  required(user.lastName);
  pattern(user.firstName, /^[A-Za-z]+$/, { message: 'Проверьте ввод, допустимы только символы' });
  max(user.age, 40);
});

По сравнению со старым подходом все стало сильно проще: никаких FormControl, FormBuilder и подписок на изменения.

Связывание с шаблоном так же упростилось:

<input [control]="form.username" />
<input [control]="form.firstName" />
<input type="number" [control]="form.age" />

<app-custom [control]="form.lastName" />

Состояние формы так же выводится через сигналы:

<pre>{{ form().valid() }}</pre>

@let errors = form().errorSummary();
@for (error of errors; track $index) {
  <p>{{ error | json }}</p>
}

<pre>{{ form().value() | json }}</pre>

И самое главное, Angular уходит от использования CVA (Control Value Accessor)

Чтобы создать новый контрол, нужно имплементировать интерфейс FormValueControl. На первый взгляд он сильно проще, но надо еще попробовать на сложном контроле. В базе выглядит как-то так:

@Component({
  selector: 'app-custom',
  imports: [Control],
  template: `
    <div>
      <label>Last name: </label>
      <input #i [value]="value()" (input)="value.set(i.value)" />
    </div>
  `
})
export class Custom implements FormValueControl<string> {
  value = model<string>('');
}

Всё, что нужно — сигнал model(), представляющий значение.
Ни registerOnChange, ни writeValue, ни setDisabledState — просто реактивная модель.

По ощущениям это действительно новая эпоха форм в Angular, похожая на то, как signals изменили работу с состоянием.

Попробовать сигнальные формы можно самостоятельно, например на StackBlitz

WeakMap

2025-07-22T16:57:22.407Z

WeakMap — это структура, которая не удерживает объект от удаления GC.

Ключи — только объекты.
Если на ключ больше нет других ссылок кроме WeakMap — объект считается мусором и будет удалён.
WeakMap не итерируемый, ты не можешь получить .keys() или .size() — потому что эти объекты могут в любой момент "исчезнуть".

const privateData = new WeakMap();

class User {
  constructor(name) {
    privateData.set(this, { name });
  }

  get name() {
    return privateData.get(this).name;
  }
}

📌 Когда экземпляр User больше нигде не используется — он удаляется, и все его "приватные данные" в WeakMap тоже.

RxJS share() в Angular

2025-07-20T11:56:13.645Z

Многие Observable в RxJS являются холодными. Это означает, что при каждой подписке создаётся новый поток, заново выполняются все операторы и возможные побочные эффекты — например, HTTP-запросы, таймеры, логирование и т.д.

Чтобы избежать повторных вычислений и разделить один источник данных между несколькими подписчиками, используется оператор share(). Он превращает Observable в горячий и включает режим мультикастинга — подписчики получают данные из общего потока, а не инициируют новые.

Пример холодного Observable

Допустим, у нас есть сервис DataService, который возвращает поток данных:

import { Injectable } from '@angular/core';  
import { Observable, of, delay, tap } from 'rxjs';  
  
@Injectable({ providedIn: 'root' })  
export class DataService {  
  private callCount = 0;

  // Холодный Observable — каждый вызов создаёт новый поток
  getData(): Observable<string> {  
    this.callCount++;  
    return of(`Ответ #${this.callCount}`).pipe(  
      delay(1000), // имитируем задержку  
      tap(value => console.log('🔥 Выполнен запрос!', value))  
    );  
  }
}

И у нас есть компонент, который подписывается на этот Observable дважды:

import { Component, OnInit } from '@angular/core';  
import { DataService } from '../../data.service';  
  
@Component({  
  selector: 'app-cold',  
  template: `
    <h2>Cold Observable (без share)</h2>
    <div *ngIf="value1">Подписка 1: {{ value1 }}</div>
    <div *ngIf="value2">Подписка 2: {{ value2 }}</div>
  `  
})  
export class ColdComponent implements OnInit {  
  value1?: string;  
  value2?: string;

  constructor(private dataService: DataService) {}

  ngOnInit() {
    const obs$ = this.dataService.getData();  
  
    obs$.subscribe(value => (this.value1 = value));  
    obs$.subscribe(value => (this.value2 = value));  
  }
}

Результат: в консоли мы увидим:

🔥 Выполнен запрос! Ответ #1  
🔥 Выполнен запрос! Ответ #2

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

🔥 Преобразуем в горячий Observable с `share()`

Теперь давайте применим share() и сделаем один общий поток:

import { Component, OnInit } from '@angular/core';  
import { DataService } from '../../data.service';  
import { share } from 'rxjs/operators';

@Component({  
  selector: 'app-shared',  
  template: `
    <h2>Shared Observable (с share)</h2>
    <div *ngIf="value1">Подписка 1: {{ value1 }}</div>
    <div *ngIf="value2">Подписка 2: {{ value2 }}</div>
  `  
})  
export class SharedComponent implements OnInit {  
  value1?: string;  
  value2?: string;

  constructor(private dataService: DataService) {}

  ngOnInit() {
    const shared$ = this.dataService.getData().pipe(share());

    shared$.subscribe(value => (this.value1 = value));  
    shared$.subscribe(value => (this.value2 = value));  
  }
}

Результат:

🔥 Выполнен запрос! Ответ #3

Теперь обе подписки получают одни и те же данные из одного источника. Это и есть эффект мультикастинга.

Запуск Chrome в режиме бeз CORS

2025-07-01T10:29:20.498Z

Во время локальной разработки часто возникает необходимость тестирования API-запросов к другим доменам. Браузер блокирует такие запросы из-за политики CORS, что затрудняет отладку. Для упрощения тестирования можно запустить Chrome в режиме без проверки CORS.

⚠️ Внимание: запуск в таком режиме снижает безопасность. Используется только для разработки.

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

Windows

Закрыть все окна Chrome.
Открыть Командную строку или PowerShell.
Выполнить команду:

start chrome --disable-web-security --user-data-dir="C:/chrome-dev-disable-cors"

Пояснения:

--disable-web-security отключает проверку политики безопасности, включая CORS.
--user-data-dir="C:/chrome-dev-disable-cors" создаёт отдельный профиль для разработки, чтобы избежать конфликта с основным профилем.

macOS

Закрыть все окна Chrome.
Открыть Terminal.
Выполнить команду:

open -na "Google Chrome" --args --disable-web-security --user-data-dir="/tmp/chrome-dev-disable-cors"

Linux

Закрыть все окна Chrome.
Выполнить в терминале:

google-chrome --disable-web-security --user-data-dir="/tmp/chrome-dev-disable-cors"

А если без командной строки?

Можно воспользоваться расширениями для браузера. Например, для chrome: или firefox. Но, по моему опыту, поведение с ними иногда непредсказуемо. Лично ловил в хроме упавшие запросы по корсам, когда они вроде бы должны быть отключены.

REST vs GraphQL

2025-04-01T10:27:19.542Z

В мире веб-разработки REST и GraphQL являются двумя наиболее популярными подходами к организации взаимодействия между клиентом и сервером. Несмотря на то, что оба подхода решают схожие задачи — передача данных через API — у них есть ключевые различия, которые могут повлиять на выбор в зависимости от потребностей проекта.

Что такое REST?

REST (Representational State Transfer) — это архитектурный стиль, который описывает взаимодействие между клиентом и сервером с использованием стандартных HTTP-методов (GET, POST, PUT, DELETE) и структурированных URL. RESTful API обычно строится вокруг ресурсов (например, пользователей, постов, товаров), и каждое действие над ресурсом выполняется через соответствующий HTTP-метод.

Пример запроса в REST:

Получение списка пользователей:
GET /users
Получение одного пользователя:
GET /users/{id}
Создание нового пользователя:
POST /users

Что такое GraphQL?

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

Пример запроса в GraphQL:

Запрос на получение информации о пользователе и его постах:

{
  user(id: "1") {
    name
    posts {
      title
      content
    }
  }
}

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

Основные различия:

Количество запросов:

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

Гибкость запросов:

REST: Сервер определяет, какие данные и в каком формате клиент получает в ответ. Это может привести к избыточным данным или, наоборот, к необходимости делать несколько запросов для получения нужной информации.
GraphQL: Клиент сам определяет, какие именно данные ему нужны. Это позволяет сократить объем передаваемых данных и повысить эффективность взаимодействия.

Структура данных:

REST: Каждый ресурс имеет свой собственный URL и обычно возвращает фиксированную структуру данных.
GraphQL: Все запросы выполняются через один URL, а структура ответа зависит от запроса клиента. Это даёт более высокую степень кастомизации.

Обработка ошибок:

REST: Ошибки обрабатываются через статус-коды HTTP (например, 404 для "не найдено", 500 для "ошибка сервера").
GraphQL: Ошибки можно передавать в теле ответа. Они не блокируют успешное получение данных — даже если часть запроса не выполнена, остальные данные могут быть возвращены.

Сложность реализации:

REST: Более прост в реализации, особенно для небольших приложений. В большинстве случаев используется стандартная структура URL и методы.
GraphQL: Сложнее в настройке, но даёт более мощные инструменты для работы с данными. Требует более тщательного планирования схемы API.

Сходства:

Обе технологии используют HTTP: Несмотря на разные подходы, REST и GraphQL работают через HTTP-протокол и могут использовать схожие механизмы аутентификации, например, с использованием токенов.
Обе предлагают механизмы фильтрации данных: В REST это обычно происходит через параметры запроса (например, ?page=1&limit=10), а в GraphQL — через поля запроса.
Обе позволяют работать с различными типами данных: и REST, и GraphQL могут работать с текстовыми данными, изображениями, файлами и т.д.

Когда использовать REST, а когда GraphQL?

REST: Подходит для простых приложений, где структура данных не меняется часто, и нет сложных зависимостей между сущностями. Это классический выбор для большинства CRUD-приложений.
GraphQL: Идеален для сложных приложений с множеством взаимосвязанных данных, где важно минимизировать количество запросов и оптимизировать трафик. Особенно полезен в случае, когда структура данных может изменяться, и нужно обеспечить гибкость запросов.

REST и GraphQL — это два подхода с разной философией. REST ориентирован на ресурсы и стандартные HTTP-методы, в то время как GraphQL даёт клиентам полную гибкость в запросах. Выбор между ними зависит от требований к проекту: если важна простота и стандартность, лучше использовать REST; если нужна гибкость и эффективность, GraphQL может быть лучшим вариантом.