Комментарии 17
Этот подход уже давно используется в конфигураторе ядра Linux — система Kconfig.
Интересно посмотреть на живой пример/ну или gif, когда сами поля строятся динамично. Например для поля `ru_passport` есть поле `ru_passport_id` (с масками и валидацией, и т. д.), но при переключении на `foreign_passport` выводим уже `foreign_passport_id` (уже другая маска, валидация...) плюс `foreign_passport_expire-date`.
Вряд ли вам это продемонстрируют. Сложные динамические формы это всегда боль, а вот такие хэлло ворлды, как в статье, могут пригодиться только в очень ограниченном числе сценариев. А если в форме еще и зависимые поля с комбобоксами и датасорсами, да еще и динамические валидации, то вообще ой.
У нас есть подобные кейсы с динамическими формами, валидацией и тд. Я очень упрощенный пример показал как раз, чтобы не усложнять для понимания. Мы же можем в элементы добавлять любые методы для валидации и формировать ответ в любом виде на бэкенде всегда, добавлять сообщения об ошибках или новые поля на ходу
В том-то и дело, что ваш упрощенный пример никому не нужен, потому что практические задачи не решает. Да и не требуется семи пядей во лбу для того, чтобы такой подход придумать и использовать. А вот штука, которая решает вышеописанные проблемы малой кровью - вот что интересно. Только все хэлло ворлдщики почему-то плавно съезжают с темы, когда их просят показать что-то действительно существенное.
Я бы поспорил, что больше полезно – описание базовой концепции, которую можно использовать под свои задачи или описание супер сложной задачи, которая возникла в конкретной компании в какой-то момент времени. Но в любом случае оба варианта могут существовать
Спорить можно бесконечно. Как вы думаете, многочисленные ToDo лист реализации, коих полно в интернете, кого-нибудь научили писать сложные приложения?
Кого-нибудь научило конечно. Но у меня штука все-таки посложнее туду листа будет, и такого точно не полно в интернете ?
Я уже пару лет занимаюсь разработкой и поддержкой подобного формбилдера. У нас в качестве блока информации выступает не какое-то конкретное поле, а виджет. Внутри себя виджет может быть чем угодно до тех пор, пока он умеет реализовывать базовое api: рисовать данные в режиме редактирования/просмотра, валидировать, настраивать права доступа/отображение и т.п.
Пока мы внутри виджета, мы можем любую логику реализовать. Но, как только у нас начинаются всякие сложные виджеты, типа контейнера, который может содержать N экземпляров других виджетов, как только появляются зависимые данные между разными виджетами, вот тогда это больно.
Например, есть таблица с десятком колонок. В каждой колонке дропдаун, значение которого зависит от выбранных значений других колонок в этой строке. Заморочились и сделали. Но, дальше заказчик начал хотеть зависимости между разными виджетами и мы сразу отгребли проблемы.
Потому что у виджетов могут быть разные права доступа, разные условия их отображения и т.п. Потом ещё захотели калькулируемые поля, когда значение какого-нибудь дропдауна переформатируется и вставляется внутрь строки.
В общем, как выше уже заметили, реально сложно и интересно становится уже именно на сложных формах.
А в чём принципиальное отличие от генерации html на сервере? Ну кроме ненужности реакта вместе с type-script-ом.
Автор предлагает сделать компонент для фронта, просто свалив всю работу на бэк. Разве не так? Но я щё подскажу - такой компонент в случае с html давно есть, называется браузер. Так зачем же нам новый фреймворк, заменяющий собой всё то, что и так уже делает браузер? Зачем снова и снова делать велосипед, если есть давно отработанное и надёжное авто марки "браузер"?
Да, это не относится ко всем проблемам фронта. Это лишь указание на проблему конкретной идеи конкретного автора.
Я как раз недавно думал о том, что все носятся с lowcode как с какой-то гениальной идеей, а ведь я сам в начале нулевых клепал движки для таких вот автоформ. И да, с очень сложными проверками, динамическим layout, ... Причем тогда это была идея фикс, что бизнес будет сам себе клепать приложения, наконец-то избавится от программистов... И не какие-то простые формочки, а вполне себе фронт-офис для страховых, банков... В общем, я тогда был молод, каждый год менял работу и в каждой айтишной конторе обязательно был проект по созданию такого чудо конструктора.
В некоторых случаях они были действительно супер сложными. Помню в одной конторе у нас все приложение описывалось xml. Это была трехзвенка и все три звена работали по этому xml. Веселее всего было с миграциями для БД, для нетривиальных случаев приходилось в этом xml прописывать миграции с предыдущих версий.
И вместо html использовался свой язык общения между фронтом и бэком тоже почти везде тогда. Совсем тонких клиентов в таких системах действительно не бывает, а с толстым клиентом зачем общаться через html, это неудобно.
Потом тренды поменялись в сторону менее конфигурируемых систем, потом вообще на эти конструкторы стали смотреть с опаской, стали делать заказуху или использовать готовые продукты.
А сейчас вот новая волна пошла :) Снова про lowcode разговоры и про то, что программисты не очень-то нужны :)
Такую коробочную эньерпрайзную штуку допиливаю уже лет 10.
Ibm product master (бывший mdm) - накидываешь спецификацию с полями и валидациями, а морда отображает. Если что-то сложное нужно, подписываешь свой код в точках расширения лайвцикла
Для MDM это очень хорошо подходит. Если оно ещё грамотно интегрируется с DataStage для того, чтобы ETL валидный было легко делать...
А насколько оно хорошо живёт с идеей, что метамодель меняется?
Кто-то в РФ вообще использует Product Master?
Интеграция с DataStage не из коробки, а через промежуточные экспорты-импорты, так как в IPM нельзя просто залезть в базу и стянуть/положить данные, там EAV и сотни таблиц с метаданными.
Нормально живет, атрибуты добавляются/удаляются как и везде.
Кто используют в РФ, думаю, по пальцам пересчитать можно.
Мы постоянно имеем дело с формами: регистрация, заполнение анкеты, составление отзыва. Первое, что нам хочется сделать как разработчикам,— максимально выделить общие компоненты, чтобы как можно меньше дублировать код.
Всё что можно было вынести в "общие компоненты" уже выделили.. называется ui-библиотека\библиотека-компонентов (material, semantic, bootstrap, uikit, etc..). Дальше выносить и обобщать во что-то общее и универсальное не рентабельно.. такие абстракции треснут очень быстро.
В итоге у нас получился универсальный компонент
ProfiForm, который сам ходит в сервис и рисует любую форму по полученной структуре данных!
Слово "универсальный" обычно должно настораживать. Форма и её результат - это чисто клиентская история.. требования могут быть ооочень динамичными. Не дешевле и не надёжнее ли всё-таки, чтоб форму собирали из готовых ui-компонентов условно джуны-верстальщики, а результаты этой формы уже отправляли бы на бек.. без всякого шаманства и кодогенерации.
Да, каждый раз бы собирали руками, каждую новую форму.. no-big-deal.. это не долго и не дорого, особенно если рука уже набита. Зато поддерживаемость и гибкость полностью под вашим контролем.
Ага, а потом этот общий компонент будет разрастаться, обретать все больше if, else if, else.
При этом в каждый момент времени нужно будет держать в голове как эта фигня работает под капотом, вместо того, чтобы делать конкретную бизнес-задачу не уровне спинного мозга.
Реально что-то похожее на проекте, даёт очень много боли при достаточной сложности проекта.
Как сделать много форм, не сделав ни одной