question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Under-documented behaviour

See original GitHub issue

Hi, great plugin, been using it for ages, but on a specific use case right now, I need to know certain behaviours to solve a specific problem, but reading your documentation, you don’t say much about the internal mechanisms.

I’ve just experienced an issue, I’ve built a lazy-loading image Vue component for a specific use case, and I used imagesLoaded to detect when the image has loaded so that dimensions can be retrieved and manipulations can take place. I, when the load is triggered, pass the <img> element directly to imagesLoaded(el, callback). However, in a strange twist, the specific listeners on each <img> element fire when an image that’s inside the Image Library pop-up component within the app is loaded, even after the specific <img> passed to the imagesLoaded function has loaded. The images loaded inside the Image library popup are different variations of the same images with a different resolution (and different URLs). Perhaps it’s some odd Vue quirk, where it re-renders the components on the page when ImageLibrary component is shown and loads it’s own images. But it’s certain that the components are not destroyed and re-created when this happens, the imagesLoaded event simply fires again for the already loaded image, when a different image is loaded in a specific context.

It isn’t mentioned in the docs that you can pass the image element, the examples you give are all container elements, not individual <img> elements.

You did say, in the imagesLoaded function definition in your docs:

elem Element, NodeList, Array, or Selector String

But, it doesn’t say HTMLImageElement (even though it derives from Element).

I’m thinking about changing the implementation so that I have an external system notifying the <lazy-load> components when an image has loaded, and the <lazy-load> component can ask the external image manager to be told when the given image is loaded.

But, you don’t say if it knows new <img> elements are added, or if I’d have to remove and re-attach the event in the instance of new images being inserted, in order to detect them.

And on events, if I just do imagesLoaded(img, callback), does the event listener remove itself after load? In can infer that it doesn’t from the problem posed above, but the point is I had to infer it from observations.

It’d be really great of there was a nice, full explanation of the library’s behaviours and the specifics of how it works. I understand this takes a little bit of time, but it’s the point that most documentation falls over on. All of the examples are well and good, but examples (and much more) can be derived from a good explanation of behaviour, removing the need for all except the most rudimentary surface examples (for those who quickly Googled a solution and copied-and-pasted it).

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (1 by maintainers)

github_iconTop GitHub Comments

3reactions
desandrocommented, Feb 28, 2019

Let me first say thank you for thoughtful and consideration around imagesLoaded.

imagesLoaded was first created in 2011. Ages ago. Both browsers and JS development has advanced so much in that time that I often wonder if its utility is necessary. You mention you are already using Vue. In which case, you may likely be better served by creating an observable that looks directly at the <img> in question, rather than relying on old imagesLoaded.

But, you don’t say if it knows new <img> elements are added, or if I’d have to remove and re-attach the event in the instance of new images being inserted, in order to detect them

imagesLoaded does not trigger again after a new image is added to a parent element or when an image’s src is changed. And that’s because it was designed for a different time, before Virtual DOM frameworks ever existed.

1reaction
CaelanStewartcommented, Apr 29, 2019

@jordanboston - I had gotten imagesLoaded to work correctly before @.desandro had responded.

But I did have some odd issues, like sometimes the imagesLoaded event would fire, when the naturalWidth and naturalHeight were still 0, and I needed those properties.

I had another weird issue, described in an above post, too. Though I think this issue is related.

I think it was perhaps related to Vue magic going on underneath the hood - not sure, but seemed the logical deduction.

To fix, when imagesLoaded fired, I checked the value of natural[Width|Height] and if both were 0, I set an interval to check again until the values were truthy, tying up to 20 times. when they became truthy, I would fire my own abstracted ‘image loaded’ event, which then triggered code that used those properties.

It was a hacky fix, and 20 is probably overkill, but it worked and there was (still is) tons more to get done and it’s been working fine since.

I will likely revisit the component at some point.

Though, may I ask what other issues you had?

Read more comments on GitHub >

github_iconTop Results From Across the Web

More undocumented behavior and the people who rely on it
Here's one example of code I've seen (reconstructed) that relies on the output buffer being left unchanged: HKEY hk = hkFallback; RegOpenKeyEx(…
Read more >
Bad Habits to Kick : Relying on undocumented behavior
In my last post in this series, I talked about the common habit of creating an IDENTITY column on every single table.
Read more >
Undocumented feature - Wikipedia
An undocumented feature is an unintended or undocumented hardware operation, for example an undocumented instruction, or software feature found in computer ...
Read more >
The Hurricane Ike experience in Houston, Texas, USA
The barriers impeding precautionary behaviours by undocumented immigrants in emergencies: The Hurricane Ike experience in Houston, Texas, USA.
Read more >
Behaviour problems are underdocumented - The BMJ
Only 10 patients had no behaviour disturbance. The commonest problems identified were agitation (57 (55%) patients), nocturnal restlessness (51 ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found