тот случай, когда у меня вновь слезы от статьи в целом на глазах. Чуть позже отпишу автору с пояснениями (с телефона затруднительно все расписывать)....
Те самые "большие" проекты на вебпаке, который уже де-факто не развивается. Отличный выбор и надежный. Законсервировать и забыть, если тяготеет душа к вебпаку, то лучше уж в сторону RSpack смотреть
DISCLAIMER: Я буду говорить относительно Vue и только в рамках Vue. Если вы собираетесь читать относительно концепции в других фреймворках и языках, то можете скипать, так как обсуждение каждого фреймворка или другого подхода требует другой аргументации и обсуждения в целом. Данный комментарий больше ориентирован на тех кто воодушивившись уже собрался тащить такой подход к себе в проект
А ради чего Vue который из коробки изначально был MVVM (в последствии реактивная модель по своей сути вышла за рамки классического MV*) пытаться превращать в MVC? Концепции заложенные во фреймворк уже прекрасно работают относительно разделения, а классические подходы в разработке фронтенда закрепляют это еще лучше.
Ну и перепишем предложенный код как он мог быть написанным в классическом Vue исполнении:
"Модель":
function useProgress() {
const isGoing = ref(false)
const percentages = ref(0)
function start() {
isGoing.value = false
percentages.value = 0
}
function finish() {
isGoing.value = false
percentages.value = 0
}
// сохраню изначальную задумку автора
function update(percentages: number) {
switch (true) {
case percentages <= 0:
percentages.value = 0;
break;
case percentages >= 100:
percentages.value = 100;
break;
default:
percentages.value = percentages;
}
}
return {
// для понятности использую самый наивный метод реализации readonly.
// однако так писать не рекомендую
isGoing: computed(() => isGoing.value),
percentages: computed(() => percentages.value),
start,
finish,
update
}
}
Да, это просто композабл. Композаблы это прекрасные кирпичики чтобы выносить бизнес логику или позволять различным компонентам использовать одну функциональность. Создавать классы нет никакой нужды и я надеюсь, что автор это сделал исключительно только ради того, чтобы быть не столь сильно привязанным ко Vue подходам
Представление:
Да не нужно никакую model создавать для передачи. Классические подходы работают прекрасно: пропсы+события это и есть МОДЕЛЬ с которой работает данный компонент (если уж мы начали так представлять). Соответственно
<ProgressBar :is-going :percentages />
Если вам так нравится концепция: передать "все", то есть уже для этого механизм
<ProgressBar v-data="progress" />
Контроллер:
Почему компонент-родитель является контроллером опустим за скобкой, но в классическом представлении для такого уже есть паттерн smart dumb components, когда простое представление контролирует умный компонент.
Итого: натянув MVC предложенный в статье на Vue приложение вы ломаете привычный флоу для Vue разработчиков, усложняете разработку пытаясь реализовать и поддерживать инородные сущности и увеличиваете количество необходимого кода для их поддержания. При этом классические паттерны для работы со Vue (да и в целом Frontend-ом) уже давно выведены и перед такими трюками лучше вначале изучить их и сравнить с тем что могут дать вам они.
Но топить за Vite, который взлетел исключительно из-за того, что его в скафолдинг тулзы стали пихать "чуть менее чем все" дждавскриптовые фреймворки - это наше все.
Звучит как какая-то обида. Нет, Vite стал популярен, так как он обходит webpack по всем характеристикам, кроме гранулярного контроля над чанками (с переездом на rolldown и это останется в прошлом). Иначе бы все "чуть менее чем все" на него не перешли.
Вспоминаю сколько сил забирал Webpack у меня в прошлом буквально 0 желания к нему вновь прикасаться.
PS. В последний раз трогал Webpack когда надо было проект с SSR+SSG Vue2 на Vue3 пернести, мата было много. В итоге переехали компанией на Vite и все остались супер счастливы
Компоненты как раз ничего не запрашивают, а в них проталкивают значение сверху вниз. В то время как у Solid пропсы это Pull-based так как они ленивы и значение пропса вычисляется только в момент попытки обращения значению пропса.
Нужно нехилую ментальнужю гимнастику применить, чтобы хоть как-то натянуть модель реактивности React на Pull-семантику. А если с точки зрения вычисления смотреть, то это прям совсем push push
Так как это изначально не было целенаправленным функционалом Vue. Скорее случайным образом обнаруженная возможность для реализации. Просто из Vue в целом выпилили идею топорных событий (теперь они заранее регистрируются). Если так подумать то действительно смешно было наблюдать по 5-6 инстансов Vue для того чтоб сообщениями обменивались компоненты, как-то логика нарушается
Лучше даже было не писать такую причину "почему не Vue". Ибо когда технический анализ анализ проводится только по популярности, хочется плакать. И нет от перехода меджу 2 и 3 компании не развалились, зато остальные бизнес-метрики отличные у vue: скорость вхождения в проект, скорость изучения, перфоманс, легкость и скорость написания проектов выше чем у React. Но это я так, на подумать, действительно ли "популярность" единственный фактор.
PS. Насчет 2 и 3: уроки учтены, огромная работа была проведена для того чтобы не допустить этого вновь. Так что... аргумент для новых проектов теперь этот на уровне "ну что-то там когда-то произошло"
Там уже почти официально свой язык программирования SvelteScript. И код всего проекта пишется только в файлах .svelte.js. Очень ванильно) По сути 5ка несет еще больше магии и подкапотной работы по итогу. В чем ванильность решения - не ясно
Вы уж больно сильно давите на "невероятную разницу Vue 2 и Vue 3". А по факту единственное что нужно будет изучить (и что является причиной мажора): разница системы реактивности на Proxy и системы реактивности на getter/setter. Это тема 1 занятия. Там же изучается 2 ушедших метода Vue.$set / Vue.$delete. Все. никаких x1.5 или 1.3 для 90%+ случаев.
Да будут некоторые особенности но не страшнее чем изучение разницы между react 14 / 18. Выбор между вакансиями тоже синтетический. Я особо не встречал, чтобы строго разделяли знания Vue2 и Vue3. Если знаешь одно, то спокойно возьмут на другое, так как на адаптацию и недели не уйдет. Были на практике даже случаи(буквально в прошлом году), когда джуны 0 опыта проходили на Vue вакансию после изучения реакта буквально 3-4 дня потренировав Vue и уловив основные концепции.
vue сейчас, кстати, тоже активно ведет разработку над no-vdom решением на основе реактивности как в Solid: vue vapor mode. Это будет опциональный режим для работы компонентов
Да они небольшие. Но вот эту пачку утилит которую все пишут как попало. Таскают из проекта в проект накапливая устаревания, бед-практисы и тд. Часто на вопрос: а на кой эта утилита? Ответ: ну вот из проекта в проект таскаю привык уже. Так что единая точка для утилит: замечательный выбор. Они всегда протестированы, задокументированы и поддерживаются силами всего сообщества
Зависимость и зависимость. Проблем от создания велосипедов гораздо больше: неожиданные корнер-кейсы. Дополнительная точка для тестирования и потенциальная проблема (Ваш пример с 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 тем проще людям вкатываться в проект
Vivaldi ставит целью скорее дать полный простор для для персонализации (буквально миллионы настроек и каждая кнопочка может быть перемещена и тд). Тогда как Arc ближе к Apple по идеологии, что мы вам даем красивые свистоперделки из коробки. И это тоже вполне себе путь.
Короч опять битва великой кастомизации и "удобно красиво из коробки"
Скорее всего если вы искали документацию по tailwind, то ее конечно нет на unoCSS. Базовая информация представлена по кнопке Getting Started. И ключевое что нужно было понять: это не новый Tailwind а буквально фреймворк для создания CSS с атомик подходом (там как раз пример с 1 правилом).
И из коробки он имеет ровно 0 выхлопа и вам показывают как создавать ваши правила для создания утилити классов.
Дальше вам сообщается что вот все это объединяется в preset-ы. А сами пресеты уже подключаются к проекту: вас отсылают к стандартным пресетам по ссылке. И уже от выбранных пресетов зависит подход (в том числе есть пресет для подобия tw)
Продающих страниц особо у технологии нет. Да и подход отличается еще раз от tw вместо готового решения это буквально супер комбайн по решению задач связанных с атомик подходом (кастом правила, аттрибутифай, айконифай, тегифай и тд)
В целом уверен что сдружить их возможно. Но как писали ниже, то есть реактивные примитивы как Reactive которые могут прятать все эти .value. Однако, если вам не переписывать с React на Vue, то лучше принять .value. От нее пытались избавиться на этапе сборки но это порождало слишком много магии и дополнительных корнер кейсов проблемного вида
Сюда же можно отнести как оперативно vitest захватывает поле еще одного "монополиста" в виде Jest-а активно смещая его позиции. Да, фокус команды в этом году был явно не на стороне Vue (что понятно по отсутствию обещанного Vapor Mode)
Так же недооценено влияние языкового туллинга как Volar который тоже выходит за пределы Vue уже. Например языковой туллинг Svelte уже на нем.
Как по мне дико не хватает качественной UI-библиотеки. Вот чтоб от создателей со всей той любовью к DX-у что и в других продуктах от этих ребят. Именно в области UI-библиотек сейчас САМОЕ слабое место у Vue. Пока пытается это исправить только Nuxt со своим Nuxt UI, но он завязан на Nuxt экосистему и вне Nuxt не жизнеспособен сейчас, поэтому пользы мало.
Если появится что-то по кач-ву близкое или превосходящее условный Mantine, то это даст невероятный буст всей экосистеме
тот случай, когда у меня вновь слезы от статьи в целом на глазах. Чуть позже отпишу автору с пояснениями (с телефона затруднительно все расписывать)....
На самом деле нормально. Сейчас в 3ке даже удобно стало
Вот пример: https://codepen.io/vokgfqld-the-flexboxer/pen/ogNjXJK
Никаких сборщиков, зато крайне удобно работать с данными сохраняя всю мощь Vue при необходимости
Те самые "большие" проекты на вебпаке, который уже де-факто не развивается. Отличный выбор и надежный. Законсервировать и забыть, если тяготеет душа к вебпаку, то лучше уж в сторону RSpack смотреть
DISCLAIMER: Я буду говорить относительно Vue и только в рамках Vue. Если вы собираетесь читать относительно концепции в других фреймворках и языках, то можете скипать, так как обсуждение каждого фреймворка или другого подхода требует другой аргументации и обсуждения в целом. Данный комментарий больше ориентирован на тех кто воодушивившись уже собрался тащить такой подход к себе в проект
А ради чего Vue который из коробки изначально был MVVM (в последствии реактивная модель по своей сути вышла за рамки классического MV*) пытаться превращать в MVC? Концепции заложенные во фреймворк уже прекрасно работают относительно разделения, а классические подходы в разработке фронтенда закрепляют это еще лучше.
Ну и перепишем предложенный код как он мог быть написанным в классическом Vue исполнении:
"Модель":
Да, это просто композабл. Композаблы это прекрасные кирпичики чтобы выносить бизнес логику или позволять различным компонентам использовать одну функциональность. Создавать классы нет никакой нужды и я надеюсь, что автор это сделал исключительно только ради того, чтобы быть не столь сильно привязанным ко Vue подходам
Представление:
Да не нужно никакую model создавать для передачи. Классические подходы работают прекрасно: пропсы+события это и есть МОДЕЛЬ с которой работает данный компонент (если уж мы начали так представлять). Соответственно
Если вам так нравится концепция: передать "все", то есть уже для этого механизм
Контроллер:
Почему компонент-родитель является контроллером опустим за скобкой, но в классическом представлении для такого уже есть паттерн smart dumb components, когда простое представление контролирует умный компонент.
Итого: натянув MVC предложенный в статье на Vue приложение вы ломаете привычный флоу для Vue разработчиков, усложняете разработку пытаясь реализовать и поддерживать инородные сущности и увеличиваете количество необходимого кода для их поддержания. При этом классические паттерны для работы со Vue (да и в целом Frontend-ом) уже давно выведены и перед такими трюками лучше вначале изучить их и сравнить с тем что могут дать вам они.
ох не по тем стопам вы пошли, неужели чужие истории не научили ничему? (это я о методах продвижения вашего решения)
Звучит как какая-то обида. Нет, Vite стал популярен, так как он обходит webpack по всем характеристикам, кроме гранулярного контроля над чанками (с переездом на rolldown и это останется в прошлом). Иначе бы все "чуть менее чем все" на него не перешли.
Вспоминаю сколько сил забирал Webpack у меня в прошлом буквально 0 желания к нему вновь прикасаться.
PS. В последний раз трогал Webpack когда надо было проект с SSR+SSG Vue2 на Vue3 пернести, мата было много. В итоге переехали компанией на Vite и все остались супер счастливы
только зачем пример с Vue2?
Компоненты как раз ничего не запрашивают, а в них проталкивают значение сверху вниз. В то время как у Solid пропсы это Pull-based так как они ленивы и значение пропса вычисляется только в момент попытки обращения значению пропса.
Нужно нехилую ментальнужю гимнастику применить, чтобы хоть как-то натянуть модель реактивности React на Pull-семантику. А если с точки зрения вычисления смотреть, то это прям совсем push push
А зря, Vue с 3кой в итоге расцвел, библиотеки подтянулись и он вполне имеет право заменять React полноценно
Так как это изначально не было целенаправленным функционалом Vue. Скорее случайным образом обнаруженная возможность для реализации. Просто из Vue в целом выпилили идею топорных событий (теперь они заранее регистрируются). Если так подумать то действительно смешно было наблюдать по 5-6 инстансов Vue для того чтоб сообщениями обменивались компоненты, как-то логика нарушается
Лучше даже было не писать такую причину "почему не Vue". Ибо когда технический анализ анализ проводится только по популярности, хочется плакать. И нет от перехода меджу 2 и 3 компании не развалились, зато остальные бизнес-метрики отличные у vue: скорость вхождения в проект, скорость изучения, перфоманс, легкость и скорость написания проектов выше чем у React. Но это я так, на подумать, действительно ли "популярность" единственный фактор.
PS. Насчет 2 и 3: уроки учтены, огромная работа была проведена для того чтобы не допустить этого вновь. Так что... аргумент для новых проектов теперь этот на уровне "ну что-то там когда-то произошло"
Там уже почти официально свой язык программирования SvelteScript. И код всего проекта пишется только в файлах .svelte.js. Очень ванильно) По сути 5ка несет еще больше магии и подкапотной работы по итогу. В чем ванильность решения - не ясно
Вы уж больно сильно давите на "невероятную разницу Vue 2 и Vue 3". А по факту единственное что нужно будет изучить (и что является причиной мажора): разница системы реактивности на Proxy и системы реактивности на getter/setter. Это тема 1 занятия. Там же изучается 2 ушедших метода Vue.$set / Vue.$delete. Все. никаких x1.5 или 1.3 для 90%+ случаев.
Да будут некоторые особенности но не страшнее чем изучение разницы между react 14 / 18. Выбор между вакансиями тоже синтетический. Я особо не встречал, чтобы строго разделяли знания Vue2 и Vue3. Если знаешь одно, то спокойно возьмут на другое, так как на адаптацию и недели не уйдет. Были на практике даже случаи(буквально в прошлом году), когда джуны 0 опыта проходили на Vue вакансию после изучения реакта буквально 3-4 дня потренировав Vue и уловив основные концепции.
vue сейчас, кстати, тоже активно ведет разработку над no-vdom решением на основе реактивности как в Solid: vue vapor mode. Это будет опциональный режим для работы компонентов
И действительно важной ни одной причины.
Да они небольшие. Но вот эту пачку утилит которую все пишут как попало. Таскают из проекта в проект накапливая устаревания, бед-практисы и тд. Часто на вопрос: а на кой эта утилита? Ответ: ну вот из проекта в проект таскаю привык уже. Так что единая точка для утилит: замечательный выбор. Они всегда протестированы, задокументированы и поддерживаются силами всего сообщества
Зависимость и зависимость. Проблем от создания велосипедов гораздо больше: неожиданные корнер-кейсы. Дополнительная точка для тестирования и потенциальная проблема (Ваш пример с useLocalStorage тоже не с первого коммита заработал корректно. Мне бы хватило взять функцию и не переживать о остальном)
Да они могут делать что-то другое что в 90%+ случаев будет более подходящим. Пример опять вышел мимо:
О какой половине шла речь? Специально сравнил с предоставленными исходниками. Я предпочту поддерживать вариант с vueuse. Тут ровно 5 строк предельно понятной логики. Те разница почти в 8 раз и не надо думать что там идет не так.
Как вы и сказали это реактивный код. И дополнили "которые ты не используешь". Да, вью реактивный и это почти полностью компенсирует сказанное в статье. Неиспользуемые вычисляемые свойства на которые нет подписчиков... не обновляются. Во Vue pull модель реактивности. Нет подписки - нет обновления. И комментарий о Vue 3.4 тут не причем, он влияет лишь на вычислимые свойства с подписками. Поэтому аргументация тоже вышла мимо. Хотя да, часто избыточная логика может присутствовать чтобы покрыть различные кейсы или закрыть граничные случаи, но которые для большинства не критичны, что в теории в какой-то момент может спасти от выстрела в ногу.
"написать свой код всегда намного эффективней". Это если хватает компетенции. Если не хватает, то можно получить монстров гораздо страшнее чем универсальное решение от опытного разработчика. (тут оставлю ремарку, что читать исходный код таких библиотек очень полезно, даже если решил реализовать по-своему, то проще взять универсальное и отрубить ненужное, опять же экономит время и силы)
А еще ваше приложение работает на Vue. Ну какой-то совсем притянутый за уши аргумент. В чем же критичность того что создается не ref / reactive а уже готовый ref и watch к нему? Да и какая диктатура архитектуры. Это утилиты, пользуйся в той мере насколько и как надо.
Удобно, не удобно. Слишком субъективно. Мне вот удобно, вам нет. На чем сойдемся? Для чего делать отдельную переменную и синхронизировать ее тем более непонятно. Исключение: вы хотите работать с LS только по какому-то событию, но это уже совсем другая логика.
Как выше заметили. "Пишите все сами", если это не джун который разбирается в азах - такой же популизм.
Добавлю от себя:
Выбор что использовать, а что нет - за вами
Если вы берете SPA, то не факт что вам не понадобится SSR в будущем. Тут же поддержка из коробки
Как хорошо выше заметили: чем больше людей используют vueuse тем проще людям вкатываться в проект
Не совсем.
Vivaldi ставит целью скорее дать полный простор для для персонализации (буквально миллионы настроек и каждая кнопочка может быть перемещена и тд). Тогда как Arc ближе к Apple по идеологии, что мы вам даем красивые свистоперделки из коробки. И это тоже вполне себе путь.
Короч опять битва великой кастомизации и "удобно красиво из коробки"
Скорее всего если вы искали документацию по tailwind, то ее конечно нет на unoCSS. Базовая информация представлена по кнопке Getting Started. И ключевое что нужно было понять: это не новый Tailwind а буквально фреймворк для создания CSS с атомик подходом (там как раз пример с 1 правилом).
И из коробки он имеет ровно 0 выхлопа и вам показывают как создавать ваши правила для создания утилити классов.
Дальше вам сообщается что вот все это объединяется в preset-ы. А сами пресеты уже подключаются к проекту: вас отсылают к стандартным пресетам по ссылке. И уже от выбранных пресетов зависит подход (в том числе есть пресет для подобия tw)
Дальше есть ссылки на плейграунд и интерактивную документацию по стандартным пресетам.
Продающих страниц особо у технологии нет. Да и подход отличается еще раз от tw вместо готового решения это буквально супер комбайн по решению задач связанных с атомик подходом (кастом правила, аттрибутифай, айконифай, тегифай и тд)
кстати да Astro тоже на основе Volar-а сделан
В целом уверен что сдружить их возможно. Но как писали ниже, то есть реактивные примитивы как Reactive которые могут прятать все эти .value. Однако, если вам не переписывать с React на Vue, то лучше принять .value. От нее пытались избавиться на этапе сборки но это порождало слишком много магии и дополнительных корнер кейсов проблемного вида
Сюда же можно отнести как оперативно vitest захватывает поле еще одного "монополиста" в виде Jest-а активно смещая его позиции. Да, фокус команды в этом году был явно не на стороне Vue (что понятно по отсутствию обещанного Vapor Mode)
Так же недооценено влияние языкового туллинга как Volar который тоже выходит за пределы Vue уже. Например языковой туллинг Svelte уже на нем.
Итого по векторам суммируя:
Frontend Framework - Vue
SSR Framework - Nuxt
SSG / Static Sites - Vitepress
STM - Pinia / @vue/reactivity
Builder - Vite
Test - Vitest
CSS framework - UnoCSS (убийца тейлвинда)
Linting / Formating - Stylistic / antfu-eslint-config
Language Tools - Volar
Презентации - Slidev
common web tasks - unjs
И уверен что я много чего еще пропустил
Чего же тут не хватает?
Как по мне дико не хватает качественной UI-библиотеки. Вот чтоб от создателей со всей той любовью к DX-у что и в других продуктах от этих ребят. Именно в области UI-библиотек сейчас САМОЕ слабое место у Vue. Пока пытается это исправить только Nuxt со своим Nuxt UI, но он завязан на Nuxt экосистему и вне Nuxt не жизнеспособен сейчас, поэтому пользы мало.
Если появится что-то по кач-ву близкое или превосходящее условный Mantine, то это даст невероятный буст всей экосистеме