Повторное использование форм на React

У нас в БКС есть админка и множество форм, но в React-сообществе нет общепринятого метода — как их проектировать для переиспользования. В официальном гайде Facebook’a нет подробной информации о том, как работать с формами в реальных условиях, где нужна валидация и переиспользование. Кто-то использует redux-form, formik, final-form или вообще пишет свое решение.

В этой статье мы покажем один из вариантов работы с формами на React. Наш стек будет вот таким: React + formik + Typescript. Мы покажем:

• Что компонент должен делать.
• Конфиг, поля и валидация на уровне пропсов.
• Как сделать форму переиспользуемой.
• Оптимизацию перерендера.
• Чем наш способ неудобен.

При новой бизнес-задаче мы узнали, что нам нужно будет сделать 15-20 похожих форм, и гипотетически их может стать еще больше. У нас была одна форма-динозавр на конфиге, которая работала с данными из `store`, отправляла actions на сохранение и выполнение запросов через `sagas`. Она была замечательной, выполняла бизнес-велью. Но уже была нерасширяемой и непереиспользуемой, только при плохом коде и добавлении костылей.

Задача поставлена: переписать форму для того, чтобы ее можно было переиспользовать неограниченное количество раз. Хорошо, вспоминаем функциональное программирование, в нем есть чистые функции, которые не используют внешние данные, в нашем случае `redux`, только то, что им присылают в аргументах (пропсах).

И вот что получилось.

Идея нашего компонента заключается в том, что ты создаешь обертку (контейнер) и пишешь в ней логику работы с внешним миром (получение данных из стора Redux и отправка экшенов). Для этого компонент-контейнер должен иметь возможность получать какую-то информацию через колбеки. Весь список пропсов формы:

interface IFormProps {   // сообщает форме когда ей показывать лоадер и дизейблить кнопки   IsSubmitting?: boolean;   // текс для кнопки отправки   submitText?: string;   //текст для кнопки отмены   resetText?: string;   // стоит ли валидировать при изменении поля (пропс для формика)   validateOnChange?: boolean;    // стоит ли валидировать при blur’e поля (пропс для формика)   validateOnBlur?: boolean;   // конфиг, на основе которого будут рендериться поля.   config: IFieldsFormMetaModel[];   // значения полей.   fields: FormFields;    // схема для валидации   validationSchema: Yup.MidexSchema;   // колбек при сабмите формы   onSubmit?: () => void;   // колбек при клике на reset кнопку   onReset?: (e: React.MouseEvent<HTMLElement>) => void;   // изменение конкретного поля   onChangeField?: (     e: React.SyntaticEvent<HTMLInputElement, name: string; value: string   ) => void;    // присылает все поля на изменение + валидны ли они   onChangeFields?: (values: FormFields, prop: { isValid }) => void;  } 

Использование Formik

Мы используем компонент <Formik />.

render() {   const {     fields, validationSchema, validateOnBlur = true, validateOnChange = true,   } = this.props;    return (     <Formik       initialValues={fields}       render={this.renderForm}       onSubmit={this.handleSubmitForm}       validationSchema={validationSchema}       validateOnBlur={validateOnBlur}       validateOnChange={validateOnChange}       validate={this.validateFormLevel}     />   ); } 

В prop’e формика `validate` мы вызываем метод `this.validateFormLevel`, в котором компоненту-контейнеру даем возможность получить все измененные поля и проверить, валидны ли они.

private validateFormLevel = (values: FormFields) => {   const { onChangeFields, validationSchema } = this.props;    if (onChangeFields) {     validationSchema       .validate(values)       .then(() => {         onChangeFields(values, { isValid: true });        })       .catch(() => {          onChangeFields(values, { isValid: false });        });    } } 

Здесь приходится вызывать еще раз валидацию для того, чтобы дать понять контейнеру, валидны ли поля. При сабмите формы мы просто вызываем prop `onSubmit`:

private handleSubmitForm = (): void => {   const { onSubmit } = this.props;    if (onSubmit) {     onSubmit();   } } 

С пропсами 1-5 все должно быть понятно. Перейдем к ‘config’, ‘fields’ и ‘validationSchema’.

Пропс ‘config’

interface IFieldsFormMetaModel {   /** Имя секции */   sectionName?: string;   sectionDescription?: string;   fieldsForm?: Array<{     /** Название поля формы */     name?: string; // по значению этого поля будет будет находить ключ из prop ‘fields’     /** Является ли поле checked */     checked?: boolean;     /** enum, возможные варианты для отображения поля */     type?: ElementTypes;     /** Текст для лейбла */     label?: string;     /** Текст под полем */     helperText?: string;     /** Признак обязательности заполнения элемента формы */     required?: boolean;     /** Признак доступности поля для изменения */     disabled?: boolean;     /** Минимальное кол-во элементов в поле */     minLength?: number;     /** Объект с начальным значением куда входит само значение и его описание */     initialValue?: IInitialValue;     /** Массив значений для выпадающих списков */     selectItems?: ISelectItems[]; // значения для select, dropdown и подобных   }>; }

На основе этого интерфейса создаем массив объектов и рендерим по такой схеме “раздел” -> “поля раздела”. Так мы можем показывать несколько полей для раздела или в каждом по одному, если нужен заголовок и примечание. Как устроен рендер, покажем немного позже.
Короткий пример конфига:

export const config: IFieldsFormMetaModel[] = [   {     sectionName: 'Общая информация',     fieldsForm: [{       name: 'subject',       label: 'Тема',       type: ElementTypes.Text,     }],   },   {     sectionName: 'Напоминание',     sectionDescription: 'Напоминание для сотрудника',     fieldsForm: [{       name: 'reminder',       disabled: true,       label: 'Сотруднику',       type: ElementTypes.CheckBox,       checked: true,     }],   }, ];

На основе бизнес-данных задаются значения для ключей `name`. Эти же значения используются в ключах prop `fields` для передачи первоначальных или измененных значений для формика.

Для примера выше `fields` может выглядеть так:

const fields: SomeBusinessApiFields = {   subject: 'Встреча с клиентом',   reminder: 'yes', }

Для валидации нам нужно передавать Yup Schema. Форме мы отдаем схему с пропсами контейнера, описывая там взаимодействия с внешними данными, например, запросами.

Форма никак не может повлиять на схему, пример:

export const CreateClientSchema: (   props: CreateClientProps, ) => Yup.MixedSchema =   (props: CreateClientProps) => Yup.object(     {       subject: Yup.string(),       description: Yup.string(),       date: dateSchema,       address: addressSchema(props),     },   );

Рендер и оптимизация полей

Для рендера мы сделали мапу, для быстрого поиска по ключу. Выглядит лаконично и поиск быстрее, чем по `switch`.

fieldsMap: Record<   ElementTypes,   (     state: FormikFieldState,     handlers: FormikHandlersState,     field: IFieldsFormInfo,   ) => JSX.Element   > = {     [ElementTypes.Text]: (       state: FormikFieldState,       handlers: FormikHandlersState,       field: IFieldsFormInfo     ) => {       const { values, errors, touched } = state;        return (         <FormTextField           key={field.name}           element={field}           handleChange={this.handleChangeField(handlers.setFieldValue, field.name)}           handleBlur={handlers.handleBlur}           value={values[field.name]}           error={touched[field.name] && errors[field.name] || ''}         />       );     },     [ElementTypes.TextSearch]: (...) => {...},     [ElementTypes.TextArea]: (...) => {...},     [ElementTypes.Date]: (...) => {...},     [ElementTypes.CheckBox]: (...) => {...},     [ElementTypes.RadioButton]: (...) => {...},     [ElementTypes.Select]: (...) => {...},   };

Каждый компонент-поле является stateful. Он находится в отдельном файле и обернут в `React.memo`. Все значения передаются через props, минуя `children`, чтобы избежать лишнего перерендера.

Заключение

Наша форма неидеальна, для каждого кейса нам приходится создавать контейнер обертку для работы с данными. Сохранять их в `store`, конвертировать и делать запросы. Присутствует повторение кода, от которого хочется избавиться. Мы пробуем найти новое решение, при котором форма в зависимости от пропсов будет брать нужный ключ из стора с полями, экшены, схемы и конфиг. В одном из следующих постов мы расскажем, что из этого получилось.