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

Новость с информацией о интенсиве была уже выше. С чем связано запаздывание: в момент когда я собирался все запускать прилетело 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, но и всем кто хочет проверить свою базовую базу