Урок №7

1. Что мы построим в этом уроке

В уроке 6 TaskService держал задачи в сигнале, заполняемом из константы. Теперь данные приходят из настоящего (учебного) сервера. Список загружается по GET, создание — по POST, отметка — по PATCH, удаление — по DELETE. Клиент — HttpClient из Angular.

Компоненты (сигналы, шаблон)
    │
TaskService (HttpClient + сигналы tasks/loading/error)
    │  HTTP
    ▼
mock API (json-server) на порту 3000

К концу урока TaskFlow работает с сетью: загрузка показывает индикатор, пустой список — заглушку, сбой — сообщение об ошибке.

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

Зафиксируем точку старта.

Модель Task не изменится: контракт данных тот же. Меняется только то, откуда сервис берёт задачи.

3. Клиент-серверная связка в TaskFlow

Angular-приложение — это клиент, работающий в браузере. Оно общается с сервером через HTTP по адресу API. В TaskFlow «сервер» на время курса — локальный mock API.

Браузер (Angular) ── HTTP ──► json-server (localhost:3000)
     ◄── JSON ──

Запросы бывают разные по действию:

• GET /tasks — получить список.
• POST /tasks — создать задачу.
• PATCH /tasks/3 — обновить поля задачи 3.
• DELETE /tasks/3 — удалить задачу 3.

4. Что такое mock API и json-server

Mock API — временный сервер, имитирующий настоящий backend. Он отдаёт заранее заготовленные данные и умеет обрабатывать CRUD-запросы. Для курса используем библиотеку json-server.

# запуск (в папке проекта)
npx json-server db.json --port 3000

Файл db.json описывает данные:

{
  "tasks": [
    { "id": 1, "title": "Выучить HttpClient", "completed": false, "priority": "high" },
    { "id": 2, "title": "Подключить loading", "completed": false, "priority": "medium" }
  ]
}

json-server по этому описанию сам предоставляет REST-адреса: /tasks, /tasks/1 и т.д. Имена коллекций берутся из ключей JSON.

5. Структура mock API: коллекции и ресурсы

Каждый ключ верхнего уровня — коллекция (таблица). Каждый элемент — ресурс с полем id.

db.json
├── tasks: [ { id, title, completed, priority }, ... ]
└── (позже: users, tags, ...)

json-server автоматически генерирует адреса:

6. Основы REST: методы и статусы

HttpClient отправляет HTTP-запрос и получает ответ, который состоит из кода состояния и тела.

• 2xx — успех: 200 OK, 201 Created, 204 No Content.
• 4xx — ошибка клиента: 400 Bad Request, 404 Not Found.
• 5xx — ошибка сервера: 500 Internal Server Error.

Пользовательский сценарий:
- загрузить задачи  → GET 200 → массив
- неверный id       → GET /tasks/999 → 404
- сервер упал       → 500 → показать ошибку

7. HttpClient: что это и зачем

HttpClient — сервис Angular для HTTP-запросов. Он внедряется через DI, как любой другой сервис.

import { HttpClient } from '@angular/common/http';

@Injectable({ providedIn: 'root' })
export class TaskService {
  private readonly http = inject(HttpClient);
}

В отличие от fetch (урок 2), HttpClient возвращает Observable, а не Promise. Поэтому отвечает «потоком», который отдаёт результат подписчику, когда приходит ответ.

8. provideHttpClient: включаем HTTP-модуль

Чтобы HttpClient был доступен, в корне приложения добавляют провайдер.

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideHttpClient } from '@angular/common/http';
import { App } from './app/app';

bootstrapApplication(App, {
  providers: [provideHttpClient()],
});

Без этого вызова inject(HttpClient) упадёт с «No provider for HttpClient».

9. Внедрение HttpClient в сервис

Внутри сервиса получаем HttpClient тем же способом, что и другие зависимости.

@Injectable({ providedIn: 'root' })
export class HttpService {
  private readonly http = inject(HttpClient);
  private readonly base = 'http://localhost:3000';

  loadTasks() {
    return this.http.get<Task[]>(`${this.base}/tasks`);
  }
}

Метод get принимает URL и возвращает Observable, типизированный через дженерик <Task[]>.

10. Первый запрос: GET /tasks

Самый простой запрос — получение списка.

readonly tasks = signal<Task[]>([]);

load() {
  this.http.get<Task[]>('http://localhost:3000/tasks')
    .subscribe(tasks => this.tasks.set(tasks));
}

Пока мы только «подписались» на результат. Когда json-server ответит, колбэк положит данные в сигнал, а шаблон перерисуется — это реактивность урока 5.

Разберём по шагам, что происходит в каждой строке:

1. http.get<Task[]>(url) — создаёт Observable, который «умеет» отправить GET.
2. .subscribe(tasks => ...) — подписывается: реально отправляет запрос.
3. Когда приходит ответ, колбэк получает распарсенный JSON как массив Task[].
4. this.tasks.set(tasks) — кладёт данные в сигнал; шаблон обновляется.

11. Observable: поток данных Angular

Observable — объект, который со временем может выдать ноль, одно или несколько значений. HTTP-ответ выдаёт одно значение (тело ответа), затем завершается.

http.get(url) ── [данные] ──(завершение)
                       │ subscribe
                       ▼
                 колбэк с данными

• Холодный — начинает работу при subscribe.
• Одно-много значений — HTTP обычно одно (URL-запрос даёт один ответ).
• Завершение — после данных поток закрывается.

12. Promise против Observable: мост из урока 2

В уроке 2 вы работали с fetch и Promise. Сравним подходы.

// fetch (урок 2)
const tasks = await fetch('/tasks').then(r => r.json());

// HttpClient (урок 7)
this.http.get<Task[]>('/tasks').subscribe(t => ...);

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

13. pipe, map, subscribe: работаем с потоком

Перед подпиской результат можно преобразовать через pipe с операторами.

this.http.get<Task[]>(url)
  .pipe(
    map(tasks => tasks.filter(t => !t.completed)), // сколько активных
  )
  .subscribe(tasks => this.activeTasks.set(tasks));

map — как Array.map, но для потока: получает значение, возвращает новое. pipe собирает цепочку операторов в порядке слева направо.

Операторов в цепочке может быть несколько — они выполняются по очереди над значением потока.

this.http.get<Task[]>(url).pipe(
  map(tasks => tasks.filter(t => !t.completed)), // сначала фильтр
  map(active => active.length),                  // затем посчитать
)
.subscribe(count => this.activeCount.set(count));

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

14. Типизированные ответы и generics

HttpClient умеет объявлять тип ответа через дженерик. Компилятор проверит, как вы используете полученные данные.

this.http.get<Task[]>(url)          // массив задач
this.http.get<Task>(`${url}/2`)     // одна задача
this.http.post<Task>(url, draft)    // ответ — созданная задача

Если ответ не соответствует типу, ошибка будет только в рантайме (это не валидация данных, а подсказка типов). Для строгой проверки на время курса достаточно типизации из урока 2.

// объявим тип ответа явно
interface TaskResponse {
  tasks: Task[];
  total: number;
}
this.http.get<TaskResponse>(url);

15. Записываем результат в сигнал

Финальный шаг GET — положить данные в сигнал, который читают компоненты.

readonly tasks = signal<Task[]>([]);

load(): void {
  this.http.get<Task[]>(this.apiUrl + '/tasks')
    .subscribe({
      next: t => this.tasks.set(t),
      error: e => console.error('Не удалось загрузить', e),
    });
}

Передаём объект с колбэками: next — данные, error — ошибка. Так мы готовимся к состояниям, которые разберём далее.

16. CRUD: POST — создание задачи

Создание отправляет черновик в теле запроса и получает созданную задачу с id.

add(draft: TaskDraft): void {
  this.http.post<Task>(this.apiUrl + '/tasks', draft)
    .subscribe({
      next: created => this.tasks.update(xs => [...xs, created]),
      error: e => this.handleError(e),
    });
}

После успеха добавляем созданную задачу в сигнал неизменяемо (spread, урок 5). id присваивает json-server.

17. CRUD: PATCH — отмечаем выполненной

Тoggle меняет одно поле. Отправляем объект с этим полем.

toggle(id: number, completed: boolean): void {
  this.http.patch<Task>(`${this.apiUrl}/tasks/${id}`, { completed })
    .subscribe({
      next: updated => this.tasks.update(xs =>
        xs.map(t => t.id === id ? updated : t)),
      error: e => this.handleError(e),
    });
}

В URL подставляем id задачи, в теле — только изменяемое поле. Полученную задачу кладём на место старой.

18. CRUD: DELETE — удаление задачи

Удаление отправляет DELETE по адресу задачи.

remove(id: number): void {
  // DELETE удаляет ресурс; тело ответа пустое — тип void
  this.http.delete<void>(`${this.apiUrl}/tasks/${id}`)
    .subscribe({
      next: () => this.tasks.update(xs => xs.filter(t => t.id !== id)),  // убираем из списка
      error: e => this.handleError(e),
    });
}

Ответ DELETE обычно пуст (204), поэтому тип <void>. После успеха убираем задачу из сигнала фильтрацией.

19. Loading/empty/error: состояния загрузки

При работе с сетью состояние не сводится к данным. Есть фазы:

loading → data (или empty)  →  error

В сервисе заведём сигналы состояния.

readonly loading = signal(false);
readonly loadError = signal<string | null>(null);

load(): void {
  this.loading.set(true);
  this.loadError.set(null);
  this.http.get<Task[]>(url).subscribe({
    next: t => { this.tasks.set(t); this.loading.set(false); },
    error: e => { this.loadError.set('Не удалось загрузить'); this.loading.set(false); },
  });
}

Обратите внимание: «пусто» — это не отдельный сигнал. Пустота выводится из данных: если tasks пуст и нет ошибки — список пуст. Так мы не держим три конфликтующих флага.

// пустота = производное состояние
readonly isEmpty = computed(() => !this.loading() && !this.loadError() && this.tasks().length === 0);

20. Обработка ошибок: catchError и throwError

RxJS позволяет перехватить ошибку прямо в потоке оператором catchError.

import { catchError, throwError } from 'rxjs';

load(): void {
  this.http.get<Task[]>(url).pipe(      // создаём поток GET
    catchError(err => {                 // ловим сбой внутри pipe
      console.error(err);
      this.loadError.set(this.messageFrom(err));  // показываем сообщение
      return throwError(() => err);   // пробрасываем дальше в error-колбэк
    }),
  ).subscribe({                         // подписка запускает запрос
    next: t => { this.tasks.set(t); },
    error: e => this.loading.set(false),  // завершаем UI-состояние
  });
}

catchError перехватывает сбой, делает побочное действие и возвращает новый поток. throwError создаёт поток, который «упадёт» — так ошибка дойдёт до error-колбэка subscribe.

У subscribe есть три колбэка — по числу исходов потока:

.subscribe({
  next: d => { /* успех: есть данные */ },
  error: e => { /* сбой: показать сообщение */ },
  complete: () => { /* поток завершился (необязательно) */ },
});

• next — обычный результат.
• error — ошибка; поток на этом завершается.
• complete — успешное завершение без ошибки (опционально).

Для единичных HTTP-ответов чаще всего хватает next и error.

21. HTTP-статусы 4xx и 5xx

Чтобы сообщение было точным, полезно смотреть на статус ошибки. HttpErrorResponse хранит его в поле status.

function messageFrom(err: any): string {
  if (err.status === 404) return 'Задача не найдена';
  if (err.status >= 500) return 'Сервер недоступен, попробуйте позже';
  return 'Произошла ошибка запроса';
}

22. Интерцептор: логика на пути запросов

Интерцептор — функция, через которую проходят все HTTP-запросы и ответы. Удобно для логов, единых заголовков, обработки ошибок.

@Injectable()
export class LoggingInterceptor implements HttpInterceptor {
  intercept(req: HttpRequest<unknown>, next: HttpHandler) {
    console.log(req.method, req.url);
    return next.handle(req);
  }
}

// включить в провайдере
provideHttpClient(
  withInterceptors([(req, next) => {
    console.log(req.method, req.url);
    return next.handle(req);
  }]),
)

23. Откуда берётся URL: токен API_URL

Адрес API лучше выносить в конфигурацию, а не зашивать в каждый запрос. Используем InjectionToken из урока 6.

export const API_URL = new InjectionToken<string>('API_URL');

// в провайдерах
providers: [
  provideHttpClient(),
  { provide: API_URL, useValue: 'http://localhost:3000' },
]

// в сервисе
private readonly apiUrl = inject(API_URL);

Теперь сменить адрес на прод можно в одном месте.

24. Переход от локального массива к API

Быстрая смена источника данных: константа → HTTP-запрос.

// было (урок 6): сигнал с константой
private readonly tasks = signal<Task[]>(initialTasks);

// стало (урок 7): сигнал наполняется из API
readonly tasks = signal<Task[]>([]);
load(): void { ... this.tasks.set(...) }

Компоненты не заметят изменений: они по-прежнему читают s.tasksRO(). Меняется только «внутренности» сервиса.

Что именно меняется внутри:

• Инициализация: вместо initialTasks — пустой массив + вызов load().
• Начальные данные: приходят по GET, а не из константы.
• Мутации: add/toggle/remove шлют запрос и обновляют сигнал из ответа.
• Новое: появляются сигналы loading и loadError.

25. Контракт данных Task при работе с API

Модель Task остаётся контрактом между сервером и клиентом.

export interface Task {
  readonly id: number;
  title: string;
  completed: boolean;
  priority: Priority;
}

Поля должны совпадать с тем, что отдаёт json-server. Если сервер даёт, например, done вместо completed, стоит выровнять модель или преобразовать ответ.

.pipe(map(task => ({ ...task, completed: task.done })))

Отображение «формы сервера → формы клиента» называют адаптацией ответа. Оно полезно, когда:

• имена полей отличаются (done vs completed);
• сервер отдаёт лишние поля, не нужные модели;
• нужно добавить производные значения при поступлении.

.pipe(map(raw => raw.map(t => ({ id: t.id, title: t.title, completed: t.done, priority: t.priority }))))

26. Асинхронность и гонки запросов

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

// плохо: две подписки могут перезаписать данные
load();

// лучше: сбрасывать насыщение loading в начале каждого
load(): void {
  this.loading.set(true);
  // ...
}

Для простых CRUD-операций сервис обычно выполняет один запрос за раз. При росте сложности используют отмену (раздел 28.17) или стабилизацию.

27. Практика 1: запускаем json-server

Создаём базу и запускаем mock API.

# db.json в корне проекта
{
  "tasks": [
    { "id": 1, "title": "Настроить HTTP", "completed": false, "priority": "high" },
    { "id": 2, "title": "Загрузить список", "completed": true, "priority": "medium" },
    { "id": 3, "title": "Обработать ошибку", "completed": false, "priority": "low" }
  ]
}

# запуск
npx json-server db.json --port 3000

Откройте http://localhost:3000/tasks в браузере — увидите JSON со списком.

28. Практика 2: подключаем HttpClient

Включаем HTTP в корне приложения и внедряем его в сервис.

import { bootstrapApplication } from '@angular/platform-browser';
import { provideHttpClient } from '@angular/common/http';
import { App } from './app/app';

bootstrapApplication(App, {
  providers: [provideHttpClient()],
});

// task.service.ts
import { HttpClient } from '@angular/common/http';

@Injectable({ providedIn: 'root' })
export class TaskService {
  private readonly http = inject(HttpClient);
  private readonly apiUrl = 'http://localhost:3000';
}

После этого все методы сервиса могут делать HTTP-запросы. Ниже — детальная разборка каждого действия.

28.1. load: загрузка списка с типизацией

Полностью типизированная загрузка.

readonly tasks = signal<Task[]>([]);
readonly loading = signal(false);
readonly loadError = signal<string | null>(null);

load(): void {
  this.loading.set(true);                       // начинаем: показываем индикатор
  this.loadError.set(null);                     // сбрасываем старую ошибку
  this.http.get<Task[]>(this.apiUrl + '/tasks').pipe(  // GET-запрос к API
    catchError(err => {                        // перехват сбоя в потоке
      this.loadError.set('Не удалось загрузить задачи');
      return throwError(() => err);             // пробрасываем дальше в error
    }),
  ).subscribe({                                 // подписка реально отправляет запрос
    next: t => { this.tasks.set(t); this.loading.set(false); },   // успех: данные + выключить loading
    error: () => this.loading.set(false),       // сбой: тоже выключить loading
  });
}

Дженерик <Task[]> гарантирует, что в колбэке next мы работаем с массивом задач.

28.2. add / create: POST в сервис

Создание задачи с отправкой черновика.

add(draft: TaskDraft): void {
  const { title, priority } = draft;
  if (!title.trim()) return;                 // guard: не шлём пустой запрос
  // POST создаёт ресурс; тело — те поля, что ждёт сервер
  this.http.post<Task>(this.apiUrl + '/tasks', { title, completed: false, priority })
    .subscribe({
      next: created => this.tasks.update(xs => [...xs, created]),  // id приходит из ответа
      error: e => this.handleError(e),        // централизованная обработка ошибки
    });
}

Сервер присвоит id. Полученную задачу добавляем в конец списка.

Детали, на которые стоит обратить внимание:

• Тело POST — именно те поля, которые хочет сервер: title, completed, priority.
• id мы не отправляем — его генерирует json-server.
• Ответ <Task> содержит созданную задачу уже с id — её и добавляем.
• Guard на пустой title возвращает рано, не отправляя запрос (урок 2, guard clauses).

28.3. toggle: PATCH в сервис

Отмечаем задачу выполненной/активной.

toggle(id: number): void {
  const task = this.tasks().find(t => t.id === id);
  if (!task) return;                          // guard: нет задачи — не шлём запрос
  // PATCH меняет только переданное поле completed
  this.http.patch<Task>(`${this.apiUrl}/tasks/${id}`, { completed: !task.completed })
    .subscribe({
      next: updated => this.tasks.update(xs =>   // заменяем элемент ответом сервера
        xs.map(t => t.id === id ? updated : t)),
      error: e => this.handleError(e),
    });
}

Находим текущее значение, отправляем противоположное, заменяем в списке ответом сервера.

Шаги операции:

1. Найти задачу в сигнале по id (find из урока 2).
2. Если её нет — выйти (guard), не слать запрос.
3. Отправить PATCH с противоположным completed.
4. Заменить элемент на обновлённый ответ сервера (map).

28.4. remove: DELETE в сервис

Удаление задачи.

remove(id: number): void {
  // DELETE удаляет ресурс; тело ответа пустое — тип void
  this.http.delete<void>(`${this.apiUrl}/tasks/${id}`)
    .subscribe({
      next: () => this.tasks.update(xs => xs.filter(t => t.id !== id)),  // убираем из списка
      error: e => this.handleError(e),
    });
}

После серверного удаления убираем id из сигнала. Если сервер вернул ошибку, задача останется — UI не рассинхронизируется с данными.

Пояснение к типам и ожиданиям:

• DELETE обычно возвращает 204 No Content — поэтому тип <void>.
• Нам не нужен ответ, нужно подтверждение; колбэк next просто фильтрует список.
• json-server по умолчанию возвращает удалённый объект — это тоже нормально, просто мы его игнорируем.

28.5. loading и error в сервисе

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

private handleError(err: HttpErrorResponse): void {
  this.loading.set(false);
  if (err.status >= 500) {
    this.loadError.set('Сервер недоступен');
  } else if (err.status === 404) {
    this.loadError.set('Задача не найдена');
  } else {
    this.loadError.set(`Ошибка запроса (${err.status || 'сеть'})`);
  }
}

Единая точка превращает любой сбой в понятное пользователю сообщение.

Обратите внимание на порядок проверки:

1. status >= 500 — серверная ошибка, повторять бессмысленно сейчас.
2. status === 404 — ресурс не найден.
3. иначе — общая ошибка; а status === 0 означает «нет сети/сервер не запущен».

Если несколько запросов должны вызывать один и тот же «переключатель загрузки», удобнее не ставить loading.set(false) в каждом колбэке, а воспользоваться finalize (раздел 28.16).

28.6. Практика 3: полный сервис на HTTP

Собираем все кусочки в один сервис.

@Injectable({ providedIn: 'root' })
export class TaskService {
  private readonly http = inject(HttpClient);
  private readonly apiUrl = 'http://localhost:3000';

  readonly tasks = signal<Task[]>([]);
  readonly loading = signal(false);
  readonly loadError = signal<string | null>(null);
  private 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();
  });

  load(): void { ... }
  add(draft: TaskDraft): void { ... }
  toggle(id: number): void { ... }
  remove(id: number): void { ... }
  setFilter(f: TaskFilter): void { this.filter.set(f); }
}

Это и есть TaskService с сетью: хранилище, производные и транспорт в одном месте (дальше можно разделить — раздел 28.13).

28.7. Компонент: читаем сигналы

Компонент-представление ничего не знает о сети.

@Component({
  selector: 'app-task-list',
  standalone: true,
  template: `
    @if (s.loading()) {
      <div class="loading">Загрузка…</div>
    } @else if (s.loadError()) {
      <div class="error">{{ s.loadError() }}</div>
    } @else if (s.tasks().length === 0) {
      <div class="empty">Задач пока нет</div>
    } @else {
      @for (task of s.visibleTasks(); track task.id) {
        <app-task-item [task]="task" />
      }
    }
  `,
})
export class TaskList {
  readonly s = inject(TaskService);

  ngOnInit() {
    this.s.load();
  }
}

28.8. Компонент: инициализация запроса

Запрос load запускаем один раз при создании компонента — например, в ngOnInit.

import { Component, OnInit, inject } from '@angular/core';

export class TaskList implements OnInit {
  ngOnInit() {
    this.s.load();
  }
}

ngOnInit срабатывает после привязки входных свойств — подходящее место для первичной загрузки.

Почему именно здесь:

• На этом этапе входные свойства (input()) уже заполнены.
• Компонент готов к работе: можно активировать подписки и запросы.
• Один вызов в ngOnInit = одна загрузка за время жизни компонента.

28.9. Практика 4: состояния в шаблоне

Полный переключатель состояний с кнопкой повтора.

@if (s.loading()) {
  <div class="state loading">Загрузка задач…</div>
} @else if (s.loadError()) {
  <div class="state error">
    <p>{{ s.loadError() }}</p>
    <button (click)="s.load()">Повторить</button>
  </div>
} @else if (s.tasks().length === 0) {
  <div class="state empty">Пока нет задач. Добавьте первую!</div>
} @else {
  <app-task-list />
}

Кнопка «Повторить» перезапускает load — удобный приём для сетевых ошибок.

Разберём порядок проверки в шаблоне:

1. loading — показываем индикатор, чтобы пользователь понял, что идёт работа.
2. loadError — сбой: сообщение и кнопка «Повторить».
3. empty — успех, но задач нет: приглашение добавить первую.
4. иначе — успех и есть данные: рендерим список.

Порядок @else-if задаёт приоритет: загрузка и ошибка важнее пустоты. Так пользователь видит именно актуальное состояние.

28.10. Debug в DevTools/Network

Вкладка Network браузера показывает каждый HTTP-запрос: метод, URL, статус, время, тело.

• Откройте DevTools (F12) → Network.
• Перезагрузите страницу — увидите GET /tasks.
• Создайте задачу — появится POST /tasks с телом в вкладке Payload.
• Если запрос красный — это ошибка 4xx/5xx, смотрите статус и Response.

На что смотреть в каждой строке Network:

28.11. Практика 5: полный CRUD-цикл

Пройдём сценарий пользователя от начала до конца.

1. load()             → GET /tasks          → список на экране
2. add(draft)         → POST /tasks         → новая в списке
3. toggle(id)         → PATCH /tasks/:id    → отмечена
4. remove(id)         → DELETE /tasks/:id   → исчезла

Проверьте в Network, что каждый шаг соответствует своему HTTP-методу и URL.

Связь сценариев пользователя (урок 1, раздел 34) и HTTP-операций:

28.12. Observable холодный и горячий

Холодный Observable создаёт новую «работу» для каждой подписки; горячий — один поток для всех.

// HTTP-запрос: холодный
const obs = this.http.get<Task[]>(url);
obs.subscribe();   // запрос 1
obs.subscribe();   // запрос 2 (ещё один GET)

Два subscribe сделали два GET-запроса. Для одиночного HTTP-ответа это нормально. Для общего потока данных иногда нужен shareReplay, чтобы не дублировать подписки.

28.13. Собственный ApiClient поверх HttpClient

Чтобы разделить транспорт и хранилище, выделим отдельный сервис-клиент.

@Injectable({ providedIn: 'root' })
export class TaskApi {
  private readonly http = inject(HttpClient);
  private readonly apiUrl = inject(API_URL);

  list(): Observable<Task[]> {
    return this.http.get<Task[]>(this.apiUrl + '/tasks');
  }
  create(draft): Observable<Task> {
    return this.http.post<Task>(this.apiUrl + '/tasks', draft);
  }
  update(id, patch): Observable<Task> {
    return this.http.patch<Task>(`${this.apiUrl}/tasks/${id}`, patch);
  }
  delete(id): Observable<void> {
    return this.http.delete<void>(`${this.apiUrl}/tasks/${id}`);
  }
}

TaskService внедряет TaskApi и превращает Observable в сигналы. Компоненты по-прежнему видят только сигналы.

28.14. httpOptions и заголовки

Иногда запросу нужны дополнительные параметры: заголовки, query-параметры.

import { HttpHeaders, HttpParams } from '@angular/common/http';

const options = {
  headers: new HttpHeaders({ 'Content-Type': 'application/json' }),
  params: new HttpParams().set('_sort', 'priority'),
};

this.http.get<Task[]>(url, options);

Заголовки описывают запрос (формат, токен), query-параметры — фильтры сервера. json-server понимает _sort, _limit, q и др.

28.15. Синтаксис catchError и работа с ошибкой

Разберём, как catchError сочетается с error-колбэком.

this.http.get<Task[]>(url).pipe(
  catchError(err => {
    this.loadError.set(this.messageFrom(err));
    return throwError(() => err);   // продолжить как ошибку
  }),
).subscribe({
  next: d => this.tasks.set(d),
  error: e => this.loading.set(false),   // также сработает после catchError
});

catchError выполняет побочное действие (ставит сообщение), а throwError «прокидывает» ошибку в error-колбэк, где завершаем UI-состояние.

28.16. finally / поляризация UI-состояний

Действие «в любом случае» (успех или ошибка) удобно положить в finalize.

import { catchError, finalize, throwError } from 'rxjs';

load(): void {
  this.loading.set(true);
  this.http.get<Task[]>(url).pipe(
    catchError(err => { this.loadError.set(...); return throwError(() => err); }),
    finalize(() => this.loading.set(false)),
  ).subscribe({
    next: d => this.tasks.set(d),
  });
}

finalize срабатывает при завершении потока в любом исходе — удобно для выключения loading в одном месте.

28.17. Отмена запросов и утечки памяти

Если компонент уничтожен, подписка на Observable всё ещё жива. Хорошая практика — отписываться.

private sub?: Subscription;

ngOnInit() { this.sub = this.s.load$().subscribe(...); }

ngOnDestroy() { this.sub?.unsubscribe(); }

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

28.18. Сравнение с fetch и async/await

Сведём наблюдения: тот же запрос двумя способами.

// fetch (урок 2) — асинхронный/ожидающий
async function loadTasks() {
  const res = await fetch('/tasks');
  if (!res.ok) throw new Error(res.status);
  return res.json();
}

// HttpClient — потоковый
loadTasks() {
  return this.http.get<Task[]>('/tasks');
}

HttpClient «встроен» в Angular и интегрирован с реактивностью. fetch — универсальный и тоже валидный выбор. Понимание обоих — цель курса.

28.19. Архитектура: слой data и слой transport

Соберём полную схему нашего приложения после урока 7.

Шаблон (computed, @if/@for)
   │  читает сигналы
Компоненты
   │  inject
TaskService (хранилище: tasks/loading/error, computed)
   │  вызывает методы API
TaskApi (транспорт: HttpClient, URL, JSON)
   │  HTTP
json-server :3000

Компоненты не знают о сети. TaskService не знает об URL-деталях. TaskApi не знает о шаблоне. Каждый слой отвечает за своё.

28.20. Сетевые ошибки: сервер не запущен

Когда json-server не запущен или недоступен, браузер не получает никакого HTTP-кода — соединение просто не устанавливается.

GET http://localhost:3000/tasks  →  (failed) net::ERR_CONNECTION_REFUSED

HttpClient при этом даёт ошибку с status = 0. Именно это значение отличает «нет связи» от «сервер вернул ошибку».

if (err.status === 0) {
  this.loadError.set('Сервер не отвечает. Проверьте, запущен ли json-server');
}

28.21. Отладка 404: адрес или данные

404 «не найдено» бывает по двум причинам:

1. Неверный URL (описка, не та коллекция).
2. Нет ресурса с таким id (например, /tasks/999).

GET /tasks        → 200 (список)
GET /task         → 404 (описка — нет коллекции task)
GET /tasks/999    → 404 (нет такой задачи)

Проверьте имя коллекции в db.json и точность URL в коде. В Network видно, по какому фактическому адресу ушёл запрос.

28.22. Имитация медленной сети и задержки

Чтобы увидеть состояние loading в действии, добавьте задержку на ответ сервера.

// json-server: задержка 1000 мс на все ответы
npx json-server db.json --port 3000 --delay 1000

С такими настройками spinner «Загрузка…» станет заметным, и вы убедитесь, что блоки @if переключаются верно.

@if (s.loading()) {
  <div class="state loading">Загрузка…</div>
}

28.23. Пагинация и query-параметры json-server

json-server поддерживает параметры «на стороне сервера»: сортировку, лимит, страницы.

GET /tasks?_page=1&_limit=10      // первая страница по 10
GET /tasks?_sort=priority&_order=desc
GET /tasks?completed=true          // фильтр по полю
GET /tasks?q=keyword               // поиск по строкам

const params = new HttpParams()
  .set('_sort', 'priority')
  .set('_order', 'desc');

this.http.get<Task[]>(url, { params });

В TaskFlow фильтрацию по статусу мы пока делаем локально через computed (урок 6). Серверные query-параметры пригодятся для больших наборов.

28.24. CORS: почему браузер блокирует запросы

CORS (Cross-Origin Resource Sharing) — политика браузера, ограничивающая запросы на другой домен/порт.

Angular (localhost:4200)  →  API (localhost:3000)  // другой порт = другой origin

Браузер блокирует ответ, если сервер не разрешает origin. json-server по умолчанию разрешает и добавляет заголовки CORS — поэтому локально всё работает.

28.25. Миграция: от локального массива к API по шагам

Переносим TaskFlow на HTTP без риска сломать интерфейс.

1. Запустить json-server и проверить /tasks в браузере.
2. Включить provideHttpClient и внедрить HttpClient в TaskService.
3. Добавить метод load(), который заполняет сигнал tasks из GET.
4. Заменить add/toggle/remove: вместо локального изменения — HTTP + обновление из ответа.
5. Добавить сигналы loading/loadError и ветки @if в шаблонах.
6. Убрать константу initialTasks и вызовы локальной инициализации.

28.26. Кэширование и shareReplay

Если несколько компонентов подписываются на один GET, каждый subscribe сделает новый запрос. Чтобы делить один ответ, используют shareReplay.

import { shareReplay, Observable } from 'rxjs';

private readonly cache$?: Observable<Task[]>;

list(): Observable<Task[]> {
  if (!this.cache$) {
    this.cache$ = this.http.get<Task[]>(url).pipe(
      shareReplay(1),
    );
  }
  return this.cache$;
}

Первый subscribe запускает запрос; остальные получают тот же результат, не обращаясь к сети повторно.

28.27. Интерцептор для единой обработки ошибок

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

export function apiErrorsInterceptor(req: HttpRequest<unknown>, next: HttpHandler) {
  return next.handle(req).pipe(
    catchError((err) => {
      const msg = err.status === 0
        ? 'Нет связи с сервером'
        : `Ошибка ${err.status}`;
      console.error(msg);
      return throwError(() => err);
    }),
  );
}

bootstrapApplication(App, {
  providers: [provideHttpClient(withInterceptors([apiErrorsInterceptor]))],
});

Теперь любая ошибка HTTP-запроса проходит через наш код, но поток по-прежнему падает, и каждая подписка может обработать её по-своему.

28.28. Авторизация-заголовки и конфиденциальность

Реальные API часто требуют заголовок авторизации: токен, который показывает, кто вы.

const headers = new HttpHeaders({
  'Authorization': 'Bearer ' + token,
});

this.http.get<Task[]>(url, { headers });

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

28.29. Работа с вложенными данными и коллекциями

Иногда API отдаёт не массив, а объект-обёртку с метаданными.

{
  "items": [ ... ],
  "total": 120,
  "page": 1
}

interface Page<T> {
  items: T[];
  total: number;
  page: number;
}

this.http.get<Page<Task>>(url).pipe(
  map(page => page.items),
).subscribe(items => this.tasks.set(items));

Дженерик помогает описать любую форму ответа. Оператор map достаёт нужную часть перед записью в сигнал.

28.30. Идемпотентность и повторные попытки

Сетевые запросы могут «теряться». Если результат неизменен при повторении (идемпотентная операция), повторная попытка безопасна.

import { retry } from 'rxjs';

this.http.get<Task[]>(url).pipe(
  retry(1),   // одна повторная попытка при сбое
);

GET безопасно повторить. POST/PATCH/DELETE повторять рискованно — можно создать дубликат. Поэтому сначала учимся повторять только чтения.

28.31. Сравнение fetch/Promise-версии с нашей

Покажем, как бы выглядел тот же TaskService на fetch, чтобы увидеть разницу (подробно — React-урок 18).

// fetch-версия (Promise)
async loadTasks() {
  const res = await fetch('/tasks');
  if (!res.ok) throw new Error('HTTP ' + res.status);
  this.tasks.set(await res.json());
}

// HttpClient-версия (Observable)
loadTasks() {
  return this.http.get<Task[]>('/tasks')
    .subscribe(t => this.tasks.set(t));
}

Обе решают одну задачу. Разница в интеграции: Observable вписан в реактивную систему Angular, Promise — универсальный стандарт JS.

28.32. Почему сначала local computed, а не серверный фильтр

В TaskFlow фильтрация «все/активные/выполненные» остаётся локальной — computed в сервисе. Почему?

• Набор задач небольшой — мгновенно фильтруется в памяти.
• Без лишних запросов UI остаётся отзывчивым.
• Логика фильтра уже написана в уроке 6 и переиспользуется.

Серверный фильтр (query-параметры) имел бы смысл для тысяч задач, когда скачивать всё дорого. Пока — локально.

28.33. Полный листинг: TaskApi + TaskService вместе

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

// task-api.ts — транспорт
@Injectable({ providedIn: 'root' })
export class TaskApi {
  private readonly http = inject(HttpClient);
  private readonly url = inject(API_URL) + '/tasks';
  list()         { return this.http.get<Task[]>(this.url); }
  create(d)      { return this.http.post<Task>(this.url, d) }
  patch(id, p)   { return this.http.patch<Task>(`${this.url}/${id}`, p); }
  delete(id)     { return this.http.delete<void>(`${this.url}/${id}`); }
}

// task.service.ts — хранилище
@Injectable({ providedIn: 'root' })
export class TaskService {
  private readonly api = inject(TaskApi);
  readonly tasks = signal<Task[]>([]);
  readonly loading = signal(false);
  readonly loadError = signal<string | null>(null);

  load() {
    this.loading.set(true);
    this.api.list().pipe(
      catchError(e => { this.loadError.set(this.msg(e)); return throwError(() => e); }),
      finalize(() => this.loading.set(false)),
    ).subscribe(t => this.tasks.set(t));
  }
  // add / toggle / remove — аналогично через this.api
}

Компоненты видят только TaskService и его сигналы. Эта структура станет эталоном и для других курсовых сценариев.

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

Восемь заданий на HTTP и клиента API. Сначала сделайте сами, затем сверьтесь с подсказками.

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

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

31. Частые ошибки HTTP и HttpClient

Соберём типичные проблемы и их решения.

32. Резюме: TaskService как клиент API

Пять правил работы с HTTP в Angular.

• HTTP включают через provideHttpClient, клиент получают через inject(HttpClient).
• HttpClient возвращает Observable; запрос стартует только при subscribe.
• Ответы типизируют дженериками: get<Task[]>, post<Task>.
• CRUD: GET (читать), POST (создать), PATCH (обновить), DELETE (удалить).
• Состояние загрузки держат в сигналах loading/error и отражают в шаблоне @if.

Дополнительные наблюдения из урока:

• Observable «ленивый»: HTTP-запрос начинается только при subscribe.
• Провайдер provideHttpClient необходим, иначе inject(HttpClient) упрёт в «No provider».
• Ошибки делят на сетевые (status 0), клиентские (4xx) и серверные (5xx).
• Транспорт (TaskApi) отделяют от хранилища (TaskService) для чистоты.
• Фильтрация остаётся локальной (computed), пока данные небольшие.
• Network в DevTools — главный помощник в отладке каждого запроса.

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

Ответьте своими словами, затем сверьтесь с конспектом.

1. Что такое mock API и зачем он нужен?
2. Зачем нужен provideHttpClient?
3. Чем Observable отличается от Promise (мост из урока 2)?
4. Что делает subscribe и почему без него запрос не уходит?
5. Как типизировать ответ GET через дженерик?
6. Какой метод для создания, обновления, удаления задачи?
7. Чем PATCH отличается от PUT?
8. Как показать loading, empty и error в шаблоне?
9. Что делает catchError и зачем throwError?
10. Как определить статус ошибки (404, 500, сеть)?
11. Как разделить транспорт и хранилище (TaskApi vs TaskService)?
12. Что даёт разделение на слой данных и слой транспорта?
13. Что означает «холодный» Observable и как это влияет на запросы?
14. Зачем интерцепторы и как добавить общий лог?
15. Как отличить сетевую ошибку (status 0) от HTTP-кода?
16. Когда фильтрацию стоит перенести с сервера на клиента и наоборот?
17. Что такое CORS и почему json-server его не вызывает?
18. Зачем нужен finalize вместо ручного выключения loading в двух местах?

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

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

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

• Официальная документация Angular: HttpClient и RxJS Observable.
• Документация json-server: примеси, query-параметры, маршруты.
• Материалы урока 2 (разделы 39, 44) про JSON из API и generics.
• Материалы урока 6 (раздел 28.17) про слой данных и TaskApiClient.

Рекомендуемый порядок повторения:

1. Перечитать разделы 28.1–28.6 (полный сервис на HTTP).
2. Выполнить задания раздела 29 без подсказок.
3. Отладить каждый запрос через Network и сравнить с ожиданиями.
4. Проследить архитектурную схему раздела 28.19.

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

• Я запускаю json-server и вижу /tasks в браузере.
• Я подключил provideHttpClient и внедрил HttpClient.
• Я понимаю, что HttpClient возвращает Observable и требует subscribe.
• Я типизирую ответы через generics (get<Task[]> и т.д.).
• Я реализовал CRUD: GET, POST, PATCH, DELETE.
• Я показываю loading, empty и error в шаблоне.
• Я обрабатываю ошибки через catchError и определяю статус.
• Я отлаживаю запросы во вкладке Network.
• Я разделяю слой данных и слой транспорта (TaskApi).
• Я могу объяснить разницу Promise и Observable.
• Я отлаживаю и сетевые ошибки (status 0), и HTTP-статусы.
• Я умею добавлять задержку на сервер для демонстрации loading.
• Я знаю про query-параметры и пагинацию json-server.
• Я понимаю интерцепторы и токен API_URL.
• Я слежу за отписками и избегаю утечек в компонентах.
• Я могу перенести приложение с локального массива на API по шагам.

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

Подключите сервис к mock API через HttpClient и обработайте состояния UI.

Задание 1. CRUD через HttpClient

getAll()   { return this.http.get<Task[]>(this.base); }
create(d)  { return this.http.post<Task>(this.base, d); }
update(t)  { return this.http.patch<Task>(`${this.base}/${t.id}`, t); }
remove(id) { return this.http.delete<void>(`${this.base}/${id}`); }

Задание 2. Обработка ошибок

return this.http.get<Task[]>(this.base).pipe(
  catchError(err => { console.error(err); return of<Task[]>([]); })
);