Эмуляция `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)

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

По поводу бага выше:
Да Vue генерирует в Dev среде комментарии из template. Это поведение можно отключить вот таким образом. Тогда баг с Transition и тп пропадет

BEM-like

Будем разбирать каждый тип по очереди и начнем с BEM-like решений. Сразу оговорюсь, что тут речь не о чистом BEM, а именно о тех вариациях которые можно встретить зачастую в проектах и конкретно ДЛЯ ИЗОЛЯЦИИ (БЭМ решает и другие проблемы, но это отдельной статьи бы потребовало)

Ключевые признаки:
1) Пишем стили в <style> выбор между css/sass/postcss не важен
2) изоляция достигается оберткой стиля в BEM-like нотацию: имя компонента становится классом, далее поверх накидываются уже элементы/модификаторы и тд

Основные плюсы:
1) Нативность: для работы BEM-like почти никакого сопровождения со стороны фреймворка не требуется, работает везде
2) Простота (относительная): пишем почти как обычный CSS, но с парой правил сверху, справится любой. в блоке скриптов тоже представляется в виде обычных строк
3) Семантичность: зайдя в девтулзы найти компонент по классу легко, легко понять что именно за классы навешены на div, да и при чтении кода компонента +- понятно за что отвечает каждый тег
4) При грамотных действиях дает неплохую стандартизацию по именам классов на проекте/
5) Очень хорошо подходит для обучения новичков с точки зрения развития инженерных навыков (новички учатся быстро понимать, что классы могут иметь четкие роли, внешняя геометрия вне компонента и тд), но в реальности большинство ограничивается только базой нейминга без самой сути

Минусы:
1) Большие имена классов: то за что ругают чаще всего, что имена становятся длинными и громоздкими, есть техники уменьшающие длину классов, но они уже компромисны
2) С точки зрения изоляции, то изоляция держится на условном контракте, те если кто-то нарушит и переиспользует имя, то будет коллизия, на больших проектах имена классов раздуваются еще сильнее и перед именем блока появляется еще и "неймспейс", данная изоляция особенно течет на микрофронтендах, если не предпринять особых мер
3) Я не просто так пишу BEM-like. ибо BEM как таковой люди понимают очень по разному и каждый проект уникален в своем "БЭМ"-е. Также селекторы могут включать в себя любой хаос и не подчиняться строгой BEM-нотации
4) Относительный минус: порой людям кажется сложным поиск элемента сразу
5) Никакой защиты на уровне типизации (очепятка в имени класса обнаруживается только в рантайме)
6) Истекает из семантичности: на каждую маломальскую потребность в использовании стиля нуно придумывать отдельное имя, иногда это людям дается сложно и некоторые ощущают в этом потерю времени за зря

Нюансы:
1) Скорее всего в 99% случаев у вас будет 1 блок = 1 компонент, так как семантика понятия блока и компонента крайне близка. Действительно желание сделать блок это повод задуматься: а почему бы не вынести это в компонент (мне нравится, когда сам подход дает такие эвристики для мышления!)
2) Если вы разрабатываете библиотеку, то сохранность имен классов дает возможность расширения стилей (что в 90% зло), но иногда действительно спасает
3) Пользователи адблоков, кастомных тем/плагинов на сайтах скажут спасибо, ибо когда есть четкие классы, то их очень легко и удобно расширять и подвязываться на них

Вариации:
1) Может сочетаться со скоупами или модулями, но это во многом избыточно. Для модулей этого точно лучше избегать, так как БЭМ+модули даст крайне громоздкий и избыточный код, предпочтите подходы специфичные для модулей
2) БЭМ+atomics подход озвучивался даже в комментариях выше. Если вам нужно повесить только внешнюю геометрию или 1-2 класса, а нейминг придумать к этому нереально, то atomics прекрасно закрывает данную потребность. Тут советую больше присмотреться к unocss нежели tw из-за простоты настройки только точечных классов, а не всего подряд

Итоги:
1) В целом данный подход все еще работает, но на проектах которые предполагают большой размер, независимую разработку команд есть более современные и простые методы изоляции
2) У него есть сторонники (в том числе и я), но есть и жесткие хейтеры.
3) Подход постепенно теряет актуальность, но я все еще вижу хороший потенциал именно в обучении людей
4) Если выбираете BEM-like для своих проектов, то пожалуйста, не поленитесь и копните глубже в философию БЭМ-а (раскрыть мне все в 1 посте тут просто нереально) и подумайте еще раз надо ли оно вам

Анатомия композаблов

DISCLAIMER: сравнение натянутое и заведомо раздутое, но в нем есть и зерно истины

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

function useA () { // имя класса
  const b = ref() // поле класса
  const c = ref() // поле класса 2
  const sum = computed(() => b.value + c.value) //  getter (и возможно setter)
  function swap() {} // метод класса
  
  // тут может быть ваша логика конструктора
  
  // и даже деструктор доступен 
  onScopeDispose(() => { ... })

  return {
    b, // теперь b публичное поле класса (а вот С приватное)
    sum // публичный метод
  }
}

Вы можете возразить: а как же 3 столпа ООП наследование/инкапсуляция/полиморфизм.
С инкапсуляцией разобраться просто: композаблы и нужны, чтобы инкапсулировать логику в 1 месте (как сокрытие работает мы уже тоже рассмотрели)

Что насчет полиморфизма: с ним все замечательно, просто мы применяем его редко:

interface A {
  (): { // описываем параметра конструктора
    b: Ref<number>
    swap(): void // описали публичный интерфейс
  }
}
const useA1: A = () => { ... }
const useA2: A = () => { ... }

A1 и A2 реализуют один интерфейс и мы можем подменять их в зависимости от ситуации, 90% нам это не понадобится, но если сильно хочется то возможно

А где наследование то?
Ну с наследованием ситуация веселе. Сейчас такая тенденция, что наследования стараются избегать всячески предлагая вместо него использовать композицю, но многим лень, так как наследование написать на классах проще и удобнее чем композицю (особенно если хочется сохранить прежний интерфейс). С композаблами ровно обратная ситуация: мы легко можем использовать композицию, но наследование становится болезненным (чему я очень рад!)

function useA() {} // base
function useB() { // композиция ❤️
  const a = useA() // изи
  const { b, swap } = useA() // внедрение тоже легкое
  ... 
}
const useB = ({...}: {...} & Parameters<typeof useA>) => { // наследование 🙈
  const a = useA() // взяли и
  const c = ref()
  return {...a, с} // вернули
  ... 
}

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