Раніше, якщо користувач вводив в калькулятор вартості послуг замість цифри літеру або ставив знак мінус, сайт або видавав легендарну помилку NaN (Not a Number), або зависав, змушуючи перезавантажувати браузер. Сьогодні розробник не просто пише код за допомогою ШІ-асистентів, він виступає в ролі QA Engineer (інженера з тестування). ШІ-асистент (ChatGPT/Claude) миттєво напише логіку, але саме розробник повинен провести її стрес-тестування через DevTools, виявити приховані баги, «крайні випадки» (Edge Cases) та змусити ШІ написати захисний, стійкий до критичних помилок код.

Стек інструментів для роботи

• Середовище кодингу: VS Code.
• ШІ-асистенти. ChatGPT (OpenAI), Claude (Anthropic) або Gemini.
• Інструменти тестування. Chrome Developer Tools (вкладка Console/Інспектор).
• Система контролю версій та автоматичний деплой: Git, GitHub, Vercel/GitHub Pages.

Інтерактивні віджети

Інтерактивний віджет (Widget) — це самостійний динамічний елемент вебсторінки (калькулятор, трекер, інтерактивна карта), який реагує на дії користувача в реальному часі без перезавантаження сторінки. На сучасних лендингах та корпоративних сайтах віджети є головним інструментом утримання уваги та збору лідів (потенційних клієнтів).

Чек-ліст для проєктування ідеального віджета

Перед тим, як змусити ШІ кодити, архітектор проекту повинен продумати три рівні взаємодії:

1. UX (Зручність). Динамічний відгук на кожну дію. Користувач не повинен тиснути на кнопку «Розрахувати» після кожної цифри. Використання події input замість click на кнопці.
2. UI (Візуалізація). Стан доступності (Accessibility/aria-* атрибути) та стани елементів. Акцентування кольором фокусу на полях, блокування кнопки надсилання, якщо форма порожня.
3. Fail-Safe (Стійкість). Обмеження діапазонів введення безпосередньо в HTML та дублювання цього в JS. Атрибути min="1" max="100" для input типу number.

Захисне програмування, Edge Cases та Критичні помилки

Штучний інтелект за замовченням генерує код для ідеального сценарію «Happy Path», коли користувач вводить саме те, що від нього очікують. Проте, в реальному світі користувачі:

1. Вводять текст або спецсимволи туди, де мають бути лише цифри.
2. Залишають поля порожніми.
3. Вставляють від’ємні значення, нулі або астрономічні числа.
4. Швидко і хаотично клікають на кнопки, викликаючи умови перегонів.

Захисне програмування (Defensive Programming) — це філософія та методологія проєктування програмного забезпечення, за якої код пишеться з усвідомленням того, що будь-які зовнішні чинники (користувачі, сторонні API, мережа чи навіть інші розробники) можуть поводитися некоректно, непередбачувано або вороже. Головна мета захисного програмування — мінімізувати наслідки помилок. Програма не повинна «падати» (завершувати роботу аварійно), видавати користувачеві технічні помилки («червоний екран смерть») чи пошкоджувати дані. Замість цього вона має ефективно обробляти аномалії, продовжувати роботу в безпечному режимі або виводити зрозумілі людські попередження.

Три золоті правила захисного коду

1. Правило №1. Ніколи не довіряти вхідним даним. Будь-які дані, що надходять ззовні конкретного методу чи функції, вважаються «брудними» за замовченням. Це стосується:
   • Значень з текстових полів форм (<input>).
   • Даних, що приходять з бази даних або стороннього API (fetch).
   • Параметрів, які передаються у функції іншими розробниками.
2. Правило №2. Передбачати граничні випадки (Edge Cases). Програма має бути протестована не лише на ідеальному сценарії, коли користувач вводить все правильно. Потрібно заздалегідь відповісти на запитання:
   • Що буде, якщо передати від'ємне число? null? undefined?
   • Що буде, якщо користувач надішле порожній рядок або натисне кнопку надсилання форми 50 разів поспіль?
   • Що станеться, якщо сервер повернув помилку 500 замість даних?
3. Правило №3. Fail-Fast або Fail-Safe. Залежно від критичності системи, застосовують одну з двох стратегій:
   • Fail-Fast (Швидка відмова). Програма миттєво зупиняє виконання та повідомляє про помилку на етапі розробки, щоб розробник міг її виправити.
   • Fail-Safe (Безпечна відмова). У фінальному продукті програма загладжує помилку, використовує резервні значення за замовченням і продовжує працювати, не заважаючи користувачеві.

Захисне програмування — це не просто написання додаткових умов if. Це професійне ставлення до коду. Якщо написати код захищеним способом один раз, розробник позбавляється необхідності виправляти неочікувані «баги» в майбутньому, коли сайтом користуватимуться реальні люди на різноманітних пристроях.

HTML
<input type="number" id="quantity" min="1" max="100" required>

JavaScript
// Зчитуємо значення та примусово перетворюємо на число
let pages = parseFloat(document.getElementById('pages').value);

// Перевірка на Edge Cases
if (isNaN(pages) || pages <= 0) {
    showError("Будь ласка, введіть коректну кількість сторінок (більше 0)");
    return; // Зупиняємо виконання функції, рятуємо додаток від NaN
}

Вміння працювати з Edge Cases — це те, що відрізняє джуніора (який радіє, що код запустився з першого разу) від мідла та сініора (які знають, що код буде протестовано в екстремальних умовах). В звіті до лабораторної роботи №11 студент має показати саме цей процес: як знайдено слабке місце в згенерованому ШІ алгоритмі та як навчалася модель писати захищений код.

Консоль розробника Chrome DevTools Console

Chrome DevTools Console (Консоль розробника) — це один з найважливіших інструментів арсеналі веброзробника та інженера з тестування (QA). Вона вбудована безпосередньо в браузер Google Chrome і виконує дві основні функції:

1. Логування та діагностика, що показує помилки в коді, попередження, системні повідомлення, а також дані, які розробник навмисно виводить для перевірки.
2. Інтерактивне середовище надає можливість в реальному часі писати та виконувати JavaScript-код, взаємодіючи з поточною вебсторінкою.

JavaScript
let totalPrice = pagesCount * 1000;
console.log("Поточна кількість сторінок:", pagesCount);
console.log("Розрахована вартість:", totalPrice);

JavaScript
console.log(document.getElementById('total-price').textContent);

Покроковий хід виконання роботи

В лабораторній роботі №11 студент створює власний інтерактивний віджет, інтегрує його в лендинг з попередніх лабораторних робіт. За допомогою ШІ реалізує JavaScript-логіку віджету.

Ланцюжок створення віджету: UX → UI → бізнес-логіка → генерація коду → Happy Path → QA → Edge Cases → Defensive Programming → повторне тестування → інтеграція → деплой.

Віджет повинен бути пов'язаний з тематикою власного вебпроєкту. Приклади:

• Калькулятор вартості створення сайту.
• Калькулятор вартості туристичної подорожі.
• Калькулятор вартості ремонту.
• Калькулятор вартості доставки.
• Конструктор кавового напою.
• Конфігуратор автомобіля.
• Калькулятор тренувань.
• Калькулятор вартості послуги.
• Квіз з підрахунком результату.
• Трекер накопичень.
• Конфігуратор товару.
• Планувальник або генератор рекомендацій.

Віджет повинен мати не менше трьох параметрів, які впливають на результат.

• Приклад Калькулятора вартості розробки сайту
• Приклад Кав'ярня в стилі BrewLab

Етап 1. Вибір ідеї та визначення функціональності віджета

1. Обрати тип віджета. Студент повинен визначити, який інтерактивний елемент буде реалізовано. Потрібно, щоб віджет був логічно пов'язаний з тематикою власного лендингу.
   • Якщо проєкт присвячений вебстудії, тоді Калькулятор орієнтовної вартості створення вебсайту.
   • Якщо проєкт присвячений кав'ярні, тоді Конструктор власного кавового напою.
   • Якщо проєкт присвячений подорожам, тоді Калькулятор розрахунку вартості подорожі.
2. Описати бізнес-логіку. До початку написання коду студент повинен визначити:
   • Які дані вводить користувач?
   • Які параметри він може вибрати?
   • Що саме розраховує віджет?
   • Яка формула використовується?
   • Що відображається користувачу?

Наприклад: Калькулятор вебсайту
Кількість сторінок → input number
Тип дизайну → select
SEO → checkbox
Адаптивність → checkbox
Підтримка → checkbox
Розрахунок
Загальна вартість

3. Створити таблицю бізнес-правил. Перед написанням JavaScript студент формує таблицю.

Параметр	Тип	Значення	Вплив
Кількість сторінок	number	1–50	+1000 грн/сторінка
Дизайн	select	шаблон/індивідуальний	+0/+5000
SEO	checkbox	true/false	+1500
Адаптивність	checkbox	true/false	+2000

Ця таблиця стане основою для промпту до ШІ.

Етап 2. Проєктування UX віджета

1. Перед створенням коду необхідно продумати, як користувач взаємодіятиме з віджетом.
2. Визначити елементи керування. Залежно від задачі можна використовувати:
   • <input type="number">, <input type="range">, <select>, <input type="checkbox">, <input type="radio">, текстове поле, кнопки.
   • Бажано використовувати різні типи елементів, щоб продемонструвати роботу з різними DOM-подіями.
3. Визначити події, коли повинен оновлюватися результат. Наприклад:
   • input при введенні;
   • change після зміни select, checkbox або range;
   • click для окремих кнопок.
4. Для калькулятора бажано використовувати миттєвий перерахунок, а не змушувати користувача щоразу натискати кнопку «Розрахувати».
5. Приклад промпту

Ти — UX/UI Designer та Frontend Developer. Проаналізуй майбутній інтерактивний віджет для мого вебпроєкту.
Віджет: калькулятор вартості створення сайту.
Користувач повинен вибирати:
1. кількість сторінок;
2. тип дизайну;
3. SEO;
4. адаптивність;
5. технічну підтримку.
Запропонуй оптимальну структуру UI.
Для кожного параметра вкажи:
- тип HTML-елемента;
- рекомендовану подію JavaScript;
- спосіб відображення результату.
Не пиши JavaScript-код. Спочатку опиши UX-логіку.

Етап 3. Створення UI-каркасу віджета

1. Створити HTML-структуру. Віджет додається до існуючого лендингу.
2. Необхідно створити окрему секцію <section>. Всередині розміщуються заголовок, поля введення, параметри, повідомлення про помилки, блок результату.
3. Стилізувати віджет за допомогою Tailwind CSS. Віджет повинен відповідати дизайн системі, що створена в попередніх лабораторних роботах. Не потрібно створювати нову палітру кольорів або нову систему компонентів.
4. Приклад промпту

Створи UI-каркас інтерактивного віджета для мого лендингу.
Використовуй:
- HTML5;
- Tailwind CSS;
- існуючу Design System.
Віджет має містити:
1. заголовок;
2. поле кількості сторінок;
3. select типу дизайну;
4. checkbox SEO;
5. checkbox адаптивності;
6. блок загальної вартості;
7. область повідомлень про помилки.
Використовуй семантичний HTML. Поки що НЕ пиши JavaScript. Всі елементи повинні мати унікальні id. Віджет повинен бути адаптивним та працювати за принципом mobile-first.

Етап 4. Формування технічного завдання для JavaScript

Студент не повинен одразу писати промпт «Напиши калькулятор», спочатку необхідно сформувати технічну специфікацію.

1. Описати алгоритм, Наприклад:

basePrice = 3000
pages = кількість сторінок

design:
template = 0
custom = 5000

SEO = 1500
responsive = 2000

total = basePrice + pages * 1000 + designPrice + SEO + responsive

2. Визначити очікувані результати, що згодом надасть можливість перевірити правильність алгоритму. Наприклад:
   • 1 сторінка + шаблон = 4000 грн.
   • 5 сторінок + індивідуальний дизайн + SEO = 13500 грн.

Етап 5. Створення системного промпту для JavaScript

1. Приклад комплексного промпту.

Ти — Senior JavaScript Developer та QA Engineer. Мені потрібно реалізувати бізнес-логіку інтерактивного калькулятора вартості вебсайту.
## HTML
В сторінці вже існують:
#pages-count
#design-type
#seo-opt
#responsive-opt
#total-price
#error-pages
Не змінюй HTML без необхідності.
						
## Бізнес-логіка
Базова вартість: 3000 грн.
Кожна сторінка: +1000 грн.
Тип дизайну:
шаблон = 0 грн
індивідуальний дизайн = 5000 грн
SEO: +1500 грн.
Адаптивність: +2000 грн.

## Поведінка
Результат повинен оновлюватися автоматично при зміні input/select/checkbox.
Використовуй:
- addEventListener;
- input;
- change;
- textContent.
Не використовуй jQuery. Код повинен бути Vanilla JavaScript.

## Вимоги
- перевіряй вхідні дані;
- не допускай NaN;
- не допускай Infinity;
- не допускай від'ємних значень;
- обробляй порожні поля;
- використовуй min/max;
- передбач обробку Edge Cases.

Спочатку поясни алгоритм, а потім надай JavaScript-код.

2. Отриманий код зберегти в файлі widget.js
3. Підключити файл JavaScript до HTML <script src="js/widget.js"></script>. Перевірити, що JavaScript завантажується без помилок.
4. Перевірити Happy Path, використовувати тільки правильні значення. Наприклад:
   • сторінок = 5
   • дизайн = індивідуальний
   • SEO = так
   • адаптивність = так
5. Перевірити, чи правильно обчислюється результат.

Етап 7. Перевірка JavaScript через Інструменти розробника Chrome DevTools

1. Відкрити Chrome → F12 → Console
   • Перевірити Errors, Warnings, Logs.
   • Увімкнути Preserve log, щоб повідомлення не втрачалися після перезавантаження сторінки.
2. Перевірити DOM через Console, чи JavaScript знаходить потрібні елементи.
   • Наприклад document.getElementById('total-price')
   • або document.querySelector('#pages-count')

Етап 8. Створення план тестування якості QA Test Plan

Тепер студент переходить від ролі розробника до ролі QA Engineer.

1. Створити тест-кейси. Доцільно перевірити щонайменше такі ситуації:

Етап 9. Стрес-тестування Гранічних випадків Edge Cases

1. Тест на пусте поле. Повністю витерти цифру з поля введення кількості. Що відображає калькулятор? Зазвичай ціна перетворюється на NaN або падає в нуль, а в консолі може виникнути помилка типу ReferenceError.
2. Тест на від'ємні значення. Ввести в поле сторінок -5 або -500. Що сталося з ціною? Якщо сайт повертає від'ємну вартість і компанія тепер «винна гроші» клієнту, тоді це є критичним багом безпеки (Critical Business Logic Bug).
3. Тест на аномальні значення. Ввести 9999999999999999. Чи поширюється текст за межі блоку дизайну?
4. Тест на вживання дробових чисел, наприклад: 2.5. Визначити, чи допускає бізнес-логіка дробові значення. Якщо ні, тоді необхідно округлювати або повідомляти про помилку.
5. Скопіювати всі негативні результати UI та тексти помилок з консолі (якщо вони виникли).

Етап 10. Аналіз помилок в Console

1. Знайти Runtime Errors. Особливу увагу звернути на TypeError, ReferenceError, SyntaxError, RangeError, Uncaught, NaN, Infinity
2. Якщо виникла помилка, тоді розгорнути повідомлення, знайти файл, знайти номер рядка, скопіювати повідомлення, скопіювати Stack Trace.
3. Передати знайдені баги до ШІ в зрозумілому вигляді "контекст + відтворення помилки + очікуваний результат".
4. Приклад промпту

Ти — Senior QA Engineer та JavaScript Developer. Я протестував інтерактивний віджет і знайшов помилку.
## Сценарій
В поле #pages-count я ввів: -5
## Фактичний результат
Віджет показав: -2000 грн
## Очікуваний результат
Від'ємна кількість сторінок повинна бути заборонена.
Користувач повинен побачити повідомлення: "Введіть кількість сторінок від 1 до 50".
## Console [вставити повідомлення Console]
## Завдання 
Проаналізуй причину помилки. Потім запропонуй мінімальне виправлення JavaScript. 
Не переписуй весь файл. Покажи тільки змінений фрагмент та поясни, чому виникла помилка.

Це значно якісніший підхід, ніж повторна генерація всього JavaScript-файлу.

Етап 12. Реалізація Захисного програмування Defensive Programming

Необхідно реалізувати щонайменше три рівні захисту.

1. Рівень 1. HTML5. Використати:

<input type="number" min="1" max="50" required>

2. Рівень 2. JavaScript. Перевіряти дані перед розрахунком:

const pages = parseInt(value, 10);
if (Number.isNaN(pages) || pages < 1 || pages > 50) {
    // повідомлення про помилку
}

3. Рівень 3. Безпечне відображення.
   • Якщо дані походять від користувача, для виведення неперевіреного тексту не використовувати innerHTML.
   • Використовувати: textContent
4. Попросити ШІ провести аудит Defensive Programming

Проведи аудит JavaScript-коду мого віджета з точки зору Defensive Programming.
Перевір:
1. порожні значення;
2. NaN;
3. Infinity;
4. від'ємні значення;
5. нуль;
6. надмірно великі числа;
7. дробові значення;
8. відсутні DOM-елементи;
9. неправильні значення select;
10. повторне швидке введення.
Не змінюй код. Для кожної проблеми вкажи:
Edge Case → Причина → Можливий наслідок → Рекомендований захист.

5. Помилка повинна бути зрозумілою для користувача.
   • Не показувати NaN, TypeError, undefined.
   • Замість цього "Введіть кількість сторінок від 1 до 50."
6. Приклад промпту

Покращ UI повідомлень про помилки в інтерактивному віджеті.
Вимоги:
- повідомлення повинно знаходитися безпосередньо під відповідним полем;
- використовуй Tailwind CSS;
- помилкове поле повинно мати помітний focus/error стан;
- повідомлення повинно бути зрозумілим звичайному користувачу;
- технічні повідомлення JavaScript не повинні відображатися користувачу.
Не змінюй бізнес-логіку.

7. Після виправлення коду необхідно повторити всі тест-кейси.
   • Не можна перевіряти тільки ту помилку, яку було виправлено. Виправлення однієї проблеми може зламати іншу частину віджета.
8. Якщо віджет інтегрується в лендинг, необхідно переконатися, що він не ламає інші компоненти.
   • Перевірити шапку, мобільне меню, форми, слайдери, галереї та інші JavaScript-компоненти.
9. Приклад промпту

Проаналізуй JavaScript віджета з точки зору ізоляції коду.
Перевір:
- глобальні змінні;
- глобальні функції;
- конфлікти id;
- повторне оголошення змінних;
- можливість розміщення двох екземплярів віджета на одній сторінці.
Запропонуй спосіб ізоляції коду за допомогою сучасного Vanilla JavaScript. Не використовуй jQuery.

Етап 17. Інтеграція в лендинг та фінальний аудит якості QA

1. Перевірити дизайн. Віджет повинен:
   • відповідати дизайн системі;
   • мати узгоджену типографіку;
   • використовувати існуючі кольори;
   • мати відповідні заокруглення форм;
   • використовувати існуючі кнопки;
   • коректно працювати на вузькому екрані.
2. Перевірити адаптивність, щонайменше на ширині 320 px, 375 px, 768 px, 1024 px, 1280 px, 1440 px.
   • Особливу увагу звернути на input, select, кнопки, блок результату, повідомлення про помилки.
3. Після завершення роботи виконати комплексний аудит.

Ти — Senior Frontend Developer, QA Engineer та Accessibility Specialist. Проведи фінальний аудит інтерактивного віджета.
Перевір:
## UX
- зрозумілість інтерфейсу;
- логіку взаємодії;
- зрозумілі повідомлення.

## JavaScript
- DOM;
- events;
- валідацію;
- обчислення;
- Edge Cases;
- Runtime Errors.

## Security
- безпечне виведення даних;
- innerHTML;
- textContent.

## Accessibility
- labels;
- keyboard navigation;
- focus;
- aria-атрибути.

## Responsive
- mobile;
- tablet;
- desktop.

## Architecture
- глобальні змінні;
- ізоляцію коду;
- можливість повторного використання.

Не переписуй код.

Сформуй таблицю:

Проблема | Рівень критичності | Причина | Рекомендація.

Етап 5. Публікація та реліз на хостингу за допомогою Git

Після того, як проєкт повністю готовий та протестований, зафіксувати цей фінальний реліз.

1. В терміналі VS Code перевірити стан робочої області: git status
2. Додати всі оновлені компоненти: git add .
3. Зробити фінальний інженерний комміт: git commit -m "feat: додано інтерактивний віджет з повним захистом від Edge Cases (QA-перевірено)"
4. Надіслати код в репозиторій GitHub: git push origin main
5. Завдяки налаштованому раніше CI/CD пайплайну на сервісі Vercel або Netlify, сторінка автоматично перезбереться в хмарі за лічені секунди. Перейти за живим посиланням та перевірити роботу віджета зі смартфона.

Етап 20. Перевірка продакшн-версії

1. Відкрити опублікований сайт. Перевірити:
   • віджет працює;
   • розрахунки правильні;
   • помилки обробляються;
   • Console не містить помилок;
   • адаптивність працює;
   • інші компоненти лендингу не зламані.
2. Особливо важливо протестувати саме продакшн-версію, а не лише локальний сайт.

Очікуваний результат

Головним результатом лабораторної роботи є віджет, який студент вміє спроєктувати, згенерувати за допомогою ШІ, протестувати, знайти в ньому слабкі місця, виправити їх та довести до стабільного продакшн-стану.

                    ІНТЕРАКТИВНИЙ ВІДЖЕТ
                            │
              ┌─────────────┼─────────────┐
              ↓             ↓             ↓
             UX            UI        Бізнес-логіка
              │             │             │
              └─────────────┼─────────────┘
                            ↓
                       Master Prompt
                            ↓
                       ШІ-генерація
                            ↓
                        Happy Path
                            ↓
                       QA Testing
                            ↓
                       Edge Cases
                            ↓
                  Defensive Programming
                            ↓
                       Debugging
                            ↓
                    Regression Testing
                            ↓
                    Production Release

ШІ є ідеальним помічником, але фінальне слово за архітектором. Якщо ШІ видає гарний з виду інтерфейс, варто увімкнути свій внутрішній UX/QA-фільтр. Подивитися на код очима користувача, який випадково або навмисно захоче зламати форму. Справжній професіоналізм полягає не в написанні коду, який працює, коли все добре, а в написанні коду, який продовжує гідно працювати, коли все йде не за правилами.

Зміст звіту та технічні фінальні артефакти

1. Титульний лист з назвою лабораторної роботи, даними студента.
2. Посилання на віддалений репозиторій на GitHub та живе посилання на сайт в інтернеті (Vercel або Netlify).
3. Опис обраного віджета та його бізнес-логіки.
4. appy Path. Показати приклад правильного розрахунку.
5. Edge Cases. Навести щонайменше 5 тестів.
6. Таблицю тест-кейсів (QA Log) за формою:
   • Що вводили | Яка була помилка/поведінка спочатку | Як її виправили завдяки ШІ-перевірочним гвардам.
7. Фінальний лістинг коду (чистий JavaScript-блок валідації та розрахунку).
8. Скріншот вкладки Console з Chrome DevTools, який підтверджує відсутність помилок під час тестування некоректних даних.
9. Промпт-паспорт (Prompt Log). Тексти запиту на генерацію логіки віджета.

Критерії оцінювання лабораторної роботи

• Логіка та складність віджета. Віджет повинен мати щонайменше 3 параметри впливу на фінальний результат (наприклад: інпут введення, селект вибору та чекбокс додаткової опції).
• Обробка помилок та Edge Cases. Ідеальна стійкість програми до некоректного введення. Повна відсутність значень NaN, Infinity або від'ємних фінансових підсумків на екрані.
• Культура тестування та промпт-паспорт в звіті. Наявність чітко заповненого журналу тестування помилок в звіті студента.
• Якість UI/UX відображення помилок. Динамічне увімкнення/вимкнення класів Tailwind CSS (наприклад, червона рамка для невалідного інпуту та текстове попередження користувачу).
• Чистота консолі та деплой. Працююче хмарне посилання, відсутність помилок розгортання та чиста консоль розробника.

Контрольні запитання

1. Що таке інтерактивний віджет в контексті веброзробки? Наведіть приклади.
2. Поясніть різницю між Happy Path та Edge Case.
3. Що таке Defensive Programming (захисне програмування)?
4. Які основні Edge Cases ви тестували в своєму віджеті? Назвіть мінімум 4 випадки.
5. Що означає поява NaN в результаті розрахунку? Чому це виникає?
6. Як ви захищали код від порожнього поля та від’ємних значень?
7. Яку роль має подія input та change при створенні інтерактивного віджета?
8. Як ви перевіряли роботу віджета? Які інструменти використовували?
9. Що потрібно робити, якщо в консолі з’являється помилка TypeError: Cannot read properties of null?
10. Наведіть приклад хорошого промпту до ШІ для виправлення Edge Cases.
11. Чому важливо обмежувати максимальне значення в полях (наприклад, max="500")?
12. Як ви інтегрували віджет в свій основний лендинг?
13. Які коміт-сообщення ви використовували під час фінального релізу? Наведіть приклади.
14. Як відбувається автоматичний деплой після git push?
15. Які головні висновки ви зробили з цієї лабораторної роботи щодо якості коду?

Глосарій термінів. Розробка інтерактивних віджетів та обробка Edge Cases

Рекомендовано для вивчення перед захистом Лабораторної роботи №11