Знаете, вы мне говорите про менторский тон, при этом сами неоднократно указываете, что у меня то опыт не такой, то его недостаточно, то я пальцы гну («я не первый год во фронтенде варюсь»), то у меня профдеформация — то есть мои аргументы можно по существу не рассматривать.
В одном соглашусь: любая технология устаревает, и BDUF может обесцениться вместе со стеком — это реальная проблема. Но это аргумент за стабильные контракты на границах, а не против них.
Идея ровно в том, чтобы инвестировать в то, что переживёт смену инструментов: типы данных и границы слоёв стабильнее, чем конкретные фреймворки. node-sass устарел, а понятие «нормализатор на входе данных» — нет.
Если есть содержательные контраргументы к нормализации, контрактам или разделению Raw/Domain типов — давайте по ним. Если нет — это не дискуссия, это перетягивание авторитета, и в ней мне неинтересно участвовать. Как и неинтересно спорить, «чей опыт ровнее».
Я неоднократно сказала, что пишу про подход в конкретной ситуации, и не предлагаю строить космолёты для лендосов. Но вы видите ровно то, что ставит вас в более красивую позицию.
Вы можете отвечать, конечно, но увы, я интерес к вашим аргументам потеряла вовсе. Бравируйте где нибудь в другом месте, пожалуйста.
Вы слишком многое о себе мните. Вы сказали "Только у себя". Я, без названия группы компаний, обозначила, что за компании такое практикуют. Более того, я там даже не работаю.
Если Дуров для телеграма использует один файл в котором все описано – это не значит, что это здоровый подход. Все равно, что говорить "ну вот чел на олимпиаде же золотую медаль выиграл, хотя курит как паровоз, значит курить – полезно для здоровья".
А вот когда вы уже заговорили про ваш опыт, то это. конечно, уважаемо, но не доказывает вашу правоту ни на йот.
Вместо ответа случайно лайк поставила... не хотела, не хотела
Что такое "онбординг"? Завязывайте вы с этим "англо-русским суржиком" - порой невозможно понять становится...
я так понимаю, у вас люди никогда не меняются, все десятками лет на одной и той же позиции и вы сами сидите исключительно на одном проекте, что вам нужно объяснять, что такое онбординг? К словам не цепляйтесь
Это уже давно просто... дань моде!
Уже лет пять TS это стандарт индустрии, в каждой вакансии требуется знание TS. Но это дань... так и запишем...
Я тоже не первый год во фронтенде, и? В любом случае, вы уходите от обсуждения в плоскость эмоций. Но один ваш аргумент ну просто великолепен, потому что он доказывает мою изначальную мысль:
Завтра вам бэк отдаст данные как и положено в виде строки, только это будет просто число в кавычках и ваш лингвистический парсер сразу на нём глюкнет.
В этом и суть нормализации, которую я привела в своем комментарии. В этом также и суть типизации. TS описывает статический контракт (то, что UI ожидает), а нормализатор может подхватить сырые данные от бэка и привести к нужному виду безопасно для интерфейса.
Если проверку не делать, то этот глюк вы будете отлавливать не на этапе рантайма, а где-нибудь у юзера багнет в глубине интерфейса, и ищи-свищи, почему и как этот баг вылез.
Если вас так беспокоит писать самостоятельно, то есть GQL, есть ZOD в конце концов.
А если перспектива не нужна? А вот на старте он как раз их резко увеличивает!
Зачем приводить в пример проекты, где "перспектива не нужна" в статье про стор? Там и VUE/REACT/ANG не нужен, если это такая однодневка, что у нее перспективы нет. Зачем туда вообще pinia затягивать и стейт-менеджмент?
Представляете - я и JS считаю избыточным там, где справится CSS!
Смотрим на предыдущий тезис. Вы приводите использование CSS там, где обсуждается использование инструментов, где CSS ну никак не поможет.
Другими словами присваиваете мне заочно то, о чем я вообще не говорила, чтобы выставить мое мнение как исходно некорректное или глупое) Если вы не можете оспорить по существу, то просто не отвечайте.
Вы не просто это предлагаете, вы ещё ожесточённо со мной спорите по этому поводу))
Цитируйте. Опять же, выдумки ради выдумок.
Разницу замечаете - я не скатываюсь в догматизм "правильно именно так!"
Есть статья, мне есть к чему придраться – я и придираюсь. Я предлагаю структуру, как бы беседуя с автором статьи через его же персонажа. Вы же выставляете так, будто я навязываю свою систему (а это не так, предложение видения – это не навязывание позиции).
Ну а говорить про парадигму и профдеформацию – это уже стендап, типичный ad hominem. У меня есть достаточно большой опыт в проектировании и работе с реальными интерфейсами, сложными и не очень, в обучении новых разработчиков, в кодревью и в целом экспериментирую (причем иногда прямо на работе) тоже очень много. Если вы это называете "догматизмом" – ок, называйте и надейтесь, что вы не будете тратить лишние часы на то, чтобы просто держать "в узде" свои проекты.
P.S. Я лично вашу позицию считаю куда более зашоренной и "догматичной". Только ваш догматизм проявляется в том, что вы хотите денег рубить за меньшее количество работы, чем у вас есть. И поэтому всякий зоопарк в проектах вас не особо напрягает. эдакий "эффект Гомера" у вас: проблемы, которые я сегодня не предусмотрел, будет решать будущий я.
Я же мыслю в той парадигме, как бы мне самой себе в будущем не добавить работы.
За сим откланяюсь, ваш переход на личности меня совершенно не радует.
Существует как минимум одна крупная компания в той же РФ, где активно применяется та логика, о которой я говорю. Ее продуктами пользуется более 22000 ритейлеров по РФ и еще сколько-то в СНГ, а сама компания входит в топ-5 интеграторов CRM систем. Дальше уже сами погуглите, что это может быть за компания.
Никто и не думал вам грубить. Мне искренне интересно было почитать и я бы почитала ещё.
Право на публикации никто не оспаривал. Мне искренне хотелось с вами пообсуждать и узнать ваше менее по теме, а вы решил почему-то, что это нападение. Discussio mater veritas est
А я считаю его использование явно избыточным (см. вышеозвученную первопричину) для многих (не для всех) проектов.
Считать TS избыточным в современном фронтенде — это, конечно, сильно. Это уже давно инструмент для онбординга, который отлично снижает трудозатраты в перспективе и никак их не увеличивает.
А ещё границы могут плавать - и тогда приходится переопределять саму базовую концепцию стора.
В этом-то и прикол: строгие контракты позволяют логике плавать как угодно и эволюционировать безболезненно. Если вы в строгом контракте меняете реализацию внутри, вы этим не ломаете логику потребителей.
Вас такое наверное в ступор вводит?
Меня мало что в ступор вводит. Писать непродуманно — это распространенная ситуация, с которой я стараюсь бороться.
Главная из которых - решение поставленной бизнес-задачи в рамках доступных трудозатрат ;)
Отказ от контрактов и TS (который вы почему-то считаете избыточным) экономит время только первые две недели проекта. Мало того, что это потенциально увеличит трудозатраты в дальнейшем при добавлении новой сущности/фичи, так еще и изменение бэка повлечет за собой набор багов, которые вы запаритесь отлавливать по всему проекту.
Удивительным образом вы пытаетесь продать техдолг и отсутствие границ зон ответственности ради мнимого "прагматичного решения бизнес-задач".
Да, границы, безусловно, могут плавать. Никто не предлагает строить космолет для лендоса. Но в итоге каждый сам волен решать: потратить 10 минут на продумывание логики стора сейчас, или тратить часы на дебаг потом, оправдывая это "доступными трудозатратами" на старте.
Что-то не вижу того, что мой образец – идеальный. Вроде и не говорю, что это идеальное решение, которое всем подойдет. Вопрос в том, что в рефакторе нужно отталкиваться не столько от практик, сколько от того, чем является стор, для чего он предназначен, что с этими данными БЛ делает. И отсутствие этих границ — это выстрел в ногу. А пока что автор не особенно-то и рассматривает эти границы, хотя паттерны про изоляцию слоев и нормализацию данных не является оверинжинироингом.
Ad hominem – вещь, конечно, интересная, но ведь можно рассмотреть вопрос того, что у собеседника макбук. Это уже давно не аргумент в пользу ИИ, полагаю у вас нет других аргументов в это.
Что по сути.
Я говорю лишь о том, что вы остановились на полпути, на симптомах, и даете статью как готовый мануал, от которого можно оттолкнуться, читатель унесет ее как образец. А в образце остались совершенно нетронутыми проблемы, которые как раз и стоило разобрать, и в которых работа с LS и watch отвалились бы самостоятельно.
На самом деле Алексу нужно задуматься вот о чем. Pinia прививает очень плохую практику, в которой стор "и швец и жнец и на дуде игрец", то есть он:
Инициализирует данные
Выполняет запрос к другим данным
Меняет собственное состояние
В идеале нужно было бы подойти с такой точки зрения:
Что в этом сторе является БЛ, а что – логикой стора
какие данные стор хранит и как их получает
как данные нормализуются при записи и какой тип является «контрактом» стора
кто имеет право мутировать состояние — стор сам через методы, или кто угодно снаружи напрямую
какие вычисления являются производными от состояния стора (computed), а какие — бизнес-логикой, которой в сторе вообще не место
какой тип является контрактом стора — any вообще не должен быть допустим, Record<string, unknown> — полумера. Нужно использовать явный интерфейс и типизировать через него хранилище. Если не получается – значит проблему надо решать уровнем выше, до написания стора
внешние элементы, включая композабл, не должны менять состояние стора напрямую — только через явные методы. Подход get/set никто не отменял
мы неожиданно поймем, что в сторе должно быть примерно так:
interface Property {
typeId: string
label: string
// ... остальные поля
}
interface RawProperty {
type_id: string
name?: string
// поля как приходят с API — snake_case, необязательные
}
export const usePropertyStore = defineStore('property', () => {
const items = ref<Property[]>([])
const activeType = ref<string | null>(null)
const currentItem = computed(() => items.value.find(p => p.typeId === activeType.value) ?? null)
function _normalize(raw: RawProperty[]): Property[] {
return raw.map(p => ({
typeId: p.type_id,
label: p.name ?? 'Unknown',
// остальные поля
}))
}
function setItems(raw) {
items.value = _normalize(raw)
}
return { items, setItems, activeType, currentItem }
})
find здесь не случаен — он явно выражает намерение: найди элемент по условию. Индексный доступ items[key] выражает другое: возьми по заранее построенному ключу, и тогда ты несёшь ответственность за консистентность этой структуры. Массив с find честнее: источник правды — список, поиск — производная операция. Если завтра условие усложнится (например, искать по typeId и regionId), массив расширяется тривиально, а Record потребует смены ключа и рефакторинга всех мест записи.
В идеале надо смотреть в сторону того, что стор может явно иметь функции для нормализации (чтобы привести входящие данные к контракту) и дальше только методы чтения/записи, использующие типы для того, чтобы извне сообщать структуру. RawProperty и Property могут и должны отличаться — граница между ними и есть зона ответственности нормализатора.
Остальную логику вытаскивать в композабл и переиспользовать (он же и должен возвращать стор — делаем компонент, который агностичен к стору, т.е. напрямую со стором не взаимодействует). Так, если логика поменяется, стор не будет затронут, и взаимодействие с ним можно расширять без риска что-то сломать.
В целом в мобильных приложениях BFF сам по себе хорошо залетает, так что думаю что-то похожее можно затащить :) насколько я понимаю , р-нэтив нормально шаблонизируется
Ваша гипотеза про «буст мотивации» разбивается о реальность. Мой опыт (в компаниях от 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 здесь — это идеальный протокол генерации структуры этого приложения.
К сожалению, ваши аргументы для меня не просто не убедительны, а скорее маркер того, что в текущей системе все сделано верно и стоит развивать ее, а не пытаться делить ресурсы команды и обучать всех - всему.
«Дети с реакт»… кхм, даже интересно, в какую именно касту вы меня записали :)
По существу: HTMX — это лишь инструмент транспорта HTML через AJAX. Он не решает проблему сложной реактивности и состояния на клиенте (валидация на лету, зависимости полей, маски, работа с модалками без перезагрузки контекста). Для ERP-систем это критично.
Что до «бизнес-сущностей»: согласна, что карта — не есть территория. Однако в описанном подходе MDUI, JSON предоставляет проекцию правил сущности на UI: какие поля доступны, какие readonly, какие действия разрешены. В контексте задачи — это спор о семантике, не более.
Ну и главное. Возврат HTML (пусть даже через HTMX) означает, что нам снова придется верстать каждую страницу руками, просто теперь на стороне бэкенда (шаблонизаторы). А цель моей архитектуры была ровно обратной — уйти от ручного создания страниц к их генерации из структур данных. Бэкендеру проще отдать JSON, чем верстать <div> с классами.
Справедливое замечание, я видела подобные проекты.
но вот в чем суть. Этот проект строится на строгом разделении ответственности. Бэк передает только бизнес сущности, фронт инкапсулирует сложность реализации.
Плюс тимлид бэка тоже понимает риски и старается не раздувать структуру на бэке, когда мы с ним согласуем контракты.
За полгода «обрастания» не произошло. Если будет какая-то сложная логика - никто не пытается натягивать сову на глобус, просто рисуем нужное поведение.
Согласна, что с React Admin есть схожесть, паттерн может вполне его напоминать, хотя под капотом описан собственный движок, а не сторонняя библиотека.
В отличие от готовых скаффолдов, наше решение не завязано на ограничениях стороннего фреймворка. Если нам перестанет хватать стандартного грида, я добавлю специфичные кейсы в рендерер, а бэк начнет использовать их в контракте. Бэк сам определяет состав формы, фронт занимается только рендером.
Вопросы кастомизации решаются slot-based подходом. Более того, компоненты можно настраивать пропсами прямо с бэка.
Про «пользовательский опыт» — всё проще: бухгалтерам важна предсказуемость и скорость, так что жесткая унификация здесь только в плюс.
Знаете, вы мне говорите про менторский тон, при этом сами неоднократно указываете, что у меня то опыт не такой, то его недостаточно, то я пальцы гну («я не первый год во фронтенде варюсь»), то у меня профдеформация — то есть мои аргументы можно по существу не рассматривать.
В одном соглашусь: любая технология устаревает, и BDUF может обесцениться вместе со стеком — это реальная проблема. Но это аргумент за стабильные контракты на границах, а не против них.
Идея ровно в том, чтобы инвестировать в то, что переживёт смену инструментов: типы данных и границы слоёв стабильнее, чем конкретные фреймворки. node-sass устарел, а понятие «нормализатор на входе данных» — нет.
Если есть содержательные контраргументы к нормализации, контрактам или разделению Raw/Domain типов — давайте по ним. Если нет — это не дискуссия, это перетягивание авторитета, и в ней мне неинтересно участвовать. Как и неинтересно спорить, «чей опыт ровнее».
Я неоднократно сказала, что пишу про подход в конкретной ситуации, и не предлагаю строить космолёты для лендосов. Но вы видите ровно то, что ставит вас в более красивую позицию.
Вы можете отвечать, конечно, но увы, я интерес к вашим аргументам потеряла вовсе. Бравируйте где нибудь в другом месте, пожалуйста.
Вы слишком многое о себе мните. Вы сказали "Только у себя". Я, без названия группы компаний, обозначила, что за компании такое практикуют. Более того, я там даже не работаю.
Если Дуров для телеграма использует один файл в котором все описано – это не значит, что это здоровый подход. Все равно, что говорить "ну вот чел на олимпиаде же золотую медаль выиграл, хотя курит как паровоз, значит курить – полезно для здоровья".
А вот когда вы уже заговорили про ваш опыт, то это. конечно, уважаемо, но не доказывает вашу правоту ни на йот.
Вместо ответа случайно лайк поставила... не хотела, не хотела
я так понимаю, у вас люди никогда не меняются, все десятками лет на одной и той же позиции и вы сами сидите исключительно на одном проекте, что вам нужно объяснять, что такое онбординг? К словам не цепляйтесь
Уже лет пять TS это стандарт индустрии, в каждой вакансии требуется знание TS. Но это дань... так и запишем...
Я тоже не первый год во фронтенде, и? В любом случае, вы уходите от обсуждения в плоскость эмоций. Но один ваш аргумент ну просто великолепен, потому что он доказывает мою изначальную мысль:
В этом и суть нормализации, которую я привела в своем комментарии. В этом также и суть типизации. TS описывает статический контракт (то, что UI ожидает), а нормализатор может подхватить сырые данные от бэка и привести к нужному виду безопасно для интерфейса.
Если проверку не делать, то этот глюк вы будете отлавливать не на этапе рантайма, а где-нибудь у юзера багнет в глубине интерфейса, и ищи-свищи, почему и как этот баг вылез.
Если вас так беспокоит писать самостоятельно, то есть GQL, есть ZOD в конце концов.
Зачем приводить в пример проекты, где "перспектива не нужна" в статье про стор? Там и VUE/REACT/ANG не нужен, если это такая однодневка, что у нее перспективы нет. Зачем туда вообще pinia затягивать и стейт-менеджмент?
Смотрим на предыдущий тезис. Вы приводите использование CSS там, где обсуждается использование инструментов, где CSS ну никак не поможет.
Другими словами присваиваете мне заочно то, о чем я вообще не говорила, чтобы выставить мое мнение как исходно некорректное или глупое) Если вы не можете оспорить по существу, то просто не отвечайте.
Цитируйте. Опять же, выдумки ради выдумок.
Есть статья, мне есть к чему придраться – я и придираюсь. Я предлагаю структуру, как бы беседуя с автором статьи через его же персонажа. Вы же выставляете так, будто я навязываю свою систему (а это не так, предложение видения – это не навязывание позиции).
Ну а говорить про парадигму и профдеформацию – это уже стендап, типичный ad hominem. У меня есть достаточно большой опыт в проектировании и работе с реальными интерфейсами, сложными и не очень, в обучении новых разработчиков, в кодревью и в целом экспериментирую (причем иногда прямо на работе) тоже очень много. Если вы это называете "догматизмом" – ок, называйте и надейтесь, что вы не будете тратить лишние часы на то, чтобы просто держать "в узде" свои проекты.
P.S. Я лично вашу позицию считаю куда более зашоренной и "догматичной". Только ваш догматизм проявляется в том, что вы хотите денег рубить за меньшее количество работы, чем у вас есть. И поэтому всякий зоопарк в проектах вас не особо напрягает. эдакий "эффект Гомера" у вас: проблемы, которые я сегодня не предусмотрел, будет решать будущий я.
Я же мыслю в той парадигме, как бы мне самой себе в будущем не добавить работы.
За сим откланяюсь, ваш переход на личности меня совершенно не радует.
Существует как минимум одна крупная компания в той же РФ, где активно применяется та логика, о которой я говорю. Ее продуктами пользуется более 22000 ритейлеров по РФ и еще сколько-то в СНГ, а сама компания входит в топ-5 интеграторов CRM систем. Дальше уже сами погуглите, что это может быть за компания.
Никто и не думал вам грубить. Мне искренне интересно было почитать и я бы почитала ещё.
Право на публикации никто не оспаривал. Мне искренне хотелось с вами пообсуждать и узнать ваше менее по теме, а вы решил почему-то, что это нападение. Discussio mater veritas est
Про теоретические абстракции смешно было. Я эту практику вижу не только у себя, но и в других крутых проектах
Считать TS избыточным в современном фронтенде — это, конечно, сильно. Это уже давно инструмент для онбординга, который отлично снижает трудозатраты в перспективе и никак их не увеличивает.
В этом-то и прикол: строгие контракты позволяют логике плавать как угодно и эволюционировать безболезненно. Если вы в строгом контракте меняете реализацию внутри, вы этим не ломаете логику потребителей.
Меня мало что в ступор вводит. Писать непродуманно — это распространенная ситуация, с которой я стараюсь бороться.
Отказ от контрактов и TS (который вы почему-то считаете избыточным) экономит время только первые две недели проекта. Мало того, что это потенциально увеличит трудозатраты в дальнейшем при добавлении новой сущности/фичи, так еще и изменение бэка повлечет за собой набор багов, которые вы запаритесь отлавливать по всему проекту.
Удивительным образом вы пытаетесь продать техдолг и отсутствие границ зон ответственности ради мнимого "прагматичного решения бизнес-задач".
Да, границы, безусловно, могут плавать. Никто не предлагает строить космолет для лендоса. Но в итоге каждый сам волен решать: потратить 10 минут на продумывание логики стора сейчас, или тратить часы на дебаг потом, оправдывая это "доступными трудозатратами" на старте.
Что-то не вижу того, что мой образец – идеальный. Вроде и не говорю, что это идеальное решение, которое всем подойдет. Вопрос в том, что в рефакторе нужно отталкиваться не столько от практик, сколько от того, чем является стор, для чего он предназначен, что с этими данными БЛ делает. И отсутствие этих границ — это выстрел в ногу. А пока что автор не особенно-то и рассматривает эти границы, хотя паттерны про изоляцию слоев и нормализацию данных не является оверинжинироингом.
Ad hominem – вещь, конечно, интересная, но ведь можно рассмотреть вопрос того, что у собеседника макбук. Это уже давно не аргумент в пользу ИИ, полагаю у вас нет других аргументов в это.
Что по сути.
Я говорю лишь о том, что вы остановились на полпути, на симптомах, и даете статью как готовый мануал, от которого можно оттолкнуться, читатель унесет ее как образец. А в образце остались совершенно нетронутыми проблемы, которые как раз и стоило разобрать, и в которых работа с LS и watch отвалились бы самостоятельно.
На самом деле Алексу нужно задуматься вот о чем. Pinia прививает очень плохую практику, в которой стор "и швец и жнец и на дуде игрец", то есть он:
Инициализирует данные
Выполняет запрос к другим данным
Меняет собственное состояние
В идеале нужно было бы подойти с такой точки зрения:
Что в этом сторе является БЛ, а что – логикой стора
какие данные стор хранит и как их получает
как данные нормализуются при записи и какой тип является «контрактом» стора
кто имеет право мутировать состояние — стор сам через методы, или кто угодно снаружи напрямую
какие вычисления являются производными от состояния стора (computed), а какие — бизнес-логикой, которой в сторе вообще не место
какой тип является контрактом стора —
anyвообще не должен быть допустим,Record<string, unknown>— полумера. Нужно использовать явный интерфейс и типизировать через него хранилище. Если не получается – значит проблему надо решать уровнем выше, до написания сторавнешние элементы, включая композабл, не должны менять состояние стора напрямую — только через явные методы. Подход get/set никто не отменял
И взглянув на старый код
мы неожиданно поймем, что в сторе должно быть примерно так:
findздесь не случаен — он явно выражает намерение: найди элемент по условию. Индексный доступitems[key]выражает другое: возьми по заранее построенному ключу, и тогда ты несёшь ответственность за консистентность этой структуры. Массив сfindчестнее: источник правды — список, поиск — производная операция. Если завтра условие усложнится (например, искать поtypeIdиregionId), массив расширяется тривиально, аRecordпотребует смены ключа и рефакторинга всех мест записи.В идеале надо смотреть в сторону того, что стор может явно иметь функции для нормализации (чтобы привести входящие данные к контракту) и дальше только методы чтения/записи, использующие типы для того, чтобы извне сообщать структуру.
RawPropertyиPropertyмогут и должны отличаться — граница между ними и есть зона ответственности нормализатора.Остальную логику вытаскивать в композабл и переиспользовать (он же и должен возвращать стор — делаем компонент, который агностичен к стору, т.е. напрямую со стором не взаимодействует). Так, если логика поменяется, стор не будет затронут, и взаимодействие с ним можно расширять без риска что-то сломать.
В целом в мобильных приложениях BFF сам по себе хорошо залетает, так что думаю что-то похожее можно затащить :) насколько я понимаю , р-нэтив нормально шаблонизируется
БэДэЮай тоже такое себе название, но называют же 😄
Давайте пойдем с конца, так как это фундамент.
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 здесь — это идеальный протокол генерации структуры этого приложения.
К сожалению, ваши аргументы для меня не просто не убедительны, а скорее маркер того, что в текущей системе все сделано верно и стоит развивать ее, а не пытаться делить ресурсы команды и обучать всех - всему.
«Дети с реакт»… кхм, даже интересно, в какую именно касту вы меня записали :)
По существу: HTMX — это лишь инструмент транспорта HTML через AJAX. Он не решает проблему сложной реактивности и состояния на клиенте (валидация на лету, зависимости полей, маски, работа с модалками без перезагрузки контекста). Для ERP-систем это критично.
Что до «бизнес-сущностей»: согласна, что карта — не есть территория. Однако в описанном подходе MDUI, JSON предоставляет проекцию правил сущности на UI: какие поля доступны, какие readonly, какие действия разрешены. В контексте задачи — это спор о семантике, не более.
Ну и главное. Возврат HTML (пусть даже через HTMX) означает, что нам снова придется верстать каждую страницу руками, просто теперь на стороне бэкенда (шаблонизаторы). А цель моей архитектуры была ровно обратной — уйти от ручного создания страниц к их генерации из структур данных. Бэкендеру проще отдать JSON, чем верстать <div> с классами.
Справедливое замечание, я видела подобные проекты.
но вот в чем суть. Этот проект строится на строгом разделении ответственности. Бэк передает только бизнес сущности, фронт инкапсулирует сложность реализации.
Плюс тимлид бэка тоже понимает риски и старается не раздувать структуру на бэке, когда мы с ним согласуем контракты.
За полгода «обрастания» не произошло. Если будет какая-то сложная логика - никто не пытается натягивать сову на глобус, просто рисуем нужное поведение.
Согласна, что с React Admin есть схожесть, паттерн может вполне его напоминать, хотя под капотом описан собственный движок, а не сторонняя библиотека.
В отличие от готовых скаффолдов, наше решение не завязано на ограничениях стороннего фреймворка. Если нам перестанет хватать стандартного грида, я добавлю специфичные кейсы в рендерер, а бэк начнет использовать их в контракте. Бэк сам определяет состав формы, фронт занимается только рендером.
Вопросы кастомизации решаются slot-based подходом. Более того, компоненты можно настраивать пропсами прямо с бэка.
Про «пользовательский опыт» — всё проще: бухгалтерам важна предсказуемость и скорость, так что жесткая унификация здесь только в плюс.
Спасибо за комментарий!