Комментарии 11
То, что вы написали — это иконка с именем из переменной mdiDogSide.<q-icon :name="mdiDogSide" />
С виду, вроде почти то же самое, но нужно обратить внимание на то, что :name — это реактивное свойство, и потому оно будет кушать ресурсы.
Просто иконка с именем mdiDogSide записывается как
<q-icon name="mdiDogSide" />
Много текста, но так и не понял, чем подход кастомных иконок лучше <q-icon name="mdiDogSide" /> (в моем случае, самописный <base-icon> с font-size, color и другими няшками вроде умения работать со спрайтами)
Зачем плодить лишние сущности компоненты?
Придет новый программер
Увидит компонент
Начнет искать его и увидит сложную генерацию
Тихо заматерится, на "прозрачный и красивый код"
Основная идея в том, что программер компонент искать не будет. Зачем программеру искать компонент svg-картинку, просто статически встраиваемую в html? Этого компонента в исходном коде просто нет. Он создаётся на этапе сборки.
Эта идея работает не только для картинок и принадлежит Anony Fu, мастеру, входящему в ядро разработчиков Vue. Она позволяет делать код более лаконичным, опуская очевидные импорты и регистрации. Советую посмотреть шаблон https://github.com/antfu/vitesse. Он претендует стать легковесной заменой Nuxt. В нём много чего реализовано с помощью такого подхода.
Согласен, что это подход на любителя, и многим он может не понравится. Но думаю, что найдётся и много его сторонников.
У вас в шаблоне новый тэг
Это и есть новый web component
Пришедший программер начнет его искать и не найдет
Свой base-icon - 30 строчек ясного кода и переиспользуемый! для производительности при надобности Vue компонент
Ваш подход - необоснованное закулисывание очевидной логики, усложнение билда, усложнение читаемости кода
Если программер знаком с тем, что на данном проекте не нужно искать компоненты с определённым префиксом, то он и не будет их искать.
>Ваш подход - необоснованное закулисывание очевидной логики, усложнение билда, усложнение читаемости кода
Понимаю, что для кого-то это выглядит именно так. На мой взгляд, это вопрос предпочтений. Тот факт, что серьёзные люди в ядре разработчиков Vue продвигают этот подход говорит о том, что есть и те, для кого такой подход выглядит логичным и красивым. Не вижу смысл вести холивар по этому вопросу.
Это два подхода, но намного более важные, чем кажется
Первый отражает концепции абстракции и инкапсуляции ООП
base-icon - это класс. С определенными свойствами и методами. Иконка - свойство.
Вы же вместо создания объектов одного класса создаете множество классов
Классы, абстрагирование, инкапсуляция нужны на уровне программиста, а не компилятора или сборщика. Именно чтобы код был "прозрачный и красивый"
И Vue.js возможно более других фронтэнд фреймворков старается придерживаться ООП парадигмы
Я Вас понимаю, но не согласен. Ещё раз хочу сказать, что это не я реализую такой подход. Его реализуют люди из ядра разработчиков Vue при поддержке Эвана Ю. Мне лишь понравился такой подход. Спорить смысла не вижу. Ваша точка зрения имеет право на жизнь.
При классическом подходе кодовая база самодостаточна и не зависит от сборки. При новом подходе (Unload) это не так - получается что сборка определяет, как код должен интерпретироваться в каждом конкретном проекте, и эти соглашения практически выносятся за рамки основной кодовой базы. Для кого-то такой подход выглядит неприемлемым. Мне видится, что здесь достаточно дополнительных соглашений.
Код — это некий язык описания поведения. В обычном языке есть какие-то вещи, которые разумеются сами собой, и мы можем их опускать в речи, потому что есть некие договорённости за рамками этой речи. То же самое реализует подход Unload. При анализе кода необходимо знать соглашения за рамками основной кодовой базы, реализованные в сборке.
Если же говорить о классах, то когда у нас в шаблоне компонента нет переменных, мы получаем вырожденный случай, в котором в нашем классе нет никаких свойств, а есть только неявно вызываемый метод render(), который просто напрямую встроит шаблон, в DOM, как html элемент. И высокие слова о инкапсуляции, свойствах и методах оказываются здесь формальностью.
По поводу множества классов — непонятно, чем это так плохо. В случае, когда класс один, и он простой без дополнительных, кроме name свойств, в итоге в DOM попадёт тот же элемент svg, только при монтировании будет искаться соответствующий код, и уже на его основе формироваться шаблон. При Unload подходе эти движения не нужны, так как выполнены на этапе сборки, и шаблон уже готов. Мне видится, что это более оптимальный вариант с точки зрения времени выполнения.
С точки зрения удобства чтения кода, для плагина unplugin-icons есть расширение под VS Code https://marketplace.visualstudio.com/items?itemName=antfu.iconify, которое прямо в коде рисует иконку, которую внедряет данный компонент. Думаю, после этого программеру не составит труда разобраться, к чему тут этот фрагмент кода.
Под мой плагин пока такого расширения нет. Я только приступил к его написанию.
Относительно реализации решения, описанного в статье, выскажусь - выглядит довольно красиво. Относительно продакшен кода - будьте готовы, что у вас будут гореть уши. У меня прямо сейчас есть два проекта, где фронтэнд на Vue не имеет документации, и моей команде приходится его до/перерабатывать, как думаете, каким словом вспомнят вас, если в третьем проекте такого плана появятся ваши иконки?
Я задумывал этот инструмент в качестве органического дополнения в шаблон https://github.com/antfu/vitesse. Для тех, кто этот шаблон уже использует (разве что в стартапе, поскольку этот шаблон ещё совсем тёпленький) подключить его в работу сложности не составит, поскольку он работает по аналогии с уже имеющимся в шаблоне инструментом https://github.com/antfu/unplugin-icons. В отрыве от упомянутого шаблона использование моего инструмента, мне представляется нелогичным.
Компактные Vue компоненты из самописных SVG иконок