# Створення банківського додатку Частина 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 body – тут будуть з'являтися всі наші різні екрани:
```html
Loading...
```
**Розуміння цього заповнювача:**
- **Створює** контейнер із ID "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);
}
```
**Крок за кроком, ось що відбувається:**
- **Знаходить** елемент шаблону за його унікальним ID
- **Створює** глибоку копію вмісту шаблону за допомогою `cloneNode(true)`
- **Знаходить** контейнер додатку, де буде відображатися контент
- **Очищає** будь-який існуючий контент із контейнера додатку
- **Вставляє** скопійований вміст шаблону у видимий DOM
Тепер викличте цю функцію з одним із шаблонів і подивіться на результат.
```js
updateRoute('login');
```
**Що досягає цей виклик функції:**
- **Активує** шаблон входу, передаючи його ID як параметр
- **Демонструє**, як програмно перемикатися між різними екранами додатку
- **Показує** екран входу замість повідомлення "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** викликають пошук у конфігурації маршрутів
- **Дійсні маршрути** відображаються на конкретні ID шаблонів для рендерингу
- **Недійсні маршрути** викликають резервну поведінку, щоб уникнути зламаних станів
- **Рендеринг шаблонів** слідує трьохетапному процесу, який ми вивчили раніше
Коли ми говоримо про веб-додаток, ми називаємо *Маршрутизацію* наміром зіставити **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 і нашими шаблонами. Д
✅ Що відбувається, якщо ввести невідомий шлях у URL? Як ми можемо це вирішити?
## Додавання навігації
З налаштованим маршрутизацією користувачам потрібен спосіб переміщатися по додатку. Традиційні вебсайти перезавантажують цілі сторінки при натисканні на посилання, але ми хочемо оновлювати як URL, так і контент без перезавантаження сторінки. Це створює більш плавний досвід, схожий на те, як настільні програми перемикаються між різними видами.
Нам потрібно узгодити дві речі: оновлення URL браузера, щоб користувачі могли зберігати сторінки в закладках і ділитися посиланнями, та відображення відповідного контенту. При правильній реалізації це створює безперервну навігацію, яку очікують користувачі сучасних додатків.
> 🏗️ **Інсайт архітектури**: Компоненти системи навігації
>
> **Що ви створюєте:**
> - **🔄 Управління URL**: Оновлює адресний рядок браузера без перезавантаження сторінок
> - **📋 Система шаблонів**: Динамічно змінює контент залежно від поточного маршруту
> - **📚 Інтеграція історії**: Зберігає функціональність кнопок "Назад" і "Вперед" у браузері
> - **🛡️ Обробка помилок**: Акуратні резервні варіанти для недійсних або відсутніх маршрутів
>
> **Як компоненти працюють разом:**
> - **Слухає** події навігації (кліки, зміни історії)
> - **Оновлює** URL за допомогою History 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 призначення з елемента посилання, на який було натиснуто
- **Викликає** нашу власну функцію навігації замість перезавантаження сторінки
- **Підтримує** плавний досвід односторінкового додатку
```html
Login
...
Logout
```
**Що досягає це прив'язування onclick:**
- **З'єднує** кожне посилання з нашою власною системою навігації
- **Передає** подію кліку до нашої функції `onLinkClick` для обробки
- **Забезпечує** плавну навігацію без перезавантаження сторінок
- **Підтримує** правильну структуру URL, яку користувачі можуть зберігати в закладках або ділитися
Атрибут [`onclick`](https://developer.mozilla.org/docs/Web/API/GlobalEventHandlers/onclick) прив'язує подію кліку до 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, реалізують маршрутизацію на стороні клієнта
- **Досліджуйте** відмінності між маршрутизацією на основі хешу і маршрутизацією через History API
- **Дізнайтеся** про серверну рендеринг (SSR) і як він впливає на стратегії маршрутизації
- **Досліджуйте**, як прогресивні вебдодатки (PWA) обробляють маршрутизацію і навігацію
## Завдання
[Покращіть маршрутизацію](assignment.md)
---
**Відмова від відповідальності**:
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають внаслідок використання цього перекладу.