Comments 20
Мне кажется, что как раз производительность в данном случае будет играть большую роль, нежели какое-то удобство настройки иконок в проекте. Как никак +1 скрипт, который будет выполняться для каждой иконки против обычной отдачи статики nginx'ом и кэшированием самим браузером.
Ваш подход конечно интересный, но как мне кажется не очень жизнеспособный.
Ваш подход конечно интересный, но как мне кажется не очень жизнеспособный.
Вы правы. На php в таком виде решение выглядит нелепо.
Можно переконфигурировать так, чтобы nginx смотрел сначала есть ли файл в кэше, а уж потом при отсутствии оного вызывал какой-нибудь icon.php, который бы в свою очередь сгенерировал иконку и сохранил результат в кэш:
Как по мне, для маленькой проблемы довольно сложный процесс развертки. Стоит учесть, что фронтендом иногда занимаются специалисты, не соображающие в php или настройку nginx. Или, даже соображающие, но просто не хотящие разворачивать этот ад в каждом проекте.
На node.js решение выглядело бы интереснее. Держа шаблон svg-икноки в оперативной памяти, node выстреливала бы готовые файлы быстрее nginx, который каждый раз читает статику с диска; и плюс не нужно сохранять кэш, а в процессе разработки шаблона сайта (например, подборе цветов иконок, их толщин линий) кэш вообще не нужен. Оформить это как подключаемый middleware. Было бы интересно!
Можно переконфигурировать так, чтобы nginx смотрел сначала есть ли файл в кэше, а уж потом при отсутствии оного вызывал какой-нибудь icon.php, который бы в свою очередь сгенерировал иконку и сохранил результат в кэш:
<img src=”/icon/star-red-00ff000--green.svg”>Как по мне, для маленькой проблемы довольно сложный процесс развертки. Стоит учесть, что фронтендом иногда занимаются специалисты, не соображающие в php или настройку nginx. Или, даже соображающие, но просто не хотящие разворачивать этот ад в каждом проекте.
На node.js решение выглядело бы интереснее. Держа шаблон svg-икноки в оперативной памяти, node выстреливала бы готовые файлы быстрее nginx, который каждый раз читает статику с диска; и плюс не нужно сохранять кэш, а в процессе разработки шаблона сайта (например, подборе цветов иконок, их толщин линий) кэш вообще не нужен. Оформить это как подключаемый middleware. Было бы интересно!
Не для каждой иконки, а только тогда, когда нужно изменить цвет, хотя может быть так, что половина иконок именно будет работать через это. И да, это не очень круто, но если включить в дело Varnish + кеш браузера, то потери думаю, будут минимальными.
Понятное дело, что если все закэшировать, то и за производительностью можно не следить, но это же не совсем верный подход?
А как же спрайт символов? А как же стек?
При этом обоих этих подходах можно модифицировать цвета. + есть плагины для работы с этим через CLI или Gulp/Grunt/что-то еще.
При этом обоих этих подходах можно модифицировать цвета. + есть плагины для работы с этим через CLI или Gulp/Grunt/что-то еще.
Про спрайт символов могу сказать, а как же старые версии платформ, которые его не поддерживают? А про стек впервые слышу, спасибо.
По умолчанию не все поддерживают спрайт символов из внешнего файла (легко полифилится, svg4everybody), а в остальном нет проблем. Вот стек да, не везде поддерживается без полифилов, но я его добавил для примера, так как это будущее SVG.
Да вот еще добавлю, при сложных svg можно запутаться с назначением цветов, Как мне узнать в каком порядке цвета, если иконку делал не я?
эм, а смысл если можно:
1) Рано или поздно вставлять картинки-svg в shadow dom(в таком случае это будет ~аналогично 1 методу без недостатка "раздутие оригинального DOM"). Там, вообщем-то, даже аргументы будут
2) Взять ровно тот-же скрипт который будет искать определённые html-теги и напрямую их вставлять в нужные места, а всё остальное — с помощью CSS?
вообщем преимущества спорны. Очередной костыль в котором никто кроме автора не разберётся + среда разработки будет ругаться и выдавать, как минимум — варнинги.
+ автор, ты представляешь сколько из-за смены цвета картинки будет перерисована вся страница? Любое изменение css заставляет страницу отрендерится заново всю, потому что неизвестно какие элементы могли быть задеты.
1) Рано или поздно вставлять картинки-svg в shadow dom(в таком случае это будет ~аналогично 1 методу без недостатка "раздутие оригинального DOM"). Там, вообщем-то, даже аргументы будут
2) Взять ровно тот-же скрипт который будет искать определённые html-теги и напрямую их вставлять в нужные места, а всё остальное — с помощью CSS?
вообщем преимущества спорны. Очередной костыль в котором никто кроме автора не разберётся + среда разработки будет ругаться и выдавать, как минимум — варнинги.
+ автор, ты представляешь сколько из-за смены цвета картинки будет перерисована вся страница? Любое изменение css заставляет страницу отрендерится заново всю, потому что неизвестно какие элементы могли быть задеты.
Если вы в этом не видите смысла, наверное, оно не для вас.
Я не настаиваю, возможно моя реализация отстойна, она просто идет в бонус. Я просто предлагаю способ/метод/подход к решению проблемы.
Нет, я не представляю, сколько раз вся страница будет перерисована, потому что она этого делать не будет. Данный метод для браузера ничем не отличается от тех, что мы используем сейчас.
Да и вообще, вы вцепились в мою реализацию, но ведь статья не про него — главное метод.
Не могу найти связь с нашей темой, извините.
Очередной костыль в котором никто кроме автора не разберётся
Я не настаиваю, возможно моя реализация отстойна, она просто идет в бонус. Я просто предлагаю способ/метод/подход к решению проблемы.
сколько из-за смены цвета картинки будет перерисована вся страница?
Нет, я не представляю, сколько раз вся страница будет перерисована, потому что она этого делать не будет. Данный метод для браузера ничем не отличается от тех, что мы используем сейчас.
Да и вообще, вы вцепились в мою реализацию, но ведь статья не про него — главное метод.
1) Рано или поздно вставлять картинки-svg в shadow dom(в таком случае это будет ~аналогично 1 методу без недостатка "раздутие оригинального DOM"). Там, вообщем-то, даже аргументы будут
2) Взять ровно тот-же скрипт который будет искать определённые html-теги и напрямую их вставлять в нужные места, а всё остальное — с помощью CSS?
Не могу найти связь с нашей темой, извините.
Гм.
Шаг первый. Настраиваем сервер так, чтобы он существующие файлы отдавал напрямик, а при запросе несуществующих — отправлял запрос на нечто вроде image.php
или
Шаг 2.
В image.php понимаем, что нам надо, используем всю мощь разбора URL, формируем из шаблона SVG готовый SVG подстановкой параметров, кладем его в заранее определенную папочку на сервере и отдаем клиенту.
Шаг 3.
Кто-то приходит за картинкой второй раз. См. шаг 1.
Шаг первый. Настраиваем сервер так, чтобы он существующие файлы отдавал напрямик, а при запросе несуществующих — отправлял запрос на нечто вроде image.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*)$ image.php [QSA]или
location / {
try_files $uri $uri/ /image.php?$args;
}Шаг 2.
В image.php понимаем, что нам надо, используем всю мощь разбора URL, формируем из шаблона SVG готовый SVG подстановкой параметров, кладем его в заранее определенную папочку на сервере и отдаем клиенту.
Шаг 3.
Кто-то приходит за картинкой второй раз. См. шаг 1.
Ага, добавлю ссылку в конце статьи, спасибо.
Да не за что. Это совершенно стандартный и избитый способ формирования, например, миниатюр
src="bigpicture.w200.jpg"
=>
image.php?request=bigpicture.w200.jpg
ну а дальше уже любой PHP-шник вам накидает более-менее нормальный скриптик за 15 минут, если дадите ему четкие инструкции, что и куда нужно подставлять
src="bigpicture.w200.jpg"
=>
image.php?request=bigpicture.w200.jpg
ну а дальше уже любой PHP-шник вам накидает более-менее нормальный скриптик за 15 минут, если дадите ему четкие инструкции, что и куда нужно подставлять
Sign up to leave a comment.
Спойлер: Вставка SVG иконок одним единственным способом