В чате закинули интересную тему. 2 подхода к извлечению данных о текущем роуте: Props vs Composables

1. Composables
Это доступ к значению напрямую через API роутов

const route = useRoute()
const currentProductId = computed(() => route.params.id)

Тут мы достаем из id указанный в URL (также можем брать метаданные и тд)

2. Props
Но нам из коробки доступен более "нативный способ" получения параметров в компоненте-странице:

const id = defineProps<{
  id: String
}>()

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

// /search?q=Hello
const routes = [
  {
    path: '/search',
    component: SearchUser,
    props: route => ({ query: route.query.q }
  }
]

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

Поэтому у меня тут не столько пост, сколько опрос, а что предпочитаете вы?

#router #poll

Дождался. Доклад по Шестеренкам реактивности Vue наконец-то вышел. В нем были разобраны базовые механизмы на которых основана работа реактивности во Vue.

- Ссылка на презентацию
- Ссылка на карту реактивности

И так полезный сопровождающий материал:
- Chibivue [Ru]
- Курс от Michael Thiessen

Эван тоже не лишен чувства юмора

Уже готовлю миграцию своих проектов на Godown

И вот в полку инструментов которые уже используют Rolldown прибыло. Надеемся на скорейший релиз vite+rolldown.

Только что на него переехал vue-create(раньше был на esbuild). В остальном релиз скорее связан с улучшением дефолтного конфига ESLint

#rolldown #release

Provide/inject
Часть 3: Используем API на практике

Во Vue у нас есть Suspense, но он уже кучу лет висит в Experimental, да и не нужен он особо сейчас во Vue в текущем виде (данное обсуждение я бы вынес в отдельный пост). Однако, что нам делать если мы хотим определять лоадеры в родителе, а дети подгружали бы данные и не парились насчет кто и как показывает лоадер и это вместо того, чтобы делать парады спиннеров (когда каждый компонент имеет свой лоадер) или 1 глобальный лоадер перекрывающий все приложение. Вот с таким запросом заходили в чате.

И решение достаточно простое:
1. Пусть компонент который может показывать лоадер запровайдит API ниже через useLoaderProvider
2. Дочерний компонент через API сможет его подгрузить через useLoader и достать оттуда функцию wait, которая принимает Promise и сообщает родителю, что мы грузим какие-то дочерние данные
3. Соответственно родитель может знать о всех загрузках и показывать Loader когда необходимо

Однако у этого решения есть 2 специфичных минуса
- При первом рендере родителя он еще не знает будут ли грузиться дети (можем первый рендер вообще ничего не рендерить как пример)
- Мы не можем показывать loader / дети по условному v-if и нам нужно думать, как их отображать (например через v-show)

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

Однако, как поведет такая реализация себя если компонент с лоадером мы вложим в компонент с лоадером? Сейчас каждый компонент с лоадером порождает независимый лоадер: то есть лоадер выше не знает о загрузках которые идут от лоадера ниже. И иногда данное поведение нас устраивает, а что если мы хотим, чтобы наш компонент показывал Loader даже, когда грузятся внутренние лоадеры? В этом случае мы могли бы просто не использовать provide во внутреннем лоадере, если он увидит уже запровайженное значение. Таким образом получаем улучшенный пример.

Теперь мы имеем достаточное простое и лаконичное API для работы с лоадерами на проекте при этом обладая полной гибкостью в работе с ними. И такой подход было бы крайне затруднительно реализовать без механизма provide/inject

#di #my #learn #example

Наглядный key

Этот пост больше направлен для начинающих, которым нужно разобраться в концепции key во Vue. И сделаю я это через вот этот пример. В нем я реализовал 4 основных "способа" установки ключей в списках.

1. Это классический-правильный: мы ставим индекс по уникальному ID квадрата. Мы можем заметить, что квадраты при обновлении корректно перемещаются, а при пересоздании заменяются на новые, также корректно ведут себя при добавлении в начало и конец списка

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

3. Вариант с ключом по индексу - по факту почти тоже самое, что без индекса

4. Вариант с рандомным key - ну тут полный треш, на любое действия элементы пересоздают и никаких анимаций вообще нет.

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

Поиграйтесь и поизучайте пример (на самом деле там достаточно интересных техник использовано, например новые cqw/cqh единицы измерения в CSS). И вам станет кристально понятно что и зачем нужен key

Небольшое дополнение о механике работы key. Key это не просто "помочь vue рендерить оптимизировано" или подобные ответы, а это буквально способ дать id нашим элементам и дать возможность vue корректно реагировать на их изменения/перемещения. Также если вы используете key вне списков, то это способ форсированно пересоздавать компоненты (соответственно при смене key произойдет полный цикл с размонтированием старого элемента и монтированием нового, а не просто "форсированный апдейт")

У нашего друга Володи(вы его можете знать как Душный Вуй) поганый телеграм каким-то образом снес канал (он просто исчез в момент и все, поддержка молчит)
Володя вел интересный авторский канал посвященный разработке на Vue
Но Володя не растерялся и создал новый (он перенес старые посты, но комменты к ним не привязаны)
Давайте поможем восстановить подписчиков

Просим дружественные нам сообщества сделать репост
https://t.iss.one/stuffy_vuejs

Всем привет. Меня не было какое-то время (2 недели), да был отпуск, но фактически было путешествие по конференциям и теперь я готов продолжать писать новые посты (во время поездки это было слишком затруднительно).

А сейчас некоторые моменты:
1) Был на конференции Holy.js, где был членом ПК и экспертом, как всегда получил невероятный заряд от ребят. Также там была команда Msk Vue.js(+ с ними был уже знакомый нам Душный Вуй) с которыми я также активно взаимодействовал. кроме этого в день конференции удалось накидать мини-доклад на открытый микрофон о Vue. Я очень надеюсь, что мини-доклад смогу развить в полноценный и реализовать его уже серьезно.
2) Был на конференции Go Cloud от cloud.ru. Там я уже был чисто гостем, но просто посетить мероприятие было бы слишком скучно, поэтому с ребятам из сообщества IT-хохяев (в том числе Siberia can code) делали стрим прямо с конференции и побыли в роли "репортеров". Встретили людей совершенно разных направлений и просили их рассказать о своей работе
3) Был на подкасте от cloud.ru, где записали подкаст о Vue и влиянии AI. Много чего не рассказали из того что хотелось из-за тайимнгов, в остальном все прошло супер.
4) Был на Стачка в роли Эксперта секции Frontend. Тоже 3 дня в Ульяновске прошли сумасшедше. На доступном мне уровне как мог просвещал в промежутках о Vue.js и его преимуществах
5) Записали подкаст Тяжелое Утро (в нем вкраплений про Vue было минимум (( )

И на самом деле это не совсем конец. Так как я уже приступил к написанию доклада к ребятам из Msk Vue.js, думаю совсем скоро они сделают анонс и расскажут о предстоящем мероприятии. Кроме этого хочется придумать доклад для уже следующего сезона Holy.js по Vue.js и тут мне нужна ваша помощь, накидайте идей в комментариях о чем бы хотели услышать на этом докладе.

PS. Если же у вас уже есть идеи и вы хотите выступить сами, то форма подачи заявки Holy.js уже работает. По любым вопросам связанным с подачей и помощью с подготовкой докладов можете трясти меня в ЛС и комментариях

#личное

@click="router.push('/hell')"

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

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

еще раз. если видите что-то подобное

@click="router.push('/smth')"

То приложите усилия, чтобы это стало <RouterLink>-ом или на крайний случай <a>, таким образом вы сделаете мир чуточку но лучше (и никто не захочет вам пожелать отдельного котла)

#remainder #learn #ux

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

Но только вот не у всех есть возможность оказаться в каком-то городе для оффлайн мероприятия (на мероприятии выше трансляция и запись будет). И вот я наткнулся на еще один митап: Vuejs Talks от кор команды Vuestic UI. Митап проходит в онлайн формате на английском, так что это шанс получить общение или даже выступить впервые на английском языке (я себе галочку уже поставил, что планирую это сделать).

Самая классная часть, что проводится митап регулярно фактически каждый месяц. Следующий митап будет 18 июня.
Зарегистрироваться можно здесь
Если же захотели стать спикером

PS, а еще как член ПК Holy.js я бы очень сильно хотел видеть заявки на доклады по Vue экосистеме у нас. Поэтому если у вас есть идеи или желания, то welcome (возможно даже выступление удаленно)

#мероприятия

Невнимательность и реактивность

Недавно в чате человек столкнулся с проблемой, что "меняя нереактивный массив он видел изменения в рендере". В чате сразу начали возникать: мол раз reactive был передан, то это уже реактивный массив. Давайте разбираться

1. Меняется ли исходный объект при передачи в reactive?
Нет. Объект сам не меняется, однако Proxy создаваемое от reactive будет мутировать именно переданный объект. Возможно это очевидно, но:
- во Vue2 редактировался исходный объект. Там каждое поле объекта становилось getter + setter (при этом во всю глубину) и конечно же такой подход имел свои последствия.
- В других фреймворках, например Svelte может быть иное поведение. Там Proxy лишь основывается на начальном объекте и мутации не идут в исходный объект

2. Отслеживает ли Vue мутации в исходном нереактивном объекте?
Нет. Однако, Proxy все-таки основан на оригинальном объекте и если кто-то изменит объект, а потом это значение прочтут реактивно, то, конечно же, будет получено актуальное значение

const a = { hello: 0 }
const aReactive = reactve(a)
const b = ref(2)
const mult = computed(() => aReactive.hello * b.value)
console.log(mult.value) // 0 * 2 = 0
a.hello = 2
console.log(mult.value) // все еще 0, Vue не знает об обновлении
b.value = 1
console.log(mult.value) // 2 * 1 = 2, так как изменилось другое реактивное значение, то Vue пересчитал computed

Кажется очевидным, но в Svelte опять же после создания реактивного значения связь с нереактивным теряется

Вот по сути 2 ключевых момента которые ввели в ступор разработчика, он не заметил, что каждую секунду из-за useFps у него происходил ререндр компонента и не мог понять почему видит обновления в нереактивных данных.

Однако затронем пару еще интересных моментов:

Знает ли Vue, что уже существует Proxy для отслеживания конкретного объекта?
Да. Vue имеет специальные WeakMap-ы со всеми существующими Proxy от реактивности (но доступа к ним прямого нет, он спрятан в исходниках @vue/reactivity)
Проверить это достаточно легко:

const a = { hello: 0 }
const aReactive1 = reactive(a)
const aReactive2 = reactive(a)
console.log(aReactive1 === aReactive2) // true

Это важная часть оптимизация реактивности Vue позволяющая существенно экономить память при работе с объектами, так как на каждый объект не более 1 соответствующего Proxy. Однако у вас нет к этому доступа

Есть ли какие-то данные в Proxy от reactive которых нет в исходном объекте?
Есть, их не существует в объекте, но Proxy особым образом проверяет на доступ к ним. И это ReactiveFlags и хотя у вас есть доступ к этим флагам, все-таки лучше использовать соответсвющие утилити функции от Vue

console.log(aReactive[ReactiveFlags.IS_REACTIVE] === isReactive(aReactive))
// и тд

#learn #reactivity

выступаю с минуты на минуту

Прерываюсь с отпуска с очень грустной новостью: NuxtLabs де-факто на зарплате у Vercel теперь. Я не буду тут описывать почему это плохо. Кто понял тот понял. Но на зарплате Vercel-я теперь все основные Nuxt мейнтейнеры: Энтони, Пуя, Себастьян и Даниель.

https://github.com/nuxt/nuxt/discussions/32559
#iwanttocry

Отпуск завершен. Возвращаюсь в рабочий ритм. Но сейчас самое главное то о чем многие меня спрашивали и ждали.
Я собираюсь сделать новый цикл интенсива по вкату во Vue. Сейчас это не объявление набора, но ждите его примерно с 10-ых чисел августа.

Для кого:
1) Те кто уже умеют писать на других фреймворках, но ему любопытно познакомиться со Vue.
2) Вы уже имеете неплохую базу JS/HTML (уровень умение пояснить за стрелочную и обычную функцию, а также знание основных HTML-тегов).
3) Вы уже пишете на Vue, но недавно или боитесь что у вас много пробелов (будем прорабатывать базу).

Формат: звонок с группой, но стрим будет и общедоступный
Домашняя работа: будет, но проверка по желанию
Протяженность: 2 недели, +- каждый день по 2-3 часа по вечерам.

Что узнаем:
1) Получим основную и прочную базу по Vue
2) Получим набор бестпрактисов для проектов
3) Ознакомимся с основной окружающей экосистемой

Чего не будет:
1) Тестирования (это заслуживает отдельной работы)
2) То что полезно при написании своих библиотек/ui либ (Storybook, tsup и тд, потребует слишком много специфичных моментов для сжатого интенсива)
3) Глубокой подкапотной работы механизмов Vue (однако база будет дана достаточная для применения на практике)

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

Думаю многие уже слышали про 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. Что именно это за песня сходу найти не смог (вариантов хватает)