Чем вам обычные импорты из barrell-файла не угодили?). Мы обеспечиваем "безопасность" правилами линтер, а не фактом DI-контейнера. Значит мы можем использовать нативные возможности языка, вместо контейнера, который тоже является зависимостью (в данном случае) и может "сменить парадигму или устареть" 😁.
Я не сильно понял тейк о том, как факт контейнера влияет на обеспечение принципа инверсии зависимостей. Для меня достижение принципа происходит с помощью написания некого "адаптера" (wrapper'а) над зависимостью N, предоставляющего свой интерфейс, который контролируется нами...
Признаюсь честно, я не сильно знаком с DDD, так как на фронтенде оно не используется (в чистом виде так уж точно). Как говорил один человек: "Мысль номер 1: никогда не делайте DDD на фронтенде. Это первая заповедь. Как это говорят: есть один человек который сделал DDD на фронтенде, потом его конечно в "психушку" забрали...". Пока за 2е статьи сделал вывод, что если проект не вида "редактор кода", то выглядит это overhead'но.
Папка /features с линтером и правилами превентирования кроссимпортов выглядит проще для понимания...
Но даже так, с нетерпением жду следующих статей, ибо интересно, каким образом мы будем синхронизировать ui-стейт с бизнесовым
Удивлен, что нет ни одного комментария. Ну, возможно из-за того, что текст статьи выглядит слегка нейрослопно.
Когда мы привязываем бизнес-логику к компонентам, мы теряем контроль над приложением.
Написание бизнес-логики в компонентах - довольно обычное явление. Например, популяризаторы и мейнетйнеры vue сами признают этот подход и активно используют его.
Если не брать rerender.js (react) - остальные фреймворки дают реактивность, di и другие фичи, которые можно использовать при написании бизнес-логики. Зачем отказываться от благ человечества, которые нам даются из коробки, в пользу собственных решений?
Логика размазывается по всем слоям приложения.
Ну, не знаю как везде-везде, но фронт в среднем по больнице строится на Фичах. Обычно логика содержится в фиче и не выходит за нее. Потребители фичи могут как-то с ней взаимодействовать, но чтобы размазать логику по всему проекту - ну хз. Не то, чтобы имел много-много опыта на текущий момент, но такого ещё не встречал.
State-машины, DDD и тд - это красиво, но звучит так, что нам дали топор, чтобы пилить дрова, а мы вместо того, чтобы подточить его голову, полностью переделали эту голову так, чтобы можно было менять ручку на любую другую ручку... Зачем, а главное... Зачем?
Если клиент толстый и фреймворк уже не справляется, и мы начинаем писать "core", отделяя его от "движка рендеринга", возможно стоит не использовать имеющиеся "движки рендеринга", а перейти на Натив.
Имхо, это избавит вас от всех "проблем" фреймворков и просто даст возможность легко самим адаптировать js-код с использованием браузерного api (DOM и тд) под core, который у вас уже есть. Думается, что написать document.querySelector и навесить listener будет проще, чем композировать компоненты на фреймворке, строить между ними связи и тд
Если лень писать объект для сотен роутов проекта - можно положиться на типизацию, путем использования либы https://www.npmjs.com/package/vue-routes-to-types или возможностей файлового роутинга, который идёт из коробки во vue-router сейчас.
PS: не встречал коллизий именно имён роутов (с конфликтующими paths сталкивался - то ещё удовольствие).
// file.js
const sharedProps = {
name: {
type: String,
required: true
}
}
// Component.vue
import { sharedProps } from "file.js"
const props = defineProps(sharedProps)
// То же и с emits
// file.ts
export type SomeSharedProps = { name?: string }
// Component.vue
import { SomeSharedProps } from "file.ts"
const props = defineProps<SomeSharedProps>()
// То же и с emits
Что же касается
emits('someEmits', value)
/* Тут крыть нечем, но серьёзно ради такого
создавать отдельную функцию?
*/
Ну, и в напоследок:
1) Composable включает в себя возможность использования себя в другом composable. С emits/props так не получится, ибо "контракты" у компонентов разные за исключением случая, когда они одинаковые by design.
2) Если у компонентов одинаковые контракты из-за design, то имхо лучше дублировать пропсы/эмиты, ибо одинаковый контракт не всегда влечёт за собой одинаковую логику внутри (например, TextInput, DatePicker МОГУТ иметь схожие контракты, но по поведению разные).
UPD: может, я чего-то не понимаю или где-то не прав, но я в тупую не догоняю, зачем использовать mixins и иметь возможные проблемы с debugging, коллизией имён и тд, но зато получить возможность "переиспользования" пропсов и эмитов
В сравнительной таблице DI нет vue :(
Чем вам обычные импорты из barrell-файла не угодили?). Мы обеспечиваем "безопасность" правилами линтер, а не фактом DI-контейнера. Значит мы можем использовать нативные возможности языка, вместо контейнера, который тоже является зависимостью (в данном случае) и может "сменить парадигму или устареть" 😁.
Я не сильно понял тейк о том, как факт контейнера влияет на обеспечение принципа инверсии зависимостей. Для меня достижение принципа происходит с помощью написания некого "адаптера" (wrapper'а) над зависимостью N, предоставляющего свой интерфейс, который контролируется нами...
Признаюсь честно, я не сильно знаком с DDD, так как на фронтенде оно не используется (в чистом виде так уж точно). Как говорил один человек: "Мысль номер 1: никогда не делайте DDD на фронтенде. Это первая заповедь. Как это говорят: есть один человек который сделал DDD на фронтенде, потом его конечно в "психушку" забрали...". Пока за 2е статьи сделал вывод, что если проект не вида "редактор кода", то выглядит это overhead'но.
Папка /features с линтером и правилами превентирования кроссимпортов выглядит проще для понимания...
Но даже так, с нетерпением жду следующих статей, ибо интересно, каким образом мы будем синхронизировать ui-стейт с бизнесовым
Удивлен, что нет ни одного комментария. Ну, возможно из-за того, что текст статьи выглядит слегка нейрослопно.
Написание бизнес-логики в компонентах - довольно обычное явление. Например, популяризаторы и мейнетйнеры vue сами признают этот подход и активно используют его.
Если не брать rerender.js (react) - остальные фреймворки дают реактивность, di и другие фичи, которые можно использовать при написании бизнес-логики. Зачем отказываться от благ человечества, которые нам даются из коробки, в пользу собственных решений?
Ну, не знаю как везде-везде, но фронт в среднем по больнице строится на Фичах. Обычно логика содержится в фиче и не выходит за нее. Потребители фичи могут как-то с ней взаимодействовать, но чтобы размазать логику по всему проекту - ну хз. Не то, чтобы имел много-много опыта на текущий момент, но такого ещё не встречал.
State-машины, DDD и тд - это красиво, но звучит так, что нам дали топор, чтобы пилить дрова, а мы вместо того, чтобы подточить его голову, полностью переделали эту голову так, чтобы можно было менять ручку на любую другую ручку... Зачем, а главное... Зачем?
Если клиент толстый и фреймворк уже не справляется, и мы начинаем писать "core", отделяя его от "движка рендеринга", возможно стоит не использовать имеющиеся "движки рендеринга", а перейти на Натив.
Имхо, это избавит вас от всех "проблем" фреймворков и просто даст возможность легко самим адаптировать js-код с использованием браузерного api (DOM и тд) под core, который у вас уже есть. Думается, что написать document.querySelector и навесить listener будет проще, чем композировать компоненты на фреймворке, строить между ними связи и тд
Если лень писать объект для сотен роутов проекта - можно положиться на типизацию, путем использования либы https://www.npmjs.com/package/vue-routes-to-types или возможностей файлового роутинга, который идёт из коробки во vue-router сейчас.
PS: не встречал коллизий именно имён роутов (с конфликтующими paths сталкивался - то ещё удовольствие).
Когда специально зарегистрировался на хабре, чтобы написать коммент...
В доке vue довольно подробно расписано о том, почему composbales (https://vuejs.org/guide/reusability/composables.html#comparisons-with-other-techniques). Если Вам очень сильно хочется упороться и получить возможность переиспользования props и emits - поздравляю, "выход" есть:
Что же касается
Ну, и в напоследок:
1) Composable включает в себя возможность использования себя в другом composable. С emits/props так не получится, ибо "контракты" у компонентов разные за исключением случая, когда они одинаковые by design.
2) Если у компонентов одинаковые контракты из-за design, то имхо лучше дублировать пропсы/эмиты, ибо одинаковый контракт не всегда влечёт за собой одинаковую логику внутри (например, TextInput, DatePicker МОГУТ иметь схожие контракты, но по поведению разные).
UPD: может, я чего-то не понимаю или где-то не прав, но я в тупую не догоняю, зачем использовать mixins и иметь возможные проблемы с debugging, коллизией имён и тд, но зато получить возможность "переиспользования" пропсов и эмитов