А чтобы не обмазываться проверками дополнительными, мы же можем создать функцию высшего порядка, которая за нас это будет делать?
об этом написано во втором абзатце, я хочу уйти от создания функций. И создания своей библиотеки функций. В каждой компании уже по такой библиотеке. Еще намешано с другими. Не понять, где композабле для модели, а где служебный. Или тут всё в перемешку? что же делать? Ну... сделаем еще один. Да..ю это же просто. Просто функция.
я не хочу что бы мой коллега помнил, что нужно вызвать где-то там какуюто функцию.
Я хочу помнить максимум 3 вещи: унаследовать от Protomodel, action для асинхроных мутаций и регистрация в контейнере. Остальное должна подсказывать IDE.
А, если это запросы API, то вообще интерцепторы используем и catch становится нужен в исчезающе редких случаях,
А ещё когда вы импортируете один компосабл на прямую в другой, особенно если они из разных бизнес доменов , вы жестко связываете доменные области, с вытекающими последствиями
Не буду спорить про компосабл, в оф. документации всё написано.
У вас просто на уровне определения свойств количество кода увеличится. Не говоря про обработку ошибок и отслеживание состояния выполнения. Придётся копировать одно и тоже. Везде будет isloading или ispending, try catch похожие друг на друга.
Я говорю это, потому что я также писал. Я прошел этот путь. Всё было прям как у вас.
Я даже хочу поднять старый код на компосаблах и просто визуально показать разницу.
Видимо придётся переписать самому пример на комплзаблах и опубликовать сравнение
Ну вот вы зря не читали, не нужно следить за деструктором. И дело вообще не в классах. Одна из причин — устранение частого повторяющегося одинакового кода.
Перепишите это на композабл, обработайте все ошибки в каждом действии, добавьте возможность отмены и блокировки. И просто посмотрите объём кода.
После этого посмотрите как этот пример сделает ваш коллега. Он точно сделает что-то не так как вы в обработке ошибок и именовании переменных. Теперь умножьте это на 10.
Сейчас вы скажете можно создать свою библиотеку и сделать служебные функции, что бы избежать повторении. И так в каждом проекте , и вот у нас набор служебных функций типа useVue, или nuxt. И это не остановить
Можно и так. Здесь нужно смотреть и разбираться с контекстом.
Например, что если логин не только по кнопке, а по событию из другой вкладки или микрофронта?
В примере, я создал связь на уровне моделей в слое приложения. Потому что она существует в бизнес-домене. Мне не нужно думать о том, что это событие должно быть где-то в другом месте проверено, обработано и вызвана загрузка. И таких мест может быть несколько. В компоненте(ах) я просто отображаю состояние и не парюсь .
Одна из задач , это создать модели с поведением и изменением состояния динамические и передавать куда угодно.
Вторая — брать в любом месте модель и не думать о иерархии и структуре компонентов внутри слоя представления.
Третья - перестать писать шаблонный код, перепишите пример из статьи на composable или pinia, так чтобы он обрабатывал все ошибки и состояния, мог отменять или блокировать выполнение. И кода будет больше чем в 2 раза.
А как вы внедряете зависимости в composable ?
Коспозаблы это не про модель , это про разбиение компонента на части и лучшая организация кода, по сравнению с миксинами. Это переиспользование в слое представления.
похоже =) ... и это прикольно, честно. Я рад видеть похожие паттерны, это значит я (мы) попали туда, куда нужно. Это значит, что есть "боль", которую хочется закрыть. Но я не хочу учить декораторы, когда shallowReactive сделает все свойтва объекта, кроме приватных, реактивнымыми. Я хочу минимум нововведений.
После создания модели - все свойства, кроме приватных будут реактивными без всяких декораторов.
Я не хочу помнить о том, что нужно где-то вызвать destructor. И я не думаю, я просто использую контенер.
Так, ребята, из этого нужно делать проект, который будет выдавать плашки, которые можно вешать на github и в других системах. Я серьезно. Типа - уровень проекта, такие-то метрики.
Вы используете "кик-офф" в контексте планирования итерации или спринта. Вы уверены, что правильно понимаете его смысл?
Я погуглил
Кик-офф" (или установочная встреча) - это первая встреча участников проекта, на которой обсуждаются цели проекта, роли и обязанности участников, а также планы на будущее. Это важный этап, на котором устанавливаются общие ожидания и цели проекта, что помогает избежать путаницы и недоразумений в процессе работы.
Потому что мало кто создает слои, как отдельные папки. Т.е. создают папку для области, а в ней сразу папки для портов, моделей и т.п. Границы слоев не понятны.
Либо все это на самом верху, и тогда еще печальнее. Самый первый комментарий это подтверждает.
Это не все принципы, список дополняется по мере написания.
Нет смысла говорить о классах, и тем более о дереве, если нет понимания почему этот класс находится именно в этом месте. Это детали, нет проблем с созданием класса, когда понятна его ответственность. Понимание ответственности - это проблема.
Не возможно формировать структуру папок согласно дерева классов. если классы образую дерево через наследование , то будут большие проблемы. Лучше когда композиция. Но композиция не предполагает иерархии.
Модель проекта вообще невозможно спроектировать на уровне разработчика. Для этого нужно быть экспертом во всех доменных областях и примено представлять реализацию.
так... допустим... Собираем слои в пакет, кладем в папку pkg на "передержку". Что бы дозрел. Выносим пакет в отдельный репозиторий. Корзина релизится как пакет с версионностью и все дела. При этом пакет может содержать все три слоя, а может только 1 слой, а может сразу содержать все слои сконфигурированные в модуль. Здесь зависит от контекста.
Конечно, я сделаю сразу пакет, если точно уверен в его границах. Если не уверен не сделаю. Но я не знаю будущее, иначе я бы сейчас не писал коммент, а играл на бирже или в казино.
Не понимаю, как структура папок может масштабироваться. Что Вы имеете ввиду?
Я нигде не написал , что она масштабируется.
На данный момент я уверен, что она НЕ должна масштабироваться. Она должна эволиционировать в пакеты. Максимальная эволюция, когда проект состоит только из пактов и конфига. Моя структура этому не мешает, скорее даже способствует.
Всё верно. Так и происходит. После стабилизации границ модуля, его зависимостей, связей каждый модуль/компонент стремится превратиться в отдельный самостоятельный пакет в своём репозитории. Мы тоже так делаем.
об этом написано во втором абзатце, я хочу уйти от создания функций. И создания своей библиотеки функций. В каждой компании уже по такой библиотеке. Еще намешано с другими.
Не понять, где композабле для модели, а где служебный. Или тут всё в перемешку? что же делать? Ну... сделаем еще один. Да..ю это же просто. Просто функция.
я не хочу что бы мой коллега помнил, что нужно вызвать где-то там какуюто функцию.
Я хочу помнить максимум 3 вещи: унаследовать от Protomodel, action для асинхроных мутаций и регистрация в контейнере. Остальное должна подсказывать IDE.
везёт вам...
Нет , совсем не применимо , потому что композиция в классах, это внедрение, построенное на интерфейсах. А наследования там почти нет.
А ещё когда вы импортируете один компосабл на прямую в другой, особенно если они из разных бизнес доменов , вы жестко связываете доменные области, с вытекающими последствиями
Не буду спорить про компосабл, в оф. документации всё написано.
У вас просто на уровне определения свойств количество кода увеличится. Не говоря про обработку ошибок и отслеживание состояния выполнения. Придётся копировать одно и тоже. Везде будет isloading или ispending, try catch похожие друг на друга.
Я говорю это, потому что я также писал. Я прошел этот путь. Всё было прям как у вас.
Я даже хочу поднять старый код на компосаблах и просто визуально показать разницу.
Видимо придётся переписать самому пример на комплзаблах и опубликовать сравнение
Ну вот вы зря не читали, не нужно следить за деструктором. И дело вообще не в классах.
Одна из причин — устранение частого повторяющегося одинакового кода.
Перепишите это на композабл, обработайте все ошибки в каждом действии, добавьте возможность отмены и блокировки. И просто посмотрите объём кода.
После этого посмотрите как этот пример сделает ваш коллега. Он точно сделает что-то не так как вы в обработке ошибок и именовании переменных. Теперь умножьте это на 10.
Сейчас вы скажете можно создать свою библиотеку и сделать служебные функции, что бы избежать повторении. И так в каждом проекте , и вот у нас набор служебных функций типа useVue, или nuxt. И это не остановить
Можно и так. Здесь нужно смотреть и разбираться с контекстом.
Например, что если логин не только по кнопке, а по событию из другой вкладки или микрофронта?
В примере, я создал связь на уровне моделей в слое приложения. Потому что она существует в бизнес-домене. Мне не нужно думать о том, что это событие должно быть где-то в другом месте проверено, обработано и вызвана загрузка. И таких мест может быть несколько. В компоненте(ах) я просто отображаю состояние и не парюсь .
Одна из задач , это создать модели с поведением и изменением состояния динамические и передавать куда угодно.
Вторая — брать в любом месте модель и не думать о иерархии и структуре компонентов внутри слоя представления.
Третья - перестать писать шаблонный код, перепишите пример из статьи на composable или pinia, так чтобы он обрабатывал все ошибки и состояния, мог отменять или блокировать выполнение. И кода будет больше чем в 2 раза.
А как вы внедряете зависимости в composable ?
Коспозаблы это не про модель , это про разбиение компонента на части и лучшая организация кода, по сравнению с миксинами. Это переиспользование в слое представления.
нет, проблем не было. Но тут работают только стнадартные инструменты: debugger и console.
похоже =) ... и это прикольно, честно. Я рад видеть похожие паттерны, это значит я (мы) попали туда, куда нужно. Это значит, что есть "боль", которую хочется закрыть.
Но я не хочу учить декораторы, когда shallowReactive сделает все свойтва объекта, кроме приватных, реактивнымыми. Я хочу минимум нововведений.
После создания модели - все свойства, кроме приватных будут реактивными без всяких декораторов.
Я не хочу помнить о том, что нужно где-то вызвать destructor. И я не думаю, я просто использую контенер.
@alexey_ym, но это круто
Так, ребята, из этого нужно делать проект, который будет выдавать плашки, которые можно вешать на github и в других системах. Я серьезно. Типа - уровень проекта, такие-то метрики.
Мне кажется это прям полезно.
Радикальная прямота, красный скрам - много воды, какой-то рефлексии. Если её выкинуть, из книг будет статья
Вы используете "кик-офф" в контексте планирования итерации или спринта. Вы уверены, что правильно понимаете его смысл?
Я погуглил
Или это что-то другое?
Потому что мало кто создает слои, как отдельные папки. Т.е. создают папку для области, а в ней сразу папки для портов, моделей и т.п. Границы слоев не понятны.
Либо все это на самом верху, и тогда еще печальнее. Самый первый комментарий это подтверждает.
Это не все принципы, список дополняется по мере написания.
Нет смысла говорить о классах, и тем более о дереве, если нет понимания почему этот класс находится именно в этом месте. Это детали, нет проблем с созданием класса, когда понятна его ответственность. Понимание ответственности - это проблема.
Не возможно формировать структуру папок согласно дерева классов. если классы образую дерево через наследование , то будут большие проблемы. Лучше когда композиция. Но композиция не предполагает иерархии.
Модель проекта вообще невозможно спроектировать на уровне разработчика. Для этого нужно быть экспертом во всех доменных областях и примено представлять реализацию.
Все верно, согласен по всем пунктам. SFS структура более гибкая. То что написано в статье не конфликтует с вашим подходом, по смыслу это одно и тоже.
А... еще если Вы посмотрите на SFS структуру, то можете заметить, что это почти тоже самое что у Вас в первом комментарии.
Поэтому даже в моём контексте Ваша структура вполне логична и соотвествует тому, что написано в статье.
В моем понимании "масштабируется" и "разрастается" - это разные термины.
так... допустим... Собираем слои в пакет, кладем в папку pkg на "передержку". Что бы дозрел. Выносим пакет в отдельный репозиторий. Корзина релизится как пакет с версионностью и все дела. При этом пакет может содержать все три слоя, а может только 1 слой, а может сразу содержать все слои сконфигурированные в модуль. Здесь зависит от контекста.
Конечно, я сделаю сразу пакет, если точно уверен в его границах. Если не уверен не сделаю.
Но я не знаю будущее, иначе я бы сейчас не писал коммент, а играл на бирже или в казино.
Не понимаю, как структура папок может масштабироваться. Что Вы имеете ввиду?
Я нигде не написал , что она масштабируется.
На данный момент я уверен, что она НЕ должна масштабироваться. Она должна эволиционировать в пакеты. Максимальная эволюция, когда проект состоит только из пактов и конфига. Моя структура этому не мешает, скорее даже способствует.
Всё верно. Так и происходит. После стабилизации границ модуля, его зависимостей, связей каждый модуль/компонент стремится превратиться в отдельный самостоятельный пакет в своём репозитории. Мы тоже так делаем.