Компоненты должны работать именно с ней, с доменной моделью при её наличии работать будет уже VM. Там даже v-model не нужен, у VM своя внутренняя мутабельность должна быть.
Подскажите где можно посмотреть примеры кода, где используется этот подход? Может подкинете почитать чего?
Ну так компонент это и есть viewModel: есть доменная модель, компонент берет из него данные и из них создает свое состояние, а когда меняем состояние в компоненте - вносим изменения в доменную модель. Это и есть viewModel: мост между view и model
реактивность мешать не должна
Ну, я не могу использовать приватные свойства #propertyName, и вынужден их раскрывать, потому что в прокси не заворачивается, и таким образом вся инкапсуляция идёт по одному месту.
Вижу 2 варианта дизайна:
в компоненте формы сделать реф с доменной моделью (const seatrip = ref(seatrip.plan(...))), разбирать модель на рефы (const seatripDate = ref(seatrip.getTimePeriod().getDate()...), эти рефы передавать вниз инпутам (<SeatripDateInput v-model="seatripDate" />), в компоненте формы вешать watch на каждый реф (watch(seatripDate,...)), внутри watch мутировать модель (сюда же обработка ошибок и обновление связанных полей) и обновлять тут же обновлять реф доменной модели (seatrip.value = newSeatrip).
попахивает. можно вместо разбора модели на отдельные рефы все это завернуть в DTO'шку, но суть не изменится: поддерживать и трогать это будет страшно и больно
сломать инкапсуляцию в доменных моделях (заменить приватные свойства публичными), в компоненте формы сделать реф с доменной моделью (const seatrip = ref(seatrip.plan(...))), спускать конкретным инпутам доменную модель (<SeatripDateInput v-model="seatrip" />), они делают с ним что считают нужным, и возвращают компоненту формы новый измененный доменный объект
Первый - кривой и страшный, второй компромиссный настолько, что неприемлемый. Выбор не очень :)
Для работы реактивности нужно 1 раз обернуть модель в прокси и всюду таскать этот прокси, всяческие toRaw и watch нужны для передачи объектов за пределы области ответственности vue.
Ну так это то что мы и пытаемся делать, потому что работа с моделью не сводится к геттерам и сеттерам вроде seatrip.timePeriod = reactiveVueTimePeriod.
Там выходит что-то вроде seatrip.moveTo(seatripTimePeriod, yachtAvailabilityService, <...>, notification,) итд итп, и реактивность тут только мешает.
Не очень понятны паттерны работы во vue со своими моделями, сервисами (js кодом который вполне работоспособен отдельно от vue).
Идея в том чтобы vue занимался формочками, собирал в своих формочках доменные объекты (entities, valueobjects, aggregate roots etc), и передавал уже в чистом виде в домен, а потом собранный агрегат/сущность в репозиторий, который из доменного объекта соберет DTO и отправит на апишку. Если захотим завтра переехать с vue на другой замечательный фреймворк - берем с собой домен, и делегируем задачу "собирать доменные штуки" другому замечательному удобному инструменту.
Но тут утыкаешься в то, что vue как-то сильно возражает против такого с ним обращения, и надо вот иначе как-то. Как - непонятно.
Зашивать всю доменную/бизнесовую логику прям в компоненты?
у нас 3 крупных SPA с нагрузкой до 10000 пользователей
тактический вопрос, помогите советом.
есть js модель seatrip (прогулка на яхте), делаем бэк-офис чтобы можно было добавлять/убирать гостей, назначать яхты, капитанов, рисовать календарь.
есть у прогулки период времени и дата, который представлен в виде Value-Object'а (в нем - datetime начала прогулки и количество часов).
есть форма, где эту дату пользователь может менять.
есть компонент, рисующий форму ввода нового периода времени, в котором нужно отрисовать текущие.
Хочется чтобы компоненты (вроде SeatripTimePeriodInput) работали с value-object'ами через v-model, или prop+event.
В текущем виде мы через пропс спускаем компоненту VO с текущим значением, пользователь меняет значение в инпуте , компонент создает новый VO из пользовательского ввода, поднимаем ивентом новый VO на уровень формы, там подставляем в модель, узнаем ошибку, блокируем сохранение (т.к. есть ошибка), спускаем сообщение об ошибке в компонент, компонент увидев сообщение об ошибке рендерит ее и меняет статус на invalid.
Везде в туториалах counter'ы и скалярные значения, которые легко и весело реактивятся, а с моделями (которые сильно сложнее чем get/set) и объектами никто как будто дела не имеет.
Vue заворачивает объекты в свои proxy, заставляя делать toRaw/markRaw, writable-computed, выдумывать трюки по выводу ошибок рядом с формой (если на уровне компонента данные валидны, а когда попадет выше - окажется что нет, и приходится в пропс спускать компоненту сообщение об ошибке для пользователя), следить за изменениями в форме через watch, и прочие странные вещи.
Ощущение, что мне намекают, что я делаю что-то не так, и надо на уровне формы разваливать value-object'ы на скалярные значения, чтобы ниже, на уровне компонентов каждого отдельного поля работать уже с ними. Или выкидывать из головы все DDD'шные/ООПшные вещи и учиться как-то уж сильно иначе все это делать, потому что во фронтенде какая то альтернативная линия времени.
easiest way to install htmx is <...> download htmx.min.js from unpkg.com and add it to the appropriate directory in your project and include it where necessary with a
Без примера статья не работает совсем. Поделитесь опытом.
Бизнес говорит: "мы хотим, чтобы можно было настраивать минимальное и максимальное количество часов брони нашей штуки".
Реализация фичи "сделать так, чтобы период времени, выбираемым пользователем в форме, был не меньше чем X и не больше чем Y, в случае неверного значения вывести ошибку, X и Y должны определяться в админке" затрагивает кучу всего и везде, от юзер интерфейса до бд.
До какой степени разумно дробить эту задачу? Как поступили бы вы?
Вам не приходится периодически удивляться, почему хорошо знакомая работа вдруг заняла непривычно много времени.
неправда, приходится, и часто. оценка скрам мастера никак на это не влияет
Вам не приходилось ни разу оценивать, к какой дате вы сможете выполнить работу, которую до этого вы ни разу не делали.
приходилось, и каждый раз я убеждаюсь что это тык пальцем в небо. независимо от методики: считать в попугаях, сторипоинтах (чтобы в итоге перевести их в часы для заказчика и руководства, пообещать, а потом давить на разработчиков, хех), на статистике, или на картах таро, или на честном слове, или на "тыщу раз так делал".
все перечисленные проблемы упираются в наличие в задаче "неизвестных неизвестных". есть задача. есть идея. есть план реализации. и есть/возникают в процессе "неизвестные неизвестные".
они не обсчитываются. дробление задачи до "известных известных", хоть и возможно в теории, но на практике я не видел чтобы где-то это работало (то есть давало практически применимую гарантию: задача будет выполнена к N). пытаются почти везде, реально работает (так, чтобы можно было дать гарантию выполнения к сроку) - нигде.
я критикую подход, а не автора.
"Задача будет выполнена к N, мы знаем будущее! У нас и методика, и циферки, и скрам мастер есть"
А на практике:
"Вы дадите денег, мы возьмемся за задачу, а там разберемся... Может повезёт и уложимся, тогда все будет прекрасно. Не повезет - будем стараться смягчать и договариваться, где-то мямлить и краснеть, где-то убалтывать, где-то врать"
вместо того, чтобы искать удобные для обеих сторон (заказчик и исполнитель) способы отказа от дачи невыполнимых обязательств, люди пытаются искать способы посчитать чего-нибудь, чтобы чего-нибудь наобещать, а потом как-нибудь разруливать.
"высер", "жопой", "пропердит", и прочие атрибуты фиксации на заднице оставьте себе, а здесь ведите себя прилично.
Крушение менеджерских фантазий суровой правдой разработки в реальном мире :)
Фантазия: "декомпозируем, проектируем, документируем, согласовываем с заказчиком четкий срок, разрабатываем, укладываемся в спеку и срок, все счастливы, готово".
Реальность: в начале получаем векторное понимание проекта, по ходу дела вместе с заказчиком и командой разбираемся в деталях, переписывая и переделывая из-за недопонимания заказчиком/командой реально происходящих процессов, и процессов которые должны происходить (нередко таким образом чиним бизнес процессы заказчика), мискоммуникации, приходим к MVP, релизим, уточняем требования, получив новые знания о проекте и требованиях в ходе "проверки боем", переписываем заново с учетом новых требований, релизим, саппортим. На каждом этапе боремся с мискоммуникацией со всей силы.
Статья пропитана реальным опытом и пониманием процессов "изнутри", тем и ценна.
нефиг с обеих сторон называть их именно инженерами и создавать завышенные ожидания
аа, так вам за гордое звание инженера обидно, все понятно :)
если вам нужен действительно DevOps-инженер, т.е. человек, который ПРОЕКТИРУЕТ специализированную АСУ ТП, то он тоже должен знать на 2 уровня ниже
2 уровня ниже - откуда считаем? почему 2 а не 3? почему должен? из вашей головы?
также я знаю на 2 уровня ниже, как работает механика, физика и химия
ну да, теперь понятно откуда.
devops знаток химии это очень уважаемо, респект вам :)
Руководитель онлайн-школы Systems.Education
надеюсь, как руководитель школы вы и образовательный процесс на 2 уровня ниже знаете, иначе как-то непрофессионально получается. или не должен? почему нет?
впрочем, с вашей претензией на "знаю химию, физику и как разрабатывается софт" разговаривать больше не о чем.
называй себя хоть сюзанной, если тебя от этого прёт (с)
"мы инженеры и все знаем а вы - не инженеры потому что дальше тулзы не видите" - это жиденькая позиция.
процессоры на сервере шуршат, и врядли вы знаете детали и тонкости его внутреннего устройства. вы скажете "а мне и не надо", и ровно то же отвечают те люди, о которых написан пост.
каждое поколение таких "инженеров" изобретает тулзы, и обвиняет следующие за "незнание основ". и каждый такой инженер почему-то за "основу" берет то, что знает и выучил сам.
весьма произвольно, не находите? почему не на уровень ниже? почему не на уровень выше?
"я инженер, а ты всего лишь жалкий пользователь, ниче не знаешь ниче не умеешь" - это игрушки в самоутверждение стареющего спеца.
Спасибо.
Подскажите где можно посмотреть примеры кода, где используется этот подход?
Может подкинете почитать чего?
Ну так компонент это и есть viewModel: есть доменная модель, компонент берет из него данные и из них создает свое состояние, а когда меняем состояние в компоненте - вносим изменения в доменную модель. Это и есть viewModel: мост между view и model
Ну, я не могу использовать приватные свойства
#propertyName, и вынужден их раскрывать, потому что в прокси не заворачивается, и таким образом вся инкапсуляция идёт по одному месту.Вижу 2 варианта дизайна:
в компоненте формы сделать реф с доменной моделью (
const seatrip = ref(seatrip.plan(...))), разбирать модель на рефы (const seatripDate = ref(seatrip.getTimePeriod().getDate()...), эти рефы передавать вниз инпутам (<SeatripDateInput v-model="seatripDate" />), в компоненте формы вешатьwatchна каждый реф (watch(seatripDate,...)), внутриwatchмутировать модель (сюда же обработка ошибок и обновление связанных полей) и обновлять тут же обновлять реф доменной модели (seatrip.value = newSeatrip).попахивает.
можно вместо разбора модели на отдельные рефы все это завернуть в DTO'шку, но суть не изменится: поддерживать и трогать это будет страшно и больно
сломать инкапсуляцию в доменных моделях (заменить приватные свойства публичными), в компоненте формы сделать реф с доменной моделью (
const seatrip = ref(seatrip.plan(...))), спускать конкретным инпутам доменную модель (<SeatripDateInput v-model="seatrip" />), они делают с ним что считают нужным, и возвращают компоненту формы новый измененный доменный объектПервый - кривой и страшный, второй компромиссный настолько, что неприемлемый.
Выбор не очень :)
Ну так это то что мы и пытаемся делать, потому что работа с моделью не сводится к геттерам и сеттерам вроде
seatrip.timePeriod = reactiveVueTimePeriod.Там выходит что-то вроде
seatrip.moveTo(seatripTimePeriod, yachtAvailabilityService, <...>, notification,)итд итп, и реактивность тут только мешает.Не очень понятны паттерны работы во vue со своими моделями, сервисами (js кодом который вполне работоспособен отдельно от vue).
Идея в том чтобы vue занимался формочками, собирал в своих формочках доменные объекты (
entities,valueobjects,aggregate rootsetc), и передавал уже в чистом виде в домен, а потом собранный агрегат/сущность в репозиторий, который из доменного объекта соберет DTO и отправит на апишку. Если захотим завтра переехать с vue на другой замечательный фреймворк - берем с собой домен, и делегируем задачу "собирать доменные штуки" другому замечательному удобному инструменту.Но тут утыкаешься в то, что vue как-то сильно возражает против такого с ним обращения, и надо вот иначе как-то. Как - непонятно.
Зашивать всю доменную/бизнесовую логику прям в компоненты?
тактический вопрос, помогите советом.
есть js модель seatrip (прогулка на яхте), делаем бэк-офис чтобы можно было добавлять/убирать гостей, назначать яхты, капитанов, рисовать календарь.
есть у прогулки период времени и дата, который представлен в виде Value-Object'а (в нем - datetime начала прогулки и количество часов).
есть форма, где эту дату пользователь может менять.
есть компонент, рисующий форму ввода нового периода времени, в котором нужно отрисовать текущие.
Хочется чтобы компоненты (вроде
SeatripTimePeriodInput) работали с value-object'ами через v-model, или prop+event.В текущем виде мы через пропс спускаем компоненту VO с текущим значением, пользователь меняет значение в инпуте , компонент создает новый VO из пользовательского ввода, поднимаем ивентом новый VO на уровень формы, там подставляем в модель, узнаем ошибку, блокируем сохранение (т.к. есть ошибка), спускаем сообщение об ошибке в компонент, компонент увидев сообщение об ошибке рендерит ее и меняет статус на invalid.
Везде в туториалах counter'ы и скалярные значения, которые легко и весело реактивятся, а с моделями (которые сильно сложнее чем get/set) и объектами никто как будто дела не имеет.
Vue заворачивает объекты в свои proxy, заставляя делать toRaw/markRaw, writable-computed, выдумывать трюки по выводу ошибок рядом с формой (если на уровне компонента данные валидны, а когда попадет выше - окажется что нет, и приходится в пропс спускать компоненту сообщение об ошибке для пользователя), следить за изменениями в форме через watch, и прочие странные вещи.
Ощущение, что мне намекают, что я делаю что-то не так, и надо на уровне формы разваливать value-object'ы на скалярные значения, чтобы ниже, на уровне компонентов каждого отдельного поля работать уже с ними. Или выкидывать из головы все DDD'шные/ООПшные вещи и учиться как-то уж сильно иначе все это делать, потому что во фронтенде какая то альтернативная линия времени.
ЧЯДНТ?
просто yet another библиотека на js, ну какие корпорации и теории заговора
Без примера статья не работает совсем.
Поделитесь опытом.
Бизнес говорит: "мы хотим, чтобы можно было настраивать минимальное и максимальное количество часов брони нашей штуки".
Реализация фичи "сделать так, чтобы период времени, выбираемым пользователем в форме, был не меньше чем X и не больше чем Y, в случае неверного значения вывести ошибку, X и Y должны определяться в админке" затрагивает кучу всего и везде, от юзер интерфейса до бд.
До какой степени разумно дробить эту задачу?
Как поступили бы вы?
неправда, я web разработчик
неправда, приходится, и часто. оценка скрам мастера никак на это не влияет
приходилось, и каждый раз я убеждаюсь что это тык пальцем в небо. независимо от методики: считать в попугаях, сторипоинтах (чтобы в итоге перевести их в часы для заказчика и руководства, пообещать, а потом давить на разработчиков, хех), на статистике, или на картах таро, или на честном слове, или на "тыщу раз так делал".
все перечисленные проблемы упираются в наличие в задаче "неизвестных неизвестных".
есть задача. есть идея. есть план реализации. и есть/возникают в процессе "неизвестные неизвестные".
они не обсчитываются. дробление задачи до "известных известных", хоть и возможно в теории, но на практике я не видел чтобы где-то это работало (то есть давало практически применимую гарантию: задача будет выполнена к N).
пытаются почти везде, реально работает (так, чтобы можно было дать гарантию выполнения к сроку) - нигде.
я критикую подход, а не автора.
А на практике:
вместо того, чтобы искать удобные для обеих сторон (заказчик и исполнитель) способы отказа от дачи невыполнимых обязательств, люди пытаются искать способы посчитать чего-нибудь, чтобы чего-нибудь наобещать, а потом как-нибудь разруливать.
"высер", "жопой", "пропердит", и прочие атрибуты фиксации на заднице оставьте себе, а здесь ведите себя прилично.
С каким утверждением вы не согласны? Почему?
Поздравляю с открытием.
Вы написали целую статью, с графиками, расчетами, объяснениями, и пр, и все еще не можете ответить заказчику на этот вопрос.
Расчеты и инструменты не дают вам предсказательной силы (т.е. знания), вы все еще тычете пальцем в небо, но с умным видом.
Ваша деятельность в этом направлении абсолютно бессмысленна как прогноз. Польза только в том, что вы всей этой шелухой заказчика успокаиваете.
Хорошего дня!
кто такие программисты баз данных? вы про DBA?
а можно лучше БДСМ?
Крушение менеджерских фантазий суровой правдой разработки в реальном мире :)
Фантазия: "декомпозируем, проектируем, документируем, согласовываем с заказчиком четкий срок, разрабатываем, укладываемся в спеку и срок, все счастливы, готово".
Реальность: в начале получаем векторное понимание проекта, по ходу дела вместе с заказчиком и командой разбираемся в деталях, переписывая и переделывая из-за недопонимания заказчиком/командой реально происходящих процессов, и процессов которые должны происходить (нередко таким образом чиним бизнес процессы заказчика), мискоммуникации, приходим к MVP, релизим, уточняем требования, получив новые знания о проекте и требованиях в ходе "проверки боем", переписываем заново с учетом новых требований, релизим, саппортим. На каждом этапе боремся с мискоммуникацией со всей силы.
Статья пропитана реальным опытом и пониманием процессов "изнутри", тем и ценна.
Спасибо.
аа, так вам за гордое звание инженера обидно, все понятно :)
2 уровня ниже - откуда считаем? почему 2 а не 3? почему должен? из вашей головы?
ну да, теперь понятно откуда.
devops знаток химии это очень уважаемо, респект вам :)
надеюсь, как руководитель школы вы и образовательный процесс на 2 уровня ниже знаете, иначе как-то непрофессионально получается. или не должен? почему нет?
впрочем, с вашей претензией на "знаю химию, физику и как разрабатывается софт" разговаривать больше не о чем.
хорошего вам дня!
полностью согласен
а как ведете себя вы, когда "упало", а почему - непонятно?
или вы просто настолько хороши, что вам всегда всё понятно?
называй себя хоть сюзанной, если тебя от этого прёт (с)
"мы инженеры и все знаем а вы - не инженеры потому что дальше тулзы не видите" - это жиденькая позиция.
процессоры на сервере шуршат, и врядли вы знаете детали и тонкости его внутреннего устройства. вы скажете "а мне и не надо", и ровно то же отвечают те люди, о которых написан пост.
каждое поколение таких "инженеров" изобретает тулзы, и обвиняет следующие за "незнание основ". и каждый такой инженер почему-то за "основу" берет то, что знает и выучил сам.
весьма произвольно, не находите? почему не на уровень ниже? почему не на уровень выше?
"я инженер, а ты всего лишь жалкий пользователь, ниче не знаешь ниче не умеешь" - это игрушки в самоутверждение стареющего спеца.
"вот в наааше-то время..."
хатьфу
к более опытным коллегам, которые подскажут где искать, помогут и передадут опыт.
или самостоятельно, разбираться погружаясь в дебри, точно так же как и вы делаете когда сталкиваетесь с неведомой хренью
Коротко: если большинство кандидатов не способны работать у вас, есть вероятность, что это у вас что-то не так, а не с кандидатами.
"У вас" - это в стеке, инфрастуктуре, в рабочих процессах, в процессе найма, в сотрудниках.
о том и речь что они будут под капотом, где-то там, а не тут, типа баш скриптами вы все это дерьмо собирать и склеивать будете