Comments 16
так если этот подход не рекомендуется, детали то в чем?
И если вопрос только в вёрстке, почему нельзя было всю ее засунуть в компонент?
Это же логично, логика одна, представление разное
так если этот подход не рекомендуется
А где написано, что он не рекомендуется? Просто о нём автор нигде ничего не нашёл в «интернетах»
И если вопрос только в вёрстке, почему нельзя было всю ее засунуть в компонент?
Иногда (точнее, почти всегда), для DX, а так же, что не маловажно, для оптимизации, лучше разграничить такие компоненты на разные, а не держать все варианты представления в одном компоненте. Это улучшит читаемость кода, его дальнейшние модификации (при надобности) и уберёт лишние пропы (или просто условия внутри компонента) по которым Вы хотите отобразить то или иное его представление
Та забей, гений на авторе придумал как перенести всё худшее из вью2 (миксины) на манер вью3 (композаблы), в итоге реализовал миксины с помощью композаблов, во (смайлик пальца вверх)
-тся
А в чём, собственно, проблема заключается? Само направление статьи казалось интересным, пока я внезапно не наткнулся на её конец.
Проблема не описана
Пример посредственный. Объясню: то, что можно сделать композабл, который принимает в себя пропы и эмиты какого-либо компонента, использует эти пропы и эмитит эти эмиты и ежу понятно
Не очень понятно, в каких реальных кейсах это может использоваться, так как даже при «однотипной» логики событий (как пример, возьмём различные типы интерактивных элементов формы — текстовый инпут, численный инпут, датапикер и прочие, где есть один и тот же эмит «изменения текущего значения») — логика внутри абсолютно разная, а вот зарывать обработки всех разных типов в один «общий» композабл — это оверхед, так как проще (и для чтения кода, и для рантайма, и для будущих модификаций кода, и для последующего рефакторинга при надобности) обособить ответственность конкретного компонента именно в нём
Но, если уж представить, что нам прям хочется сделать что-то такое универсальное, то использование эмита в описанном примере не совсем корректное. Если уж Вы решаете проблему «переиспользования одинаково названных и по сути дублирующих логику эмитов», то недостаточно описать тип эмита в самом композабле — как минимум понадобится дженерик, т.к. такие эмиты могут «выбрасывать» разные типы данных, как максимум — всё-таки придётся дать возможность прокидывать свой обработчик на данное событие, так как логика в каком-то компоненте может быть нетривиальна, а нам же захочется его поместить в эту нами созданную «универсальную бутылку» (не, ну а зачем тогда мы это делали, верно же?). Но тут опять же поинт про то, что это усложнение кодовой базы, которое в будущем вряд ли даст нам профит — скорее наоборот, принесёт проблем, когда нужно будет что-то изменить в одном из типов компонентов (либо придётся обработку выносить на верхний уровень — в сам компонент (но зачем мы тогда всё это делали, опять же?), либо изменять реализацию уже в самом композабле — что будет довольно проблематично, так как его уже будут использовать несколько компонентов). В итоге получаем некий «вендор лок», который станет блокером для некоторых задач и потребует ресурсов на устранение созданных нами проблем в рамках всеми любимого «техдолга»
Возможно, в чём-то я не прав, что-то не понял из Вашей статьи и так далее и тому подобное. Основной мой поинт в чём: из статьи не понятна проблема, предложенное решение соответственно не понятно, какую проблему решает, так как проблема явно не описана, а пример уж очень поверхностный, что из него так же не становится ясна проблема
Если бы Вы добавили пример реального использования (да, прям реального использования из коммерческой разработки) — возможно, это бы всё расставило на свои места
В любом случае, спасибо за статью!
UPD: если Вы имели ввиду компоненты, которые действительно делают прям одно и то же, но просто имеют разное представление (да, да, такое действительно бывает) — в таком случае всё встаёт на свои места. Кроме одного: почему у статьи уровень «сложный»?)
Спасибо за развернутый коммент.
UPD: если Вы имели ввиду компоненты, которые действительно делают прям одно и то же, но просто имеют разное представление (да, да, такое действительно бывает) — в таком случае всё встаёт на свои места.
Да, я писал в точности об этом.
Реальную проблему из жизни, на основе которой писал статью, не стал описывать по 2-м причинам:
- Нехорошо код из продакшн-проекта, находящийся под NDA, публиковать на всеобщее обозрение.
- Хотелось сделать минимальный пример, который я или кто-то другой может скопировать в шпаргалки или сниппеты, и в следующий раз не выдумывать заново. Исходя из моего опыта - это периодически повторяющийся шаблон.
Да, я писал в точности об этом.
Тогда, как я и написал, всё встаёт на свои места :)
Нехорошо код из продакшн-проекта, находящийся под NDA, публиковать на всеобщее обозрение
Ну, никто не говорит прям брать код из продакшна проекта под NDA и сувать его сюда. Можно взять юзкейс из него и описать пример со всеми вытекающими. Да, и, на самом деле, Вы бы в любом случае полностью весь код с бизнес-логикой и тд не вставляли, а вставили части, которые относятся непосредственно к сути данной статьи. NDA может быть, конечно, всякий, но, думаю, никто бы не был против этого, если уж так говорить :)
Думаю, многим было бы интересно узнать, в каких именно реальных кейсах это можно использовать с пользой, а не во вред. Но это Ваше право, как автора статьи
Спасибо за ответ!
Почему уровень "сложный"?
Насколько я понял:
"простой" - нужно ставить, если целевая аудитория - не программисты вовсе,
"средний" - для около-программерских специальностей, которые имеют примерное представление о кодинге, но сами непосредственно им редко занимаются,
"сложный" - непосредственно для кодеров, которые знают тонкости языков, фреймворков, инструментов и прочего.
Нечто подобное было написано в интерфейсе хабра при публикации.
Разве нет?
Может-быть и я что-то не так понял.
Это моя первая статья на Хабр.
Я, кстати, не знал, что официальная документация не рекомендует эмитить из композаблов. Спасибо, автору, что поднял эту тему. Но, честно говоря, если бы мне пришлось решать подобную описанной в статье задачу, я бы врятли использовал такой паттерн. Апи композабла усложняется. Теперь, чтобы понять, что он делает, нужно в него провалиться, т.е. это теперь не просто набор входных параметров и выходных значений или методов, которые афектят только внутреннее состояние композабла. В сложных случаях, я наверно предпочел бы иметь больше бойлерплейта для уменьшения сцепленности компонента и композабла.
Доброго времени суток.
По поводу связанности:
Компонент знает о композабле, его пропсах, эмитах, и в данном случае типах,т.к. компонент использует композабл.
Но композабл ничего не знает о компонентах, в которых он используется.
Например, при использовании сторонней библиотеки и необходимости в клиентском коде работать с типом, возвращаемым или принимаемым методом этой библиотекой,
мы можем импортировать из библиотеки в клиентский код нужный нам тип.
Но при этом библиотека ничего не знает о нашем клиенской коде.
А касательно импорта типов из композабла:
В выборе между дублированием описания типов и их повторным использованием,
по моему предпочтительнее повторное использование.
Особенно если дублировать пришлось бы несколько раз.
Ничего страшного в проваливании в композабл/библиотеку/хелпер и импорте из него тип не вижу.
Мы можем даже из Vue импотировать типы.
Стандартная практика.
Согласен, зависимость одностороння от компонента на композабл. Так что сцепленности нет. Разве что апи композабла чуть усложняется из-за эмитов, но это мелочи и, возможно, субъективное усложнение.
Так что если даже документация не запрещает эмитить из композаблов, то вполне рабочий подход. Спасибо буду держать на вооружении.
К слову, это уже не первый коммент, по поводу того, что официальная документация не рекомендует эмитить из композаблов.
Поэтому я усомнился в своём утверждении, и пошел в документацию.
И.... не смог найти подобного утверждения в доках.
Возможно невнимательно искал, а возможно нашел эту информацию ранее в другом источнике.
В следующий раз при написании статьи мне нужно быть внимательнее, и фиксировать у себя ссылку на источник сразу.
Если вдруг обнаружу этот тезис в документации снова - напишу об этом здесь в комменте или сделаю UPD к статье.
Когда специально зарегистрировался на хабре, чтобы написать коммент...
В доке vue довольно подробно расписано о том, почему composbales (https://vuejs.org/guide/reusability/composables.html#comparisons-with-other-techniques). Если Вам очень сильно хочется упороться и получить возможность переиспользования props и emits - поздравляю, "выход" есть:
// 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, коллизией имён и тд, но зато получить возможность "переиспользования" пропсов и эмитов
Интерфейс для каждого компонента должен быть уникален, и не должен быть привязан к модели
Вызов событий, и получения пропсов в composable плохая практика, т.к привязывает к определенному компоненту, такой подход максимально не расширяемый, самый банальный пример, компонент изменил название пропсов, и ваша декомпозиция становится бесполезной.
Mixins это боль второй версии, и не нужно тянуть такой подход в третью версию, где есть идеальное решение в виде composables
Vue: Composables и TS это вам не Mixins и JS. С ними сложнее