# Создание банковского приложения, часть 1: HTML-шаблоны и маршруты в веб-приложении
Когда навигационный компьютер Apollo 11 вел корабль к Луне в 1969 году, он переключался между различными программами, не перезагружая всю систему. Современные веб-приложения работают аналогично — они изменяют то, что вы видите, без полной перезагрузки. Это создает плавный и отзывчивый интерфейс, который пользователи ожидают сегодня.
В отличие от традиционных веб-сайтов, которые перезагружают целые страницы при каждом взаимодействии, современные веб-приложения обновляют только те части, которые необходимо изменить. Этот подход, подобно тому, как центр управления миссией переключается между различными дисплеями, поддерживая постоянную связь, создает тот самый плавный опыт, к которому мы привыкли.
Вот что делает разницу такой заметной:
| Традиционные многостраничные приложения | Современные одностраничные приложения |
|-----------------------------------------|---------------------------------------|
| **Навигация** | Полная перезагрузка страницы для каждого экрана | Мгновенное переключение контента |
| **Производительность** | Медленнее из-за загрузки полного HTML | Быстрее благодаря частичным обновлениям |
| **Пользовательский опыт** | Резкие вспышки страниц | Плавные переходы, похожие на приложения |
| **Обмен данными** | Сложно между страницами | Легкое управление состоянием |
| **Разработка** | Множество HTML-файлов для поддержки | Один HTML с динамическими шаблонами |
**Понимание эволюции:**
- **Традиционные приложения** требуют запросов к серверу для каждого действия навигации
- **Современные SPA** загружаются один раз и динамически обновляют контент с помощью JavaScript
- **Ожидания пользователей** теперь ориентированы на мгновенные, бесшовные взаимодействия
- **Преимущества производительности** включают уменьшение объема передаваемых данных и более быстрые ответы
В этом уроке мы создадим банковское приложение с несколькими экранами, которые плавно переходят друг в друга. Как ученые используют модульные инструменты, которые можно перенастроить для различных экспериментов, мы будем использовать HTML-шаблоны как повторно используемые компоненты, которые можно отображать по мере необходимости.
Вы будете работать с HTML-шаблонами (повторно используемыми чертежами для различных экранов), маршрутизацией на JavaScript (система, которая переключает экраны) и API истории браузера (который обеспечивает корректную работу кнопки "Назад"). Это те же самые фундаментальные техники, которые используются в таких фреймворках, как React, Vue и Angular.
К концу урока у вас будет рабочее банковское приложение, демонстрирующее профессиональные принципы одностраничных приложений.
## Предварительный тест
[Предварительный тест](https://ff-quizzes.netlify.app/web/quiz/41)
### Что вам понадобится
Нам понадобится локальный веб-сервер для тестирования нашего банковского приложения — не волнуйтесь, это проще, чем кажется! Если у вас его еще нет, просто установите [Node.js](https://nodejs.org) и выполните команду `npx lite-server` из папки вашего проекта. Эта удобная команда запускает локальный сервер и автоматически открывает ваше приложение в браузере.
### Подготовка
На вашем компьютере создайте папку с именем `bank` и файл с именем `index.html` внутри нее. Мы начнем с этого [шаблона HTML](https://en.wikipedia.org/wiki/Boilerplate_code):
```html
Bank App
```
**Что предоставляет этот шаблон:**
- **Устанавливает** структуру документа HTML5 с правильным объявлением DOCTYPE
- **Настраивает** кодировку символов как UTF-8 для поддержки международного текста
- **Включает** адаптивный дизайн с метатегом viewport для совместимости с мобильными устройствами
- **Устанавливает** описательный заголовок, который отображается на вкладке браузера
- **Создает** чистый раздел body, где мы будем строить наше приложение
> 📁 **Предварительный обзор структуры проекта**
>
> **К концу этого урока ваш проект будет содержать:**
> ```
> bank/
> ├── index.html
> ├── app.js
> └── style.css
> ```
>
> **Ответственность файлов:**
> - **index.html**: Содержит все шаблоны и обеспечивает структуру приложения
> - **app.js**: Управляет маршрутизацией, навигацией и управлением шаблонами
> - **Шаблоны**: Определяют пользовательский интерфейс для входа, панели управления и других экранов
---
## HTML-шаблоны
Шаблоны решают фундаментальную проблему веб-разработки. Когда Гутенберг изобрел печатный станок с подвижными литерами в 1440-х годах, он понял, что вместо того, чтобы вырезать целые страницы, можно создать повторно используемые блоки букв и расставлять их по мере необходимости. HTML-шаблоны работают по тому же принципу — вместо создания отдельных HTML-файлов для каждого экрана вы определяете повторно используемые структуры, которые можно отображать по мере необходимости.
Думайте о шаблонах как о чертежах для различных частей вашего приложения. Как архитектор создает один чертеж и использует его несколько раз, а не перерисовывает одинаковые комнаты, мы создаем шаблоны один раз и используем их по мере необходимости. Браузер держит эти шаблоны скрытыми, пока JavaScript не активирует их.
Если вы хотите создать несколько экранов для веб-страницы, одним из решений было бы создать один HTML-файл для каждого экрана, который вы хотите отобразить. Однако это решение имеет некоторые неудобства:
- Вам придется перезагружать весь HTML при переключении экрана, что может быть медленным.
- Сложно обмениваться данными между различными экранами.
Другой подход — иметь только один HTML-файл и определить несколько [HTML-шаблонов](https://developer.mozilla.org/docs/Web/HTML/Element/template) с использованием элемента ``. Шаблон — это повторно используемый HTML-блок, который не отображается браузером и должен быть создан во время выполнения с помощью JavaScript.
### Давайте создадим
Мы собираемся создать банковское приложение с двумя основными экранами: страницей входа и панелью управления. Сначала добавим элемент-заполнитель в тело HTML — здесь будут отображаться все наши разные экраны:
```html
Loading...
```
**Понимание этого заполнителя:**
- **Создает** контейнер с идентификатором "app", где будут отображаться все экраны
- **Показывает** сообщение о загрузке, пока JavaScript не инициализирует первый экран
- **Обеспечивает** единую точку монтирования для нашего динамического контента
- **Позволяет** легко обращаться к элементу из JavaScript с помощью `document.getElementById()`
> 💡 **Полезный совет**: Поскольку содержимое этого элемента будет заменено, мы можем добавить сообщение о загрузке или индикатор, который будет отображаться, пока приложение загружается.
Далее добавим HTML-шаблон для страницы входа. Пока мы добавим туда только заголовок и раздел, содержащий ссылку, которую мы будем использовать для навигации.
```html
Bank App
```
**Разбор шаблона страницы входа:**
- **Определяет** шаблон с уникальным идентификатором "login" для обращения через JavaScript
- **Включает** основной заголовок, который устанавливает бренд приложения
- **Содержит** семантический элемент `` для группировки связанного контента
- **Предоставляет** навигационную ссылку, которая будет перенаправлять пользователей на панель управления
Затем добавим еще один HTML-шаблон для страницы панели управления. Эта страница будет содержать различные разделы:
- Заголовок с названием и ссылкой для выхода
- Текущий баланс банковского счета
- Список транзакций, отображаемый в таблице
```html
```
**Разберем каждую часть панели управления:**
- **Структурирует** страницу с помощью семантического элемента ``, содержащего навигацию
- **Отображает** название приложения на всех экранах для узнаваемости бренда
- **Предоставляет** ссылку для выхода, которая перенаправляет обратно на экран входа
- **Показывает** текущий баланс счета в выделенном разделе
- **Организует** данные о транзакциях с использованием правильно структурированной HTML-таблицы
- **Определяет** заголовки таблицы для столбцов Дата, Объект и Сумма
- **Оставляет** тело таблицы пустым для последующего динамического заполнения контента
> 💡 **Полезный совет**: При создании HTML-шаблонов, если вы хотите увидеть, как они будут выглядеть, вы можете закомментировать строки `` и ``, заключив их в ``.
✅ Почему, по вашему мнению, мы используем атрибуты `id` для шаблонов? Могли бы мы использовать что-то другое, например классы?
## Оживляем шаблоны с помощью JavaScript
Теперь нам нужно сделать наши шаблоны функциональными. Как 3D-принтер берет цифровой чертеж и создает физический объект, JavaScript берет наши скрытые шаблоны и создает видимые, интерактивные элементы, которые пользователи могут видеть и использовать.
Процесс состоит из трех последовательных шагов, которые формируют основу современной веб-разработки. Как только вы поймете этот шаблон, вы узнаете его во многих фреймворках и библиотеках.
Если вы попробуете открыть текущий HTML-файл в браузере, вы увидите, что он застрял на отображении `Loading...`. Это потому, что нам нужно добавить немного JavaScript-кода, чтобы создать и отобразить HTML-шаблоны.
Создание экземпляра шаблона обычно выполняется в 3 шага:
1. Найти элемент шаблона в DOM, например, используя [`document.getElementById`](https://developer.mozilla.org/docs/Web/API/Document/getElementById).
2. Клонировать элемент шаблона, используя [`cloneNode`](https://developer.mozilla.org/docs/Web/API/Node/cloneNode).
3. Присоединить его к DOM под видимым элементом, например, используя [`appendChild`](https://developer.mozilla.org/docs/Web/API/Node/appendChild).
```mermaid
flowchart TD
A[🔍 Step 1: Find Template] --> B[📋 Step 2: Clone Template]
B --> C[🔗 Step 3: Attach to DOM]
A1["document.getElementById('login')"] --> A
B1["template.content.cloneNode(true)"] --> B
C1["app.appendChild(view)"] --> C
C --> D[👁️ Template Visible to User]
style A fill:#e1f5fe
style B fill:#f3e5f5
style C fill:#e8f5e8
style D fill:#fff3e0
```
**Визуальный разбор процесса:**
- **Шаг 1** находит скрытый шаблон в структуре DOM
- **Шаг 2** создает рабочую копию, которую можно безопасно модифицировать
- **Шаг 3** вставляет копию в видимую область страницы
- **Результат** — функциональный экран, с которым пользователи могут взаимодействовать
✅ Почему нам нужно клонировать шаблон перед его присоединением к DOM? Что, по вашему мнению, произойдет, если мы пропустим этот шаг?
### Задание
Создайте новый файл с именем `app.js` в папке вашего проекта и импортируйте этот файл в секцию `` вашего HTML:
```html
```
**Понимание этого импорта скрипта:**
- **Связывает** файл JavaScript с нашим HTML-документом
- **Использует** атрибут `defer`, чтобы скрипт выполнялся после завершения парсинга HTML
- **Обеспечивает** доступ ко всем элементам DOM, так как они полностью загружены перед выполнением скрипта
- **Следует** современным лучшим практикам загрузки скриптов и производительности
Теперь в `app.js` мы создадим новую функцию `updateRoute`:
```js
function updateRoute(templateId) {
const template = document.getElementById(templateId);
const view = template.content.cloneNode(true);
const app = document.getElementById('app');
app.innerHTML = '';
app.appendChild(view);
}
```
**Шаг за шагом, что здесь происходит:**
- **Находит** элемент шаблона, используя его уникальный идентификатор
- **Создает** глубокую копию содержимого шаблона с помощью `cloneNode(true)`
- **Находит** контейнер приложения, где будет отображаться контент
- **Очищает** любой существующий контент из контейнера приложения
- **Вставляет** клонированное содержимое шаблона в видимый DOM
Теперь вызовите эту функцию с одним из шаблонов и посмотрите на результат.
```js
updateRoute('login');
```
**Что делает этот вызов функции:**
- **Активирует** шаблон входа, передавая его идентификатор в качестве параметра
- **Демонстрирует**, как программно переключаться между различными экранами приложения
- **Отображает** экран входа вместо сообщения "Loading..."
✅ Какова цель этого кода `app.innerHTML = '';`? Что произойдет без него?
## Создание маршрутов
Маршрутизация — это, по сути, соединение URL-адресов с правильным контентом. Представьте, как ранние телефонные операторы использовали коммутаторы для соединения звонков — они принимали входящий запрос и направляли его в нужное место. Веб-маршрутизация работает аналогично, принимая запрос URL и определяя, какой контент отображать.
Традиционно веб-серверы обрабатывали это, предоставляя разные HTML-файлы для разных URL-адресов. Поскольку мы создаем одностраничное приложение, нам нужно самостоятельно обрабатывать эту маршрутизацию с помощью JavaScript. Такой подход дает нам больше контроля над пользовательским опытом и производительностью.
```mermaid
flowchart LR
A["🌐 URL Path
/dashboard"] --> B["🗺️ Routes Object
Lookup"]
B --> C["🎯 Template ID
'dashboard'"]
C --> D["📄 Find Template
getElementById"]
D --> E["👁️ Display Screen
Clone & Append"]
F["📍 /login"] --> G["🎯 'login'"]
H["📍 /unknown"] --> I["❌ Not Found"]
I --> J["🔄 Redirect to /login"]
style B fill:#e3f2fd
style E fill:#e8f5e8
style I fill:#ffebee
style J fill:#fff3e0
```
**Понимание потока маршрутизации:**
- **Изменения URL** запускают поиск в конфигурации маршрутов
- **Допустимые маршруты** сопоставляются с конкретными идентификаторами шаблонов для рендеринга
- **Недопустимые маршруты** запускают резервное поведение, чтобы предотвратить ошибки
- **Рендеринг шаблонов** следует изученному ранее трехэтапному процессу
Когда мы говорим о веб-приложении, мы называем *маршрутизацией* намерение сопоставить **URL-адреса** с конкретными экранами, которые должны быть отображены. На сайте с несколькими HTML-файлами это делается автоматически, так как пути к файлам отражаются в URL. Например, с этими файлами в вашей папке проекта:
```
mywebsite/index.html
mywebsite/login.html
mywebsite/admin/index.html
```
Если вы создадите веб-сервер с корнем `mywebsite`, то сопоставление URL будет следующим:
```
https://site.com --> mywebsite/index.html
https://site.com/login.html --> mywebsite/login.html
https://site.com/admin/ --> mywebsite/admin/index.html
```
Однако для нашего веб-приложения мы используем один HTML-файл, содержащий все экраны, поэтому это поведение по умолчанию нам не поможет. Мы должны создать эту карту вручную и обновить отображаемый шаблон с помощью JavaScript.
### Задание
Мы будем использовать простой объект для реализации [карты](https://en.wikipedia.org/wiki/Associative_array) между путями URL и нашими шаблонами. Добавьте этот объект в начало вашего файла `app.js`.
```js
const routes = {
'/login': { templateId: 'login' },
'/dashboard': { templateId: 'dashboard' },
};
```
**Понимание этой конфигурации маршрутов:**
- **Определяет** сопоставление между путями URL и идентификаторами шаблонов
- **Использует** синтаксис объекта, где ключи — пути URL, а значения содержат информацию о шаблонах
- **Обеспечивает** легкий поиск, какой шаблон отображать для любого заданного URL
- **Предоставляет** масштабируемую структуру для добавления новых маршрутов в будущем
Теперь немного изменим функцию `updateRoute`. Вместо того чтобы передавать непосредственно `templateId` в качестве аргумента, мы хотим сначала получить текущий URL, а затем использовать нашу карту для получения соответствующего значения идентификатора шаблона. Мы можем использовать [`window.location.pathname`](https://developer.mozilla.org/docs/Web/API/Location/pathname), чтобы получить только раздел пути из URL.
```js
function updateRoute() {
const path = window.location.pathname;
const route = routes[path];
const template = document.getElementById(route.templateId);
const view = template.content.cloneNode(true);
const app = document.getElementById('app');
app.innerHTML = '';
app.appendChild(view);
}
```
**Разбор того, что здесь происходит:**
- **Извлекает** текущий путь из URL браузера с помощью `window.location.pathname`
- **Ищет** соответствующую конфигурацию маршрута в нашем объекте маршрутов
- **Получает** идентификатор шаблона из конфигурации маршрута
- **Следует** тому же процессу рендеринга шаблона, что и раньше
- **Создает** динамическую систему, реагирующую на изменения URL
Здесь мы сопоставили маршруты, которые объявили, с соответствующим шаблоном. Вы можете проверить, что это работает корректно, изменив URL вручную в вашем браузере.
✅ Что произойдет, если ввести неизвестный путь в URL? Как мы можем это исправить?
## Добавление навигации
После настройки маршрутизации пользователям нужно предоставить способ перемещения по приложению. Традиционные веб-сайты перезагружают всю страницу при нажатии на ссылки, но мы хотим обновлять URL и содержимое без перезагрузки страницы. Это обеспечивает более плавный опыт, похожий на то, как настольные приложения переключаются между различными представлениями.
Нам нужно согласовать две вещи: обновление URL в браузере, чтобы пользователи могли сохранять страницы в закладках и делиться ссылками, и отображение соответствующего содержимого. При правильной реализации это создает бесшовную навигацию, которую ожидают пользователи современных приложений.
> 🏗️ **Инсайт архитектуры**: Компоненты системы навигации
>
> **Что вы создаете:**
> - **🔄 Управление URL**: Обновляет адресную строку браузера без перезагрузки страницы
> - **📋 Система шаблонов**: Динамически меняет содержимое в зависимости от текущего маршрута
> - **📚 Интеграция с историей**: Поддерживает функциональность кнопок "назад" и "вперед" в браузере
> - **🛡️ Обработка ошибок**: Элегантные решения для недействительных или отсутствующих маршрутов
>
> **Как компоненты работают вместе:**
> - **Слушают** события навигации (клики, изменения истории)
> - **Обновляют** URL с помощью API истории
> - **Отображают** соответствующий шаблон для нового маршрута
> - **Поддерживают** бесшовный пользовательский опыт
Следующий шаг для нашего приложения — добавить возможность перемещаться между страницами без необходимости вручную изменять URL. Это подразумевает две вещи:
1. Обновление текущего URL
2. Обновление отображаемого шаблона на основе нового URL
Мы уже позаботились о второй части с помощью функции `updateRoute`, поэтому нам нужно разобраться, как обновить текущий URL.
Для этого нам понадобится JavaScript, а точнее [`history.pushState`](https://developer.mozilla.org/docs/Web/API/History/pushState), который позволяет обновлять URL и создавать новую запись в истории браузера без перезагрузки HTML.
> ⚠️ **Важное замечание**: Хотя HTML-элемент якоря [``](https://developer.mozilla.org/docs/Web/HTML/Element/a) сам по себе может создавать гиперссылки на разные URL, он по умолчанию заставляет браузер перезагружать HTML. Необходимо предотвратить это поведение при обработке маршрутизации с помощью пользовательского JavaScript, используя функцию preventDefault() для события клика.
### Задача
Давайте создадим новую функцию, которую можно использовать для навигации в нашем приложении:
```js
function navigate(path) {
window.history.pushState({}, path, path);
updateRoute();
}
```
**Понимание этой функции навигации:**
- **Обновляет** URL браузера на новый путь с помощью `history.pushState`
- **Добавляет** новую запись в стек истории браузера для поддержки кнопок "назад/вперед"
- **Вызывает** функцию `updateRoute()` для отображения соответствующего шаблона
- **Поддерживает** опыт работы с одностраничным приложением без перезагрузки страницы
Этот метод сначала обновляет текущий URL на основе заданного пути, затем обновляет шаблон. Свойство `window.location.origin` возвращает корень URL, позволяя нам реконструировать полный URL из заданного пути.
Теперь, когда у нас есть эта функция, мы можем решить проблему, которая возникает, если путь не соответствует ни одному из определенных маршрутов. Мы изменим функцию `updateRoute`, добавив резервный вариант для одного из существующих маршрутов, если совпадение не найдено.
```js
function updateRoute() {
const path = window.location.pathname;
const route = routes[path];
if (!route) {
return navigate('/login');
}
const template = document.getElementById(route.templateId);
const view = template.content.cloneNode(true);
const app = document.getElementById('app');
app.innerHTML = '';
app.appendChild(view);
}
```
**Основные моменты, которые нужно помнить:**
- **Проверяет**, существует ли маршрут для текущего пути
- **Перенаправляет** на страницу входа при доступе к недействительному маршруту
- **Обеспечивает** механизм резервного варианта, предотвращающий поломку навигации
- **Гарантирует**, что пользователи всегда видят действительный экран, даже с неправильными URL
Если маршрут не найден, теперь мы будем перенаправлять на страницу `login`.
Теперь давайте создадим функцию, которая будет получать URL при клике на ссылку и предотвращать стандартное поведение браузера для ссылок:
```js
function onLinkClick(event) {
event.preventDefault();
navigate(event.target.href);
}
```
**Разбор обработчика кликов:**
- **Предотвращает** стандартное поведение браузера для ссылок с помощью `preventDefault()`
- **Извлекает** целевой URL из элемента ссылки, на который был произведен клик
- **Вызывает** нашу пользовательскую функцию navigate вместо перезагрузки страницы
- **Поддерживает** плавный опыт работы с одностраничным приложением
```html
Login
...
Logout
```
**Что делает эта привязка onclick:**
- **Соединяет** каждую ссылку с нашей пользовательской системой навигации
- **Передает** событие клика в нашу функцию `onLinkClick` для обработки
- **Обеспечивает** плавную навигацию без перезагрузки страницы
- **Поддерживает** правильную структуру URL, которую пользователи могут сохранять в закладках или делиться
Атрибут [`onclick`](https://developer.mozilla.org/docs/Web/API/GlobalEventHandlers/onclick) связывает событие `click` с кодом JavaScript, в данном случае с вызовом функции `navigate()`.
Попробуйте кликнуть на эти ссылки, теперь вы должны иметь возможность перемещаться между различными экранами вашего приложения.
✅ Метод `history.pushState` является частью стандарта HTML5 и реализован во [всех современных браузерах](https://caniuse.com/?search=pushState). Если вы создаете веб-приложение для старых браузеров, есть трюк, который можно использовать вместо этого API: используя [хэш (`#`)](https://en.wikipedia.org/wiki/URI_fragment) перед путем, можно реализовать маршрутизацию, которая работает с обычной навигацией по якорям и не перезагружает страницу, так как ее цель — создание внутренних ссылок на странице.
## Настройка кнопок "Назад" и "Вперед"
Кнопки "назад" и "вперед" являются основополагающими для веб-серфинга, так же как для NASA важно иметь возможность просматривать предыдущие состояния системы во время космических миссий. Пользователи ожидают, что эти кнопки будут работать, и если они не работают, это нарушает ожидаемый опыт использования браузера.
Нашему одностраничному приложению требуется дополнительная настройка для поддержки этой функции. Браузер поддерживает стек истории (который мы добавляем с помощью `history.pushState`), но когда пользователи перемещаются по этой истории, наше приложение должно реагировать, обновляя отображаемое содержимое соответствующим образом.
```mermaid
sequenceDiagram
participant User
participant Browser
participant App
participant Template
User->>Browser: Clicks "Login" link
Browser->>App: onclick event triggered
App->>App: preventDefault() & navigate('/dashboard')
App->>Browser: history.pushState('/dashboard')
Browser->>Browser: URL updates to /dashboard
App->>App: updateRoute() called
App->>Template: Find & clone dashboard template
Template->>App: Return cloned content
App->>Browser: Replace app content with template
Browser->>User: Display dashboard screen
Note over User,Template: User clicks browser back button
User->>Browser: Clicks back button
Browser->>Browser: History moves back to /login
Browser->>App: popstate event fired
App->>App: updateRoute() called automatically
App->>Template: Find & clone login template
Template->>App: Return cloned content
App->>Browser: Replace app content with template
Browser->>User: Display login screen
```
**Ключевые точки взаимодействия:**
- **Действия пользователя** вызывают навигацию через клики или кнопки браузера
- **Приложение перехватывает** клики по ссылкам, чтобы предотвратить перезагрузку страницы
- **API истории** управляет изменениями URL и стеком истории браузера
- **Шаблоны** предоставляют структуру содержимого для каждого экрана
- **Слушатели событий** гарантируют, что приложение реагирует на все типы навигации
Использование `history.pushState` создает новые записи в истории навигации браузера. Вы можете проверить это, удерживая *кнопку назад* вашего браузера, должно появиться что-то вроде этого:
Если вы попробуете несколько раз нажать кнопку назад, вы увидите, что текущий URL изменяется, а история обновляется, но отображается тот же шаблон.
Это происходит потому, что приложение не знает, что нужно вызывать `updateRoute()` каждый раз, когда история изменяется. Если вы посмотрите документацию [`history.pushState`](https://developer.mozilla.org/docs/Web/API/History/pushState), вы увидите, что если состояние изменяется — то есть мы переместились на другой URL — событие [`popstate`](https://developer.mozilla.org/docs/Web/API/Window/popstate_event) будет вызвано. Мы используем это, чтобы исправить проблему.
### Задача
Чтобы убедиться, что отображаемый шаблон обновляется при изменении истории браузера, мы добавим новую функцию, которая вызывает `updateRoute()`. Мы сделаем это в конце файла `app.js`:
```js
window.onpopstate = () => updateRoute();
updateRoute();
```
**Понимание этой интеграции с историей:**
- **Слушает** события `popstate`, которые происходят, когда пользователи перемещаются с помощью кнопок браузера
- **Использует** стрелочную функцию для лаконичного синтаксиса обработчика событий
- **Автоматически вызывает** `updateRoute()` каждый раз, когда состояние истории изменяется
- **Инициализирует** приложение, вызывая `updateRoute()` при первой загрузке страницы
- **Гарантирует**, что правильный шаблон отображается независимо от того, как пользователи перемещаются
> 💡 **Полезный совет**: Мы использовали [стрелочную функцию](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Functions/Arrow_functions) для объявления обработчика события `popstate` для краткости, но обычная функция работала бы так же.
Вот видео-обзор о стрелочных функциях:
[](https://youtube.com/watch?v=OP6eEbOj2sc "Стрелочные функции")
> 🎥 Нажмите на изображение выше, чтобы посмотреть видео о стрелочных функциях.
Теперь попробуйте использовать кнопки "назад" и "вперед" вашего браузера и убедитесь, что отображаемый маршрут теперь правильно обновляется.
---
## Вызов GitHub Copilot Agent 🚀
Используйте режим Agent, чтобы выполнить следующий вызов:
**Описание:** Улучшите банковское приложение, добавив обработку ошибок и шаблон страницы 404 для недействительных маршрутов, улучшив пользовательский опыт при переходе на несуществующие страницы.
**Задание:** Создайте новый HTML-шаблон с идентификатором "not-found", который отображает удобную страницу ошибки 404 с оформлением. Затем измените логику маршрутизации в JavaScript, чтобы отображать этот шаблон, когда пользователи переходят на недействительные URL, и добавьте кнопку "На главную", которая возвращает на страницу входа.
Узнайте больше о [режиме Agent](https://code.visualstudio.com/blogs/2025/02/24/introducing-copilot-agent-mode) здесь.
## 🚀 Вызов
Добавьте новый шаблон и маршрут для третьей страницы, на которой будут указаны авторы этого приложения.
**Цели вызова:**
- **Создайте** новый HTML-шаблон с соответствующей структурой содержимого
- **Добавьте** новый маршрут в объект конфигурации маршрутов
- **Включите** ссылки для навигации на страницу авторов и обратно
- **Проверьте**, что вся навигация работает корректно с историей браузера
## Викторина после лекции
[Викторина после лекции](https://ff-quizzes.netlify.app/web/quiz/42)
## Обзор и самостоятельное изучение
Маршрутизация — одна из удивительно сложных частей веб-разработки, особенно в условиях перехода веба от поведения с перезагрузкой страниц к одностраничным приложениям. Почитайте немного о [том, как служба Azure Static Web App](https://docs.microsoft.com/azure/static-web-apps/routes/?WT.mc_id=academic-77807-sagibbon) обрабатывает маршрутизацию. Можете ли вы объяснить, почему некоторые из описанных решений необходимы?
**Дополнительные ресурсы для изучения:**
- **Изучите**, как популярные фреймворки, такие как React Router и Vue Router, реализуют маршрутизацию на стороне клиента
- **Исследуйте** различия между маршрутизацией на основе хэша и маршрутизацией с использованием API истории
- **Узнайте** о серверной рендеринге (SSR) и о том, как он влияет на стратегии маршрутизации
- **Изучите**, как прогрессивные веб-приложения (PWA) обрабатывают маршрутизацию и навигацию
## Задание
[Улучшите маршрутизацию](assignment.md)
---
**Отказ от ответственности**:
Этот документ был переведен с использованием сервиса автоматического перевода [Co-op Translator](https://github.com/Azure/co-op-translator). Несмотря на наши усилия обеспечить точность, автоматические переводы могут содержать ошибки или неточности. Оригинальный документ на его родном языке следует считать авторитетным источником. Для получения критически важной информации рекомендуется профессиональный перевод человеком. Мы не несем ответственности за любые недоразумения или неправильные интерпретации, возникающие в результате использования данного перевода.