LQIP not updated when src changes

[simonihmig]

I see LQIP styles (bg image) only getting applied on the initial "use" of the component. In a scenario where the src argument changes dynamically, but the component instance is reused, it would properly load the new image, but its LQIP styles are not getting applied while loading.

I experienced this with the React component, but I believe all implementations are subject to this bug. All have an isLoaded reactive property (@tracked, useState, signal, rune, whatever they are called) that is initially false and gets set to true on load event. But this should be "scoped" to the src, or reset when src changes, as changing src would trigger a new load and a new load event.

It'll be a bit interesting how to best implement this in terms of proper reactivity patterns. Ideally, you would only have tracked state or derived state, this would be something in-between, as it is tracked state but also depends on other tracked state (src).

For Ember there is a @trackedReset decorator covering this use case, for other frameworks it remains to be seen what the proper APIs to use here are...

[simonihmig]

Have to reopen this. While #1662 did fix some reactivity issues, it didn't actually fix the use case from a user's perspective, as I found out later.

The problem is: the <img> element is basically a stateful element. Rendering a new element with src and LQIP styles is not the same as updating an existing image with the same attributes and styles. The latter happens when we dynamically update the src argument. The existing image element will continue to show the previously loaded image. But as the LQIP styles are all based on showing a background image/color, this only works when the actual image is not visible.

We could try to enforce a new <img> when changing src, or at least when LQIP options are present. I have a spike where this seems to be working with the react component, using the key prop. I am not sure though if this will work with all other frameworks. Some might require some awkward workarounds. For example Ember has the concept of key as well, but only for iterating over an array (the main use case for key) with {{#each}}, not for a single DOM element. 🤔

@wkillerud any thoughts by any chance?

[wkillerud]

The existing image element will continue to show the previously loaded image. But as the LQIP styles are all based on showing a background image/color, this only works when the actual image is not visible.

Ah, that's a good point.

Perhaps an option is to set the src attribute to null/undefined or the empty string first in this scenario, to maybe force a render of an empty <img>? For React using key is probably the way to go. Like Ember it's technically designed for lists, but it's a fairly common workaround in cases like this.

[simonihmig]

Perhaps an option is to set the src attribute to null/undefined or the empty string first in this scenario, to maybe force a render of an empty ?

Yeah, I have thought about this also. But it feels even more hacky than forcing to recreate the element. Like you would have to unset src, make sure the browser sees that (like delay further steps for after the framework has rerendered), then set src to the new image. Which is delaying the loading even for a tiny bit.

Even worse, Chrome seems to show the broken image icon when unsetting src, which then might flash up for a fraction of a second before the good src is set!?

[wkillerud]

Could it work to use document.createElement('img') in that case, and replace the existing <img> element with a new one? Not how these frameworks typically want you to do things, but at least we should get a new DOM element.

I suppose the next problem would be how to either force a re-render or set all the correct attributes on the new <img> element outside the typical render method.

[simonihmig]

Not how these frameworks typically want you to do things

Yes, and I would really really want to avoid that! 😅

Let's see how far we can get trying to use legit framework features only. Here's a first attempt at fixing the react component (I'm no react expert, so let me know what you think). I'll try to implement similar changes for the other frameworks next...