# Створення банківського додатку Частина 2: Створення форми входу та реєстрації
## Тест перед лекцією
[Тест перед лекцією](https://ff-quizzes.netlify.app/web/quiz/43)
Чи заповнювали ви коли-небудь форму онлайн, яка відхиляла формат вашої електронної пошти? Або втрачали всю інформацію після натискання кнопки "Надіслати"? Ми всі стикалися з такими неприємними ситуаціями.
Форми є мостом між вашими користувачами та функціональністю вашого додатку. Як і ретельні протоколи, які використовують диспетчери повітряного руху для безпечного керування літаками, добре спроєктовані форми забезпечують чіткий зворотний зв'язок і запобігають дорогим помилкам. Погано спроєктовані форми, навпаки, можуть відлякати користувачів швидше, ніж непорозуміння в переповненому аеропорту.
У цьому уроці ми перетворимо ваш статичний банківський додаток на інтерактивний. Ви навчитеся створювати форми, які перевіряють введені дані, взаємодіють із серверами та надають корисний зворотний зв'язок. Уявіть, що це як створення інтерфейсу управління, який дозволяє користувачам орієнтуватися у функціях вашого додатку.
Наприкінці уроку у вас буде повна система входу та реєстрації з перевіркою, яка допомагає користувачам досягти успіху, а не розчарування.
## Передумови
Перш ніж ми почнемо створювати форми, переконайтеся, що у вас все налаштовано правильно. Цей урок продовжує попередній, тому якщо ви пропустили його, можливо, вам варто повернутися і спочатку налаштувати основи.
### Необхідна підготовка
| Компонент | Статус | Опис |
|-----------|--------|-------------|
| [HTML Шаблони](../1-template-route/README.md) | ✅ Обов'язково | Основна структура вашого банківського додатку |
| [Node.js](https://nodejs.org) | ✅ Обов'язково | JavaScript середовище виконання для сервера |
| [Сервер Bank API](../api/README.md) | ✅ Обов'язково | Сервіс бекенду для зберігання даних |
> 💡 **Порада для розробників**: Ви будете запускати два окремі сервери одночасно – один для вашого фронтенд банківського додатку, а інший для бекенду API. Така конфігурація відображає реальну розробку, де фронтенд і бекенд працюють незалежно.
### Конфігурація серверів
**Ваше середовище розробки включатиме:**
- **Сервер фронтенду**: Обслуговує ваш банківський додаток (зазвичай порт `3000`)
- **Сервер бекенду API**: Обробляє зберігання та отримання даних (порт `5000`)
- **Обидва сервери** можуть працювати одночасно без конфліктів
**Перевірка з'єднання з API:**
```bash
curl http://localhost:5000/api
# Expected response: "Bank API v1.0.0"
```
**Якщо ви бачите відповідь версії API, ви готові продовжувати!**
---
## Розуміння HTML форм та елементів управління
HTML форми – це спосіб, яким користувачі взаємодіють із вашим веб-додатком. Уявіть їх як телеграфну систему, яка з'єднувала віддалені місця у 19 столітті – це протокол зв'язку між намірами користувача та відповіддю додатку. Коли вони спроєктовані з розумом, вони виявляють помилки, направляють форматування введення та надають корисні підказки.
Сучасні форми значно складніші за базові текстові поля. HTML5 представив спеціалізовані типи введення, які автоматично обробляють перевірку електронної пошти, форматування чисел та вибір дат. Ці покращення сприяють як доступності, так і зручності використання на мобільних пристроях.
### Основні елементи форми
**Будівельні блоки, які потрібні кожній формі:**
```html
```
**Що робить цей код:**
- **Створює** контейнер форми з унікальним ідентифікатором
- **Визначає** HTTP метод для надсилання даних
- **Зв'язує** мітки з полями введення для доступності
- **Визначає** кнопку "Надіслати" для обробки форми
### Сучасні типи введення та атрибути
| Тип введення | Призначення | Приклад використання |
|--------------|-------------|-----------------------|
| `text` | Загальне текстове поле | `` |
| `email` | Перевірка електронної пошти | `` |
| `password` | Приховане введення тексту | `` |
| `number` | Введення чисел | `` |
| `tel` | Номери телефонів | `` |
> 💡 **Перевага HTML5**: Використання специфічних типів введення забезпечує автоматичну перевірку, відповідні клавіатури для мобільних пристроїв та кращу підтримку доступності без додаткового JavaScript!
### Типи кнопок та їх поведінка
```html
```
**Що робить кожен тип кнопки:**
- **Кнопки "Надіслати"**: Запускають надсилання форми та передають дані на вказаний кінцевий пункт
- **Кнопки "Скинути"**: Відновлюють всі поля форми до початкового стану
- **Звичайні кнопки**: Не мають стандартної поведінки, вимагають власного JavaScript для функціональності
> ⚠️ **Важлива примітка**: Елемент `` є самозакриваючим і не потребує закриваючого тегу. Сучасна найкраща практика – писати `` без слешу.
### Створення форми входу
Тепер давайте створимо практичну форму входу, яка демонструє сучасні практики HTML форм. Ми почнемо з базової структури і поступово покращимо її, додаючи функції доступності та перевірки.
```html
Bank App
Login
```
**Розбір того, що тут відбувається:**
- **Структурує** форму за допомогою семантичних елементів HTML5
- **Групує** пов'язані елементи у контейнерах `div` з осмисленими класами
- **Зв'язує** мітки з полями введення за допомогою атрибутів `for` та `id`
- **Включає** сучасні атрибути, такі як `autocomplete` та `placeholder` для покращення UX
- **Додає** `novalidate`, щоб обробляти перевірку за допомогою JavaScript замість стандартів браузера
### Сила правильних міток
**Чому мітки важливі для сучасної веб-розробки:**
```mermaid
graph TD
A[Label Element] --> B[Screen Reader Support]
A --> C[Click Target Expansion]
A --> D[Form Validation]
A --> E[SEO Benefits]
B --> F[Accessible to all users]
C --> G[Better mobile experience]
D --> H[Clear error messaging]
E --> I[Better search ranking]
```
**Що забезпечують правильні мітки:**
- **Дозволяють** екранним читачам чітко оголошувати поля форми
- **Розширюють** область кліку (натискання на мітку фокусується на введенні)
- **Покращують** мобільну зручність завдяки більшим зонам дотику
- **Підтримують** перевірку форми з осмисленими повідомленнями про помилки
- **Покращують** SEO, надаючи семантичне значення елементам форми
> 🎯 **Ціль доступності**: Кожне поле введення форми повинно мати пов'язану мітку. Ця проста практика робить ваші форми доступними для всіх, включаючи людей з обмеженими можливостями, і покращує досвід для всіх користувачів.
### Створення форми реєстрації
Форма реєстрації вимагає більш детальної інформації для створення повного облікового запису користувача. Давайте створимо її з використанням сучасних функцій HTML5 та покращеної доступності.
```html
Register
```
**У наведеному вище коді ми:**
- **Організували** кожне поле у контейнерах `div` для кращого стилювання та макету
- **Додали** відповідні атрибути `autocomplete` для підтримки автозаповнення браузером
- **Включили** корисний текст-підказку для направлення введення користувача
- **Встановили** розумні значення за замовчуванням за допомогою атрибуту `value`
- **Застосували** атрибути перевірки, такі як `required`, `maxlength` та `min`
- **Використали** `type="number"` для поля балансу з підтримкою десяткових чисел
### Дослідження типів введення та їх поведінки
**Сучасні типи введення забезпечують розширену функціональність:**
| Функція | Перевага | Приклад |
|---------|----------|---------|
| `type="number"` | Числова клавіатура на мобільних пристроях | Зручніше введення балансу |
| `step="0.01"` | Контроль десяткової точності | Дозволяє копійки у валюті |
| `autocomplete` | Автозаповнення браузером | Швидше заповнення форми |
| `placeholder` | Контекстні підказки | Направляє очікування користувача |
> 🎯 **Виклик доступності**: Спробуйте навігацію формами, використовуючи лише клавіатуру! Використовуйте `Tab` для переміщення між полями, `Space` для вибору чекбоксів та `Enter` для надсилання. Цей досвід допоможе вам зрозуміти, як користувачі екранних читачів взаємодіють із вашими формами.
## Розуміння методів надсилання форм
Коли хтось заповнює вашу форму і натискає "Надіслати", ці дані повинні кудись потрапити – зазвичай на сервер, який може їх зберегти. Є кілька способів, як це може відбуватися, і знання, який з них використовувати, може врятувати вас від головного болю в майбутньому.
Давайте розглянемо, що насправді відбувається, коли хтось натискає кнопку "Надіслати".
### Поведінка форми за замовчуванням
Спочатку давайте спостерігати, що відбувається при базовому надсиланні форми:
**Перевірте ваші поточні форми:**
1. Натисніть кнопку *Реєстрація* у вашій формі
2. Спостерігайте зміни в адресному рядку вашого браузера
3. Зверніть увагу, як сторінка перезавантажується і дані з'являються в URL

### Порівняння HTTP методів
```mermaid
graph TD
A[Form Submission] --> B{HTTP Method}
B -->|GET| C[Data in URL]
B -->|POST| D[Data in Request Body]
C --> E[Visible in address bar]
C --> F[Limited data size]
C --> G[Bookmarkable]
D --> H[Hidden from URL]
D --> I[Large data capacity]
D --> J[More secure]
```
**Розуміння відмінностей:**
| Метод | Сценарій використання | Розташування даних | Рівень безпеки | Обмеження розміру |
|-------|------------------------|--------------------|----------------|-------------------|
| `GET` | Пошукові запити, фільтри | Параметри URL | Низький (видимий) | ~2000 символів |
| `POST` | Облікові записи користувачів, конфіденційні дані | Тіло запиту | Вищий (прихований) | Практично без обмежень |
**Розуміння основних відмінностей:**
- **GET**: Додає дані форми до URL як параметри запиту (підходить для пошукових операцій)
- **POST**: Включає дані в тіло запиту (необхідно для конфіденційної інформації)
- **Обмеження GET**: Обмеження розміру, видимі дані, постійна історія браузера
- **Переваги POST**: Велика ємність даних, захист конфіденційності, підтримка завантаження файлів
> 💡 **Найкраща практика**: Використовуйте `GET` для пошукових форм і фільтрів (отримання даних), використовуйте `POST` для реєстрації користувачів, входу та створення даних.
### Конфігурація надсилання форми
Давайте налаштуємо вашу форму реєстрації для правильного спілкування з бекенд API за допомогою методу POST:
```html
```
**Розуміння вдосконаленої перевірки:**
- **Поєднує** індикатори обов'язкових полів із корисними описами
- **Включає** атрибути `pattern` для перевірки формату
- **Надає** атрибути `title` для доступності та підказок
- **Додає** допоміжний текст для керування введенням користувача
- **Використовує** семантичну структуру HTML для кращої доступності
### Розширені правила перевірки
**Що досягає кожне правило перевірки:**
| Поле | Правила перевірки | Користувацька перевага |
|------|-------------------|------------------------|
| Ім'я користувача | `required`, `minlength="3"`, `maxlength="20"`, `pattern="[a-zA-Z0-9_]+"` | Забезпечує дійсні, унікальні ідентифікатори |
| Валюта | `required`, `maxlength="3"`, `pattern="[A-Z$€£¥₹]+"` | Приймає загальні символи валют |
| Баланс | `min="0"`, `step="0.01"`, `type="number"` | Запобігає негативним балансам |
| Опис | `maxlength="100"` | Розумні обмеження довжини |
### Тестування поведінки перевірки
**Спробуйте ці сценарії перевірки:**
1. **Надішліть** форму з порожніми обов'язковими полями
2. **Введіть** ім'я користувача коротше 3 символів
3. **Спробуйте** спеціальні символи в полі імені користувача
4. **Введіть** негативну суму балансу

**Що ви спостерігатимете:**
- **Браузер показує** нативні повідомлення про перевірку
- **Зміни стилізації** на основі станів `:valid` і `:invalid`
- **Надсилання форми** блокується, поки всі перевірки не пройдуть
- **Фокус автоматично** переміщується на перше поле з помилкою
### Перевірка на клієнті vs сервері
```mermaid
graph LR
A[Client-Side Validation] --> B[Instant Feedback]
A --> C[Better UX]
A --> D[Reduced Server Load]
E[Server-Side Validation] --> F[Security]
E --> G[Data Integrity]
E --> H[Business Rules]
A -.-> I[Both Required]
E -.-> I
```
**Чому потрібні обидва рівні:**
- **Перевірка на клієнті**: Забезпечує миттєвий зворотний зв'язок і покращує користувацький досвід
- **Перевірка на сервері**: Гарантує безпеку та обробляє складні бізнес-правила
- **Комбінований підхід**: Створює надійні, зручні та безпечні додатки
- **Прогресивне покращення**: Працює навіть якщо JavaScript вимкнено
> 🛡️ **Нагадування про безпеку**: Ніколи не покладайтеся лише на перевірку на клієнті! Зловмисники можуть обійти перевірки на клієнті, тому перевірка на сервері є важливою для безпеки та цілісності даних.
---
---
## Виклик GitHub Copilot Agent 🚀
Використовуйте режим Agent, щоб виконати наступний виклик:
**Опис:** Покращіть форму реєстрації, додавши комплексну перевірку на клієнті та зворотний зв'язок для користувача. Цей виклик допоможе вам практикувати перевірку форм, обробку помилок і покращення користувацького досвіду за допомогою інтерактивного зворотного зв'язку.
**Завдання:** Створіть повну систему перевірки форми реєстрації, яка включає: 1) Миттєвий зворотний зв'язок для кожного поля під час введення, 2) Користувацькі повідомлення про перевірку, які з'являються під кожним полем введення, 3) Поле підтвердження пароля з перевіркою відповідності, 4) Візуальні індикатори (наприклад, зелені галочки для дійсних полів і червоні попередження для недійсних), 5) Кнопка надсилання, яка стає активною лише тоді, коли всі перевірки пройдені. Використовуйте атрибути перевірки HTML5, CSS для стилізації станів перевірки та JavaScript для інтерактивної поведінки.
Дізнайтеся більше про [режим Agent](https://code.visualstudio.com/blogs/2025/02/24/introducing-copilot-agent-mode) тут.
## 🚀 Виклик
Показати повідомлення про помилку в HTML, якщо користувач вже існує.
Ось приклад того, як може виглядати фінальна сторінка входу після невеликого стилізування:

## Післялекційний тест
[Післялекційний тест](https://ff-quizzes.netlify.app/web/quiz/44)
## Огляд і самостійне навчання
Розробники стали дуже креативними у своїх зусиллях щодо створення форм, особливо щодо стратегій перевірки. Дізнайтеся про різні потоки форм, переглядаючи [CodePen](https://codepen.com); чи можете ви знайти цікаві та надихаючі форми?
## Завдання
[Стилізуйте ваш банківський додаток](assignment.md)
---
**Відмова від відповідальності**:
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають внаслідок використання цього перекладу.