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