Комментарии 6
VueUse - это прекрасное место, чтобы посмотреть «а что, так можно было». Библиотека примеров.
Многие перечисленные минусы для одного проекта - это плюсы для другого.
Зависимость? Да. Документированная, с тестами, написанная крутым разработчиком, бесплатная для тебя. Tree-shaking лишнее отрежет, не понял вообще посыла выбросить его из уравнения.
На эту зависимость завязана бизнес-логика? Открой код, посмотри - подходит ли тебе это. Или здесь только «фатальный недостаток»?
Библиотека будет развиваться и перестанет тебе подходить? Форкай, выкидывай лишнее, модернизируй.
Универсальная? Да. Дофига проектов, которые будут еще годы переезжать с Naruto на vue3.
Прекрасно документированная распространенная библиотека повышает скорость онбординга новых людей: не нужно учить своим решениям. Не нужно писать на него документацию, не нужно покрывать тестами.
Доступность разработкам не высокого уровня? Гугл целый язык создал - go lang, чтобы было проще.
Но, я с этим тезисом не согласен относительно vueuse. Утилиты часто довольно сложные для понимания: нужно залезть в код, чтобы «дошло».
Диктует архитектуру? Что ж за архитектур такой, что набор мелких утилиток без какой-либо философии диктует что-то? Может просто архитектурной концепции не было? Делает как где-то видел и плывет по течению?
В общем, как всегда, люди ругают молоток, а не плотника.
Я помню время, когда люди также ругали за использование underscore/lodash - лучше ведь писать свое. Как писали свой jQuery. У которого, кстати, 3 дня назад вышла 4 версия в бету.
Про популизм в конце улыбнуло.
Ну не подходит - не используйте. Лично я считаю VueUse отличным сборником иногда по-настоящему целебных макросов. Отлично подходит, чтобы не писать лишний раз boilerplate код, особенно когда у браузеров отличаются реализации (привет, useClipboard).
Да, это подходит в основном для типичных use-case-ов, но в этом и суть инструмента. Если нужно что-то кастомное - пилите сами. Но зачем из-за этого хаять отличную библиотеку - не очень понятно.
Все утилиты в ней - небольшие
И это прекрасно: одна общая библиотека реактивных примитивов и адаптированных под реактивность браузерных функций. Эдакая std для vue которой нет в самом vue
Это зависимость
Как и сам vue, но она очень сильно облегчает работу, поэтому это просто trade-off
Утилиты в ней не делают то, что надо именно тебе
Если одна функция не подошла по какой-то причине, это не повод отказываться от всей библиотеки. Можно всегда адаптировать исходный код под свой случай
избыточная и чрезмерная логика и код
Composabl'ы из библиотеки поддерживают 2 и 3 версии vue, по возможности дружат с Nuxt'ом и vue-router'ом, а также поддерживают SSR и уже пофиксили баги о которых невозможно знать заранее при разработке "в лоб"
диктует реализацию элементов архитектуры всего проекта
Вы привели пример исходного кода своего проекта интернет магазина которому мешает архитектура vueuse, но я вижу проблемы с архитектурой:
Отсутствует поддержка SSR, и ее нельзя будет подключить без переписывания части утилит (довольно серьезная проблема для интернет магазина, где важна отдача данных внутри html для поисковых ботов)
Отсутствует code splitting по роутам, из-за чего у приложения один большой бандл
Не вижу в проекте каких-то требований к супер сложным вычислениям, где считался бы каждый computed (это не повод плодить лишние, я согласен, но это также не повод делать велосипеды с возможными багами)
Из беглого осмотра проекта, как минимум две вышеперечисленные проблемы можно решить, либо минимизаровать, с помощью vueuse. Поэтому считаю совет "не берите vueuse, пишите сами" как минимум вредным
И действительно важной ни одной причины.
Да они небольшие. Но вот эту пачку утилит которую все пишут как попало. Таскают из проекта в проект накапливая устаревания, бед-практисы и тд. Часто на вопрос: а на кой эта утилита? Ответ: ну вот из проекта в проект таскаю привык уже. Так что единая точка для утилит: замечательный выбор. Они всегда протестированы, задокументированы и поддерживаются силами всего сообщества
Зависимость и зависимость. Проблем от создания велосипедов гораздо больше: неожиданные корнер-кейсы. Дополнительная точка для тестирования и потенциальная проблема (Ваш пример с useLocalStorage тоже не с первого коммита заработал корректно. Мне бы хватило взять функцию и не переживать о остальном)
Да они могут делать что-то другое что в 90%+ случаев будет более подходящим. Пример опять вышел мимо:
const breakpoints = useBreakpoints({
desktop: 1800,
notebook: 1200,
tablet: 480,
mobile: 0,
}).current()
// Так как vueuse возвращает нам все подходящие брикпоинты, то берем самый большой
const currentBreakpoint = computed(() => breakpoints.value[0])
// Тут и комментировать нечего, код нагляднее некуда
watch(currentBreakpoint, (newBreakpoint, oldBreakpoint) => {
document.body.classList.remove(oldBreakpoint)
document.body.classList.add(newBreakpoint)
}, { immediate: true })О какой половине шла речь? Специально сравнил с предоставленными исходниками. Я предпочту поддерживать вариант с vueuse. Тут ровно 5 строк предельно понятной логики. Те разница почти в 8 раз и не надо думать что там идет не так.
Как вы и сказали это реактивный код. И дополнили "которые ты не используешь". Да, вью реактивный и это почти полностью компенсирует сказанное в статье. Неиспользуемые вычисляемые свойства на которые нет подписчиков... не обновляются. Во Vue pull модель реактивности. Нет подписки - нет обновления. И комментарий о Vue 3.4 тут не причем, он влияет лишь на вычислимые свойства с подписками. Поэтому аргументация тоже вышла мимо. Хотя да, часто избыточная логика может присутствовать чтобы покрыть различные кейсы или закрыть граничные случаи, но которые для большинства не критичны, что в теории в какой-то момент может спасти от выстрела в ногу.
"написать свой код всегда намного эффективней". Это если хватает компетенции. Если не хватает, то можно получить монстров гораздо страшнее чем универсальное решение от опытного разработчика. (тут оставлю ремарку, что читать исходный код таких библиотек очень полезно, даже если решил реализовать по-своему, то проще взять универсальное и отрубить ненужное, опять же экономит время и силы)
А еще ваше приложение работает на Vue. Ну какой-то совсем притянутый за уши аргумент. В чем же критичность того что создается не ref / reactive а уже готовый ref и watch к нему? Да и какая диктатура архитектуры. Это утилиты, пользуйся в той мере насколько и как надо.
Удобно, не удобно. Слишком субъективно. Мне вот удобно, вам нет. На чем сойдемся? Для чего делать отдельную переменную и синхронизировать ее тем более непонятно. Исключение: вы хотите работать с LS только по какому-то событию, но это уже совсем другая логика.
Как выше заметили. "Пишите все сами", если это не джун который разбирается в азах - такой же популизм.
Добавлю от себя:
Выбор что использовать, а что нет - за вами
Если вы берете SPA, то не факт что вам не понадобится SSR в будущем. Тут же поддержка из коробки
Как хорошо выше заметили: чем больше людей используют vueuse тем проще людям вкатываться в проект
Подключать из-за этого всю библиотеку нецелесообразно, несмотря на tree-shaking
И почему же? Это совершенно не так
Это зависимость, и как все зависимости может измениться, устареть, получить уязвимость, тормозить развитие проекта и прочее, прочее
Любой код может измениться, устареть, получить уязвимость, тормозить развитие проекта, в том числе написанный собственноручно, и что дальше? Это не проблема библиотеки, а реалии программирования
Утилиты в ней не делают то, что надо именно тебе.
Опять же - очень субъективно. Утилиты, которые мы используем, делают именно то что нам нужно, и часто лучшим способом
нет никаких гарантий, что при изменении экрана или сдвиге мышки не будет производиться множество не нужных тебе пересчетов
Как так-то? В документации есть линки на исходный код, есть DevTools, позволяющие проанализировать потребление памяти, обработчики и фпс, просто надо смотреть внимательно что происходит, что необходимо и что навешивается
Я не увидел здесь аргументов, которые относились бы конкретно к VueUse, а не программированию в целом или программисту. Нельзя сделать библиотеку, которая бы использовалась на 100%, не устаревала со временем и была лишена всех перечисленных недостатков. VueUse - это отличная, тришейкающаяся либа, которая покрывает приличное количество рутинных задач и поддерживается другими людьми, дающая возможность сконцентрироваться на бизнес-логике приложения
Страдания по VueUse