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

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

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

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

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

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

Да. Теперь связанные сущности чуть лучше упакованы и да это работает. А если у вас несколько листенеров (такое бывает при обработке форм в ручную или 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

У меня 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. Специально для душнил: конечно про общение с Эваном я пошутил, но совпадение все еще веселое

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

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

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

📦 NativeScript Vue for Web

Map common NativeScript UI tags to browser-ready Vue 3 components, enabling the same SFC to run on both Native and Web.

https://github.com/ponzS/NativeScript-for-web

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

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

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

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

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

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

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

Наконец-то дождался!

Был на подкасте в гостях у cloud.ru. Съемки были еще в апреле, так что основную часть уникальности про AI подрастеряло (с августа +- многие стали говорить об этой проблеме уже), но лучше уж поздно чем никогда. В остальном же подкаст достаточно лайтовый: про роль Vue в мире современного фронтенда и экосистемный подход.

youtube

Всем привет!

Я тут написал большую статью на Хабр про Nuxt UI. Если что, с недавних пор эта библиотека работает и с обычным Vue.

В общем, если кому интересно, приглашаю почитать. https://habr.com/ru/companies/timeweb/articles/971892/

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

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, с} // вернули
  ... 
}

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