привет, коллеги! думаю, как бы прикрутить svg-иконки. у нас SPA без SSR, задачи вставлять через CSS нету, так что выбираю между разными способами инлайнинга в HTML 1) есть https://github.com/visualfanatic/vue-svg-loader - он просто читает svg-файл, прогоняет через SVGO и рендерит во vue-компонент 2) есть https://github.com/kisenka/svg-sprite-loader - собирает файлы в спрайт, возвращает объект с айдишником символа, который можно использовать в <use> - но есть возможность дописать "генератор рантайма", чтобы возвращал сразу компонент (есть пример для реакта https://github.com/kisenka/svg-sprite-loader/blob/master/examples/custom-runtime-generator/svg-to-icon-component-runtime-generator.js - для ву получилось сделать аналогичный за 20 минут) То есть клиентский код у обоих может быть одинаковым: <template> <button>Hi, <Icon /></button> </template> <script> let Icon = require("icon.svg") export default { components: {Icon} } </script> в первом не нравится, что он превращает svg в render-функцию (нафига?) во втором не нравится, что SVGO можно подключить только сбоку, соответственно каждый svg будет парситься дважды. и, главное, не могу понять, есть ли у спрайта преимущества перед тупой вставкой в код, если мы не используем svg из CSS. вроде при тупой вставке на каждое использование иконки будет генериться N дом-узлов, а для спрайта - только 2 (<svg> и <use>). с другой стороны, use вроде как порождает кусок shadow dom, который кажется копируется из источника. при этом при тупой вставке мы можем легко раскрашивать из CSS отдельные куски SVG, а для спрайта - только все целиком (или я не прав?) короче, пока накидал свой лоадер на основе vue-svg-loader, он тупо передает содержимое svg строкой в функцию, которая уже создает из нее компонент, всталяя svg через domProps: {innerHTML: ...}, - вроде работает, но прежде чем начать его активно юзать, хочу посоветоваться с умными людьми =)

я первое юзаю, доволен как слон. Код красивый.

я первое юзаю, доволен как слон. Код красивый.

привет, коллеги! думаю, как бы прикрутить svg-иконки. у нас SPA без SSR, задачи вставлять через CSS нету, так что выбираю между разными способами инлайнинга в HTML 1) есть https://github.com/visualfanatic/vue-svg-loader - он просто читает svg-файл, прогоняет через SVGO и рендерит во vue-компонент 2) есть https://github.com/kisenka/svg-sprite-loader - собирает файлы в спрайт, возвращает объект с айдишником символа, который можно использовать в <use> - но есть возможность дописать "генератор рантайма", чтобы возвращал сразу компонент (есть пример для реакта https://github.com/kisenka/svg-sprite-loader/blob/master/examples/custom-runtime-generator/svg-to-icon-component-runtime-generator.js - для ву получилось сделать аналогичный за 20 минут) То есть клиентский код у обоих может быть одинаковым: <template> <button>Hi, <Icon /></button> </template> <script> let Icon = require("icon.svg") export default { components: {Icon} } </script> в первом не нравится, что он превращает svg в render-функцию (нафига?) во втором не нравится, что SVGO можно подключить только сбоку, соответственно каждый svg будет парситься дважды. и, главное, не могу понять, есть ли у спрайта преимущества перед тупой вставкой в код, если мы не используем svg из CSS. вроде при тупой вставке на каждое использование иконки будет генериться N дом-узлов, а для спрайта - только 2 (<svg> и <use>). с другой стороны, use вроде как порождает кусок shadow dom, который кажется копируется из источника. при этом при тупой вставке мы можем легко раскрашивать из CSS отдельные куски SVG, а для спрайта - только все целиком (или я не прав?) короче, пока накидал свой лоадер на основе vue-svg-loader, он тупо передает содержимое svg строкой в функцию, которая уже создает из нее компонент, всталяя svg через domProps: {innerHTML: ...}, - вроде работает, но прежде чем начать его активно юзать, хочу посоветоваться с умными людьми =)

ага, пасиб. а много иконок на странице бывает?

Я галпом собираю спрайт из символов, потом вебпак инлайнит его в index.html при сборке. Использую с помощью компонента, в который передаю id символа, где он вставляется в use

надо тебе через д3 точку поправить. одну из 47 тысяч

ага, ну вот это подход из svg-sprite-loader, над которым я голову ломаю +) а вы понимаете, зачем нужен спрайт? или у вас есть обращения из CSS?

а, но у вас он физически инлайнится в HTML?

ага, ну вот это подход из svg-sprite-loader, над которым я голову ломаю +) а вы понимаете, зачем нужен спрайт? или у вас есть обращения из CSS?

ясно, но это вроде значит, что спрайт не попадет в кеш (а у svg-sprite-loader попадет, потому что он физически сидит в js-бандле и вставляется в дом уже при загрузке)

Nuxt.config.js добавил render: {resourceHints: False }

ну типа если юзер часто ходит на сайт

ок, ну не суть +) короче, если я не хочу юзать svg в качестве фона из css, на спрайты можно забить и вставлять тупо в хтмл целиковый svg?

не понял )

Такой вопрос: у меня модули, которые я мёржу в один стор, как из одного модуля получить доступ к геттерам другого модуля?

никакой стейт не будет нужен

ок, тогда последний вопрос =) у svg vue loader есть вот такая строчка: https://github.com/visualfanatic/vue-svg-loader/blob/4921cf1069f59db5a0a30b169ee001db72bd1755/index.js#L22 это типа содержимое svg подается на вход vue-компайлеру, а он возвращает render-функцию. меня почему-то этот момент смутил - оно точно затормозит сборку, и, скорее всего, затормозит рантайм (потому что при рендере компонента весь svg будет собираться обратно из vnode-ов) мне захотелось тупо зафигачить содержимое через innerHTML, что я на коленке и сделал =) вопрос: есть ли у моего решения недостатки?

ок, тогда последний вопрос =) у svg vue loader есть вот такая строчка: https://github.com/visualfanatic/vue-svg-loader/blob/4921cf1069f59db5a0a30b169ee001db72bd1755/index.js#L22 это типа содержимое svg подается на вход vue-компайлеру, а он возвращает render-функцию. меня почему-то этот момент смутил - оно точно затормозит сборку, и, скорее всего, затормозит рантайм (потому что при рендере компонента весь svg будет собираться обратно из vnode-ов) мне захотелось тупо зафигачить содержимое через innerHTML, что я на коленке и сделал =) вопрос: есть ли у моего решения недостатки?

ну на первый взгляд у твоего решения нет svgo optimizer'a

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

ну там теоретически может возникнуть конфликт, если в спецуху свг добавят теги <component> и <template> ?

или например если где-то в проекте кто-то добрый зарегает глобально компонент <g> или <path> ?