Если я сделаю mixin и там будет data и 2

метода,импортну в 2 компонента, то я смогу в компоненте еще раз написать data , и добавлять что нужно? или еще методы?

сможешь

Если у меня в 3 компонентах надо использувать часть одинаковых методов и watch? то хорошым решениям вынести в mixin будет*

нет, не будет если нужно использовать что-то общее, то это выносится либо в отдельный js-файл, либо в общий компонент, либо в компонент-родитель, в зависимости от твоей задачи

Зачем в компонент ? если там только js логика будет, разметки нет

я и написал, что это зависит от твоей задачи если разметки нет, значит логично вынести эту часть в отдельный файл

Да, но не просто будет вынести просто в 1 js файл 3 метода, computed ,watch , и даные из data

computed и watch ты и не сможешь вынести в модуль, если у тебя не Composition API туда выносятся только методы, которые не требуют доступа к инстансу компонента

Ну почему же только которые не требуют доступ к инстансту, можно импортнуть функцию и спокойно прибиндить this

можно, но не нужно:)

Как не могу? я смотрел что можно и не только в comp API выносить computed и watch

Это уже другой вопрос :)

в Options API они прибиты гвоздями к компоненту, поэтому ты не можешь просто взять и вынести условный computed в отдельный js-файл, сохранив его реактивность

Так сразу вынести Options API в отдельный файл, и просто подключать к mixin?

миксин - это не просто отдельный js-файл, это кусок компонента, который потом мержится с реальными полями компонента, а не импортируется как es модуль под отдельным js-файлом я подразумевал es модуль, который ты экспортируешь и импортируешь как обычно

Ну все правильно ,мне и надо его мержить с другими полями

когда у тебя появится парочка-тройка миксинов, которые будут непонятно как и где мержиться, станет немного больно выносить логику в отдельный es модуль проще и удобнее, чем каждый раз ползать по разным миксинам и держать в голове поля, которые подмерживаются тебе в компонент

Ну да, есть такое, Тогда где и какое лучше решения использувать mixin?)

если ты имеешь в виду “где лучше использовать миксины”, то ответ простой - нигде конкретно в твоем кейсе я бы написал простой компонент-обертку над слайдером, которая будет ему передавать параметры, а он уже будет в зависимости от этого кастомизироваться ну и затем просто используешь этот компонент для каждого слайдера, кастомизируя его как угодно обычно в качестве слайдера используются какие-то готовые инструменты, которые можно кастомизировать буквально за пару минут под любой из тех форматов, которые ты скинул

Да знаю, есть много пакетов слайдеров и т.д, но хочу все сам сделать)

слайдер с нуля - это довольно большая работа, потому что там гораздо больше нюансов, чем может показаться на первый взгляд

Да, заметил, но уже 50% сделал) размер, количество картинок , анимация

ну суть в любом случае одна - у тебя будет компонент слайдера, который будет кастомизироваться длинным списком параметров (ты можешь посмотреть, как это делают уже существующие слайдеры), ты будешь его использовать в разных частях приложения и передавать ему параметры, в которых уже будет указано, какой ширины/высоты слайды, какой отступ, какое количество и все такое при правильной реализации тебе даже не понадобится что-то куда-то выносить, полагаю

на чем делаешь? скролл или transform?

transform сделал

Maks
Уже чуть есть ))

лучше вынести это в один условный объект options, потому что по итогу их будет в лучшем случае штук 20

да хоть 100, какая разница?

зачем компоненту 100 пропов, если их можно сгруппировать в один объект и не плодить портянку в props?

зато портянка из 100 свойств в условном объекте лучше? тут мы хотя бы можем указать дефолтное значение/тип, таким образом пропы более прозрачны чем то, что вы предлагете

лучше, потому что в данном случае эта портянка нужна для внутренней работы слайдера, которую, например, он может использовать разом для обновления своих свойств через условный setOptions, что довольно часто встречается в слайдерах ты предлагаешь портянку пропов ручками собирать внутри компонента? пропы - это прекрасно и лучше всегда их описывать явно, но в его ситуации логичнее их засунуть в объект

да, но речь идёт о самописном слайдере

опять же, слайдеру часто требуется иметь под рукой объект своих опций, которые ты утомишься собирать руками из пропов

А зачем собирать?)

чтобы получить их в объекте

как по мне сомнительный аргумент отказываться от полноценного механизма пропов в угоду не писать лишних 20 строчек

ну с учетом, что их будет целое полотно - вопрос спорный очевидный плюс в том, что они будут валидироваться и задокументированы, но мне лично не нравится, что ты будешь открывать компонент и листать кучу второстепенных опций в пропах, которые, возможно, ты почти никогда не будешь использовать в общем, дело вкуса, это была только рекомендация, ей вовсе не обязательно следовать)