Vueist

Не хочу ничего более обсуждать. Сегодня на улице праздник!

Гайд по Vue в 2026 Актуализируем свои проекты с последними тенденциями и мощностями. Обговорим весь стек. 1 шаблоны показали свою неэффективность используйте нечто иное - язык <template lang="pug">: позволит эффективнее использовать переменные в шаблонах, делать преиспользуемые части без костылей и сильно лаконичнее - использовать jsx: аналогично тому что выше, но вы можете улучшить экспириенс с помощью jsx-directive + setup sfc. import { ref } from 'vue' defineProps<{ title: string }>() const count = ref(0) export default () => ( <section> <h3>{title}</h3> <button onClick={() => count.value++}>+1</button> <p v-if={count.value === 0}>Пока пусто</p> <p v-else>Счёт: {count.value}</p> <ul> <li v-for={(item, index) in count.value} key={index}> Элемент #{item} </li> </ul> </section> ) Итого получаете все плюсы всех подходов разом 2. SASS не отвечает современным требованиям. Лучше совместить самые мощные и лучшие подходы + всегда выносите файл отдельно и переиспользуйте его между компонентами. Это кратно облегчит ваш бандл. Создаст единую точку ответственности и позволит вам легко и просто писать стили любой сложности @reference "../../app.css" radius = 16px gap = 12px .card @apply rounded-xl border border-slate-200 bg-white p-4 shadow-sm border-radius radius &--active @apply ring-2 ring-blue-500 &__title @apply text-lg font-semibold text-slate-900 margin-bottom gap &__text @apply text-sm text-slate-600 &__button @apply mt-3 inline-flex items-center rounded-md bg-slate-900 px-3 py-2 text-sm font-medium text-white transition &:hover @apply bg-slate-700 @media (min-width: 768px) @apply p-6 Теперь по инструментам: Реактивность вью слишком громоздкая лучше предпочесть легковесную и мощную систему наносторов а для логики использовать ее написание на rxjs // stores/counter.ts import { atom } from 'nanostores' import { Subject } from 'rxjs' export const $count = atom(0) const increment$ = new Subject<void>() increment$.subscribe(() => { $count.set($count.get() + 1) }) export function increment() { increment$.next() } Ну и основной набор инструментов: - роутер: nanostores router - SSR/SPA: vike гибкая альтернатива наксту, который позволит вам с меньшей магией управлять вашим приложением в любом из режимов Все это позволит сделать ваши приложения - легковесными - быстрыми - вам будет нужно писать сильно меньше кода для поддержки - все эти инструменты хорошо известны ИИ и идеальны в сочетании с агентным кодингом

Порция RFC Видимо под влиянием анонса Solid 2 один из членов кор тимы vue (ubugeeei) решил накидать своего вижена какие фичи неплохо было бы видеть во vue дальше 1. RFC: Composed Async текущий Suspense завис в эксперементале на долгие годы. И по факту он прижился только в кишках Nuxt остальным же он оказался мало полезен (у Vue сейчас есть поддержка асинхронного setup (который отрабатывает лишь 1 раз) но нет асинхронного рендера). Этот rfc значительно расширяет возможности для асинхронности во Vue. Добавляя явный async аттрибут компонентам, своеобразный async для директив v-defer и дополнительная фича для Suspense. Мне лично не совсем нравится вот эта гонка за асинхронностью во фреймворках, она создает достаточно много ментальной сложности Но реального применения у этого меньше бы чем хотелось. Был бы больше рад условному resource паттерну из коробки. 2. Паттерн-матчинг в шаблонах (само описание) Предлагает вместо использования цепочек v-if/v-else-if сделать РАЗНОУРОВНЕВЫЙ v-match + v-case <template v-match="theme"> <link v-case="'dark'" rel="stylesheet" href="/dark.css" /> <link v-case="'light'" rel="stylesheet" href="/light.css" /> <link v-case.default rel="stylesheet" href="/default.css" /> </template> Мы видим, что v-match на уровень выше чем v-case что должно способствовать читабельности. Ключевые слова и конечный синтаксис под вопросом. Тут мне не сильно важно. как фича интересно, но и без нее ОК 3. Вложенные компоненты (описание) Воистину самое спорное и холиварное из решений, Позволить внутри SFC создавать новые компоненты. <!-- Parent.vue --> <script setup lang="ts"> import { ref } from 'vue' const count = ref(0) </script> <template> <button @click="count++">increment</button> <CountDisplay :count /> </template> <component name="CountDisplay"> <script setup lang="ts"> const { count } = defineProps<{ count: number }>() </script> <template> <p>Current count: {{ count }}</p> </template> </component> Ключевой момент, что это полноценный изолированный компонент(не как snippet из Svelte или createReusableComponent), но приватный для текущего (возможность явно указать export под вопросом). С одной стороны фича интересная, с другой будет способствовать файлам переросткам. Нужно будет большая дисциплина чтобы следить за таким. 4. Server-Side Props А вот это апи крайн сомнительно. Не думаю что оно должно дойти до нас Если кратко: defineServerSideProps позволяет указать зависимости от сервера асинхронной функцией (крайне схоже с asyncData из nuxt) и возможность указать server компоненты которые не должны никак попасть на клиент. Это вообще не про server component из React. а скорее попытка сделать стандартизированный подход и вырезание чувствительных данных и гарантия непопадания их на клиент 5. Props Variance А вот это то чего так многие ждали: возможность отключать рантайм проверку пропсов. Опция nonValidatedProps позволит это включать. Те если раньше компилятор генерировал из TS типа рантайм пропсы для валидации, то такая фича позволяет типу остаться просто типом. Но тогда возникает вопрос как поступать с аттрибутами. И вот тут уже главные обсуждения данного rfc Это достаточно краткий обзор на каждую из RFC и в действительности они заслуживают более глубокого анализа. Также напомню. что RFC вовсе не гарантирует попадание его в реаольность и скорее повод обсудить перед действиями. Поэтому если у вас есть стойкое мнение о них. то вы можете отписаться в RFC и сделать свой вклад в развитие Vue. PS. Более подробно об изменениях Solid 2 и RFC во Vue буду обсуждать сегодня twitch / youtube буквально через час

Мы дождались. Vue-ответ на современные вызовы (Tanstack Query) вышел в релиз: Pinia Colada! Создано автором Pinia и главный мйнтйнером Vue Router Posva Что дает? управление асинхронными ресурсами и кэшем поверх pinia В чем отличие от TanstackQuery? То что pinia colada построена поверх системы реактивности Vue и будет чуть лучше интегрироваться с экосистемой (например data loaders внутри Vue Router). В остальном API достаточно схожи (на первый взгляд, поджробный разбор не делал). Все это позволяет ему быть крайне миниатюрным (3кб влияния на бандл) Посмотрим как пойдет дело. Но в целом рад, что такие инструменты развиваются

Небольшое исследование как активно используют новые Vue фичи (можно отмечать несколько)

Ну что, ждем официальный порт Lynx (альтернатива react-native, работает по принципам схожим с react-native, а не WebView-based) под Vue? Твит от главы разработки Lynx PS. Есть народные попытки портов от автора Vue Vine для Vue Vine другая попытка (есть даже WIP PR в сам Lynx)

Мне прислали вопрос по моему докладу: почему нежелательно использовать классы вместо компосаблов. Тема на самом деле куда обширнее чем кажется на первый взгляд, Именно поэтому я добавил ее в блок "потенциальный доклад по теме", Тут будет моя адаптация ответа. Так как композаблы сами в себе альтернатива ООП заточенная конкретно под нужды Vue. Они уже используют фичи соответствующие потребностям и отсекают вещи которые не особо нужны. Выше уже было мое сравнение композаблов и ООП, потом в отдельных чатах эта тема прорабтывалась куда подробнее. Но тут я сосредоточусь на минусах классов как замены композаблов 1) Классы - не vue way. Ни в одном гайде не будет такого использования. Вы увеличите время онбоардинга, а разработчикам придется куда сложнее с точки зрения приспосабливаемости к проекту, Библиотеки также не адаптированы под данный подход. В одном из случаев вам придется писать огромную портянку с оберткой композаблов в классы, в другом у вас будет адская смесь из классов и композаблов. Выдерживать единый стиль в таких проектах кратно сложнее. 2) Нет четко выработанных практик о том как БЕЗОПАСНО использовать смесь Vue и классов. Высока вероятность получения хрупкого кода, потери реактивности и лапши, При этом опять же у вас не будет гайдов, как правильно это использовать в том или ином случае. Реактивность Vue не дружит полноценно с классами. Например private property несоввместимы с proxy, вам придется полагаться только на TS зоны видимости, но и с ними будут свои нюансы 3)ООП дает избыточные инструменты которые будут только мешать при использовании Vue, они хуже связываются с его жизненным циклом. Наследование, instanceof и тп просто бесполезны. А вот классическую деструктуризацию использовать сложнее 4) Вы не получите никаких бенефитов от данного подхода. Все что дает ООП и реально нужно, то возможно использовать с композаблами и так. Так стоит ли это того? Классы часто берут по привычке, либо если почувствовали в себе труъ-инженеров (а это буквально самое страшное что может случиться с проектом, самые запущенные случаи которые видел, когда кто-то посчитал себя истинным инженером и нагородил такой лапши, что проще проект выкинуть и переписать заново, чем править его логику) Почему же это использовали со Vue2? - А потому что других вариантов адекватных не было. Как раз из-за отсутсвия композаблов выносить логику из компонентов для переиспользования было прям сильно сложнее, а миксины были еще хуже как решение. Вот собственно и все Когда классы+Vue ок? Когда вы используете сторонние специализированные инструменты которые уже заточены под классовое ооп. Например, если вы подключили Mobx (хотя особого смысла я в этом тоже не вижу)

#ТяжелыйПонедельник #видеозаписи Публикуем новую видеозапись выступления: Денис Чернов — Созвездия композаблов 😉 YouTube | 📺 VK Видео

Вышел мой доклад по Vue composables где я попытался собрать практики использования композаблов по Vue в одном месте исходники на презу и сама преза

Вью роутер 5 вышел! Подробнее я писал уже выше. Гайд по миграции (если вы были на 4ой версии и не хотите файловый роутинг. то вам хвтит просто обновления, никаких ломающих изменений) Наиболее интересной частью мажора для меня явлется Data Loader-ы (experimental) Ну и нам сразу анонсировали, что стоит ждать 6-ого релиза

Слияние роутеров Вот такой вот мерж реквест вышел. Если кратко, то сейчас происходит процесс слияния unplugin-vue-router и vue-router. Что в этом интересного? unplugin-vue-router был неофициальным решением по отношению ко vue, но от самого автора и главногомейнтейнера vue-router. Изначально unplugin-vue-router давал возможность использовать файловый роутинг (да тот самый что в Nuxt) для vue-router-а. В последствии он стал уже игровой площадкой для posva, куда он добавлял все интересные фичи перед добавлением их во vue-router. Давайте кратко по фичам (в мре есть подробнее) 1) Типизированные роуты. Так как теперь vue-router получит тесную интеграцию с Volar (а это ядро на котором работает vue langage tools). Теперь страницы точно и легко получают значения из useRoute`/`$route 2) Возможность вместо выноса конфига определят его прямо в файле через definePage либо через новый блок в SFC <route> 3) Эксперементальные фичи от unplugin-vue-router тоже приходят в основной пакет 3.1) Data Loaders - фича которая может огромным образом повлиять на то как мы работаем с ресурсами страницы во Vue. Советую как минимум всем ознакомиться, чтобы иметь мнение по вопросу 3.2) Custom Resolvers - нишевая фича для кастомного парса параметров в путях 4) Ну и конечно же файловый роутинг теперь будет фичей из коробки (конечно же никто у вас ручную настройку роутов не забирает, можете оставаться на ней) Надеемся, что эта миграция освободит posva и он наконец-то добавит поддержку vue vapor во vue router (иначе ждать его релиза не придется) Для Vue это шаг приличный по масштабам, но вот в хорошую ли сторону, решать уже вам.

Мой первый контрибьют во Vue Vapor 🥳 Наконец-то удалось хоть частичку но себя приложить к работе над Vapor модом во Vue. даже если это просто фикс бага. Единственное что омрачает для меня это событие, что AI украло у меня возможность самоу сделать запись строчки с фиксом (который я и так знал). Но все равно считаю что тут мое вложение: проблему удалось найти, определить, приложить к ней силы, описать и выложить :D Огромный шаг для меня и крошечный шажочек для Vue Vapor :D PS. как украл AI у меня правку. Я спросил помощь написание теста, она помогла с тестом и увидела, что тест-то падает и сама исправила баг.

Нас тоже ждут радостные новости по полной поддержке всего со стороны oxc для Vue - Парсер Vue на oxc - issue по лучшей поддержке Vue в oxc - Поддержка JSX Vapor со стороны oxc Так что ждем и надеемся

Vue примереряет тоже рождественские обновочки Что интересно: - prettier -> oxfmt дало дифф в файлах около нуля. Очень бесшовный переход, можно смело брать в свои петы и неважные проекты, не смотря на отсутсвие релизной версии oxfmt - eslint -> oxlint - тут ситуация погрустнее, например, oxlint пока не дает возможности линтить vue файлы и сосредоточен на JS/TS, в остальном же выглядит достаточно круто (поддержка eslint-like JS-плагинов на месте!) - ну и rolldown прям все больше и больше команд себе внедряют, обзательно попробуйте для новой библиотеки использовать инструмент tsdown (сборщик заточенный од задачи написания именно библиотек) PS роллдаун уже подключен был раньше, но так эта троица выглядит еще лучше

Подарки и не думают заканчиваться: встречаем бету Vue 3.6.0

Щедрость души Vue сообщества, то за что я и обожаю этот фреймворк и людей работающих с ним. На самом деле не в первый раз уже так приходят в другие фреймворки с протянутой рукой помощи 💚 https://github.com/sveltejs/language-tools/pull/2905 PS. А что касается обновления выше - для такого огромного минора то суммарно 4 ишью из которых 3 уже в 3.2.1 пофикшены. а послений просто без описания воспроизведения бага