Генератор форм

Описание реализации

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

• Api (nextjs): для реализции был создан отдельный GET endpoint app/api/form/[id]/route.ts - в случве, если клиент идет по пути [host]:[port]/api/form/[id] выполянется поиск файла с названием [id] + .json в папке mocks. В реальной ситуации, логика endpoint-а будет совсем другая и кофиг будет храниться в db - даный endpoint является иллюстрацией того, как приложение могло бы работать. Запрос к API выполнялся с помощью метода createQuery из библиотеки @farfetched/core, так как под капотом она тоже использует effector``.

• Validation (zod): Событие запроса $data, связано с эффектом validateConfig, который использует метод safeParseAsync предоставляемый схемами zod. Подробнее как выглядят схемы, можно посмотреть в /src/shared/validation.

• Form store initialization (Effector): После того как форма провалидирована, есть два возможных исхода - success true/false. В случае если валидация завалилась, создается стандартный стор для формы, с массивом ошибок. В данном случае, компонент который отрисовывает форму выведет Failed to display form., в случае успеха он отрисует форму, которая пришла с сервера в конфиге.

• Form state (Effector): Форма также подписана на событие formFieldChange. Данное событие срабаывает каждый раз, когда пользователь меняет значение элементов формы, переписывая стейт. Для того, чтобы не происходило полного ререндера всей формы на каждое такое событие, был использован метод useStoreMap предоставляемые библиотекой effector-react в сочетании с updateFilter. Значение каждого компонента формы валидируется с помощью zod. Валидаторы создаются автоматически методом createDynamicValidation.

• Submit: В данной реализации кнопка является частью формы. По задумке она должна быть в конфиге, так как ее состояние может быть разным (но в данной реализации можно менять только текст).

• Title/subtitles: Название формы и описание тоже являются частью конфига и используют компонент typography, который должен динамически создавать текст с заданными параметрами.

Обоснование выбора структуры данных

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

Реализовано

• API endpoint
• Валидация конфига формы
• Отрисовка элементов (typography, input text, input number, button)
• Стейт менеджмент и валидация элементов