Ng-lazyload-image: Lazyload e srcset

Criado em 18 jul. 2017  ·  6Comentários  ·  Fonte: tjoskar/ng-lazyload-image

Olá, antes de mais nada, obrigado pelo seu trabalho, esta biblioteca é muito boa :)

Eu tenho uma pergunta, eu preciso implementar o carregamento lento em uma tag img com srcset. Estudei um pouco a biblioteca e me parece que srcset não é compatível, estou certo ou estou faltando alguma coisa?

Se for, você pode fornecer um exemplo com imagens de resolução diferente? (1x, 2x etc ...)

Muito obrigado por sua ajuda.

G.

help wanted

Todos 6 comentários

Oi,

Esta biblioteca infelizmente não suporta srcset, mas deveria suportá-lo. É um recurso muito importante.

Dito isso, não é muito fácil dar suporte, pois precisamos analisar e entender o srcset da mesma forma que o navegador.

Opção 1:

Tratamos srcset como um caso especial e não tentamos carregar a imagem no plano de fundo, mas apenas definimos srcset quando a imagem é a janela de visualização:
Digamos que temos a seguinte tag html:
<img [defaultImage]="defaultImage" lazyLoad="small.jpg 300w, large.jpg 500w">
Quando a imagem está na janela de visualização, observamos srcset e detectamos que lazyLoad contém uma srcset -string e apenas transformamos a tag em:
<img srcset="small.jpg 300w, large.jpg 500w">

Pró:
Implementação simples
Vigarista:
O usuário nunca verá "defaultImage".
Nunca podemos lidar com erros de rede ao carregar a imagem.

Opção 2:

Analisamos srcset e escolhemos a melhor opção (como pensamos que o navegador deveria ter feito).
Digamos que temos a seguinte tag html:
<img [defaultImage]="defaultImage" lazyLoad="small.jpg 300w, large.jpg 500w">
Detectamos que lazyLoad contém srcset e analisamos a string para algo como:
[ { url: 'small.jpg', width: 300 }, { url: 'large.jpg', width: 500 } ]
Nós a comparamos com a largura do navegador (e a proporção de pixels do dispositivo ) e escolhemos a melhor imagem. Carrega a imagem em segundo plano e quando é carregada apenas configuramos srcset e como a imagem está no cache, ela será carregada imediatamente.

Pró:
A imagem será carregada lentamente 🎉
O usuário verá a imagem padrão.
Podemos lidar com erros de rede (devemos tentar carregar alguma outra imagem de srcset ou devemos apenas carregar a imagem de erro ?).
Vigarista:
É sempre complicado analisar uma string da mesma maneira que o navegador deveria ter feito; provavelmente perderemos algum caso de uso extremo.
No meu entendimento, o navegador sempre usará a maior imagem se ela estiver armazenada no cache. Como não temos como saber se a imagem já foi carregada, temos que carregar a imagem mais bem ajustada (mas a imagem maior será mostrada após definirmos srcset ). por exemplo, digamos que temos o seguinte srcset small.jpg 300w, large.jpg 500w e a tela é menor que 500 px, mas large.jpg já está carregado. Pelo que entendi, o navegador deveria ter feito um piquete de large.jpg pois está no cache, mas como não sabemos se carregaremos small.jpg e quando for carregado, definiremos srcset e o navegador escolherá large.jpg (no entanto, posso estar errado). ou seja, carregamos uma imagem desnecessariamente.

Conclusão:

Acho que a opção 2 é viável (não deve ser muito difícil) e acho que devemos fazê-lo. No entanto, meu tempo é bastante limitado agora, mas eu aceito com prazer um PR :)

Olá @tjoskar , obrigado pela resposta rápida, concordo com você que a segunda opção poderia ser viável. Eu também não tenho muito tempo agora, pois estou com alguns prazos, mas assim que eu tiver mais tempo gostaria de contribuir com esse recurso, especialmente considerando que já estendi o comportamento da biblioteca para suportar preguiçoso carregando para a tag de imagem com propriedade hlink.href :)

Ou ignore a opção srcset do navegador padrão e implemente-a como seu próprio processo de tomada de decisão e ajuste-a com o tempo para torná-la da melhor maneira possível :)

Spec

Você só precisa seguir as especificações e acredito que as especificações sejam bastante diretas.

Mas, como você apontou, a implementação do navegador pode quebrar o que você deseja alcançar aqui, então acredito que deve ser contornado.

Enviei uma solicitação pull (# 231) que adiciona o suporte de imagem responsiva a ambos \ Estou aguardando qualquer entrada.

Isso está incluído em 3.4.0 . Obrigado @sapierens

Esta página foi útil?
0 / 5 - 0 avaliações