Чтобы создать дружелюбный интерфейс, необходимо обеспечить однообразное поведение всех форм в приложении. Однообразное поведение часто достигается повторяющимся кодом, хоть и в неявной форме. Позвольте поделиться наброском паттерна, который, по моему мнению, упрощает разработку и стандартизирует поведение форм.
Если код отправки форм в вашем проекте похож на этот, советую заглянуть под кат.
onSubmit(): void
// login.component.ts
// bad practices
onSubmit(): void {
this.formSubmitted = true;
this.isUnhandledServerError = false;
if (!this.formGroup.valid) return;
this.isLoading = true;
const { username, password } = this.formGroup.value;
this.login(username, password)
.pipe(finalize(() => (this.isLoading = false)))
.subscribe({ error: error => this.handleError(error) });
}
Для тех кто просто любит код:
Проект на stackblitz до рефакторинга.
Проект на stackblitz после рефакторинга.
Описание проблемы
Формы требуют учитывать много нюансов. С функциональной точки зрения, форма всего лишь отправляет введенную пользователем информацию на сервер. Но для обеспечения качественного UX помимо всего приходится заниматься валидацией, отображать ошибки от сервера, индикатор загрузки, и т.п. Эти детали на практике часто остаются без должного внимания со стороны разработчиков, что либо негативно сказывается на комфорте использования приложения, либо выливается в дублирование кода и превращает разработку форм в невыносимую рутину.
Предлагаю разобрать пример обработчика отправки формы, хорошего с точки зрения UX, но плохого с точки зрения разработки. Проект на stackblitz до рефакторинга.
// login.component.ts
onSubmit(): void {
this.formSubmitted = true; // подкрашиваем невалидные элементы
this.isUnhandledServerError = false; // скрываем сообщение об неизвестной ошибке на сервере
if (!this.formGroup.valid) return; // валидируем форму
this.isLoading = true; // показываем индикатор загрузки
const { username, password } = this.formGroup.value;
this.login(username, password) // отправляем данные на сервер
.pipe(finalize(() => (this.isLoading = false))) // скрываем индикатор загрузки
.subscribe({ error: error => this.handleError(error) });
}
Как вы видите, в данном обработчике учтено большое количество деталей, составляющих UX. Проблема лишь в том, что при таком подходе, эти нюансы придется прописывать для каждой формы в приложении.
Решение
Чтобы упростить разработку и стандартизировать поведение форм в приложении, необходимо вынести код обработчика отправки формы в отдельный класс. Проект на stackblitz после рефакторинга. (Я намеренно упростил код для примера, в реальном проекте нужно заменить все boolean поля на Observable.)
class Form<T> {
submitted = false;
pending = false;
hasUnhandledServerError = false;
constructor(private formGroup: FormGroup, private action: (value: any) => Observable<T>) {}
submit(): Observable<T> {
if (this.pending) return EMPTY;
this.submitted = true;
this.hasUnhandledServerError = false;
if (this.formGroup.valid) {
this.pending = true;
return this.action(this.formGroup.value).pipe(
tap({ error: () => (this.hasUnhandledServerError = true) }),
finalize(() => (this.pending = false)),
);
}
return EMPTY;
}
}
Таким образом, мы концентрируем большую часть особенностей UX в одном классе и избавляемся от дублирования логики. Теперь написание новой формы будет отнимать меньше времени, а дополнить поведение форм во всем приложении можно через изменение одного лишь класса Form.
Почему не вынести это в библиотеку?
Требования к UX для каждого проекта уникальны, и в большей степени зависят от дизайнера. Мне уже приходилось переопределять поведение стандартных Material элементов по пожеланию заказчика. Поэтому я не вижу хоть сколько-нибудь возможным стандартизировать поведение форм во всех приложениях с помощью одной библиотеки. Пусть поведение интерфейса остается во власти дизайнера и разработчиков. Тем не менее я считаю, что это неплохая идея — выделять связанную с UX логику в отдельные классы.
Надеюсь, пример был полезен, и вы попробуете использовать идею в своих проектах. Пока!
