Angular форм: лучшие практики для сложных вложенных реактивных форм и проверки в компоненте root

Question

В течение нескольких дней я пытался найти хороший шаблон для моего варианта использования. У меня очень сложная реактивная форма, полная вложенных компонентов, некоторые поля требуются, некоторые поля могут появляться при определенных условиях и т. Д. c ... и это создает огромную проблему с поддержанием кода. Подход, который я использовал до сих пор, заключается в передаче formControl дочерним компонентам и заполнению оттуда, но стало очень трудно отлаживать, учитывая размер формы. Обязательным условием для этой формы является то, что при отправке всей формы выполняется проверка всех вложенных полей и отмечается отметка AsTouched любого поля, которое требуется, но не было вставлено. Я изучал 2 подхода, но ни один из них, похоже, не помог:

• Аксессор контрольного значения: концепция идеальна, logi c идеально разделяется между детьми без родителя. есть необходимость беспокоиться об этом, но CON заключается в том, что дочерние контроллеры не отображаются, и я не могу отметить все вспомогательные формы, чтобы показать соответствующие ошибки. элементы управления должны быть определены на родительском уровне, но, будучи очень большой формой, это кажется действительно контрпродуктивным и не решает мою проблему.

Интересно, есть ли у кого-нибудь опыт работы с такими формами и может ли он дать некоторые рекомендации о том, что является наилучшей практикой в ​​этом случае. Я сделал очень простой stackblitz только с одним дочерним элементом, используя Контейнер управления, к сожалению, мне не удалось его запустить https://stackblitz.com/edit/angular-ivy-axbgr5

Answer 1

Сложные формы в Angular могут быть большой проблемой. По моему опыту, лучший подход - создать родительский компонент с сохранением состояния и множество дочерних компонентов без состояния.

Родительский компонент должен быть выделен для определенной формы. Дочерние компоненты можно многократно использовать повсюду много раз.

Правила родительского компонента:

• Stateful
• создает и удерживает определение формы
• испускает состояние формы (значение, действительное, исходное) для каждой формы change
• содержит пользовательский журнал проверки c

Правила дочерних компонентов:

• без сохранения состояния
• получает части формы (вложенные FormGroups) от родителя
• нет настраиваемого журнала проверки c

В приведенном выше сценарии дочерние компоненты представляют собой «повторно используемые представления» без каких-либо журналов проверки c. Он всегда будет исходить от родителя.

Как передать части формы дочерним компонентам?

Вы можете передать вложенные FormGroups следующими способами:

• через Input (https://github.com/p-programowanie/angular-forms/tree/forms-form-group)
• через ControlContainer и внедрение конструктора (https://github.com/p-programowanie/angular-forms/tree/forms-control-container)
• через ControlContainer и viewProvider инъекция (https://github.com/p-programowanie/angular-forms/tree/forms-control-container-provider)

ControlValueAccessor

На мой взгляд, использование ControlValueAccessor для создания частей формы - не лучшая идея. Логи валидации c заключены внутри. Это хороший подход для создания действительно сложных частей, таких как «палитра цветов», а не просто «адрес клиента» с несколькими полями.

Business logi c вне компонента

У меня есть также попытался переместить бизнес-логи c из компонента с помощью следующего простого кода:

constructor(public businessLogic: VendorBusinessLogicService) { }

ngOnInit() {
    this.form = this.businessLogic.createForm(this.initialValue);

    this.subscription = this.form.valueChanges.subscribe(value => {
        this.businessLogic.applyBusinessLogic(value);
        this.emitFormState();
    });

    this.emitFormState();
}

Конечно, требование состоит в том, чтобы держать ссылку на форму внутри службы. Если честно, я не вижу в этом пользы. Этот сервис для бизнес-логи c выглядит устрашающе. (https://github.com/p-programowanie/angular-forms/tree/forms-separated-business-logic)

Answer 2

Я обнаружил, что лучше всего создать одну специализированную службу со всей формой logi c и структурой. Здесь есть все проверки, зависимости, подписки, заполнение групп и массивов форм. Таким образом, очень легко протестировать детали формы и повторно использовать их.