-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Lazy Load property on images #671
Conversation
…images before applying the lazy load property
Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖 Please select which version do you want to release:
And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.
|
Beep boop 🤖 I noticed you didn't make any changes at the
In order to keep track, I'll create an issue if you decide now is not a good time
|
Oi @arturmagalhaesjr , aqui entendo que esse comportamento deseja ser feito visando apenas a alteração do tipo de carregamento da Logo, que é carregada no Header, para qualquer outro componente entendo que funciona como esperado, dado que temos esse comportamento por padrão funcionando na store-image. Aqui, o que altera o comportamento do lazy load desse componente é porque setamos para todos os before e after, sempre esse carregamento de imagens lazy, ref No caso deles, por se tratar de algo bem específico e passível de ser customizado, em vez de alterarmos um comportamento que pode gerar diversos side effects em clientes, eles podem simplesmente remover o header customizado deles do before e adicionar como se fosse um bloco normal do tema que irá funcionar como esperado. Aqui a ideia é de fato carregarmos o header de forma lazy. Do nosso lado, podemos guiar um estudo pensando na alteração desse comportamento caso faça sentido em questões performáticas ou tornar ele de fato mais customizável com base em flags de performance do admin, e também guiar um estudo de melhorar a documentação sobre o carregamento de imagens e lazyload de algumas páginas |
@iago1501 nesse caso é um componente personalizado onde o cliente está colocando uma tag img padrão e o render ta sobrescrevendo a tag forçando o lazy. Está é a razão de quando a imagem já vir com o eager setado o render não vai atuar. Eu entendo a otimização para a performance, mas ignorar um setting que tá vindo já do componente não deveria ser corrigido? Ou o que devemos orientar ao parceiro a modificar para ele ter esse componente funcionando com o eager de propriedade? |
@arturmagalhaesjr , ignorar o que está setado no componente é o comportamento padrão específico nesse caso de uso deles (o header ser um before do store deles), por isso não se trata de um "problema que precisa ser corrigido", é apenas um padrão: "Todo after e before é tratado como lazy", independente se está com algo setado ou não. Por isso a recomendação aqui é caso eles queiram esse comportamento, seria tirar o header do before do tema deles, simples assim, é algo que por ser específico desse cliente, termos essa única demanda com uma solução, que é customizável e passível de alteração, que não precisamos fazer uma alteração geral, é o ideal |
@iago1501 beleza, vou encaminhar a thread pra eles ajustarem do lado deles então. Obrigado! |
Encerrando aqui o PR, em caso de sentir necessidade, pode abrir de novo |
Problem
The render runtime replaces the property whatever takes.
If the property already exists it will be skipped.
What does this PR do?
Added a conditional to check if the property already exist on images before applying the lazy load property
How to test it? *
https://artur--gs1usdev.myvtex.com/