Ng-lazyload-image: Lazyload и srcset

Привет,

К сожалению, эта библиотека не поддерживает srcset, но должна его поддерживать. Это довольно важная особенность.

С учетом сказанного, поддерживать его непросто, поскольку нам нужно анализировать и понимать srcset так же, как это делает браузер.

Опция 1:

Мы рассматриваем srcset как особый случай и не пытаемся загрузить изображение в фоновом режиме, а вместо этого просто устанавливаем srcset когда изображение является окном просмотра:
Допустим, у нас есть следующий тег html:
<img [defaultImage]="defaultImage" lazyLoad="small.jpg 300w, large.jpg 500w">
Когда изображение находится в области просмотра, мы смотрим на srcset и обнаруживаем, что lazyLoad содержит srcset -строку, и просто преобразуем тег в:
<img srcset="small.jpg 300w, large.jpg 500w">

Pro:
Простая реализация
Против:
Пользователь никогда не увидит defaultImage.
Мы никогда не сможем справиться с сетевой ошибкой при загрузке изображения.

Вариант 2:

Мы анализируем srcset и выбираем лучший вариант (как мы думаем, что браузер должен был это сделать).
Допустим, у нас есть следующий тег html:
<img [defaultImage]="defaultImage" lazyLoad="small.jpg 300w, large.jpg 500w">
Мы обнаруживаем, что lazyLoad содержит srcset и анализируем строку примерно так:
[ { url: 'small.jpg', width: 300 }, { url: 'large.jpg', width: 500 } ]
Мы сравниваем его с шириной браузера (и соотношением пикселей устройства ) и выбираем лучшее изображение. Загружает изображение в фоновом режиме, и когда оно загружается, мы просто устанавливаем srcset и, поскольку изображение находится в кеше, оно будет загружено немедленно.

Pro:
Изображение будет загружено лениво 🎉
Пользователь увидит изображение по умолчанию.
Мы можем обрабатывать сетевые ошибки (должны ли мы попытаться загрузить какое-то другое изображение из srcset или просто загрузить изображение ошибки ?).
Против:
Всегда сложно разобрать строку так, как это должен был сделать браузер; мы, вероятно, упустим какой-нибудь крайний вариант использования.
Насколько я понимаю, браузер всегда будет использовать самое большое изображение, если оно хранится в кеше. Поскольку у нас нет возможности узнать, было ли уже загружено изображение, мы должны загрузить наиболее подходящее изображение (но самое большое изображение будет показано после того, как мы установим srcset ). например, допустим, у нас есть следующий srcset small.jpg 300w, large.jpg 500w и экран меньше 500 пикселей, но large.jpg уже загружен. Насколько я понимаю, браузер должен был пикетировать large.jpg поскольку он находится в кеше, но поскольку мы не знаем, что загрузим small.jpg и когда он будет загружен, мы установим srcset и браузер выберет large.jpg (однако я могу ошибаться). т.е. мы без надобности загрузили изображение.

Заключение:

Я думаю, что вариант 2 выполним (не должен быть слишком сложным), и я думаю, что мы должны это сделать. Мое время, правда, сейчас довольно ограничено, но я с радостью принимаю пиар :)

Здравствуйте @tjoskar , спасибо за быстрый ответ, я согласен с вами, что второй вариант может быть осуществимым. У меня также нет слишком много времени прямо сейчас, так как я нахожусь под некоторыми крайними сроками, но как только у меня будет больше времени, я хотел бы внести свой вклад в эту функцию, особенно учитывая, что я уже расширил поведение библиотеки для поддержки ленивых загрузка для тега изображения со свойством hlink.href :)

Или проигнорируйте параметр srcset браузера по умолчанию и реализуйте его как свой собственный процесс принятия решений и настройте его со временем, чтобы сделать его как можно лучше :)

Спецификация

Вам нужно только придерживаться спецификации, и я считаю, что спецификация довольно проста.

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

Я отправил запрос на перенос (№ 231), который добавляет поддержку адаптивного изображения к обоим \ Я жду каких-либо комментариев.

Это включено в 3.4.0 . Спасибо @sapierens