Аудит UI-форм бізнес-процесів
| Назва | Критичність |
|---|---|
Висока |
|
Середня |
|
Висока |
FR-01. Великі форми
| Критичність: Висока |
Робити форми якомога простішими та короткими
-
Зниження продуктивності при рендерінгу форми в браузері
-
Ускладнення внесення змін до форми розробниками регламенту
-
Погіршення користувацького досвіду при заповненні або перегляді форми
-
Збільшення ймовірність виникнення системної помилки у користувача при роботі з формою (наприклад, втрата заповнених даних через закінчення сесії користувача)
-
При внесенні даних, розбивати форму на декілька окремих і робити збір даних поетапно
-
При перегляді даних:
-
Показувати обмежений набір даних за замовчуванням
-
Для перегляду детальної інформації використовувати звіти чи витяги
-
| Детальніше про кращі практики по розробці WEB форм можна ознайомитись за посиланням |
FR-02. Lazy load для компоненту Select
| Критичність: середня |
При наявності великої кількості компонентів Select на формі, використовувати lazy load для підвантаження даних по URL. За замовчуванням компонент Select заздалегідь дістає дані (eager load) по URL в наступних випадках:
-
При первинному рендерінгу форми
-
При зміні в пов’язаному компоненті
-
При оновленні користувацького токена (системна поведінка, яка відбувається безумовно незалежно від дій користувача)
-
Додаткове навантаження на сервери та мережу
-
Збільшення часу рендерінгу форми
-
На момент написання документа в деяких випадках при значній кількості компонентів Select у користувача може виникати системна помилка з оновленням авторизаційного токена
-
Уникати створення великих форм (див. FR-01. Великі форми)
-
Використовувати lazy load для компонентів Select якщо їх кількість на формі достатньо велика (понад 5)
-
Використовувати eager load у випадках, коли це дійсно може покращити користувацький досвід. Наприклад, для першого компоненту Select на формі, щоб у користувача відразу після рендерінгу форми були необхідні дані для вибору
FR-03. Javascript логіка в компонентах форми
| Критичність: висока |
Конструктор форм дозволяє втілити значну кількість обробки даних та валідацій за допомогою вбудованих можливостей. Додатково, існує можливість для певного переліку налаштувань (validation, conditional, custom default value) реалізувати індивідуальну логіку на javascript. Це дозволяє з одного боку гнучко налаштовувати форму, однак, складна та об’ємна логіка створює приховану складність, яка може призвести до проблем, що важко відлагоджуються або непередбачуваної поведінки форми.
Підтримка та розвиток складної javascript логіки на рівні моделювання форми стають крайно незручними. Це може призвести до додаткового часу, витраченого на відлагодження, а також збільшити ймовірність помилок. Особливо це стає актуальним, коли команда розробників змінюється або проєкт передається на підтримку.
-
Контроль обсягу використання Javascript. Обмежувати складність javascript логіки в формах. Намагатися зберігати логіку якомога простішою та більш прямолінійною.
-
Використовувати вбудовані можливості конструктора форм для валідації та обробки даних
-
Уникати побічних ефектів в місцях використання. Кожна вставка javascript логіки має єдину відповідальність (валідація, умовне відображення, обробка даних тощо) та не має впливати на інші частини форми
FR-04. Зовнішні АПІ сервіси в компоненті Select
| Критичність |
,Опис При інтеграції з зовнішніми АПІ сервісами враховувати чи підтримує сервіс cookie для автентифікації, що вплине на налаштування відповідного компоненту select (Add authentication cookies for cross-site requests)
FR-05. Компонент карти. Інтеграція з підкладинками
При необхідності інтеграції з кастомними підкладинками на картах, враховувати CORS політики, які додатково повинні бути налаштовані на API-Gateway MDTUDDM-23166