Ability to trigger gatsby-image visibility #16678
Replies: 2 comments
-
@sidharthachatterjee maybe it's something you missed in your eager/lazy implementation, but if an image starts with visibility="lazy", and then visibility updates to "eager", the image does not become visible (it will actually only load eagerly on chrome). Maybe a low hanging fruit would be to trigger image visibility if this lazy->eager transition is detected on updates |
Beta Was this translation helpful? Give feedback.
-
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing! Thanks for being a part of the Gatsby community! 💪💜 |
Beta Was this translation helpful? Give feedback.
-
Summary
Currently, once a gatsby-image is rendered as non-critical, there's no way force it to become visible.
Motivation
I want to put gatsby images inside a slider, and force visibility of gatsby-images around current slide, so that the fade in animation does not kick in. The intersection observer does not work so well for that usecase in my app.
Here is some pseudo code to better illustrate:
When critical or loading prop changes, it does not trigger visible=true on images around current slide, which leads to a slide transitioning from left to center + transitioning its visibility at the same time, leading to a weird visual effect. User would rather expect the slides around to be loaded and just have a translateX animation to happen, but he also get the traced SVG/blur/background => visible animation at the same time. Nobody does that kind of anim imho.
I would like the ability to trigger image visibility manually. Weither it's from an imperative method api, or preferable a simple props change, like "forceVisibility" or something?
Currently gatsby-image does not implement componentDidUpdate, which leads to changing props like "critical" having no effect (which I know is deprecated, while it would actually be useful).
Related note
I understand there's a new native lazy image loading api that came to chrome, and also seen the closed PRs about unability to specific custom IntersectionObserver root margins.
The thing is, saying that the current logic is going to be 100% replaced by browser native image lazy loading is not true to me. It's like saying web components will replace React. There's space for both. Native platform progress is good but JS apis on top of strong primitives will always offer more. Will native APIs allow traced SVGs and decent transition from placeholder to real image? How long until all browsers implement those behaviors anyway?
I suggest the Gatsby team to consider that Gatsby users will want more than what native apis will offer. I don't see in the future why I would like to enable those native apis while current gatsby-image provides me a better experience. So please, don't deprecate all the gaysby-image features in favor of native behavior, that would be a regression for many users.
Beta Was this translation helpful? Give feedback.
All reactions