Думаю многие уже слышали про Vue Vapor (режим работы без VDOM) и он уже проделал неплохой путь:
1) был в закрытой репе и мы ждали хоть каких-то деталей
2) открыли отдельный репозиторий частично
3) дополнили этот репозиторий всеми фичами (компайлер и рантайм)
4) мучительно долго ждали пока репозиторий сольют в главный и это происходило в отдельной ветке
5) ждали каких-то вестей, когда он наконец-то войдет в минор...
6) и вот мы имеем Vapor в альфе
— вы здесь —
7) Vapor выходит в бета версию, а после и релиз в экспериментальны состоянии

Что же нас отделяет от 7ого пункта? Стабилизация. Но как за ней следить?
А вот об этом и пост: пару дней назад появился публичный роадмап по стабилизации Vapor. В нем и можно будет отследить состояние дел.
Ну и в целом сейчас в ишьюсах репозитория целая россыпь вещей связанных непосредственно с Vapor режимом.

Ждем и надеямся, что все пройдет без затыков

Небольшой лайфхак с лайфсайклом

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

Наверное вы периодически могли видеть что-то подобное

const onScroll = () => { /* ... */ }
onMounted(() => {
  window.addEventListener('scroll', onScroll)
})
onUnmounted(() => {
  window.removeEventListener('scroll', onMounted)
})

И данный код кажется слегка изыточным, а порой это бывает и с запросами и тд. И есть ощущение что немного лишнего вываливается в общий скоуп компонента. Однако можно сделать код чуть более семантичным и собранным:

onMounted(() => {
  const onScroll = () => { /* ... */ }
  window.addEventListener('scroll', onScroll)
  onUnmounted(() => {
    window.removeEventListener('scroll', onScroll)
  })
})

Да. Теперь связанные сущности чуть лучше упакованы и да это работает. А если у вас несколько листенеров (такое бывает при обработке форм в ручную или D'n'D) можно доработать до

onMounted(() => {
  controller = new AbortController();
  window.addEventListener('scroll',  () => { /* ... */ }, { signal: controller.signal })
  window.addEventListener('resize',  () => { /* ... */ }. { signal: controller.signal })
  window.addEventListener('click',  () => { /* ... */ }. { signal: controller.signal })
  onUnmounted(() => {
    controller.abort()
  })
})

это позволит вам разом отключать всех подписчиков разом без нужды давать каждому отдельное имя (работает и с запросами и прочими браузерными API)

Надеюсь это поможет сделать вашу кодовую базу чуточку лучше

#лайфхак #composition

Расширение для Vue переименовывают... опять. Теперь это "Vue.js". Как выяснилось причиной по которой только сейчас взяли это имя... им просто не приходило в голову это раньше. А Volar изначально был проектом Джонсона и был назван так в честь любимой песни.

PS. Что именно это за песня сходу найти не смог (вариантов хватает)

Вновь любопытная статистика о vue/langauge-tools. Да, в него входит и расширение Vue.js

Заметен тренд на резкое снижение количества заведенных проблем на гитхабе и насколько оно было огромным при переходе на Volar с новой архитектурой. Все еще далеко от идеала, но стало явно гораздо стабильнее.

Ссылка со скрина

У меня 2 новости. Обе хорошие. Сейчас сообщу первую, а вечером вторую (вы уже даже догадываетесь о чем речь)

1. У Vue чата отделили старый Vuejs jobs от нашей сетки, так как мнения администраций частенько не совпадали. Теперь у самого крупного русскоговорящего чата Vue свой чат по поиску работы Vuejs Career. С более щадящей и мягкой модерацией (без банов за выход / ограничений зп в 150к и тп). Также администраций будет единой с чатом Vuejs, так что договариваться будет проще в случае возникновения проблем.

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

PS. В честь этого также провели небольшой ребрендинг сообщества (сменили лого), так что не пугайтесь

Запоздалая хорошая новость

Новость с информацией о интенсиве была уже выше. С чем связано запаздывание: в момент когда я собирался все запускать прилетело 2 крупных проекта горящих и я все еще не знаю как это все дело буду разруливать. Но вас кидать пообещавши тоже не хочется.

Критические даты: 7-11 сентября. 25-30 сентября, они связаны с работой и конференциями, те пересечение с этими датами = пауза в интенсиве.

И тут я встал на развилке. Спокойно все сделать 2 проекта и уносить интенсив на октябрь. Но по ощущениям ждать этого вам придется достаточно долго. Либо же в судорожном порядке попытаться жонглировать сразу 6 активностями при этом мне нужно еще и фуллтайм работать. И в этом случае я не знаю как обеспечить качество интенсива и не выгореть на половине пути.

Хотелось бы услышать ваше мнение. Если мы остаемся на ближайшем времени, то интенсив начнется со следующей недели. Если готовы терпеть, то на октябрь.

Самому крайне неловко и жаль, что все это произошло так внезапно... Сижу и думаю как правильно все разрулить теперь (да буквально в 1 день пришли 2 проекта и аппрув выступления на конфу, даже не думал что такое бывает).

Радует лишь 1: делаю я интенсив бесплатно и мне не стыдно за взятые с других деньги (но стыдна мысль об откладывание того о чем все долго ждали и просили)

Так ребят, интенсив уезжает на октябрь. Но не расстраиваемся. Я немного перетер с Эваном, мол так и сяк "ребята ждали, бросать нельзя".

И вот ловите подгончики: Free Weekend от certificates.dev: уже в эти выходные!
И даже новый бесплатный курс по Vue от Scrimba в результате партнерства со Vue: появился только сегодня!

В целом, кто хочет, тот найдет себе источники для изучения.
PS. Насколько я знаю что certificates.dev что scrimba это свежак по такому формату, поэтому отзывы приветствуются!
PPS. Специально для душнил: конечно про общение с Эваном я пошутил, но совпадение все еще веселое

не мутируйте вычисляемое!

Daily reminder: неосторожное использование sort/splice/reverse может привести к зависанию на странице, которое при этом не всегда легко обнаружить.
Поэтому, никогда не используйте sort/splice/reverse с реактивными данными внутри computed/template/watchEffect. Оно может привести к зависанию приложения и чаще всего вы и не хотели что-то мутировать, а просто подзабыли о том как работают данные функции.

1) Используйте немутирующие методы(toSpliced/toSorted/toReversed), если вам и не нужна мутация, а, например, только для отображения
2) Используйте их на нереактивных сущностях, если вам это необходимо

Зато, если вы обнаружите баг с бесконечными ререндерами, это доп пунктик, что вы можете проверить

#советы

В последних версиях редакторов jetbrains наконец появилась возможность включить VUE LSP третей версии.

Сильно улучшает производительность, наконец вью стало приятно писать.

Поставьте галку вот тут, больше ничего делать не нужно.

SFC и раздутые компоненты

какое-то время в нескольких сообществах бурно обсуждаются плюсы и минусы подходы к SFC в целом. Описание всех плюсов и минусов оставлю на другой раз. Сейчас же сосредоточимся на конкретной претензии: SFC ведет к раздутым компонентам. Так ли это? А давайте разберемся с этим на примере работы в вакууме.

1. У вас есть компонент и внутри него есть template + style + script
2. В какой-то момент времени вы ловите себя на мысли "компонент стал большим, по нему неудобно навигироваться и работать с ним"
3. Вам нужно что-то предпринять

И тут у вас 2 выбора, но вначале разберем первый:
Взять компонент и посмотреть на него еще раз:
- Вынести переиспользуемую логику в композаблы
- Разбить шаблон на более базовые компоненты
- Даже банально вынести обычные утилиты из компонента

Итого получаем обратно более лаконичный компонент, он не раздут. Стало больше переиспользуемых частей. Это и есть pit of succes.
- Делать хорошо легко: маленькие компоненты легко и приятно поддерживать в SFC стиле
- Делать вербозные и раздутые компоненты неудобно, навигация усложняется и вы чувствуете как много времени уходит на что-то не то
- Есть мотивация перейти из плохого состояния в хорошее: у вас естественным образом возникает желание разбить компонент

Однако иногда система дает сбой и кому-то кажется, что решение проблемы это "а давайте разобьем компонент и вынесем из него css/html/js" не важно что. Как только вы поставили самоцелью сделать не функциональное разбиение, а типовое, то вы сразу
1) Ломаете то как работает изначальная идея: вам должно неприятно работать с раздутыми компонентами
2) Ломаете привычный флоу работы со Vue
3) Теряете плюсы которые дает SFC
И ради чего? Ради того, чтобы лечить раковую опухоль(использование практики раздутых компонентов) сбивая температуру(просто разбивая файл, а не функционал)

Надеюсь, что мораль ясна. А вам стало понятна еще одна причина, почему SFC — это хорошо

Эмуляция `object-fit` и custom property

Накидал учебную демку. Изначально делалось для себя, для решения конкретной задачи. Mне лично это нужно было чтобы canvas в div вел себя также как изображения внутри img используя проперти object-fit. К сожалению, из коробки CSS подобного не дает, однако с современными возможностями CSS можно воссоздать нечто очень похожее. И я решил поделиться с вами, уж больно много разных интересных тонкостей вылезело пока пытался реализовать данную фичу.

И так встречаем демо
в нем расставлены комментарии, но если что-то непонятно, то спрашивайте. Конечно, тут осталась какая-то часть на js, но в недалеком будущем можно будет еще несколько костылей отсюда выкинуть.

Кому показалось мало, то есть более извращенный вариант, где еще более честно пытаемся создать кастомное воплощение object-fit.

В целом.. это то на что уже способен CSS и пока я пытался реализовать демку натыкался на несколько драфтов которые еще больше сахара в данный процесс вставят (например использование var внутри container query полноценно, а не только style query)

Бонусом: тут можно подсмотреть некотрые трюки для более удобной работы с SFC плейграундом

PS. В первую очередь расчитано на работу в Chrome. В сафари тоже ок должно быть, а вот у Firefox все еще нет поддержки style queries 😢

Сегодня совсем скоро провожу мок-собес специфичный на Vue.js джуна.

Так как это мок собес, а не реальный, будем копать всегда чуть глубже, чем это могло бы понадобиться, так как нам нужно видеть точки роста, а не только "подходит/не подходит" нам человек. Надеюсь выйдет интересно не только джунам на Vue, но и всем кто хочет проверить свою базовую базу

Гранулярность в реактивности

Когда в наш код приходит реактивность, то весь мир начинает делиться на реактивный и нереактивный. Но на самом деле даже реактивность часто подразумевает собой множество средств для достижения одного результата. Vue не стал исключением, а скорее наоборот является ярким представителем "дать много средств достижения 1 цели".

Главные способы внести раздор: определение границ реактивности, определение гранулярности реактивности.
Первое +- еще понятно: мы сами хотим управлять, что реактивно должно быть, а что нет. И если нам не нужно чтобы что-то было реактивным, то мы это и указываем соответствующим образом.

Интереснее дела обстоят с гранулярностью: это показатель насколько точечно мы хотим следить за реактивностью. Сравните эти 2 примера

const size = computed(() => ({ width: x.value * xScale, height: y.value * yScale}))
// vs
const width = computed(() => x.value * xScale)
const height = computed(() => y.value * yScale)

На самом деле есть третий вариант, связанный с границами реактивности, но оставим его на потом.
Что же предпочтительнее использовать? Скорее всего это будет не сильно важно. Однако, второй вариант обладает большей гранулярностью: изменение x не затрагивают обновления y и наоборот. Соответственно если одно значение независимо от второго и подписки неравноценны (нам важно знать x, но y нам знать важно гораздо реже), то второй вариант оказывается сильно предпочтительнее. Первый же вариант уместен, когда данные имеют смысл только вместе и данные +- обладают схожей важностью (например size мы используем для написания transform: transition(x, y) ), тогда второй вариант оказывается более громоздким и более требовательным по ресурсам (еще и .value расписывать приходится).

Поэтому для выбора всегда стоит прикинуть как будут использоваться ваши данные и насколько независимы его компоненты.
Но вариант выше не ограничивается этими 2мя вариантами. Например, вы любите семантичный код и первый вариант с image.width.value вам кажется понятнее width.value. Можно конечно наращивать префиксы imageWidth.value, но если таких значений много, то можно пойти альтернативным путем

const image = {
  width: computed(() => x.value * xScale)
  height: computed(() => y.value * yScale)
}

Почему-то многие забывают о такой вариации, хотя она полностью законна (вы даже можете закрепить на уровне TS такой контракт и перекидывать его между компонентами). В чем главное отличие от первого варианта с size? То что в данном случае мы сохраняем прежний уровень гранулярности (данные независимы), и немного "оптимизируем" работу не порождая новый объект на каждый прогон (не думаю, что много где это будет критично, хотя и может спасти вас от некоторых избыточных перевычислений)

const transition = computed(() => `transition(${size.value.width}, ${size.value.height})`)
const transition = computed(() => `transition(${size.width.value}, ${size.height.value})`)

Первый вариант явно проигрывает, так как даже если у нас значения после вычислений остались прежними (например скейл и размер свапнулись местами), то объект все равно новый и перевычисление произойдет, а второй вариант не будет триггериться, так как видит, что итоговое значение одинаковое. Так и работает гранулярность

Мне не нравится писать `.value` после каждой компоненты значения

Конечно, сугубо дело вкуса, но если вы готовы пожертвовать перфом, то вспоминаем трюк для создания композаблов без .value: обертнуть в reactive(readonly)

const image = readonly({
  width: computed(() => x.value * xScale)
  height: computed(() => y.value * yScale)
})
const transition = computed(() => `transition(${size.width}, ${size.height})`)

Тут уже, конечно, ощущается специфично, но решение рабочее. Перф будет слегка пониже из-за дорогого доступа к проксям, но это не сильно критично

Vue, конечно же, будет корректно работать во всех этих сценариях и найдется решение на любой вкус, но осознанный выбор, может сделать ваш код: более производительным/более выразительным, все зависит от ваших желаний. Моя задача была лишь подсветить вам вариации и к чему они ведут.

скрыть нельзя уничтожить

Тема скрытия/уничтожения компонентов редко бывает какой-то сильно особенной, но в ней тоже есть свои нюансы. Первое что знают все: существование v-if v-else-if v-else это главное управление. Также большинство слышало о v-show. Кто-то даже мог успеть поиспользовать v-cloak(хоть это и крайне специфичный случай).

В чем разница базово тоже большинству понятна: одна управляет временем жизни, другая просто скрывает элемент из DOM. Может возникнуть вопрос, а когда использовать v-show?

На самом деле ответ: в 99% вы будете использовать v-if. v-show же не более чем прописать `display: none`(почти..). Те компонент с v-show рендерится в dom-е и все элементы жизненного цикла продолжают работать: будут происходить ререндеры при изменении данных, отрабатывать все вотчеры и тд. И это то что иногда и нужно вместо v-if! Давайте рассмотрим ситуации, когда это нужно

1. Предзагрузка сложного компонента. В случае, когда компонент требует больших ресурсов, он с большой вероятностью понадобится, а показывать сразу его нельзя. Неплохой вариант, но это лишь оптимизация и сильно заранее делать так не стоит, только если вам действительно нужно прибегнуть к такому способу. Ну или сторонний код на ванилле не лучшего качества, который подвязывается на DOM элементы (сценарий уже вероятностью один на миллион).

2. Компоненты которые сложно назвать бесплатными и они часто закрываются/открываются. В этом случае тоже неплохой вариант для оптимизации. Так как вместо полного пересоздания компонентов вы будете просто прятать их из виду вместо пересоздания. Хотя в этом случае тоже есть альтернативный подход. v-if + keep-alive keep-alive будет удерживать жизнь компонента, а v-if честно прятать и открывать его. Мне вариант с keep-alive более симпатичен, так как он буквально и создан почти под такие задачи.

3. SSR Friendly. Крайне специфичный момент. Но если v-if в негативном случае не отрендерит ваш компонент, то v-show все равно вставит HTML в код и он придет с сервера, нужно это на самом деле не часто, но если вы знаете что делаете и у вас противный случай с ошибкой гидратации, то v-show может от них уберечь. Но стоит к этому прибегать, только в случае решения конкретной проблемы и другие варианты вам уже не могут помочь. Решением будет архитектурный пересмотр, почему вам вообще понадобилось такое (скорее всего вы пытаетесь играть в угадайку, что отрендерится на клиенте с учетом настроек браузера напр media-query).

4. Хаки и костыли. Ну это уже крайне специфично и этого сценария лучше как раз избегать: компонент даже с v-show="false" продолжает жить и значит, что все запущенные в нем процессы также продолжают работать, даже когда компонент скрыт. Не советую полагаться на это поведение. Но, например, если у вам необходима подгрузка с бека по специфичному сценарию и она меняется прямо в рантайме и вы не можете без костылей вынести это в какое-то более глобальную область, то v-show тоже может вам помочь спрятать, но продолжать отрабатывать. Хотя я бы все равно по возможности вынес такую логику за пределы компонента, а то и в отдельный компонент обретку, которая бы грузила данные и. возможно, следила бы за необходимостью показа такого фрейма.

В целом: не используйте по возможности v-show желание заиспользовать его, скорее маячок, что что-то при проектировании приложения пошло не так, а альтернативные сценарии, как решать те же проблемы я перечислил (и решений, зачастую, далеко не 1, но на все мне не хватит сходу фантазии и места под пост).

PS. А чем v-show лучше чем просто написать display: none? Если откинем разговоры про декларативность: то гарантией Vue уважать его как метод скорытия, например, поддержкой transition-ов

Немного о грустном

Определенное время будучи самоназванным евангелистом Vue, я сталкиваюсь с одной и той же проблемой: при продвижении Vue есть главный pain point: UI-библиотеки.
Я всей душой и телом обожаю Vue, но Vue как экосистема страдает от нехватки выбора opensource UI либ качественного и современного уровня. Чтобы человек не взял при переходе react -> vue он все равно сталкивается с тем, что упирается то в шероховатости и забагованность, то в буквальную нехватку функционала. Но пост скорее попытка понять: как вы живете со Vue относительно UI либ. Поэтому хотелось бы увидеть в комментариях ваши истории.

А ниже моя манялитика как же так произошло:

1 и главное: Vue 2 -> Vue 3
У меня ощущение, что это дико сбило темп авторам UI библиотек на несколько лет. Bootstrap Vue, например, так и не оправился полноценно от этого, а многие либы застряли в развитии на года. Но, все равно мы можем встретить библиотеки которые ощущаются UI либами этого поколения: vuetify, Ant disign. Element UI (который стал Element Plus для Vue3 и тд). Их отличительная черта: сложная кастомизация, перегруженность функционалом, многое прибито гвоздями

2 на их место пришли UI либы среднего поколения:
Это амбициозные библиотеки которые пытались сделать все и сразу, эдакий модерн: Quasar (он ближе к первому поколению, но все-таки отнесем к 2ому). Naive UI (с любовью JSX для Vue) и главный представитель в виде PrimeVue (наверное, лучший представитель данного поколения). Тут UI библиотеки пытались проработать боль сложности кастомизации из 1ого поколения, но они ударились в другую крайность, что сделало системы: 1 местами хрупкими, местами испытывающими проблемы с функционалом, ибо предугадать все хотелки задача не из легких. Из-за того как сильно просело 1ое поколение в переходах, то и 2ке пришлось достаточно нелегко.

3 поколение: headless / shadcn like
Вначале пришли headless библиотеки: а ля radix, далее революция в мире UI библиотек в виде shadcn подхода с импортом в кодовую базу. В мире Vue это очень молодой подход, чувствуется, что многое сделано наспех, однако переход все-таки происходит. Тот же PrimeVue вначале сделал headless версию, а после вообще выпустил Volt UI. До него к нам уже запортировали из мире реакта Reka UI + Shadcn Vue и в последствии сделанный поверх Nuxt UI (и как видно пока он главный любимчик, хотя мне он тоже не полностью нравится). И, на самом деле, еще большое множество библиотек. Но все они на 2025 год ощущаются сырыми и их сложно брать as is скорее всего, вам придется становиться помощником и репортить ишьюсы и помогать их править. Таким образом это очень молодое поколение и, я думаю, что стабилизация займет еще года 2.

4 поколение: А тут я жду AI friendly UI библиотек, но все еще не до конца представляю как это будет выглядеть, но точно стоит ждать шаг в эту сторону (MCP + spec first design)

А что думаете вы? Какие используете библиотеки для петов или для коммерческой разработки?