[PROPOSAL] Strategy implementation

[thom4parisot]

The intention

Imager replaces a DIV (or container) tag by a placeholder image prior to its width URL calculation. The logic of Imager might pleased everybody but users have different contraints:

• their CMS is too complicated to hack
• for design reasons, you might want to add the placeholder image inside the container

The proposal

The user can decide how the responsive image is treated without altering the internals of Imager.

Here are the various options to implement that.

One buildfile per strategy

• imager-core.js + imager-strategy-replacer.js = imager.js
• imager-core.js + imager-strategy-container.js = imager-container.js
• function Imager() + (Imager.prototype.getPlaceholder + Imager.prototype.processPlaceholder()) = imager-custom.js

<script src="imager.js">
<script>
var imgr = new Imager();
</script>

or

<script src="imager-container.js">
<script>
var imgr = new Imager();
</script>

Pros:

• Nothing to configure, just dropping in the good file

Cons:

• would not be possible to mix strategies together within a same page
• might be more complicated for someone wanting to bake his own strategy

DIY

<script src="imager.js">
<script src="imager-strategy-replacer.js">
<script src="imager-strategy-container.js">
<script>
// by default it will look for the `replacer` one
var imgr = new Imager();

// or we can specify which strategy we want to use
var imgr_sidebar = new Imager({ strategy: 'container' });
</script>

Pros:

• Freedom to make Imager working the exact way you want
• Ability to use different replacements within a same page

Cons:

• May be slightly less intuitive than the other proposal

[Integralist]

@oncletom OK I'm starting to see the benefit of the Strategy pattern now and how this could be a useful addition. My only concern is how can we incorporate this (e.g. being able to use both types of strategies on the same page) but have just one script file?

Could we develop a Grunt task that creates a single file based on the user provided requirements (e.g. similar to David Mark's dynamic API which he uses with his custom http://www.cinsoft.net/mylib-builder.asp tool)

[thom4parisot]

Yep. It will rather be tight to how someone's declare the way he wants its pictures to be replaced:

• by passing a string (which means the strategy function has to be living in a defined place, like Imager.strategies)
• by passing a function (which means it could be easy to use with AMD).

The latest example could look like this:

// In an AMD world
require(['imager', 'imager/strategy/replacer', 'my/cms/strategy'], function(Imager, ReplacerStrategy, CMSStrategy){
  var imgr = new Imager('.delayed-image-load', { strategy: ReplacerStrategy });
  var cmsImgr = new Imager('.delayed-image-load', { strategy: CMSStrategy });
});

In a non-AMD world it would be basically the same, except we rely on global objects:

<script src="imager.js"></script>
<script src="imager-strategy-replacer.js"></script>
<script src="/cms/static/js/imager-strategy.js"></script>
<script>
  var imgr = new Imager('.delayed-image-load', { strategy: ImagerReplacerStrategy });
  var cmsImgr = new Imager('.delayed-image-load', { strategy: CMSImagerStrategy });
</script>

[Integralist]

Yeah it'll be awkward to have a build script that handles everything in an efficient way.

Just didn't want the performance overhead of an additional blocking script in the page. Performance suffers for the user to be able to implement their own Strategy.

Suggestion?

What I would suggest is that we have a single Imager.js file which by default handles the standard 'replacement' and also the 'container' strategy.

If the user has a page which utilises both strategies then the file can stay unchanged, but if their page needs only one strategy then we could have a simple Grunt build task that strips out the unused strategy.

That way we gain better performance. But we could implement a small amount of code to let the user load their own strategy file and use that instead.

Feels a bit of hassle doing it this way, but I'm really not comfortable about the extra blocking script in the page and would like to avoid it however possible. At least if the user passes in their own strategy then they've opted into a slightly less performant experience.

What do you think?