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

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-ов