Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
Вы сделали свой React Admin. Скаффолд фреймворков довольно много, они приходят и уходят когда пользователям перестает хватать шаблонов грида и формы. С улучшением эргономики растет степень кастомизации. Но для быстрого прототипирования когда у пользователя нет голоса, самое оно
Согласна, что с React Admin есть схожесть, паттерн может вполне его напоминать, хотя под капотом описан собственный движок, а не сторонняя библиотека.
В отличие от готовых скаффолдов, наше решение не завязано на ограничениях стороннего фреймворка. Если нам перестанет хватать стандартного грида, я добавлю специфичные кейсы в рендерер, а бэк начнет использовать их в контракте. Бэк сам определяет состав формы, фронт занимается только рендером.
Вопросы кастомизации решаются slot-based подходом. Более того, компоненты можно настраивать пропсами прямо с бэка.
Про «пользовательский опыт» — всё проще: бухгалтерам важна предсказуемость и скорость, так что жесткая унификация здесь только в плюс.
Спасибо за комментарий!
Напишите что там будет с этим кодом через полгода или год, если там будете ещё работать;). По опыту разбора json для управления ui на фронте, через некоторое время это становится не поддерживаемым месивом, в которое не хочется заглядывать..
Там проблема в том ,что этот кастрмный json язык потом все обрастает и обрастает атрибутами и правилами и начинает плохо умещаться в изначальную концепцию - привет месиво...
Справедливое замечание, я видела подобные проекты.
но вот в чем суть. Этот проект строится на строгом разделении ответственности. Бэк передает только бизнес сущности, фронт инкапсулирует сложность реализации.
Плюс тимлид бэка тоже понимает риски и старается не раздувать структуру на бэке, когда мы с ним согласуем контракты.
За полгода «обрастания» не произошло. Если будет какая-то сложная логика - никто не пытается натягивать сову на глобус, просто рисуем нужное поведение.
Ну, если схема не будет расти, то может оно и норм будет... В любом случае интересно куда эволюционирует код через год активного внедрения фич
Могу поделиться опытом) У нас очень похожий проект, но ему уже 5 лет и стартовал он с JS, Vue2, Vuex и Element UI. Потом было много переездов, но в итоге мы пришли к почти такому же стеку.
Мы и правда врезали целое море фич и иногда продолжаем что-то допиливать, так как появляются новые пользователи и их хотелки. Вот ряд важных проблем подобной системы:
1. Легаси. У вас нет возможности накатить новую мажорную версию и сломать совместимость. Если где-то не продумали что-то и этим стали пользоваться, придется тащить до конца. Например у нас часть компонентов в value может получать разные типы данных - это не удобно обрабатывать, но деваться уже некуда. Или необходимость мапиться по каким-то данным так как они опирались на старую UI либу.
2. Работа с клиентом. Чтоб не превратить проект в неподдерживаемый кусок говна, надо понять, что из хотелок пользователя - реальный нужный функционал, а что "перламутровые пуговицы" с которыми он должен быть послан в увлекательное эротическое путешествие.
3. Скорость рендеринга. Когда разрабатываешь админки для финтеха надо все умножать на 1000. Например, вот что если надо отрендерить 1000 таблиц или есть у нас 5 чекбоксов, но давайте сделаем 1000 раз по 5 чекбоксов. Надо много опыта, чтоб научиться все адаптировать. Например автор этого поста наступила на те же грабли, что и мы. Взяла готовую ui либу. На больших объемах она начнет тормозить (либа, не автор). Самое лучшее - это взять что-то острое и горячее и пытать дизайнера пока он не напишет вам свою дизайн систему. У нас некого было пытать и мы в итоге перешли на DaisyUI, там под капотом нет js, только css.
4. Высокий порог вхождения. У нас даже опытные фронты в шоке когда пытаются разобраться в проекте)
Терь плюсы:
1. В конечном итоге все это вышло на плато. Люди пользуются, пользователей все больше, с хотелками почти не приходят и живет оно все само по себе.
2. Есть одна система для сотен админок.
Наверно еще надо добавить, что успех всей организации во многом был достигнут еще и разработками на бэке, у нас вся компания пишет бэк на Питоне и мы сделали специальный адаптер, который позволяет создавать админки не возясь с 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-разработчикам