Handle Ajax & client-side templating with response.js content?

[alanhogan]

I am using response.js with its data-* methods of specifying alternative content. It works well, but when I AJAX in content from the same templates, it is always shown in mobile.

Is there any way to hook in response.js during the ajax handling phase?

[ryanve]

@alanhogan Not yet but soon. Many people have asked me about AJAX capabilities on Twitter and #15 and #13. Not thinking about AJAX initially was an oversight on my part. It really ties into my original vision and makes tons of sense. I have a longer answer with some more details. Let me start another related thread that I can reference so that the my "longer answer" will make more sense. Hang on =]

[alanhogan]

Can’t wait. Let me know if you would like me to take a stab at a patch. If you have a plan for it, though, I’m sure that will be much better than anything I would contribute :)

[ryanve]

@alanhogan A necessary feature is to make it so that if someone loads AJAX content (by any means) they could call Response.create() w/o any args to re-scan the DOM for new elements that belong to breakpoint sets that were already defined. Possibly a boolean attribute like [data-response-active] could be used to detect whether the swapping was activated (and it could be used in CSS). Concurrently as #19 I want to better organize how the breakpoint data is stored so that it is easier access/update on the fly.

My idea for the hooks revolves around a new method called hook that I describe in dj » #1. It would give devs a way override/customize certain functionality, and could be applied in a lot of ways, for example like:

Response.hook('myset-update', function () {
   // `this` would be the current element containing the data- attrs
   // load ajax the first time and later just insert
});

The arguments supplied to hooks would be on a hook-by-hook basis. Depending on the purpose of the hook it would receive different args (or none at all). In an example like above we could pass it an object containing applicable breakpoint data or we could make sure that all applicable is stored in data- attributes on that element. Response already makes heavy use of data attributes. I think the latter might make it easier to document and debug.

[ryanve]

@alanhogan I'm hoping to get this in there soon but it'll probably be a couple weeks. A partial solution in the meantime is to call Response.create manually after templates have loaded rather than putting JSON on the body tag, but that'll only work once for each breakpoint set.

[alanhogan]

@ryanve That means that if multiple AJAX calls & renders occur, you cannot call Response.create each time, right?

[ryanve]

@alanhogan In 0.7- you can call Response.create multiple times but not for the exact same set. The prefix has to be different for each one. It activates for all matching elements currently on the page at the time it is called. A dirty solution would be to create different sets with the same info, except a different prefix for each. They could later be combined into one by setting the prefix to both, via a space-separated string, in which case they becomes aliases.

[ryanve]

@alanhogan I''ve been working rewriting the breakpoint API. I'm leaning towards a using a state attribute like "data-responsejs-active" to track whether an element is active. It would make it easy to activate/deactivate elements/sets.