Comments 12
Вы сделали свой React Admin. Скаффолд фреймворков довольно много, они приходят и уходят когда пользователям перестает хватать шаблонов грида и формы. С улучшением эргономики растет степень кастомизации. Но для быстрого прототипирования когда у пользователя нет голоса, самое оно
Согласна, что с React Admin есть схожесть, паттерн может вполне его напоминать, хотя под капотом описан собственный движок, а не сторонняя библиотека.
В отличие от готовых скаффолдов, наше решение не завязано на ограничениях стороннего фреймворка. Если нам перестанет хватать стандартного грида, я добавлю специфичные кейсы в рендерер, а бэк начнет использовать их в контракте. Бэк сам определяет состав формы, фронт занимается только рендером.
Вопросы кастомизации решаются slot-based подходом. Более того, компоненты можно настраивать пропсами прямо с бэка.
Про «пользовательский опыт» — всё проще: бухгалтерам важна предсказуемость и скорость, так что жесткая унификация здесь только в плюс.
Спасибо за комментарий!
Напишите что там будет с этим кодом через полгода или год, если там будете ещё работать;). По опыту разбора json для управления ui на фронте, через некоторое время это становится не поддерживаемым месивом, в которое не хочется заглядывать..
Там проблема в том ,что этот кастрмный json язык потом все обрастает и обрастает атрибутами и правилами и начинает плохо умещаться в изначальную концепцию - привет месиво...
Справедливое замечание, я видела подобные проекты.
но вот в чем суть. Этот проект строится на строгом разделении ответственности. Бэк передает только бизнес сущности, фронт инкапсулирует сложность реализации.
Плюс тимлид бэка тоже понимает риски и старается не раздувать структуру на бэке, когда мы с ним согласуем контракты.
За полгода «обрастания» не произошло. Если будет какая-то сложная логика - никто не пытается натягивать сову на глобус, просто рисуем нужное поведение.
С незапамтных времен бэк отдавал фрон простым html и все были счастливы. Потом пришли дети с реакт и все свихнулись. Используйте htmx и будете счастливы. Не считая того что "бизнес сущность" это не про json...
«Дети с реакт»… кхм, даже интересно, в какую именно касту вы меня записали :)
По существу: HTMX — это лишь инструмент транспорта HTML через AJAX. Он не решает проблему сложной реактивности и состояния на клиенте (валидация на лету, зависимости полей, маски, работа с модалками без перезагрузки контекста). Для ERP-систем это критично.
Что до «бизнес-сущностей»: согласна, что карта — не есть территория. Однако в описанном подходе MDUI, JSON предоставляет проекцию правил сущности на UI: какие поля доступны, какие readonly, какие действия разрешены. В контексте задачи — это спор о семантике, не более.
Ну и главное. Возврат HTML (пусть даже через HTMX) означает, что нам снова придется верстать каждую страницу руками, просто теперь на стороне бэкенда (шаблонизаторы). А цель моей архитектуры была ровно обратной — уйти от ручного создания страниц к их генерации из структур данных. Бэкендеру проще отдать JSON, чем верстать <div> с классами.
htmx - это не просто транспорт. Это перенос стейта на бэк, где ему и положено быть. А это очень сильно все упрощает. Да придется чуть больше рутов добавить, но это проще чем решать решать проблему со стейтом на фронте. Simple != Easy.
Там где нужно посыпать UI сахарком, можно добавить alpine.js или вообще обойтись CSS. А так-то все он решает, было бы желание покопать вглубь.
Идея то у Вас правильная. Страницы не должны быть захардкожены. Но решение очень спорное.
Это дополнительный слой, лишняя абстракция, которая только усложняет разработку. Скорее всего еще и не задокументированная. Этот конфиг должел Знания об этой поделке не переносятся на другие проекты. Просто лишняя сложность из ничего.
Раз уж критикую - буду предлагать. Есть проверенное решение - Микрофронты с виджетами. У каждого микрофронта свой бэк с htmx + alpine. Весь стейт и правила доступа там. Реактивность - через shell app.
В случаях где вам действительно без супер динамики не обойтись - сделайте только виджет на фреймворке, не надо всю страницу на них делать.
Никаких больших JSON, старые добрые проверенные технологии. И да все ваши бэк девелоперы могут и сами собрать работающий html и даже фронт за вас делать. Вам останется только предложить им коллекцию примеров(не компонентов) как это делать. Дизайн гайд бук, так сказать. И помочь где они застрянут. Ваша роль трансформируется в ментора по фронту, а их - в фулстеков. Те кто так сделают - получат отличный буст к мотивации.
Польза от ваших активностей с JSON может быть в другом. Можно преобразовать эти JSON-ы в приемочные тесты.
Давайте пойдем с конца, так как это фундамент.
1. Про мотивацию бэкендеров
Ваша гипотеза про «буст мотивации» разбивается о реальность. Мой опыт (в компаниях от 50 до 1000 человек) показывает обратное: современные бэкендеры (даже PHP-разработчики, которые исторически ближе к вебу) не хотят заниматься фронтендом — ни версткой, ни UX, ни изучением специфики браузеров.
В данном кейсе вводная от Тимлида (самого бэкендера) была жесткой: «Мы НЕ хотим писать фронт». Превращать профильных специалистов в фуллстаков поневоле — это прямой путь к выгоранию команды и потере качества на обеих сторонах.
2. Инфраструктура и стоимость
Вы предлагаете вместо JSON-контракта (который мы внедрили силами 1 фронта и 1 тимлида) развернуть оркестрацию Микрофронтендов. То есть задействовать DevOps, перестроить CI/CD и переучить всю команду?
Это колоссальный оверхед ради того, чтобы получить разрозненную логику на Alpine.js без нормальной типизации.
Для сравнения: онбординг PHP-разработчика в мою структуру JSON занимает 10 минут. Это прозрачный, типизированный контракт, который сразу дает результат.
3. UX и State на бэке
Мы строим ERP, аналог 1С. Пользователи требуют мгновенной отзывчивости, сравнимой с Excel.
Гонять стейт (валидацию, зависимые поля, калькуляцию в таблицах) через сеть на бэкенд — это проигрыш в отзывчивости. Сетевой лаг на каждом клике в высоконагруженном интерфейсе недопустим.
Есть такое подозрение, что у вас есть убеждение, что фронтенд — это просто «формочки». Но современный фронтенд — это полноценное приложение, работающее в среде браузера (сродни разработке под iOS/Android).
Вы же не станете предлагать переносить логику рендера нативного мобильного приложения на бэкенд, чтобы оно просто отображало картинки? Здесь то же самое. Мы управляем сложным состоянием клиента, и JSON здесь — это идеальный протокол генерации структуры этого приложения.
К сожалению, ваши аргументы для меня не просто не убедительны, а скорее маркер того, что в текущей системе все сделано верно и стоит развивать ее, а не пытаться делить ресурсы команды и обучать всех - всему.
1. Про мотивацию бэкендеров
Ваш опыт это лично ваш опыт в нескольких компаниях - это ошибка выжившего. Вы стали его заложником и не видите проблемы в классической модели управления с распределением ответственности в IT. Не осуждаю, чтобы понять в чем проблема надо целенаправленно интересоваться управлением проектов.
Это не проблема современных бэкендеров - это проблема индутрии, которая говорит им: "у нас тут дети Реакт, зовут себя фронтендерами - они делают фронт". Конечно никакой мотивации у людей не будет. Так что проблема не в них. Они в первую очередь разработчики. И отлично со всем разберутся.
Немножко спекуляции - возможно ваш Тимлид имел ввиду, что они не будут лезть в очередную дурно пахнущую кастрюлю с "UI Framework" лапшой. И тут он абсолютно прав. Нет никакого смысла там ковыряться и что-то чинить, да еще и выслушивать от "фронтендеров" что-то. Проще выбросить обычно.
Средства современного CSS позволяют с минимальными усилиями создавать качесственные интерфейсы. Нет уже той проблемы, что была 10-15 лет назад.
2. Инфраструктура и стоимость
Надо считать не 1 день внедрения, а все часы затупов и поиска багов которые последуют после этого. Что там с документацией? Вы сделали себя ботлнеком для этого решения. Теперь если вдруг что-то новое добавится, а вы будете в отпуске - все будут страдать. Новый валидатор не напишется или еще что.
Между монолитом и Микрофронтами есть достаточно решений не требующих больших изменений. Но то что вы это упомянули говорит о качестве процессов в вашей организации. Не мудрено что вы выбрали JSON боль. Сочувствую.
Изменения которые в долгосрочной перспективе упрощают работу гораздо важнее сиюминутной метрики. Разве что у вас там где-то бонус привязан?
3. UX и State на бэке
Да хоть космический корабль. Я писал что где надо - делается виджет на любимом фреймворке.
Есть такое подозрение
Есть встречные подозрения.
Ваш "Современный фронтенд" - это Теория оправдания системы в действии. Он сложен только по тому что "Дети" не думают, а берут самую сладкую конфету, а не брокколи. Они не видят картину целиком, где на самом деле границы ответственности, и не стараются делать проще. Типичный карго-культ.
В мобильном приложении конечно существуют ограничения платформы. Вот только там еще есть web-view, который сам покажет картинки с нужной странички. Если уж сильно захотеть - можно дать самому приложению доступ к базе и убрать все прослойки. Есть еще интересные варианты.
Удачи с развитием поделки. Искренне желаю чтобы у вас все получилось и вас за это не наказали в итоге.
Назвать решение МдэЮаем это сильно, конечно)
MDUI: как отдать UI backend-разработчикам