Adding "Processors"

[xat]

I've just looked through the reponse.js docs. It looks very promising and we consider using it in upcoming projects. However, I have a suggestion how the library could be even more flexible, here is a mockup of the basic idea:

The API gets a new method like addProcessor([name], [function])

Response.addProcessor('myprocessor', function(args, context) {
  // Here you have information about the breakpoint triggerd and the
  // arguments passed in

  context.$el.html('some custom content...'); // set the elemnts content
});

In the Markup you can then trigger this Processor with a syntax like:

<div data-min-width-481-myprocessor="some argument">
  default
</div>

The Processor 'myprocessor' gets triggerd and "some argument" passed in through 'args' and 'context' provides information about 'min-with', '481' and the element itself ($el). Instead of a pure string argument we could also think of an object as argument: data-min-width-481-myprocessor="{param1:'my argument',param2:'my argument2'}"

The benefit of this is that we get great flexibility. One real-world example how this could be used: Instead of putting all content inside attributes, pull the content from templates:

Response.addProcessor('template', function(args, context) {
  context.$el.html( $(args).html() );
});

<script id="desktop_content">
  This will be shown to desktop users. We can also use &quot;-Symbols here without
  to worry, since we are not inside an attribute.
</script>

<div data-min-width-980-template="#desktop_content">
  my default content
</div>

Content could also be loaded with ajax requests and so on...

Just some thoughts :-)

[ryanve]

@kat I like the overall idea. It'd probably be easiest to implement it by allowing a processor to be specified in the object you pass to Response.create. When do you think the processor should be called? Would it be called each time there's a breakpoint crossover or only once? Should the return of the processor be used to override the content? There already is a crossover event (see the readme) which would enable you to do some of that already.

Response.create({prop: 'width'}).crossover(function() {
    // do stuff each time viewport crosses width breakpoints
}, 'width');

[xat]

First of all thanks for the response and for making my text more readable :-)

I see Processors as independed of Response.create. Just an example why I think they should be independed:

<div

  <!--
    default behavour like it is already implemented
    Content is set directly within the attribute
    We could also call it the 'default processor'
  -->

  data-min-width-481="Some Content"

  <!--
    on this breakpoint the 'template'-Processor gets called
    instead of the default processor
    The 'template'-Processor decides which content should be shown
  -->

  data-min-width-980-template="#mytemplate"

  <!--
    The 'ajax'-Processor gets called.. content is loaded async
  -->

  data-min-width-1024-ajax="ajax-snippet.html"

>
  default content
</div>

As you see, if we dont bind Response.create directly to an processor we are totally free to choose which processor to use on a ceratain breakpoint crossover within the markup.

The processor would always be called on an breakpoint crossover which is postfixed with name of the processor, not just once.

No, I thought of the content being set inside the processor instead of being returned. Something like context.$el.html( 'new value' ); inside the processor. In this way we could also deal with async processors like the following example:

Response.addProcessor('ajax', function(args, context) {
  $.get(args, function(response) {
    context.$el.html(response);
  });
});

If I understand the readme correctly the already existing crossover event informs me if a breakpoint has been "crossoverd" but I'm not able to influence which content to load, or am I wrong?

Simon

[ryanve]

Internally it still needs to be tied to a breakpoint set so that it knows what breakpoints to listen for. I have a pretty good idea about how to go about adding the capabilty. It seems like it would be most flexible to have it so that the function is called at the time of the update on a per element basis and overrides the default update action. The function would get passed info about what breakpoint was crossed etc.