В последних версиях редакторов 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, с} // вернули
  ... 
}

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