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

• 9 апреля, 20:00. Angular без RxJS? Пишем реактивные формы на сигналах
  ^{Открытый урок курса «Angular-разработчик»}

• 13 апреля, 20:00. Flutter GenUI: когда ИИ-агент собирает ваш интерфейс
  ^{Открытый урок курса «Flutter-разработчик»}

• 15 апреля, 18:00. Основы протокола HTTP
  ^{Открытый урок курса «Проектирование API»}

• 20 апреля, 20:00. От интерфейса до корзины: создаём мини интернет-магазин на языке JavaScript
  ^{Открытый урок курса «JavaScript-разработчик. Базовый уровень»}

• 21 апреля, 20:00. Архитектура Angular-приложения: как писать масштабируемый frontend
  ^{Открытый урок курса «Angular-разработчик»}

Полный список бесплатных уроков апреля смотрите в дайджесте.

KeyValueDiffers позволяет создать KeyValueDiffer для сравнения изменений текущих пар ключ-значение с новыми. Если вы используете иммутабельные объекты, то можно просто обернуть все в эффект, ну а если вы наследники крутого легаси, где все объекты мутируются по ссылке, тогда проверку нужно вешать в DoCheck, чтобы реагировать на каждый тик change detection.

Накидал оба примера, чтобы поделиться с вами:

Иммутабельный с effect:

@Component({
  selector: 'app-test',
  template: ''
})
export class TestComponent {
  public state = input.required<Record<string, string | number>>();
  
  private differs = inject(KeyValueDiffers);
  private differ: KeyValueDiffer<string, string | number> | undefined;

  constructor() {
    effect(() => {
      const currentState = this.state();
      
      // создаем диффер, если он еще не создан
      if (!this.differ) {
        this.differ = this.differs.find(currentState).create();
      }

      // Эффект будет перезапускаться при изменении инпут-сигнала.
      const changes = this.differ.diff(currentState);

      // только если есть изменения
      if (changes) {
        changes.forEachAddedItem((record) => {
          console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`)
        });

        changes.forEachChangedItem((record) => {
          console.log(`Изменено: ${record.key} | Новое значение: ${record.currentValue}`)
        });

        changes.forEachRemovedItem((record) => {
          console.log(`Удалено: ${record.key}`)
        });
        
        // Остальные методы forEachItem и forEachPreviousItem по необходимости
      }
    })
  }
}

Легаси подход, которого, надеюсь, ни у кого нет, но на всякий случай :)

@Component({
  selector: 'app-legacy',
  template: ''
})
export class LegacyComponent implements OnInit, DoCheck {
  @Input({ required: true }) state!: Record<string, string | number>;
  
  private differs = inject(KeyValueDiffers);
  private differ: KeyValueDiffer<string, string | number> | undefined;

  ngOnInit() {
    // Создаем диффер при инициализации
    this.differ = this.differs.find(this.state).create();
  }

  // Запускается на каждый тик change detection, так как мутации по-другому не отследим.
  ngDoCheck(): void {
    const changes = this.differ?.diff(this.state);

    if (changes) {
      changes.forEachAddedItem((record) => {
        console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`)
      });

      changes.forEachChangedItem((record) => {
        console.log(`Значение изменилось: ${record.key}`)
      });

      changes.forEachRemovedItem((record) => {
        console.log(`Запись удалена: ${record.key}`)
      });

      // Остальные методы forEachItem и forEachPreviousItem по необходимости
    }
  }
}

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

Автор условно говорит, что у нас есть плохой пример использования:

this.http.get('/api/data').subscribe((data) =>; {
  this.data = data; // Что если запрос не вернётся?
});

и затем приводит хороший пример с сигналами и RxJs:

readonly data = signal([]);
readonly error = signal(null);

loadData() {
  this.http.get('/api/data').pipe(
    tap(() =>; this.error.set(null)), // Сбрасываем предыдущую ошибку перед загрузкой
    catchError((err) =>; {
      this.error.set('Не удалось загрузить данные');
      return of([]); // Возвращаем пустой массив, чтобы поток не прерывался
    })
  ).subscribe((result) =>; {
    this.data.set(result);
  });
}

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

interface State<T = object> {
  data: T[];
  error: string | null;
}

@Component({...})
export class BestRxJs {
  private http = inject(HttpClient);
  private loadDataAction$ = new Subject<void>();

  private state$ = this.loadDataAction$.pipe(
    switchMap(() => 
      this.http.get<State[]>('/api/data').pipe(
        map((result) => ({ data: result, error: null })),
        catchError(() => of({ data: [], error: 'Не удалось загрузить данные' })),
        startWith({ data: [], error: null })
      )
    ),
    shareReplay({ bufferSize: 1, refCount: true })
  );

  readonly private state = toSignal(this.state$, {
    initialValue: { data: [], error: null } 
  });

  readonly protected data = computed(() => this.state().data);
  readonly protected error = computed(() => this.state().error);

  protected loadData(): void {
    this.loadDataAction$.next();
  }
}

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

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

Часто мы по инерции делаем public любые методы и свойства, которые нужны в шаблоне (HTML). Но public в TypeScript означает, что это публичный API компонента - к этим методам может получить доступ любой родительский компонент через @ViewChild.

Почему стоит использовать protected:

1. Явное намерение: protected сигнализирует, что метод предназначен для использования внутри класса или в его шаблоне, но не должен вызываться извне.

2. Защита от регрессии: Если другой разработчик попытается вызвать такой метод через @ViewChild, TypeScript выдаст ошибку. Это заставит его задуматься: «Действительно ли мне нужно делать этот метод публичным?» или «Может, стоит создать отдельный метод для API?».

3. Читаемость: Открывая код, вы сразу видите: public - для внешнего мира, protected - для шаблона, private - для внутренней логики сервисов и подписок.

Разделяйте Public API и внутреннюю логику шаблона - ваш код станет надежнее и понятнее.

@Component({
  selector: 'app-user-profile',
  template: `
    <!-- В шаблоне мы без проблем обращаемся к protected свойствам -->
    <div class="card">
      <h3>{{ userName() }}</h3>
      <button (click)="onUpdateClick()">Обновить</button>
        @if(isLoading()) {
          <div>Загрузка...</div>
        }
    </div>
  `
})
export class UserProfileComponent {
  // PRIVATE: Внутренняя логика. 
  // Не доступно ни в шаблоне, ни родительскому компоненту.
  private _userId = 123;

  // PROTECTED: Доступно только внутри класса и в ШАБЛОНЕ.
  // Идеально для переменных состояния UI и обработчиков событий.
  protected userName = signal('Алексей');
  protected isLoading = signal(false);

  protected onUpdateClick(): void {
    this.logAction();
    console.log('Кнопку нажали в шаблоне');
  }

  // PUBLIC: Публичный API компонента.
  // Только эти методы мы разрешаем вызывать родительскому компоненту.
  public resetState(): void {
    this.userName.set('Гость');
    this.isLoading.set(false);
  }

  private logAction(): void {
    console.log(`Action logged for userId: ${this._userId}`);
  }
}

Буду рад фидбеку и баг-репортам (проект активно допиливаю).

Ссылка на курс: https://rxjs-course-avy.web.app/

Приглашаем на бесплатный вебинар «Эффективное использование RxJS в Angular: шаблоны, подходы, лучшие практики».

📅 Дата: 15.07.2025

⏰ Время: 17:00-18:00 (Мск)

Этот семинар углубит ваши знания в RxJS и Angular. Вы изучите, как организовать потоки данных, управлять подписками, избегать утечек памяти и эффективно настроить change detection. Мы рассмотрим полезные RxJS-операторы, частые ошибки и лучшие практики. Обсудим, как выстраивать архитектуру на основе RxJS, использовать AsyncPipe и делить компоненты на умные и глупые.

На вебинаре:

✔️ Как устроен RxJS под капотом.

✔️ Проблемы RxJS в реальных приложениях.

✔️ Tестирование потоков.

✔️ Лучшие практики и архитектурные паттерны.

✔️ Работа с операторами.

✔️ Работа с данными в реальном времени.

✔️ Кастомные операторы.

✍️Записаться

Кнопка 'Загрузить еще' (либо автоматическая подгрузка данных при скролле) довольно часто встречается в проектах и обычно решение связано с большим количеством подписок и переменных.

Как всегда, для оптимизации чего либо нам на помощь приходит великий и могучий RxJS, а в данной ситуации конкретно операторы scan & mergeScan.

Код:

  readonly loadTrigger$ = new Subject<void>();
  private readonly batchSize = 5;

  private readonly posts$ = this.loadTrigger$.pipe(
    startWith(void 0),
    scan((offset) => offset + this.batchSize, -this.batchSize),
    mergeScan(
      (accPosts: Post[], offset: number) =>
        getPosts(offset, this.batchSize).pipe(
          map((newPosts) => [...accPosts, ...newPosts]),
        ),
      [] as Post[],
    ),
  );

1. scan – калькулятор + хранитель состояния для offset:

   • Управляет состоянием загрузки (текущее смещение)

   • Начинается с -batchSize, чтобы первая загрузка была с 0

   • Увеличивает смещение на batchSize при каждом срабатывании

2. mergeScan – волшебный оператор для инкрементальной загрузки:

   • Сохраняет массив накопленных постов

   • Объединяет новые данные с существующими

   • Корректно обрабатывает параллельные запросы (в отличие от обычного scan)

Где полезен этот паттерн?

• Постраничные API (пагинация)

• Бесконечная прокрутка

• Порционная загрузка данных

• Любые сценарии накопления асинхронных данных

scan - https://rxjs.dev/api/operators/scan
mergeScan - https://rxjs.dev/api/operators/mergeScan
Больше об Angular - https://t.me/grandgular

В Angular 20 afterRender был переименован в afterEveryRender, и это очень логично, так как теперь он более четко отражает суть (нейминг решает). Сам afterRender (далее afterEveryRender) и его брат afterNextRender появились в версии 17. Рассмотрим, почему эти два мощных инструмента управления рендерингом — не просто альтернативы ngAfterViewInit, а полноценные хуки жизненного цикла с бесшовной поддержкой SSR!

Это хуки?
Да! Это хуки нового типа, которые выполняются после рендеринга компонента:

• Они не заменяют ngAfterViewInit/ngAfterContentInit, а дополняют их

• Включают гранулярные реакции на рендеры, включая обновления

Почему идеально подходит для SSR?
Главное преимущество: обратные вызовы выполняются только на клиенте!
✅ После гидратации (в SSR)
✅ После первоначального рендеринга (в CSR)
✅ Больше никаких ошибок «документ не определен»

Использование:
constructor() {
// 🚫 Не запускается на сервере
// ✅ Запускается только один раз после загрузки браузера!
// 📊 Идеально подходит для однократной инициализации
afterNextRender(() => {
console.log('Next');
});

// 🚫 Не запускается на сервере
// 🔄 Запускается после каждого цикла обнаружения изменений
// ✨ Отлично подходит для обновлений, зависящих от DOM
afterEveryRender(() => {
console.log('Every');
});
}

Когда использовать?

afterNextRender

• Одноразовые операции (инициализация библиотеки, загрузка данных)

• Безопасная замена ngAfterViewInit для SSR

afterEveryRender

• Отслеживание изменений DOM (измерения элементов, позиции)
  
  ⚠️ Внимание: может повлиять на производительность

Основные выводы

• Интегрировано в систему жизненного цикла Angular

• Автоматический пропуск на стороне сервера - больше никаких хаков isPlatformBrowser!

• afterNextRender - "один раз после рендеринга"

• afterEveryRender - "после каждого обновления"

"Я пока не использовал afterEveryRender в своих проектах - есть ли у вас практические примеры использования? Поделитесь в комментариях!"

Больше об 🅰️ngular в моём Telegram-канале

Как было раньше?

1. Создаем переменную/свойство (Signal, BehaivorSubject, Observable, неважно)

2. Инжектим и подписываемся на ActivatedRoute

3. Получаем параметры маршрута

4. Записываем в BS/Signal

😵‍💫😵‍💫😵‍💫

Манипуляций довольно много, но мы все к этому привыкли и это кажется нормальным.

Но с withComponentInputBinding() все стало намного проще:
1. Создаем сигнальный инпут... и...
Вот и все!

Никаких дополнительных манипуляций, и значение «у вас в кармане». Все, что вам нужно, чтобы это работало, — это передать withComponentInputBinding() в качестве аргумента в provideRouter().

Функция не новая (кажется, появилась в Angular 16), но я редко ее видел в проектах.

Немного технической информации из документации:

🔍Маршрутизатор передает данные в input() из:

1. Параметров запроса (?page=1&sort=asc)

2. Параметров пути и матрицы (/users/123;details=true)

3. Статических данных маршрута (data: { role: 'admin' })

4. Результатов резолвера (resolve: { user: userResolver })

🔍 Приоритеты:
Если есть дублирующиеся ключи, данные переопределяются в порядке выше — резолверы имеют наивысший приоритет и перезапишут остальные.

🚩 Важный нюанс
Если в маршруте нет данных для input(), он получит undefined (например, если параметр запроса удален из URL).

ℹ️ Как задать значения по умолчанию?

✔ Через resolver (чтобы данные всегда были в маршруте)
✔ Через transform в input() (если нужно обрабатывать undefined)

Спасибо разработчикам Angular за эту функциональность 🙏.

Больше об 🅰️ngular в моём Telegram-канале

defer — это фабрика, которая создает Observable только при подписке, а не во время объявления. Идеально подходит для:

• HTTP-запросов (чтобы избежать преждевременного выполнения)

• динамических данных (которые должны быть свежими при каждой подписке)

• условных потоков (когда Observable зависит от состояния времени выполнения)

📌 Основные варианты использования

1. Свежие данные при каждой подписке

   const freshData$ = defer(() => of(Date.now()));

   // Новая временная метка при каждой подписке()

2. Работа с изменяемым состоянием

   const token$ = defer(() => of(localStorage.getItem('token')));

   // Всегда получает текущий токен, даже если обновлен

3. Условные наблюдаемые

   const api$ = defer(() => isLoggedIn ? http.get('/user') : http.get('/guest') );

4. Генерация случайного значения

   const random$ = defer(() => of(Math.random()));

   // Новое случайное число на подписку

🚫 Ограничения defer

• нет кэширования → используйте shareReplay, если вам нужно повторно использовать результаты.

• нет отмены запроса → объедините с switchMap/takeUntil для управления отменой

⚡Когда следует выбирать defer вместо обычных наблюдаемых?

• данные должны быть свежими при каждом subscribe()

• cоздание наблюдаемого стоит дорого и должно быть отложено

• поток зависит от изменяемых условий (флаги функций, статус аутентификации и т. д.)

Больше об 🅰️ngular в моём Telegram-канале

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

И вот, как-то я в очередной раз писал подобные строки:

isOpened = signal(false);

toggle() {

  this.isOpened.update(value => !value);

}


#isOpenedEffect = effect(() => {

  console.log('New state:', this.isOpened())

})

- и подумал: 'Было бы удобно, если бы был булевый signal с методом toggle'

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

Пример, согласен, так себе. 

👍🏼 меньше кода, более аккуратно

👎🏼 всей команде придется подстроится

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

💬 А какого сигнала не хватает вам?

Больше об 🅰️ngular в моём Telegram-канале

Если вы используете shareReplay(1) в RxJS, будьте осторожны — в некоторых случаях это может привести к утечкам памяти! Давайте разберёмся, почему так происходит и как это исправить.

❌ Проблема с shareReplay(1). По умолчанию:

• Сохраняет последнее значение в бесконечном буфере, даже если подписчиков больше нет

• Не отписывается от источника, когда никто не слушает (например, interval, Subject, HTTP-запросы)
  Это означает, что данные могут накапливаться, а ненужные Observable продолжают работать в фоне

✅ Решение: shareReplay({ bufferSize: 1, refCount: true })

• Добавление refCount: true решает проблему:

• Автоматически отписывается, когда не остаётся подписчиков

• Очищает буфер, предотвращая утечки памяти

💡 Ключевые выводы:

1. shareReplay(1) - Может оставлять "висящие" подписки

2. shareReplay({ bufferSize: 1, refCount: true }) - Безопасная альтернатива

Я обнаружил эту проблему во время code review вчера, а впервые узнал о ней из видео Dmytro Mezhenskyi.

🔗 P.S. Самое время быстро исправить это в наших проектах!)

Больше об 🅰️ngular в моём Telegram-канале

Вы знаете mergeMap, concatMap, exhaustMap и switchMap — но знали ли вы, что только один из них принимает второй аргумент?

👉 mergeMap уникален благодаря параметру concurrent, который ограничивает параллельные подписки. Это как "регулятор скорости" для ваших Observable.

_____

Пример использования (контролируемая загрузка файлов):

Представьте, что вам нужно:
1️⃣ Обработать несколько файлов
2️⃣ Избежать перегрузки браузера/API
3️⃣ Сохранить порядок загрузки

В этом случае второй аргумент mergeMap становится незаменимым:

from(fileList).pipe(
  mergeMap(
    file => uploadFile(file), // функция загрузки
    3                        // одновременно только 3 файла
  )
).subscribe();

_____

Преимущества mergeMap с concurrent:
✅ Предотвращает перегрузку API
✅ Оптимизирует нагрузку на сеть
✅ Сохраняет отзывчивость интерфейса
_____

Знали ли об этой возможности? 😉

Больше об Angular в телеграмм-канале

Бывают случаи, когда нужно, чтобы определенные методы работали только:

• 🛠️ В dev-режиме (например, фича-тогглы, дебаг-логи, экспериментальные функции)

• 🚀 В prod-режиме (аналитика, мониторинг, продакшен-логика)

Вместо того чтобы писать if (isDevMode()) {...} везде, можно использовать декораторы Angular для более чистого и декларативного подхода.

_____

Одно из решений:

export function EnvMode(mode: 'dev' | 'prod') { return function (_: unknown, __: string, descriptor: PropertyDescriptor) { const originalMethod = descriptor.value; descriptor.value = function (...args: unknown[]) { const shouldExecute = mode === 'dev' ? isDevMode() : !isDevMode(); if (!shouldExecute) return; return originalMethod.apply(this, args); }; return descriptor; }; }

_____

Как использовать:

@EnvMode('dev') public setFeatureToggle(): void { // Сработает только в dev-режиме } @EnvMode('prod') public sendAnalytics(): void { // Сработает только в prod-режиме }

_____

🤔 А вы создавали кастомные декораторы? Зачем?

Больше про Angular в тг канале

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

Вот мой способ (по крайней мере, я нигде такого не видел):

@for (_ of [].constructor(10); track $index) {
<div class="item"></div>
}

Используется Array.constructor, чтобы создать пустую массив фиксированной длины, который @for может перебрать по индексам.

Плюсы ✅

• Чудо-код (удивит коллег)

• Минимум кода (не нужно объявлять массив в компоненте)

Минусы ⚠️

• Чудо-код (может ненадолго ввести в ступор чающего код человека)

Конечно, можно просто использовать Array.from({length: 10})... но так все делают, не интересно)

Норм тема? Как считаете?

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

проверить что-то, если все ок то вернуть true или кинуть редирект на другую страницу

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

В 19 же версии нам немного упростили жизнь и резолвер научили в RedirectCommand.

Пример с angular.dev

export const heroResolver: ResolveFn<Hero>= async (
  route: ActivatedRouteSnapshot,
  state: RouterStateSnapshot,
) => {
  const router = inject(Router);
  const heroService = inject(HeroService);
  
  try {
    return await heroService.getHero(route.paramMap.get('id')!);
  } catch {
    return new RedirectCommand(router.parseUrl('/404'));
  }
  
};

Ну просто сказка какая-то, а не только сигналы =)

Fusor это новый способ разработки вэб приложений https://github.com/fusorjs/dom