Урок №5

1. Почему реактивность: от состояния к производным значениям

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

Состояние TaskFlow — это список задач tasks и выбранный фильтр filter. А вот «сколько задач выполнено», «какие задачи показывать при фильтре "активные"», «есть ли задача с данным id» — это уже производные значения: они автоматически следуют из состояния и не хранятся отдельно.

// состояние — храним
readonly tasks = signal<Task[]>([]);
readonly filter = signal<TaskFilter>('all');

// производное — вычисляем из состояния
computed(() => this.tasks().filter(t => t.completed)); // выполненные

Почему это важно? Если вы храните в отдельной переменной счётчик «выполнено» и не обновите его при изменении списка, он устареет. Производные значения исключают эту ошибку: они всегда соответствуют состоянию, потому что пересчитываются из него.

В уроке 4 мы уже использовали signal() и методы-геттеры вроде visibleTasks(). Урок 5 заменит ручной пересчёт на автоматический реактивный механизм.

2. Обзор темы: что мы уже знаем и что добавим

К этому моменту у вас есть база: signal() для состояния (урок 1, 4), методы для вычисления (урок 4) и неизменяемые обновления через map/filter/spread (урок 2). Урок 5 систематизирует реактивность.

3. signal(): создание, чтение и запись

Сигнал — это контейнер, который хранит значение и уведомляет о его изменении. Создаётся через signal(), читается вызовом (), меняется через set()/update().

Контекст. Это базовый пример работы с сигналом: создали счётчик, прочитали, записали новое значение. Так же будет устроен список задач в TaskFlow.

import { signal } from '@angular/core';

const count = signal(0);      // создать со стартовым значением 0
console.log(count());          // прочитать — вызов без аргументов
count.set(5);                  // записать новое значение
console.log(count());          // 5

Что увидит пользователь: в консоли сначала 0, потом 5.

Сигнал типизирован. Тип выводится из начального значения, но его можно задать явно:

Контекст. В TaskFlow список задач — это массив, поэтому тип сигнала Task[]. TypeScript проверит, что вы не запишете туда что-то другое.

const title = signal<string>('Задача');
const tasks = signal<Task[]>([]);

В компоненте сигналы объявляют как поля:

Контекст. Здесь сигнал tasks живёт внутри компонента TaskList, а метод addOne() добавляет задачу неизменяемо (подробно — в разделе 12).

@Component({ selector: 'app-task-list', standalone: true, ... })
export class TaskList {
  readonly tasks = signal<Task[]>([
    { id: 1, title: 'Изучить сигналы', completed: false },
  ]);

  addOne() {
    // update получает ТЕКУЩИЙ массив (cur) и возвращает НОВУЮ ссылку
    this.tasks.update(cur => [...cur, newTask]);
  }
}

Что увидит пользователь: в списке появится новая задача без ручного обновления.

4. set() и update(): два способа обновить сигнал

У любому записываемому сигналу есть два метода изменения значения.

Контекст. Оба метода меняют значение сигнала, но по-разному: set() заменяет целиком, update() строит новое на основе старого. Это пригодится, когда в TaskFlow мы будем переключать фильтр или менять задачу.

// set() — присвоить целиком
this.filter.set('done');

// update() — вычислить новое на основе текущего
this.filter.update(current => current === 'all' ? 'done' : 'all');

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

set() удобен, когда новое значение не зависит от старого — например, выбранный фильтр. update() нужен, когда новое значение получается из текущего: переключение флажка, добавление в массив, изменение одного поля.

5. Writable и readonly сигналы

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

// внутри компонента — можно изменять
private readonly tasks = signal<Task[]>([]);

// снаружи — только читать
readonly tasksSignal = this.tasks.asReadonly();

asReadonly() возвращает сигнал без методов set/update. Это защищает данные от случайного изменения из других мест.

// компонент хранит state, но отдаёт только для чтения
export class TaskList {
  private readonly tasks = signal<Task[]>([]);
  readonly tasksRO = this.tasks.asReadonly();

  toggle(id: number) {
    this.tasks.update(cur => ...); // можно — метод внутри
  }
}

В шаблоне нельзя вызвать set(). Шаблон только читает сигналы; изменения происходят в методах. Это согласуется с принципом «данные вниз» из урока 4.

6. computed(): производные значения

Метод computed() создаёт сигнал, значение которого вычисляется из других сигналов. Когда источники меняются, производное значение пересчитывается автоматически.

Контекст. Самый простой пример: удвоенный счётчик. Когда меняется count, doubled пересчитывается сам.

import { computed, signal } from '@angular/core';

const count = signal(2);
const doubled = computed(() => count() * 2);

console.log(doubled()); // 4
count.set(5);
console.log(doubled()); // 10 — автоматически

Что увидит пользователь: в консоли 4, затем 10 — без ручного пересчёта.

Внутри computed мы читаем сигналы. Angular запоминает эти зависимости и знает, когда пересчитать.

Контекст. Здесь производное значение — список активных задач, который зависит от сигнала tasks.

const tasks = signal<Task[]>([]);
// computed читает сигнал tasks() и запоминает зависимость
const activeTasks = computed(() => tasks().filter(t => !t.completed));

// activeTasks() всегда отражает текущее состояние списка

Внутри computed можно читать несколько сигналов и даже другие computed:

Контекст. Фильтр задач: что показывать — зависит и от списка, и от выбранного фильтра.

const filter = signal<TaskFilter>('all');
const visibleTasks = computed(() => {
  const f = filter();
  if (f === 'active') return tasks().filter(t => !t.completed);
  if (f === 'done') return tasks().filter(t => t.completed);
  return tasks();
});

7. Ленивость и кэширование computed

Computed-сигналы ленивы и кэшируются. Это два ключевых свойства производительности.

• Ленивость. Значение не вычисляется, пока его никто не читает.
• Кэширование. Если источники не менялись, повторное чтение возвращает закэшированный результат без пересчёта.

Контекст. Покажем на примере «тяжёлого» computed, который пишет в консоль при каждом реальном пересчёте, чтобы увидеть кэширование в действии.

const heavy = computed(() => {
  console.log('пересчёт');
  return tasks().filter(...).length;
});

heavy(); // «пересчёт» — первое чтение
heavy(); // тишина — используется кэш
tasks.update(...); // источник изменился
heavy(); // «пересчёт» — снова вычислено

Что увидит пользователь: в консоли «пересчёт» появится только при реальном изменении данных, а не при каждом чтении.

Это выгодно отличает computed от обычного метода-геттера, который пересчитывается при каждом вызове.

8. effect(): побочные эффекты

effect() выполняет функцию каждый раз, когда меняется любой сигнал, прочитанный внутри неё. Это место для побочных эффектов: запись в localStorage, отправка в сервис, логирование.

Контекст. Самый простой эффект — пишет в консоль при каждом изменении фильтра.

import { effect, signal } from '@angular/core';

const filter = signal('all');

effect(() => {
  console.log('Текущий фильтр:', filter());
});
// при первом запуске: «Текущий фильтр: all»
filter.set('done');
// «Текущий фильтр: done» — сработал снова

Что увидит пользователь: в консоли две записи: сначала про «all», потом про «done».

Эффект отслеживает, какие сигналы он прочитал, и перезапускается, когда они меняются.

Контекст. Реальный пример — автосохранение списка задач в браузере, чтобы при перезагрузке данные не пропали.

// сохранение в localStorage при изменении списка
effect(() => {
  // читаем this.tasks() → эффект «подписан» на этот сигнал
  localStorage.setItem('tasks', JSON.stringify(this.tasks()));
});

Что увидит пользователь: сам по себе — ничего на экране, но данные сохраняются «за кадром» и восстановятся после перезагрузки.

9. Когда эффекты уместны, а когда нет

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

Главное правило: для производных значений, которые влияют на отображение, используйте computed(), а не эффект, меняющий другую переменную. Эффект не должен «переворачивать» состояние ради перерисовки.

// ПЛОХО: эффект синхронизирует дубль
const a = signal(1);
const b = signal(a());
effect(() => b.set(a() * 2)); // лишний сигнал и цикл

// ХОРОШО: computed выражает зависимость напрямую
const a2 = signal(1);
const b2 = computed(() => a2() * 2);

10. Чтение сигналов в шаблоне

В шаблоне сигнал читается вызовом со скобками, как и в TypeScript-коде.

Контекст. В шаблоне Angular пишем те же вызовы, что и в коде: {{ ...() }}. Это то, что видит пользователь (DOM).

<h2>Задач: {{ tasks().length }}</h2>
<p>Фильтр: {{ filter() }}</p>
<!-- computed тоже вызывается -->
<p>Активных: {{ activeCount() }}</p>

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

Для списка через @for:

Контекст. Цикл перебирает элементы производного списка visibleTasks() и для каждого рисует дочерний компонент задачи.

@for (task of visibleTasks(); track task.id) {
  <app-task-item [task]="task" />
}

Что увидит пользователь: список карточек задач, соответствующий текущему фильтру.

N.B. В уроке 4 мы передавали [task]="task" из цикла. Здесь visibleTasks() — computed, который читается в шаблоне один раз, а внутри цикла task — уже элемент массива.

Когда источник меняется, Angular перерисовывает только те части шаблона, которые прочитали изменившийся сигнал (подробнее — разделы 11 и 28.3).

11. Перерисовка: когда Angular обновляет DOM

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

Механизм в общих чертах:

1. Компонент создаёт сигнал состояния.
2. Шаблон читает сигнал при рендере. Angular запоминает, какой фрагмент от какого сигнала зависит.
3. Кто-то меняет сигнал через set()/update().
4. Angular знает, что значение изменилось, и обновляет только зависимые фрагменты DOM.

Контекст. Две строки зависят от разных сигналов — Angular обновит только ту, что изменилась.

<p>Всего: {{ tasks().length }}</p>     <!-- зависит от tasks -->
<p>Фильтр: {{ filter() }}</p>        <!-- зависит от filter -->

Что увидит пользователь: при смене фильтра поменяется текст фильтра, а число задач останется прежним (и наоборот).

Если поменяется только filter, Angular обновит вторую строку, а первую не тронет. Это «тонкая» перерисовка, точечная, а не полная перезагрузка страницы.

Существует также классический механизм change detection (CD). Современные сигналы интегрируются с ним, но точную стратегию перерисовки вы можете влиять (например, onPush, урок 13). Для этого урока достаточно понимать идею зависимости «шаблон ← сигнал».

12. Неизменяемость массивов: map, filter, spread

Чтобы Angular заметил изменение, нужно создать новую ссылку на массив, а не мутировать старую. Это мы уже применяли в уроке 4; теперь закрепим как основу реактивности.

Контекст. Три базовые операции со списком задач: добавить, удалить, изменить один элемент — каждая возвращает НОВЫЙ массив (поэтому реактивность срабатывает).

// ДОБАВИТЬ — новый массив с новой задачей
this.tasks.update(cur => [...cur, task]);

// УДАЛИТЬ — новый массив без задачи
this.tasks.update(cur => cur.filter(t => t.id !== id));

// ИЗМЕНИТЬ ОДИН ЭЛЕМЕНТ — map, создающий новые объекты
this.tasks.update(cur =>
  cur.map(t => t.id === id ? { ...t, completed: !t.completed } : t)
);

Что увидит пользователь: задача появится/исчезнет/переключится, и счётчики пересчитаются сами.

Контекст. Показываем, почему «правка на месте» ломает реактивность: ссылка не меняется, и Angular «думает», что ничего не произошло.

// ПЛОХО — мутация, сигнал не узнает об изменении
const list = this.tasks();
list.push(task);
// ссылка та же — Angular может не перерисовать

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

Ключ к пониманию: сравнение ссылок. Новый массив — новая ссылка — сигнал «увидел» изменение. Тот же массив с изменённым содержимым — старая ссылка — реактивность может пропустить изменение.

13. Неизменяемость объектов: spread

Объект внутри массива тоже обновляют копированием через spread, а не присваиванием полю.

Контекст. Переключение флага completed у конкретной задачи — классический пример неизменяемого обновления объекта.

// переключить completed в конкретной задаче
this.tasks.update(cur =>
  cur.map(t =>
    t.id === id ? { ...t, completed: !t.completed } : t
  )
);

Здесь { ...t, completed: !t.completed } создаёт новый объект: сначала распространяются все поля t, затем переопределяется completed.

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

// изменить несколько полей
{ ...task, title: newTitle, completed: true }

// добавить поле (изменить форму объекта)
{ ...task, priority: 'high' }

Старый объект не меняется — он остаётся в памяти, пока нужен. Это делает обновления безопасными и соответствующими принципу неизменяемости из урока 2 и 15 урока 4.

14. Фильтры через computed: все, активные, выполненные

Классическая задача TaskFlow — показать список по фильтру. Реализуем её через computed на основе методов из урока 2 (раздел 9).

Контекст. Один computed visibleTasks решает, какие задачи показывать в зависимости от выбранного фильтра. Значение фильтра — только 'all' | 'active' | 'done'.

type TaskFilter = 'all' | 'active' | 'done';

const tasks = signal<Task[]>([...]);
const filter = signal<TaskFilter>('all');

const visibleTasks = computed(() => {
  const f = filter();
  if (f === 'active') return tasks().filter(t => !t.completed);
  if (f === 'done') return tasks().filter(t => t.completed);
  return tasks();
});

Что увидит пользователь: список подстроится под выбранный фильтр без перезагрузки страницы.

Шаблон использует visibleTasks():

Контекст. В шаблоне просто перебираем уже готовый отфильтрованный список.

@for (task of visibleTasks(); track task.id) {
  <app-task-item [task]="task" />
}

Что увидит пользователь: ровно те задачи, которые соответствуют фильтру.

В уроках 4–5 filter() — это вызов сигнала, а не метод. Две разные сущности: сигнал filter (тип TaskFilter) и метод массива filter(). Не путайте имена.

15. Счётчики через computed: производные от списка

Счётчики «всего / активных / выполнено» — чистые производные от списка.

Контекст. Три счётчики — это по одному computed на каждый показатель. Они считаются из списка задач.

const total = computed(() => tasks().length);
// производное: пересчитывается только при изменении tasks()
const activeCount = computed(() => tasks().filter(t => !t.completed).length);
const doneCount = computed(() => tasks().filter(t => t.completed).length);

В шаблоне статистика:

Контекст. В шаблоне просто выводим значения счётчиков — они всегда актуальны.

<div class="stats">
  <span>Всего: {{ total() }}</span>
  <span>Активных: {{ activeCount() }}</span>
  <span>Выполнено: {{ doneCount() }}</span>
</div>

Что увидит пользователь: три числа, которые меняются сами при отметке задач (например, отметили — «Выполнено» растёт, «Активных» падает).

Счётчики автоматически следуют за списком. Отметьте задачу — doneCount() вырастет, activeCount() уменьшится без единой строчки «обновления счётчика».

16. Поиск через find и reduce в computed

Помимо filter, полезны find и reduce (урок 2, раздел 9).

find: найти одну задачу по id

Контекст. Выбираем одну задачу по её id — например, чтобы показать карточку выбранной.

const selectedTask = computed(() =>
  tasks().find(t => t.id === selectedId()) ?? null
);

find возвращает первый подходящий элемент или undefined. Оператор ?? null нормализует в явный null, если задачи нет.

reduce: посчитать ненулевые приоритеты

Контекст. Считаем, сколько задач с высоким приоритетом — одним проходом по массиву.

const highCount = computed(() =>
  tasks().reduce((acc, t) => acc + (t.priority === 'high' ? 1 : 0), 0)
);

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

reduce сворачивает массив в одно значение. Здесь считаем задачи с приоритетом high.

17. Сортировка через computed

Сортировка — тоже производное значение. Важно не сортировать исходный массив, а работать с копией.

Контекст. Сортируем задачи по приоритету: high выше всего, low ниже всех.

const sortedByPriority = computed(() => {
  const rank = { high: 0, medium: 1, low: 2 };
  return [...tasks()].sort((a, b) => rank[a.priority] - rank[b.priority]);
});

Что увидит пользователь: список, где сначала high, потом medium, потом low.

Заметьте [...tasks()]: spread создаёт копию, и sort() мутирует копию, а не исходный сигнал. Такой подход безопасен.

Контекст. Ещё один пример — сортировка по названию с учётом языка (русского алфавита).

// сортировка по названию (locale-aware)
const sortedByTitle = computed(() =>
  [...tasks()].sort((a, b) => a.title.localeCompare(b.title))
);

Что увидит пользователь: задачи, упорядоченные по алфавиту названий.

18. Каскад computed: производное от производного

Computed могут зависеть от других computed. Это позволяет строить цепочки вывода.

const visibleTasks = computed(() => { ... }); // фильтр
const sortedVisible = computed(() => [...visibleTasks()].sort(...));
const visibleCount = computed(() => sortedVisible().length);

Здесь visibleCount зависит от sortedVisible, тот — от visibleTasks, тот — от исходных сигналов. Изменение любого источника «пробегает» по цепочке.

Angular отслеживает эти зависимости и пересчитывает только то, что изменилось.

19. Сравнение: методы-геттеры и computed

В уроке 4 мы писали методы-геттеры. Разберём разницу с computed.

// метод-геттер — пересчитывается каждый вызов
visibleTasks() { ... }

// computed — кэшируется и реактивен
readonly visibleTasks = computed(() => ...);

Когда годится метод: если вычисление должно выполняться заново при каждом вызове по иной причине (например, время). Для производных значений от сигналов — computed почти всегда лучше.

20. Полный цикл TaskFlow с сигналами

Соберём реактивную модель TaskFlow: состояние в сигналах, производные в computed.

Контекст. Один компонент, где есть список, фильтр, производные списки/счётчики и обработчики событий (toggle, create, filter). Это «скелет» всего приложения TaskFlow.

import { Component, computed, signal } from '@angular/core';
import type { Task, TaskFilter } from '../task';

@Component({ selector: 'app-task-list', standalone: true, ... })
export class TaskList {
  readonly tasks = signal<Task[]>([
    { id: 1, title: 'Изучить сигналы', completed: true },
    { id: 2, title: 'Связать события', completed: false },
  ]);
  readonly filter = signal<TaskFilter>('all');

  readonly visibleTasks = computed(() => {
    const f = this.filter(); // читаем сигнал фильтра → зависимость зафиксирована
    if (f === 'active') return this.tasks().filter(t => !t.completed);
    if (f === 'done') return this.tasks().filter(t => t.completed);
    return this.tasks(); // 'all' — без фильтрации
  });

  // счётчики — производные от списка, пересчитываются сами
  readonly activeCount = computed(() =>
    this.tasks().filter(t => !t.completed).length
  );
  readonly doneCount = computed(() =>
    this.tasks().filter(t => t.completed).length
  );

  onToggled(id: number) {
    // update от текущего массива; map создаёт НОВЫЕ объекты (неизменяемо)
    this.tasks.update(cur =>
      cur.map(t => t.id === id ? { ...t, completed: !t.completed } : t)
    );
  }

  onCreated(title: string) {
    const id = Math.max(0, ...this.tasks().map(t => t.id)) + 1;
    // новый массив со свежей задачей в начале — новая ссылка
    this.tasks.update(cur => [
      { id, title, completed: false },
      ...cur,
    ]);
  }

  onFilterChange(value: TaskFilter) {
    this.filter.set(value);
  }
}

Что увидит пользователь: отмечает задачу — она перемещается между активными/выполненными, счётчики меняются; меняет фильтр — список перестраивается.

Весь «мир» умещается в состояние (сигналы) + производные (computed) + методы-обработчики событий. Шаблон только читает результаты.

Контекст. Шаблон компонента: передаём фильтр вниз, перебираем видимые задачи, показываем счётчики.

<app-filter-bar [filter]="filter()" (filterChange)="onFilterChange($event)" />
@for (task of visibleTasks(); track task.id) {
  <app-task-item [task]="task" (toggled)="onToggled(task.id)" />
}
<p>Активных: {{ activeCount() }} · Выполнено: {{ doneCount() }}</p>

Что увидит пользователь: рабочий экран со списком, фильтром и живыми счётчиками.

21. Связь с React: useState, useMemo, производные

Идея реактивности есть и в React, но синтаксис иной. Проведём параллель (урок 1, раздел 24).

Контекст. Тот же замысел «производное следует за состоянием», но на React выглядит иначе: состояние в useState, производное — в useMemo с явным списком зависимостей.

// React (уроки 15–16, для сравнения)
const [tasks, setTasks] = useState([]);
const visibleTasks = useMemo(
  () => tasks.filter(t => t.completed),
  [tasks]
);

22. Осторожно: мутации и сигналы

Самый частый источник «немой» ошибки — мутировать объект или массив внутри сигнала и не получить перерисовку.

Контекст. Самый частый источник «немой» ошибки: правим объект «на месте» вместо создания нового. Плохой пример меняет поле напрямую; хороший — создаёт новый объект.

// ПЛОХО
const task = this.tasks()[0];
task.completed = true; // мутация внутри объекта
// сигнал не «узнал» об изменении — ссылка не поменялась

// ХОРОШО
this.tasks.update(cur =>
  cur.map((t, i) => i === 0 ? { ...t, completed: true } : t)
);

Ещё одна ловушка — мутировать коллекцию внутри computed:

Контекст. Ещё одна ловушка — мутировать коллекцию внутри computed. Плохой вариант сортирует сам сигнал; хороший — его копию.

// ПЛОХО: sort мутирует массив внутри computed
const bad = computed(() => tasks().sort((a, b) => ...));
// tasks() отдаёт исходный массив, sort его портит

// ХОРОШО: сортируем копию
const good = computed(() => [...tasks()].sort((a, b) => ...));

Что увидит пользователь при плохом варианте: список может «сломаться» или перестать обновляться, потому что сам источник испорчен.

Список опасных мутирующих методов: push, pop, splice, sort, reverse, присваивание полю объекта. Заменяйте их на spread/map/filter.

23. Практика 1: сигнал списка задач

Создадим компонент, где список задач — сигнал, и опробуем чтение в шаблоне.

Контекст. Команда Angular CLI создаёт каркас компонента (файлы и папку).

ng generate component task-list

Контекст. В классе компонента объявляем сигнал-список с двумя задачами. Это состояние, которое дальше будем показывать и менять.

// task-list.ts
import { Component, signal } from '@angular/core';
import type { Task } from '../task';

@Component({ selector: 'app-task-list', standalone: true, ... })
export class TaskList {
  readonly tasks = signal<Task[]>([
    { id: 1, title: 'Изучить сигналы', completed: false },
    { id: 2, title: 'Проверить шаблон', completed: true },
  ]);
}

Контекст. Шаблон читает сигнал и перебирает задачи через @for, показывая заголовок и галочку/пустое поле по completed.

<!-- task-list.html -->
<h3>Задач в списке: {{ tasks().length }}</h3>
<ul>
  @for (task of tasks(); track task.id) {
    <li>{{ task.title }} — {{ task.completed ? '✅' : '⬜' }}</li>
  }
</ul>

Что увидит пользователь: заголовок «Задач в списке: 2» и два пункта со статусами ✅/⬜.

Шаблон читает tasks(), а внутри @for перебирает элементы. Убедитесь, что в браузере появятся заголовок и два пункта.

24. Практика 2: toggle через computed

Свяжем чекбокс с сигналом: переключение меняет состояния, шаблон перерисовывается автоматически.

Контекст. Метод onToggled неизменяемо переключает флаг задачи: создаётся новый массив с новым объектом для нужной задачи.

// task-list.ts
onToggled(id: number) {
  this.tasks.update(cur =>
    cur.map(t => t.id === id ? { ...t, completed: !t.completed } : t)
  );
}

<!-- task-list.html -->
@for (task of tasks(); track task.id) {
  <li>
    <input
      type="checkbox"
      [checked]="task.completed"
      (change)="onToggled(task.id)"
    />
    {{ task.title }}
  </li>
}

Что увидит пользователь: отметил чекбокс — галочка появилась/исчезла, без ручного обновления.

Отметьте чекбокс — пункт получит другой checked. Изменение прошло: событие → update() → новый массив → перерисовка.

25. Практика 3: фильтры через computed

Добавим фильтр и visibleTasks в виде computed.

Контекст. Сигнал фильтра + computed, который показывает нужные задачи; метод setFilter меняет фильтр.

import { Component, computed, signal } from '@angular/core';
import type { Task, TaskFilter } from '../task';

// ...
readonly filter = signal<TaskFilter>('all');
readonly visibleTasks = computed(() => {
  const f = this.filter();
  if (f === 'active') return this.tasks().filter(t => !t.completed);
  if (f === 'done') return this.tasks().filter(t => t.completed);
  return this.tasks();
});

setFilter(value: TaskFilter) { this.filter.set(value); }

<button (click)="setFilter('all')">Все</button>
<button (click)="setFilter('active')">Активные</button>
<button (click)="setFilter('done')">Выполненные</button>

@for (task of visibleTasks(); track task.id) {
  <li>{{ task.title }}</li>
}

Что увидит пользователь: нажал «Выполненные» — в списке остались только сделанные задачи.

Выберите «Выполненные» — в списке останутся только сделанные. Изменение фильтра автоматически пересчитало visibleTasks().

26. Практика 4: счётчики через computed

Добавим счётчики как производные значения.

Контекст. Три счётчика как производные значения — они считаются из списка и обновляются сами.

readonly total = computed(() => this.tasks().length);
readonly activeCount = computed(() =>
  this.tasks().filter(t => !t.completed).length
);
readonly doneCount = computed(() =>
  this.tasks().filter(t => t.completed).length
);

Контекст. Выводим счётчики в шаблоне — они всегда актуальны.

<p>Всего: {{ total() }} · Активных: {{ activeCount() }} · Выполнено: {{ doneCount() }}</p>

Что увидит пользователь: помечает задачи чекбоксом — счётчики меняются сами, без ручного пересчёта. Это демонстрация реактивности в действии.

27. Практика 5: поиск через find

Реализуем выбор одной задачи по id с помощью computed и find.

Контекст. Сигнал выбранного id и computed, который находит задачу по нему (паттерн из раздела 16, теперь в компоненте).

readonly selectedId = signal<number | null>(null);
readonly selectedTask = computed(() =>
  this.selectedId() === null
    ? null
    : this.tasks().find(t => t.id === this.selectedId()) ?? null
);

select(id: number) { this.selectedId.set(id); }

@if (selectedTask(); as task) {
  <div class="detail">
    <h4>{{ task.title }}</h4>
    <p>Приоритет: {{ task.priority }}</p>
  </div>
} @else {
  <p>Выберите задачу</p>
}

Что увидит пользователь: выбрал задачу — открылась её карточка; ничего не выбрано — подсказка.

Новый синтаксис @if (expr; as alias) сохраняет результат в локальную переменную task, чтобы не вызывать selectedTask() многократно.

28. Практика 6: статистика и каскад computed

Объединим фильтрацию и статистику в каскад computed.

Контекст. Каскад: visibleCount зависит от отфильтрованного списка, а doneShare — от счётчиков. Показываем число видимых и долю выполненных в процентах.

readonly visibleTasks = computed(() => { ... }); // из раздела 25
readonly visibleCount = computed(() => this.visibleTasks().length);
readonly doneShare = computed(() =>
  this.total() === 0
    ? 0
    : Math.round((this.doneCount() / this.total()) * 100)
);

Контекст. Выводим два показателя статистики.

<p>Показано записей: {{ visibleCount() }}</p>
<p>Доля выполненных: {{ doneShare() }}%</p>

Что увидит пользователь: число видимых задач и процент выполнения, меняющиеся сами.

Здесь visibleCount зависит от visibleTasks, а doneShare — от doneCount и total. Любое изменение источника пробегает по каскаду.

28.1. Сигналы для отдельных полей: checkbox и форма

Не только списки — отдельные значения (флажок, текст поля) тоже бывают сигналами.

Контекст. Два отдельных сигнала: открыт ли блок, и что введено в поле. Это удобно, когда значение читается в шаблоне или участвует в вычислениях (например, можно ли отправить форму).

const isOpen = signal(false);
const newTitle = signal('');

// обработчик для поля
onInput(event: Event) {
  this.newTitle.set((event.target as HTMLInputElement).value);
}

<input [value]="newTitle()" (input)="onInput($event)" />
<label>
  <input type="checkbox" [checked]="isOpen()" (change)="isOpen.set(!isOpen())" />
  Показать детали
</label>

Отдельные сигналы удобны, когда значение читается в шаблоне или используется в вычислениях. В уроке 4 форма TaskForm использовала обычное поле newTitle; вариант с сигналом даёт ту же реактивность для производных (например, можно ли отправить кнопку).

const canSubmit = computed(() => this.newTitle().trim().length > 0);

<button type="submit" [disabled]="!canSubmit()">Добавить</button>

Что увидит пользователь: кнопка «Добавить» серая и неактивная, пока поле пустое, и становится активной, стоит начать вводить текст — автоматически.

28.2. Поток данных: снова «данные вниз, события вверх»

Сигналы не отменяют архитектуру урока 4. Родитель владеет сигналом, передаёт производные вниз, а события поднимаются вверх и меняют состояние.

TaskList (владеет tasks, filter)
 ├── FilterBar   ← [filter], (filterChange) → изменяет filter
 ├── StatsBar    ← [tasks]
 └── TaskItem    ← [task], (toggled) → обновляет tasks

Computed помогает родителю передавать необработанные данные или готовые производные:

<app-stats-bar [total]="total()" [done]="doneCount()" />

Можно передать счётчики как входы, а сам StatsBar оставить «чистым» — он просто показывает переданные числа. Так вычисление остаётся у владельца данных.

28.3. Схема реактивности: отклик на изменение

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

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

28.4. Эффекты на практике: сохранение и логирование

Разберём два реалистичных применения effect().

Сохранение в localStorage

Контекст. Эффект в конструкторе компонента автоматически сохраняет список задач в браузер при каждом его изменении — без ручных вызовов «сохранить».

import { Component, effect, signal } from '@angular/core';

@Component({ selector: 'app-task-list', standalone: true, ... })
export class TaskList {
  readonly tasks = signal<Task[]>([]);

  constructor() {
    // при каждом изменении списка — сохраняем
    effect(() => {
      localStorage.setItem('tasks', JSON.stringify(this.tasks()));
    });
  }
}

Что увидит пользователь: сам по себе — ничего на экране, но данные сохраняются «за кадром» и восстановятся после перезагрузки.

Каждый раз, когда tasks меняется, эффект записывает новую версию. Никаких ручных вызовов «сохранить» — изменение состояния само запускает побочное действие.

Логирование изменения фильтра

Контекст. Второй пример — логирование: при смене фильтра пишем в консоль. Это тоже побочное действие «наружу».

readonly filter = signal<TaskFilter>('all');

constructor() {
  effect(() => {
    console.log('Фильтр изменён на:', this.filter());
  });
}

Что увидит пользователь: в консоли разработчика — записи о смене фильтра (сам экран не меняется от лога).

Эффект удобен, но не перегружайте им компонент. В уроке 6, вынося состояние в сервис, эффекты тоже переносите вместе с логикой.

28.5. Производная статистика через reduce

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

Контекст. Один проход по массиву через reduce даёт сразу все показатели статистики (вместо нескольких отдельных filter).

interface TaskStats {
  total: number;
  active: number;
  doneCount: number;
  high: number;
}

const stats = computed<TaskStats>(() =>
  this.tasks().reduce(
    (acc, t) => ({
      total: acc.total + 1,
      active: acc.active + (t.completed ? 0 : 1),
      doneCount: acc.doneCount + (t.completed ? 1 : 0),
      high: acc.high + (t.priority === 'high' ? 1 : 0),
    }),
    { total: 0, active: 0, doneCount: 0, high: 0 }
  )
);

В шаблоне:

<p>Всего: {{ stats().total }}</p>
<p>Активных: {{ stats().active }} · Выполнено: {{ stats().doneCount }}</p>
<p>Высокий приоритет: {{ stats().high }}</p>

Объект-аккумулятор делает статистику компактной. Если показателей много, reduce эффективнее нескольких filter.

28.6. Чтение старого кода: subscription и BehaviorSubject

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

// RxJS / BehaviorSubject (старый подход)
import { BehaviorSubject } from 'rxjs';

export class TaskService {
  private readonly tasks$ = new BehaviorSubject<Task[]>([]);
  readonly tasks = this.tasks$.asObservable();
}

// компонент подписывается (старый подход)
this.tasks$.subscribe(tasks => {
  this.tasks = tasks;
});

Параллель с сигналами:

28.7. Что такое контекст инъекций и почему эффекты в компоненте

Вы могли заметить, что вызовы computed() и effect() выполняются в теле компонента (в поле или в конструкторе), а не внутри произвольной функции. Это связано с контекстом инъекций.

Angular создаёт эффект в «реактивном контексте» текущего компонента, чтобы связать его с жизненным циклом этого компонента. Когда компонент уничтожается, его эффекты тоже автоматически прекращаются — не нужно вручную отписываться.

// эффект связан с жизненным циклом компонента
export class TaskList {
  constructor() {
    effect(() => { /* живёт, пока жив компонент */ });
  }
}

Если вызвать effect() вне такого контекста, Angular выдаст ошибку «effect() can only be used within an injection context». Это частая неожиданность.

28.8. Сравнение сигналов в Angular и React

Закрепим таблицу сравнения из раздела 21 на примере одного сценария — отфильтровать активные задачи.

// Angular — сигналы
const tasks = signal<Task[]>([]);
const filter = signal('all');
const visible = computed(() => filter() === 'active'
  ? tasks().filter(t => !t.completed)
  : tasks());

// React — state + мемоизация
const [tasks, setTasks] = useState([]);
const [filter, setFilter] = useState('all');
const visible = useMemo(() => filter === 'active'
  ? tasks.filter(t => !t.completed)
  : tasks, [tasks, filter]);

Механизмы различны, намерение то же: производное значение, следующее за состоянием.

28.9. Computed от нескольких сигналов

Computed может читать несколько сигналов одновременно — он пересчитается, если изменится любой из них.

const tasks = signal<Task[]>([]);
const filter = signal<TaskFilter>('all');
const search = signal('');

const result = computed(() => {
  const q = search().toLowerCase();
  return this.filter()
    .split('')
    .map(() => 0) // placeholder ради примера
    .length ? tasks() : tasks();
});

Лучше покажем реалистичный пример — фильтр плюс поиск:

const visibleTasks = computed(() => {
  const f = filter();
  let list = tasks();
  if (f === 'active') list = list.filter(t => !t.completed);
  if (f === 'done') list = list.filter(t => t.completed);
  const q = search().trim().toLowerCase();
  if (q) list = list.filter(t => t.title.toLowerCase().includes(q));
  return list;
});

Здесь computed отслеживает три сигнала: tasks, filter, search. Изменение любого из них пересчитывает результат.

28.10. Модель Task: readonly id и неизменяемые поля

Неизменяемость начинается с типа. Объявим модель так, чтобы компилятор помогал её соблюдать.

export type Priority = 'high' | 'medium' | 'low';

export interface Task {
  readonly id: number;        // нельзя перезаписать
  title: string;
  completed: boolean;
  priority: Priority;
}

Поле readonly id защищает идентификатор от случайной перезаписи. Другие поля остаются изменяемыми по типу, но мы всё равно меняем их через spread (создавая новый объект).

// правильно: новый объект с новым id невозможно (readonly), но меняем title
this.tasks.update(cur => cur.map(t => t.id === id ? { ...t, title: newTitle } : t));

Параллель: в уроке 2 (раздел 28) мы видели readonly для массивов и объектов TypeScript. Здесь тот же инструмент применяется к полю модели.

28.11. Передача сигнала в дочерний компонент

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

// task-list.ts
<app-stats-bar [tasksSignal]="tasks" />

// stats-bar.ts
import { Component, input } from '@angular/core';
import type { Signal } from '@angular/core';
import type { Task } from '../task';

export class StatsBar {
  readonly tasks = input.required<Signal<Task[]>>();
}

Дочерний читает внутри computed или метода:

readonly total = computed(() => this.tasks().().length);

Синтаксис this.tasks()() может запутать: первый вызов берёт сам сигнал, второй читает его значение. Чаще проще передавать значение [tasks]="tasks()", чтобы дочерний видел обычный массив.

28.12. Структура сигнала: примитив, массив, объект

Что можно хранить в сигнале? Все что угодно: примитив, массив, объект, даже другой сигнал (хотя это редкость). Структура влияет на то, как вы его обновляете.

Объект в сигнале — например, целое состояние формы:

const form = signal({ title: '', priority: 'low', completed: false });

// обновить одно поле — новый объект (поле задачи — completed, не done)
form.update(f => ({ ...f, priority: 'high' }));

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

28.13. Вынос чистой логики в функции

Фильтрация и подсчёты — чистая логика. Её можно вынести из компонента в обычные функции, чтобы переиспользовать и тестировать.

Контекст. Чистую логику (фильтрация, подсчёт, сортировка) выносим в обычные функции-утилиты, чтобы переиспользовать и тестировать их без Angular.

// tasks.util.ts
import type { Task, TaskFilter } from './task';

export function filterTasks(tasks: Task[], f: TaskFilter): Task[] {
  if (f === 'active') return tasks.filter(t => !t.completed);
  if (f === 'done') return tasks.filter(t => t.completed);
  return tasks;
}

export function countDone(tasks: Task[]): number {
  return tasks.filter(t => t.completed).length;
}

export function sortByPriority(tasks: Task[]): Task[] {
  const rank = { high: 0, medium: 1, low: 2 };
  return [...tasks].sort((a, b) => rank[a.priority] - rank[b.priority]);
}

В компоненте computed просто вызывает утилиты:

readonly visibleTasks = computed(() =>
  filterTasks(this.tasks(), this.filter())
);

Такой слой делает computed лаконичным, а логику — переносимой и тестируемой отдельно от Angular.

28.14. Автодополнение и prefill через computed

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

const lastCreated = signal<Task | null>(null);

const suggestion = computed(() =>
  this.lastCreated() ? 'Продолжите: ' + this.lastCreated()!.title : ''
);

Non-null assertion ! работает, потому что мы уже проверили в условии. В шаблоне:

@if (suggestion()) {
  <p class="hint">{{ suggestion() }}</p>
}

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

const defaultTitle = computed(() =>
  this.filter() === 'done' ? 'Новая задача (завершена)' : 'Новая задача'
);

28.15. Синхронизация фильтра и видимости

Фильтр и видимый список связаны: изменение одного автоматически обновляет другое. Это и есть главное преимущество реактивности.

// состояние
readonly filter = signal<TaskFilter>('all');

// производная
readonly visibleTasks = computed(() => filterTasks(this.tasks(), this.filter()));

// событие от FilterBar
onFilterChange(value: TaskFilter) {
  this.filter.set(value);
}

Никакой ручной «синхронизации»: вы меняете фильтр, а видимый список пересчитывается сам. Строка кода, которую пишет разработчик, — только filter.set(value).

<app-filter-bar [filter]="filter()" (filterChange)="onFilterChange($event)" />
@for (task of visibleTasks(); track task.id) { ... }

28.16. Поиск по строке: ещё один computed

Добавим поле поиска и связанный с ним computed, как в разделе 28.9.

readonly query = signal('');

readonly visibleTasks = computed(() => {
  let list = filterTasks(this.tasks(), this.filter());
  const q = this.query().trim().toLowerCase();
  if (q) {
    list = list.filter(t => t.title.toLowerCase().includes(q));
  }
  return list;
});

onSearch(event: Event) {
  this.query.set((event.target as HTMLInputElement).value);
}

<input #q (input)="onSearch($event)" placeholder="Поиск по названию" />

Композиция двух производных (фильтр + поиск) в одном computed даёт комбинированный результат. При работе с большими списками такое сочетание фильтрует сразу по двум критериям.

28.17. Когда пора переходить на сервисы

Пока реактивное состояние живёт в одном компоненте, сигналы и computed в нём уместны. Но есть два признака, что пора выносить в сервис (урок 6).

• Список нужен нескольким компонентам. Если TaskList и ещё какой-то компонент читают один и тот же список — логично хранить его в общем сервисе.
• Логика повторяется. Если фильтрацию и счётчики используют в нескольких местах — вынести вычисления в сервис или утилиты.

// сейчас: сигнал внутри компонента
export class TaskList {
  readonly tasks = signal<Task[]>([]);
}

// урок 6: сигнал в сервисе, компонент читает его через DI
@Injectable({ providedIn: 'root' })
export class TaskService {
  readonly tasks = signal<Task[]>([]);
}

28.18. Проверка реактивности: маленькие тесты

Сигналы и computed легко проверить вне браузера — они обычные классы. Это упрощает тестирование (урок 12).

// task.logic.spec.ts
import { computed, signal } from '@angular/core';

it('счётчик следует за списком', () => {
  const tasks = signal([{ completed: false }, { completed: true }]);
  const done = computed(() => tasks().filter(t => t.completed).length);

  expect(done()).toBe(1);
  tasks.set([{ completed: true }, { completed: true }]);
  expect(done()).toBe(2); // пересчиталось само
});

Плюс вынесенных утилит (раздел 28.13) очевиден: чистые функции тестируются всего строкой импорта, без монтирования компонента.

28.19. Производительность больших списков

Сигналы комфортны на обычных объёмах. Но если список огромный, важно понимать, что вызывает пересчёт.

// каждый computed фильтрует весь массив заново
const highCount = computed(() =>
  this.tasks().filter(t => t.priority === 'high').length
);

Фильтрация массива — O(n). На тысячах задач это мгновенно; на сотнях тысяч — ощутимо. Приёмы оптимизации:

• кэш computed помогает, если значение уже вычислено и источники не менялись;
• избегайте повторных одинаковых filter — считайте в один reduce (раздел 28.5);
• для очень частых изменений рассмотрите структуру, где производное не пересоздаётся без нужды (урок 13).

28.20. Обратная связь: события изменяют сигнал

Полный цикл реактивности замыкается: события дочерних компонентов поднимаются наверх и меняют сигнал, а computed пересчитывает производные.

readonly tasks = signal<Task[]>([]);
readonly visibleTasks = computed(() => filterTasks(this.tasks(), this.filter()));

onToggled(id: number) {
  this.tasks.update(cur => cur.map(t => t.id === id ? { ...t, completed: !t.completed } : t));
}

<app-task-item
  [task]="task"
  (toggled)="onToggled(task.id)"
/>

Клик в дочернем → событие вверх → update() → сигнал изменён → computed пересчитан → шаблон обновлён. Один цикл, четыре шага, уже знакомых из раздела 28.3.

Здесь сигнал выступает единой точкой правды: дочерний не трогает данные напрямую, только сообщает намерение. Это согласуется с уроками 4–5.

28.21. @let и локальные переменные из computed

Если computed-результат используется в шаблоне несколько раз, можно сохранить его в локальную переменную через @let (новый синтаксис Angular).

@let visible = visibleTasks();

@for (task of visible; track task.id) {
  <app-task-item [task]="task" />
}
<p>Показано: {{ visible.length }}</p>

@let берёт значение один раз и переиспользует, не вызывая computed повторно на каждой строке. Это и читаемость, и небольшой выигрыш в производительности.

То же в форме с условным блоком:

@if (selectedTask(); as task) {
  ...
}

; as task внутри @if даёт псевдоним непустого значения. Обе конструкции — способ «не вызывать сигнал по несколько раз».

28.22. Опциональные фильтры и значения по умолчанию

Некоторые сигналы могут быть «пустыми» или иметь значение по умолчанию. Поработаем с этим аккуратно.

const selectedId = signal<number | null>(null);
const query = signal('');

// опциональный фильтр: если query пуст — не фильтруем
const visibleTasks = computed(() => {
  let list = tasks();
  const q = query().trim().toLowerCase();
  if (q) list = list.filter(t => t.title.toLowerCase().includes(q));
  return list;
});

Проверка if (q) — guard-приём из урока 2 (раздел 6): обрабатываем пустое значение раньше и выходим.

Для «нет выбора» используем null:

const selectedTask = computed(() =>
  selectedId() === null ? null : tasks().find(t => t.id === selectedId()) ?? null
);

28.23. Практика 7: поиск + фильтр + сортировка в одном экране

Финальное упражнение соединяет все приёмы: сигналы состояния, каскад computed и неизменяемые обновления.

readonly tasks = signal<Task[]>([...]);
readonly filter = signal<TaskFilter>('all');
readonly query = signal('');
readonly sortBy = signal<'priority' | 'title'>('priority');

readonly visibleTasks = computed(() => {
  let list = filterTasks(this.tasks(), this.filter());

  const q = this.query().trim().toLowerCase();
  if (q) list = list.filter(t => t.title.toLowerCase().includes(q));

  if (this.sortBy() === 'priority') return sortByPriority(list);
  return [...list].sort((a, b) => a.title.localeCompare(b.title));
});

readonly shownCount = computed(() => this.visibleTasks().length);

<input (input)="onSearch($event)" placeholder="Поиск" />
<button (click)="onFilter('all')">Все</button>
...
@let visible = visibleTasks();
@for (task of visible; track task.id) { ... }
<p>Показано: {{ shownCount() }}</p>

Все три оси (фильтр, поиск, сортировка) — это сигналы состояния, а итоговый список — каскад computed. Никакой ручной синхронизации: меняется любой источник — список пересчитывается.

28.24. TaskForm на сигналах: полный сценарий

Соединим форму и список через сигналы в полный цикл: ввод → событие → обновление сигнала списка → пересчёт производных.

Контекст. Полный сценарий формы на сигналах: поле ввода — сигнал, кнопка блокируется через computed, при отправке форма «излучает» событие родителю.

// task-form.ts — поле как сигнал
import { Component, computed, output, signal } from '@angular/core';

export class TaskForm {
  readonly newTitle = signal('');
  readonly created = output<string>();

  readonly canSubmit = computed(() => this.newTitle().trim().length > 0);

  onInput(event: Event) {
    this.newTitle.set((event.target as HTMLInputElement).value);
  }

  submit() {
    const title = this.newTitle().trim();
    if (!title) return;                  // guard clause
    this.created.emit(title);
    this.newTitle.set('');               // очистка поля
  }
}

Что увидит пользователь: пока поле пустое — кнопка неактивна; ввёл текст — кнопка активна; отправил — поле очистилось, кнопка снова неактивна.

<!-- task-form.html -->
<input [value]="newTitle()" (input)="onInput($event)" aria-label="Название задачи" />
<button type="submit" [disabled]="!canSubmit()">Добавить</button>

<!-- родитель: слушает событие и меняет сигнал -->
<app-task-form (created)="onCreated($event)" />

// task-list.ts
onCreated(title: string) {
  const id = Math.max(0, ...this.tasks().map(t => t.id)) + 1;
  this.tasks.update(cur => [{ id, title, completed: false }, ...cur]);
}

Что увидит пользователь: новая задача появляется вверху списка, счётчики пересчитываются автоматически.

Кнопка автоматически активна/неактивна в зависимости от поля — через canSubmit(). Очистка поля после отправки делает [disabled] снова истинным. Всё реактивно, без ручного контроля.

28.25. Архитектурный итог: реактивное состояние как система

Соберём всё, что умеет делать реактивное состояние TaskFlow к концу урока.

Итоговая картина — единый «источник правды» (сигналы) и её реактивные «отражения» (computed). Компоненты лишь читают отражения и сообщают о намерениях.

Состояние (сигналы)
   │  читают
   ▼
Производные (computed)
   │  кормят
   ▼
Шаблон (декларативно показывает)
   ▲
   │  событийный вызов
Методы-обработчики  →  обновляют сигналы

29. Самостоятельная работа

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

30. Подсказки к самостоятельной работе

Совет: сначала сформулируйте идею, затем открывайте код.

31. Частые ошибки реактивности

Разберём типичные проблемы, которые возникают при работе с сигналами.

32. Резюме: как устроено реактивное состояние

Пять правил реактивности в Angular.

• Состояние хранится в signal(); читается вызовом ().
• Изменения — через set() (новое значение) или update() (от текущего).
• Производные значения — через computed(): лениво, с кэшированием, реактивно.
• Побочные действия — через effect(), но только «наружу» (хранилище, логи, сеть).
• Обновление всегда неизменяемо: новая ссылка через spread/map/filter; для сортировки — копия.

Когда эти правила становятся привычными, TaskFlow на сигналах пишется и читается легко: состояние — в сигналах, вывод — в computed, а шаблон лишь отражает результат. Любая перестройка данных, к которой вы придёте в уроках 6–12 (сервисы, HTTP, формы, маршрутизация), сохранит эту фундаментальную схему.

33. Контрольные вопросы

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

1. Чем состояние отличается от производного значения?
2. Как создать, прочитать и изменить signal()?
3. Когда нужен set(), а когда update()?
4. Что делает computed(), и почему он «ленивый»?
5. Зачем asReadonly()?
6. В чём смысл «неизменяемого обновления» и почему оно критично для сигналов?
7. Почему перед sort() нужна копия массива?
8. Что такое каскад computed, и как он работает?
9. Когда уместен effect(), а когда нет?
10. В чём разница между методом-геттером и computed?
11. Как сигналы связаны с перерисовкой DOM?
12. Как эта модель переносится на React (useState/useMemo)?
13. Что такое каскад computed и как отслеживаются зависимости?
14. Почему внутри computed не следует выполнять побочные действия?
15. Как @let помогает шаблону при многократном чтении computed?
16. Когда невыгодно держать глубоко вложенный объект в одном сигнале?

34. Мини-словарь

35. Источники и продолжение

Для самостоятельного углубления:

• Официальные руководства Angular: сигналы, computed, effect.
• Материалы урока 2 (разделы 9, 12) про map/filter/find/reduce и spread.
• Материалы урока 4 (разделы 7, 15) про владельца состояния и неизменяемость.
• Материалы урока 1 (разделы 12, 31) про декларативный UI и состояние.

36. Чек-лист урока

• Я создаю состояние через signal() и читаю вызовом ().
• Я выбираю между set() и update() по зависимости от текущего значения.
• Я выделяю производные значения в computed().
• Я понимаю ленивость и кэширование computed.
• Я применяю effect() только для побочных действий.
• Я всегда обновляю данные неизменяемо (spread/map/filter), без мутаций.
• Я сортирую копии массивов, а не исходные.
• Я строю каскады computed и читаю результат в шаблоне.
• Я применяю @let, чтобы не вызывать computed повторно в шаблоне.
• Я передаю дочерним готовые производные (числа, списки), читая их из computed.
• Я выношу чистую логику (фильтры, счётчики) в отдельные функции-утилиты.
• Я аккуратно работаю с null/undefined/'' для опциональных сигналов.
• Я понимаю, когда состояние пора выносить в сервис (урок 6).
• Я умею читать и старый RxJS-код подписок.
• Я применяю принцип «единого источника правды»: не храню лишних копий состояния.
• Я понимаю, как реактивность переносится на React.

🛠 Практика к уроку 5

Замените ручные пересчёты на сигналы и computed.

Задание 1. Состояние и производные значения

const tasks = signal<Task[]>([ /* ... */ ]);
const doneCount = computed(() =>
  tasks().filter(t => t.completed).length);
tasks.update(list => [...list, newTask]); // счётчики пересчитались сами

Задание 2. Фильтрация через computed

const visibleTasks = computed(() => {
  const f = filter();
  if (f === 'done')   return tasks().filter(t => t.completed);
  if (f === 'active') return tasks().filter(t => !t.completed);
  return tasks();
});