Views Slideshow Cycle doesn't re-initialize properly after an AJAX content update

Question

I have a Views Slideshow on my site that works perfectly until I try to reload only part of the page (containing the slideshow among other stuff) via AJAX (using Ajax links API module). The content itself is reloaded properly but:

If the new content contains different blocks than the old content, I'm getting the following error:

Uncaught TypeError: Cannot set property 'targetId' of undefined

It's the following lines that cause the error:

var fullId = '#' + $(this).attr('id');
var settings = drupalSettings.viewsSlideshowCycle[fullId];
settings.targetId = '#' + $(fullId + " :first").attr('id');

An inspection of drupalSettings.viewsSlideshowCycle in Chrome DevTools shows that it doesn't contain the current block id ($(this).attr('id')) but contains the old block id, already gone, so drupalSettings.viewsSlideshowCycle[fullId] returns null. In other words, the AJAX-driven content update doesn't seem to update drupalSettings - is it supposed to? I checked the AJAX response and it contains correct settings but for some reason the script doesn't see them and uses the original settings that came with the initial page load.

If the new content has the same structure as the old one (same block name for the Views Slideshow) then I don't get the error and the slideshow sort of works but the slide counter shows funny numbers in funny sequence (like 6 of 2, then 2 of 2) and at funny times (not when the slides change but when they stand still too). It looks like there are two scripts running simultaneously interfering with each other.

I would expect the behaviors mechanism to somehow kill the old scripts and settings and replace them with new ones upon processing an AJAX response but it doesn't seem to happen and I can't find any documentation on this particular aspect.

Sorry for a possibly fuzzy description (must admit I don't know the inner workings of AJAX all too well) - will be happy to provide more info if needed!

Answer 1

I would expect the behaviors mechanism to somehow kill the old scripts and settings and replace them with new ones upon processing an AJAX response but it doesn't seem to happen and I can't find any documentation on this particular aspect.

The D7 Managing Javascript docs explains this well:

Drupal.behaviors will often be called multiple times on a page. For example, every time a form performs some Ajax operation, all Drupal behaviors will be executed again after page load, in order to attach any relevant JavaScript to the newly loaded elements. This can have the undesired affect of applying JavaScript to elements each time Drupal behaviors are executed, resulting in the same code being applied multiple times. To ensure that the JavaScript is applied only once, we can use the jQuery $.once() function. This function will ensure that the code inside the function is not executed if it has already been executed for the given element.

The D8 Javascript Overview docs tells you how to use $.once() in D8.

---

If your code is not recognizing the ajaxed in divs, then you need to attach the behaviors to the ajax wrapper, with drupal.attachBehaviors($('.ajax-wrapper'));

Ex:

$.ajax({
    url: '/some/url',
    type: 'GET',
    success: function (data) {
        var result = $(data).find('.some-wrapper').html();
        $('.ajax-wrapper').html(result);
        Drupal.attachBehaviors($('.ajax-wrapper'));

    }
});

Answer 2

This is what I wound up doing:

Issue #1 (Uncaught TypeError): Added the following code to the Ajax links API ajaxAfter function right after pasting the AJAXed content into DOM:

$.extend(true, drupalSettings, JSON.parse($(selector).find("script[data-drupal-selector='drupal-settings-json']").html()));

This code should have probably been there from the start but who knows - it can break something for someone else.

Issue #2 (counter acting funny): Added the following code to the Ajax links API ajaxBefore function right before wiping the old content:

$('#views_slideshow_cycle_teaser_section_photo_slideshow-block_1').cycle('destroy');

As opposed to #1 this is a horrible site-specific kludge but will work for me until I find a more elegant and more generic solution.