[PROPOSAL] Update API

[thom4parisot]

The intention

Once we have instantiated an Imager instance, there is no documented way to update the pool of responsive images it handles (unless a DIY of the cache property).

The proposal

Adding a prototype method to replace the actual pool of responsive images by another one.

Ideally, it will share the same behavior as the Constructor Explicit Argument API (cf. #22).

Note: not satisfied with the naming, as it should suggest updating the list of related responsive images and not updating their src attribute (cf. #25).

With jQuery:

var imgr = new Imager();

pubsub.on('news.updated', function(){
  imgr.updateElements($('#main .delayed-image-load'));
});

With DOM NodeList:

var imgr = new Imager();

pubsub.on('news.updated', function(){
  imgr.updateElements(document.querySelectorAll('#main .delayed-image-load'));
});

With string CSS selector:

var imgr = new Imager();

pubsub.on('news.updated', function(){
  imgr.updateElements('#main .delayed-image-load');
});

[Integralist]

@oncletom So this proposal is to allow a user to completely change the list of images that Imager is watching to a different set of images.

For example, given the following HTML...

<div id="a">
    <img class="delayed-image-load" src="1.jpg">
    <img class="delayed-image-load" src="2.jpg">
    <img class="delayed-image-load" src="3.jpg">
</div>
<div id="b">
    <img class="delayed-image-load" src="4.jpg">
    <img class="delayed-image-load" src="5.jpg">
    <img class="delayed-image-load" src="6.jpg">
</div>

...the user could initially instantiate an instance of Imager with new Imager('#a .delayed-image-load') but then decide later they no longer want those images to be updated on the resize event (i.e. orientation change) and so could then switch to a different container of images instead using imgr.updateElements('#b .delayed-image-load');

Is that what this proposal is suggesting? If so I'm not sure I see a real world use case for this need.

It seems like a nice idea but I just can't imagine why I'd ever use it?

Maybe you can give me a better real world example.

[thom4parisot]

Changing the selector is not indeed very relevant, it's like creating a new Imager instance. So no, it's not needed.

I was rather thinking if the content was updated dynamically. Some new images were added in the same container (AJAX request, a user adds a new comment containing an image, swipe navigation etc.).

If we use var imgr = new Imager('main .delayed-image-load'), using imgr.updateElements() could retarget the same selector and update its image collection. Using a liveNode list too. If a use passes a jQuery object, that's fine, we can retrieve the used selector. However if someone passes a querySelectorAll result, I wonder if we can access the CSS selector used to generate this NodeList.

[Integralist]

@oncletom OK that makes more sense.

So to clarify: the update API would be primarily used to update the tracked list of images (as both querySelectorAll and jQuery returns a static NodeList and not a live NodeList).

I don't believe we can access the CSS selector that querySelectorAll was passed. I tried to implement a hack around this which was along the lines of...

window.selectorResults = [];

document.querySelectorAllOriginal = document.querySelectorAll;

Element.prototype.querySelectorAll = function (selector) {
    console.log('over ridden version');
    var results = document.querySelectorAllOriginal(selector);
    window.selectorResults.push(results);
    return results;
}

...but that didn't work (I had tried overriding the document.prototype.querySelectorAll but you can't do that with Document).

If I directly used Element.prototype.querySelectorAll('body'); it was OK.

So yeah it does looks like we might need to use the update API you've proposed.

Unless we get the user to just pass in a selector String and then we do some trickery in the implementation to actually use 'delegation' on the body element instead (but that could get complicated - especially with multiple Imager instances created).