Is there a technique to change images in LiveView without flashing that preferably does not involve js or the browser downloading the images ahead of time (i.e. more than a few seconds)? This is a hard business requirement. Unfortunately based on my understanding of LiveView I will have to relent and use a js hook for this.
There will probably be techniques around this, but I think the JS hook would probably end up being the most straightforward and fault tolerant.
It sounds like you’re aware but for other readers: the core problem is that the DOM doesn’t know about the URL so it can’t fetch it until it first sees the replacing of the src attribute on the img element. Any trick you take to get that URL in the DOM before switching the src will reduce the flash but JS is the way only way to ensure the image is actually loaded before taking another action.
e.g
var img=new Image();
img.src=url;
img.onload = callback; // callback places url in DOM.
I’m thinking off the top of my head here without testing but…
…a possible working could be having a list of images rather than one per item you want to display on the page. You always render the first image in the list normally. When a new images comes in, append to the list, and add an img element to the DOM (invisible but not display: none; otherwise it won’t download) without taking the original one away.
Then get the LiveComponent to tick after say 5s and remove the first element from the list, “promoting” your next image URL into the one which actually gets displayed. While the 5s window would give the image time to download it, it would not guarantee it like the JavaScript version would, obviously though you could play with the time window. You’d need CSS to ensure the images were laid on top of each other, and you could also add CSS transitions to transition between them, there are some examples of that here.
Writing that out I feels like I’ve invented frankenstein, I have no idea if that would actually work or be worth it.
Good luck, let us know.
5 Likes
Another thing I didn’t mention is that I assumed you were dealing with bitmaps…
If you’re not, or can otherwise get away with using SVGs, then you can largely avoid this problem by inlining them. I’ve used this method before and it worked very well.
Thanks for writing this up! It helps clarify my thinking. Funnily enough I’m actually using bitmap images inside SVG. So I can’t easily embed them inline, although I suppose I still could, but I’m not sure the larger payload size would be worth it, but I guess it depends on the size of the images (which I’m still figuring out).
I wonder if it would make sense to build support for this into Phoenix LiveView itself, since that could make this all transparent to the developer.
1 Like
Interesting. Yeah, given its the download size which is the problem I don’t think inlining them would have a benefit there.
As for building it in, I’m not quite sure where the line between framework/user space is for LiveView, so it might be worth an ask.
If you already know what images you will be using, you might introduce them somewhere else in the page, thereby allowing the browser to fetch them already, possibly.
