Типизация или опять костылизация?

На прошлой неделе открыл для себя один немаловажный нюанс.

В своем решении мне нужно было передавать в аргумент функции KeyboardEvent. При включенном strict mode и попытке считать значение event.target.value, как в примере ниже, получаем ошибку: TS2339: Property value does not exist on type EventTarget.

private keydownHandler(event: KeyboardEvent): void {
  if (
    event.target && 
    event.target.value
  ) {
      ...
    }
}

Первое решение, которое пришло в голову, было сделать принудительный каст. Это решало проблему, но так делать плохо. Гораздо удобнее и правильнее было бы использовать type guard.

private keydownHandler(event: KeyboardEvent): void {
    if (event.target instanceof HTMLInputElement && event.target.value) {
      ...
    }
}

Но, насколько я знаю, HTMLInputElement это интерфейс, соответственно это не сработает. Оказывается, сработает! Дело в том, что если посмотреть в lib.dom.d.ts, то можно найти, что HTMLInputElement это и интерфейс, и объявление класса:

interface HTMLInputElement extends HTMLElement, PopoverInvokerElement {...}

declare var  HTMLInputElement: {
  prototype: HTMLInputElement;
  new(): HTMLInputElement;
}


Поэтому решение с instanceof сработает. Но похоже, что сделано специально для подобной проверки, но подход весьма сомнительный. А вы знали об этом? И как вы относитесь к подобному решению?

#js

Host directives

Новая статья от Саши Инкина - на этот раз продолжение, на мой взгляд, целой серии про декомпозицию и работу с директивами.

- Практические примеры из Taiga UI. (Знаю, недавно вышла новая версия. Поздравляю ребят)
- Детальный разбор применения directive composition API
- Недостатки данного API и как их избегать.

Подробности - по ссылке ниже.

https://www.angularspace.com/host-directives-decomposition-unleashed/

#angular

Вышел Angular v18.2

В пятницу открыл репозиторий Angular, а тут релизнулась новая версия.

Решил разобрать, что изменилось и описать здесь основное, на мой взгляд:

📌 Улучшили обработку и вывод ошибок, warnings при биндинге событий. Кроме того, теперь будет показываться warning, если в шаблоне объявлена переменная через @let, но при этом не используется.

📌 Добавили схематик для миграции роутинга - eagerly loaded standalone компонентов на lazy loaded. Для этого надо запустить команду:

ng generate @angular/core:route-lazy-loading

📌 Добавили схематик, преобразующий существующий код с использованием constructor-based injection на функциональный способ инжектирования. Миграция не является обязательной, и команда Angular прямо заявила, что инжектирование с помощью конструктора будет поддерживаться в будущем. Вызывается командой:

ng generate @angular/core:inject-migration

📌 В тестах теперь в fakeAsync() автоматически в конце будет вызываться flush():

it('should do something', fakeAsync(() => {
  // ...
  // no flush() or discardPeriodicTasks() required!
}, { flush: true }));

📌 В новой версии в конфигурации ProvideRouter() возможно указать стратегию обработки queryParams по умолчанию для всех маршрутов. Сейчас параметр по умолчанию replace изменяется только через RouterLink` или `router.navigate.

provideRouter(routes, withRouterConfig({ defaultQueryParamsHandling: 'merge' }));

#angular

Ссылка на релиз

Оператор безопасного присваивания?

Недавно был представлен пропозал для ECMAscript - оператор безопасного присваивания.

Суть его работы в том, что он преобразует полученный результат в кортеж. Например, если функция завершилась успешно, то получаем [null, result]. Если с ошибкой, возвращается [error, null]. Немного прослеживается аналогия с Go,Swift, Rust. Предложение вызвало споры о том, насколько это вообще нужно и насколько удобно.

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

const [error, response] ?= await fetch("https://api.example.com/data")

const [validationError, data] ?= validator.parse(json);

if (validationError) {   
  handleValidationError(validationError);
  return;
}

return data;

Оператор задизайнен для работы с промисами, async/await, с оператором using.

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

📌 Получаем больше бойлерплейта с if/else для каждого оператора (fetch, parse и тд). При этом конструкция не заставляет обрабатывать исключения. Как и в случае с try/catch, синтаксис не обязывает это делать.
📌 Еще один способ делать одно и тоже, вместо стандартизации одного подхода.
📌 Отсутствие сигнатуры типов. Как обрабатывать ошибки разного типа? В случае интеграции c TS, компилятору не будет понятно, что за тип ошибки возвращается и как ее обрабатывать.

Что же, поглядим, пропозал пока даже не в основном репозитории комитета TC39.

#js

Новости Material

Я не слежу пристально за Material, поскольку в ежедневной работе использую другой ui-kit. А оказывается зря, здесь такие нововведения!😅

📌 В свежей версии 18.2.0 добавили свойство (input) disabledInteractive, который, в отличие от свойства disabled, позволяет отлавливать события и фокус на элементе.

Это может быть полезно, например, если вы хотите показать тултип (matTooltip), но внешне элемент должен отображаться, как disabled. Нововведение исправит огромную проблему для скринридеров при работе с disabled элементами. Крайне рекомендую к использованию. Работает даже с VoiceOver! Еще один шаг в сторону доступности!

И еще одна, не менее важная доработка!

📌 Добавили поддержку drag&drop для обеих осей одновременно! Появился параметр «mixed». Раньше cdk поддерживал перетаскивание по горизонтали или по вертикали. И делается это с помощью CSS transform, а набор элементов обычный массив. Новый способ производит изменения непосредственно в DOM, что позволяет переносить объект на следующую строку.

Я помню, что на одном из проектов было большой проблемой и приходилось писать много дополнительного кода и анимаций, чтобы решение смотрелось приемлемо при перетаскивании элементов.

#material

Standalone по умолчанию

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

После релиза 14 версии и добавления standalone компонентов, CLI и сами разработчики указывали параметр standalone: true для написания приложения, не использующего модули. Кстати, я писал о своем опыте миграции на standalone. Можете прочитать, если интересно.

После релиза 19 версии делается следующий шаг, как говорит команда Angular. Теперь значение флага по умолчанию будет false, если необходимо использовать NgModule. Подчеркивается, что модули не переходят в статус deprecated. По крайней мере, пока что😉

При обновлении будет автоматическая миграция, в ходе которой удалится флаг standalone: true для существующих standalone сущностей и добавится standalone: false для NgModule. При желании можно включить режим компилятора strictStandalone для генерации только таких компонентов. Я раньше не слышал об этом, вы тоже? 🤔

#angular

Что еще ожидается от предстоящего обновления?

Был представлен примитив afterRenderEffect().

Эта штука полностью замещает случаи, где нужно использовать effect(). Кроме того, как я понял по содержимому комита, API позволяет создавать effects для работы с DOM элементами. При этом Angular будет оптимизировать подобные вызовы.

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

#angular

Всем привет! Я был в отпуске и немного забросил написание постов. За это время вышло несколько новостей, которые я решил объединить.

📌 19 версия Angular будет представлена с новыми схематиками. Pre-release версия уже их содержит.
Первый обновляет @Input, а второй DOM Queries на сигнальные.

ng generate @angular/core:signal-input-migration

ng generate @angular/core:signal-queries-migration

📌 Кроме того, из dev preview выйдут input, output, model API.

📌 И еще одна заметная новость! Для material добавили компонент TimePicker! Я сначала попытался найти его в разделе DatePicker. Я предположил, что время сделают, как опциональный параметр даты. Но нет, нужно пролистать ниже, это отдельный полноценный элемент.

Пару-тройку лет назад, на многих проектах, с использованием Material, picker добавляли отдельным пакетом. Я думаю, что все помнят и сейчас с грустью или радостью читают этот пост. Мне понравился внешний вид picker, можно в autocomplete-режиме выбрать нужное время. Но у меня уже получилось крашнуть страницу с примером - при выборе секунды, как интервала времени. Я надеялся, что, в этом случае, добавится отдельный инпут, изменится отображение. Но, посмотрев код, понял, что это не так. Отправил обратную связь команде.

#angular #material

Ограничения Clipboard API

Мы привыкли, что во многих веб приложениях пользуемся буфером обмена. Google Docs, Figma и тд. Для его добавления существует Clipboard API. Этим я и пользовался на одном из проектов для реализации копирования и вставки текста и картинок. Тогда не задумался об ограничениях, т.к. ничего сверхъестественного не требовалось, а сейчас нашел статью об API и его особенностях.

Оказывается, что буфер обмена хранит данные в разных представлениях, поэтому скопированный текст будет отличаться при вставке на сайте и VS Code, например. Из особенностей, которые я отметил для себя, сказано, что, по соображениям безопасности, могут быть обработаны только типы данных: text/plain, text/html и image/png. Причем раньше типов было больше, а ограничения ввели позднее.

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

Alex Harri рассказывает про API, показывает примеры. Отличный, подробный гайд.

#js

Обновления работы effect()

Команда Angular озвучила вчера то, какие изменения нас ждут.

Сейчас API effect() запрещает изменять сигналы внутри функции effect(), намекая, что для этого лучше использовать computed(). Или добавлять специальный флаг allowSignalWrites. На примере ниже это показано.

from = signal('Hamburg');
to = signal('Graz');

effect(() => {
    this.to.set(this.from());
}, { allowSignalWrites: true })

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

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

Как мы видим, немного обновились принципы. Есть то, на что стоит обратить внимание. Например, при работе с DOM элементами, формами, учитывать очередность выполнения. Подробнее по ссылке.

#angular #signals

Время анонсов!

📌 Уже послезавтра состоится Angular Event, на котором должны представить новую версию!

Ставьте 👍🏻, кто планирует смотреть трансляцию! Подключаемся в 21:00.

📌 Кроме того, Microsoft выпустила статью в блоге о бете TS 5.7. Из особенностей я бы отметил:

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

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

- Добавление поддержки новых возможностей ECMAScript 2024

#angular #typescript

Enum или сплошное разочарование

Мы знаем некоторые особенности работы с enum. Например, объявление через const enum, что позволяет сделать меньше бандл, а TS напрямую обращаться к свойствам. Столкнувшись опять с несовершенством enum, я решил показать пару примеров, где использовать его не стоит.

1. Для типизации параметров функций. Здесь должна возникнуть ошибка, но фактически ее нет.

const enum StatusEnum { approved = 1, declined = 0 }

function checkStatus(param: StatusEnum) {
  console.log(param);
}

let x: number = 10;
checkStatus(x);

Это поведение объясняется тем, что типу enum с числовым значением можно присвоить любое число. Поэтому он небезопасен. Такая конструкция разработана, чтобы допускать структуры битовых флагов. Грубо говоря, это оптимизация хранения логических значений. Каждый бит в числе - отдельное значение. Для управления битами создаются enum с числами (где есть каждый флаг по отдельности) и потом комбинируются между собой. Результат объединения флагов в один не обязательно одно из чисел, которое есть в enum. Поэтому, если создать переменную с типом enum, то C# допускает хранить число соответствующей размерности, а TS позволяет объявить переменную с типом вашего enum и присвоить ей любое число.

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

2. Типы enum со строковыми значениями имеют номинальную типизацию, вместо структурной. В примере ниже будет ошибка, несмотря на то, что строка "эквивалентна" enum. Но это не так, потому что для работы с битовыми полями enum дает доп слой безопасности.

enum Flavor {
 VANILLA = 'vanilla',
 CHOCOLATE = 'chocolate',
 STRAWBERRY = 'strawberry',
}
function scoop(flavor: Flavor) { /* ... */ }
scoop('vanilla'); // Ошибка

По этой же причине разные enum нельзя присвоить друг другу:

enum PackStatus {
  Draft = "Draft",
  Approved = "Approved",
}
enum PackStatus2 {
  Draft = "Draft",
}

const logStatus = (status: PackStatus) => {...};
logStatus(PackStatus2.Draft); // Ошибка

Подобные детали работы с enum давно известны, но здесь я решил для себя структурировать в один пост и дать ответ на вопросы. А выводы изложить в виде кода.

// Если нужно объявить набор строковых параметров, используйте string union
type Country = 'Russia' | 'Finland' | 'Germany';
function printCountry(country: Country) {}

// Если нужен mapping между ключами и ззначениями, используйте 'as const'
const Countries = {
  Russia: 'RU',
  Finland: 'FI',
  Germany: 'DE',
} as const;

// Тип с доступными ключами
type CountryKeys = keyof typeof Countries;
// "Russia" | "Finland" | "Germany"

// Тип с доступными значениями
type CountryValues = typeof Countries[CountryKeys];
// "RU" | "FI" | "DE"

Как пишете вы? Не стесняйтесь комментировать, скидывать свои примеры.

#typescript

Анонсы пятницы

На прошлой неделе команда Angular сильно удивила.

📌 Сначала представили Incremental Hydration для компонентов, который, скорее всего, добавят в 19 версии.
Я не работал никогда с SSR, но, как я понял, подход повышает производительность и улучшает метрики Core Web Vitals.

Грубо говоря, гидратация — это процесс, в ходе которого статически сгенерированный HTML, полученный с сервера, "оживает", благодаря JS. Это позволяет пользователям взаимодействовать с контентом, не дожидаясь полной загрузки. Минус в том, что процесс ресурсоемкий, при этом время отклика замедляется.
А представленный механизм позволяет загружать те части приложения, которые нужны в первую очередь. Напомнило lazy loading или deferrable views, если смотреть RFC. Пример из комментариев, объясняющий принцип работы:

Есть список элементов. Если не знаем, будет ли пользователь взаимодействовать с элементом, помещаем его в defer блок с синтаксисом гидратации. В этом случае элемент отобразится, но код для компонента загрузится по мере необходимости. Если контент статичный, то помещается в блок hydrate never.

📌 Анонсирован Resource API. Это способ работы с запросами, удобно интегрированный с сигналами.

Мы можем прокидывать в resource сигналы в виде параметров. Resource имеет тип Resource<T>, который включает сигналы для хранения текущего состояния. WritableResource расширяет этот тип, чтобы позволить локальные преобразования resource через значение сигнала (двусторонняя привязка).
Кроме того, API позволяет
- конвертировать результат работы в Observable,
- отклонять предыдущий запрос, если значение сигнала изменилось.

Подробности по ссылке. Все три примитива resource, rxResource, toResource будут доступны в developer preview в Angular 19.

Я заметил, что подход нацелен на работу с промисами. Потому что по умолчанию работает именно с ними. На мой взгляд, это шаг в сторону отказа от RxJS. Постепенный отказ от библиотеки и желание не делать жесткое связывание нового API на работу с ними. А вы заметили?

#angular

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

https://www.angularspace.com/angular-friction-points/

#angular

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

Автор считает, что невозможно научиться ясно выражать свои мысли и думать, без умения изложить их на письме (привет голосовые сообщения? 😅), при этом с развитием генеративных AI люди будут все реже писать что-то сами.

По мнению Пола, через пару десятилетий, мир может разделиться на тех, кто умеет писать и тех, кто не умеет совсем, т.е. исчезнет золотая середина из людей, кто может не идеально, но писать о чем-либо (мысли, статьи, что-то серьезнее).
Он приводит цитату американского ученого компьютерщика и математика Лесли Лэмпорта (Leslie Lamport):

If you're thinking without writing, you only think you're thinking.

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

So there are still strong people, but only those who choose to be.

Что думаете по этому поводу, господа и госпожи (господыни)?

Команда Angular (совместно с авторами Angular Space community) обновят весьма устаревший style guide!

На прошлой неделе RFC (Request For Comments) был опубликован, просмотреть у меня получилось только на выходных.

Я предполагал, что в гайде покажут стиль работы с новыми API, интеграции с RxJS, работу с конвертацией toSignal() / toObservable() и тд. Но для этого придется ждать последующих обновлений.

Из интересного:

📌 Автор в комментах предлагает помечать свойства класса, которые используются только в шаблонах, как protected и уже сейчас переписать тесты, опираясь на это правило.
📌 Добавление типа сущности в имена (component, service, pipe) - от данного подхода RFC предлагает отказаться, что вызвало бурное обсуждение. На мой взгляд, подобное правило приведет к путанице. Данный подход не должен быть регламентирован в официальном style guide, а принят в конкретном проекте командой/техлидом и изменен, если считаете, что это лучше отразит функциональность.
📌 Рекомендация писать отдельный файл для шаблона, если размер превышает несколько строк - будет убрана. И здесь, конечно же, отсылка к распространению JSX. О DevExp команда предпочла здесь забыть…

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

Чат для обсуждений

#angular

Для тех, кто еще не знает, анонсирован Angular Developer Event, на котором состоится выход 19 версии.

В вторник 19 ноября в 20:00 MSK. На скрине дата неправильная.

А чего бы вы хотели увидеть в новой версии?

На мой взгляд, эта версия скорее минорная. Из основного:

📌 Выход из dev preview многих фичей.
📌 Resource API. Experimental mode. В целом, сомнительный подход.
📌 Incremental hydration.
📌 Улучшение HMR (кто не знает, это обновление шаблонов, стилей без полной перезагрузки приложения).

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

#angular

Что с ресурсами?

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

Ресурс состоит из функции loader(), возвращающей Promise и опционального сигнала. Функция срабатывает при инициализации ресурса и при изменении параметров сигнала.

cities = resource({
  request: () => ({ id: this.id() }),
  loader: (param) => {
    return this.service.findCity(param.request);
  }
});

Новое API:
📌 обладает семантикой switchMap. Другими словами, предыдущие запросы будут отклонены и возвращены последние запрашиваемые данные.
📌 позволяет удобно обрабатывать ошибки и состояние загрузки. Можно просто обратиться к ресурсу и получить состояние.

this.cities.isLoading;
this.cities.error;

📌 присутствует совместимость с RxJS.

Преимущества
1. Позволяет легко управлять состоянием загрузки, успешного завершения и ошибок без необходимости писать собственные велосипеды.
2. Возможная интеграция с Angular Forms. Это было бы круто связать данные между формами и асинхронными источниками. Есть в сети примеры с linkedSignal и формами.
3. Кэширование данных, что может значительно повысить производительность приложения, уменьшая количество запросов к серверу.

// EditUserComponent
userId = input<string>();
userRes = rxResource({
  request: () => ({ id: this.userId() }),
  loader: (param) => this.service.getUser(param.id);
})
form = {
  name: linkedSignal(() => this.userRes.value().name),
  email: linkedSignal(() => this.userRes.value().email)
};

Недостатки
📌 Снова получаем 1000 и 1 способ сделать одно и то же.
Противоречие существующему HttpClient. Очень интересно, представят ли в следующих версиях отдельный HttpClient с тем же API, но возвращающим Promise?
📌 Будет ли такая гибкость, как у RxJS? Пока что есть ощущение, что придется преобразовывать туда/обратно, что приведет к невообразимому количеству бойлерплейта. Если хотели уменьшить порог входа, то получили пока ровно обратное.
Пример, как на фото в комментариях, лично для меня сложно читаем. Это то, что ждут от Angular сейчас? Чтобы не тратить часы на разбор, цель в примере: получить список городов по запрашиваемому году основания.

Чат для обсуждений

#angular

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

И уже есть МР, добавляющий поддержку глобального this для шаблонов.

Возвращение к AngularJS? Что вы думаете об этом?

И, еще из недавних обновлений, прочитал на выходных, что LinkedSignal все-таки будет в dev preview, (не experimental) в 19 версии.

Чат для обсуждений

#angular

Привет!

Мы знаем, что вы до сих пор спите и видите сны на TypeScript! 🌟
Мы прекрасно знаем, как вы любите Angular. Сейчас ещё есть возможность зарегистрироваться на Angular Meetup #23.

Мы будем обсуждать текущее состояние Angular и что нас ждет. Узнаем, сколько версий фреймворка нужно пропустить, чтобы считать свой проект устаревшим. 👩‍💻

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

✅ Если ты с нами
1️⃣ Регистрируйся здесь
2️⃣ Добавляй напоминание в календарь
3️⃣ Поделись этим сообщением с друзьями - чем больше нас будет, тем веселее!

Если не получится прийти на митап, можно посмотреть трансляцию онлайн.

Angular 19 вышел

Что нового? Я подчеркнул основные фичи, на мой взгляд.

📌 Поддержка TS 5.7
📌 Теперь в статусе stable: takeUntilDestroyed, signal quieries, model, inputs, outputToObservable, outputFromObservable, @let
📌 Добавлены схематики для конвертации @Input , DOM queries на сигнальные.

ng generate @angular/core:signal-input-migration
ng generate @angular/core:signal-queries-migration



📌 Добавлен afterRenderEffect() замещает случаи, где нужно использовать effect(). позволяет создавать эффекты для работы с DOM элементами. При этом Angular будет оптимизировать подобные вызовы.
📌 При обновлении будет автоматическая миграция, в ходе которой удалится флаг standalone: true для существующих standalone сущностей и добавится standalone: false для NgModule. При желании можно включить режим компилятора strictStandalone для генерации только таких компонентов.
📌 Добавлено свойство для обнаружения неиспользуемых импортов standalone сущностей. Опция включается в tsconfig.

{ "angularCompilerOptions": {
    "extendedDiagnostics": {
      "checks": {
        "unusedStandaloneImports": "suppress"
      }
    }
  }
}



📌 Добавлено новое Incremental Hydration API.
📌 Добавлен input в RouterOutlet, который позволит передавать данные из родительского компонента в компоненты вывода. Значение будет доступно для дочерних компонентов через токен ROUTER_OUTLET_DATA.

Подробнее по ссылке

#angular