Check for async function re-entry in JS

Question

Scenario:

We have a MutationObserver handler function handler.

In handler, we do some DOM manipulation that would trigger handler again. Conceptually, we would have a reentrant handler call. Except MutationObserver doesn't run in-thread, it will fire after the handler has already finished execution.

So, handler will trigger itself, but through the async queue, not in-thread. The JS debugger seems to know this, it will have itself as an async ancestor in the call stack (i.e. using Chrome).

In order to implement some efficient debouncing of events, we need to detect same; that is, if handler was called as a result of changes triggered by itself.

So how to do?

mutationObserver=new MutationObserver(handler);
mutationObserver.observe(window.document,{
    attributes:true,
    characterData:true,
    childList:true,
    subtree:true
});

var isHandling;
function handler(){
    console.log('handler');

    //  The test below won't work, as the re-entrant call 
    //  is placed out-of-sync, after isHandling has been reset
    if(isHandling){
        console.log('Re-entry!');
        //  Throttle/debounce and completely different handling logic
        return;
    }
    
    isHandling=true;
    
    //  Trigger a MutationObserver change
    setTimeout(function(){
        // The below condition should not be here, I added it just to not clog the 
        // console by avoiding first-level recursion: if we always set class=bar,
        // handler will trigger itself right here indefinitely. But this can be
        // avoided by disabling the MutationObserver while handling.
        if(document.getElementById('foo').getAttribute('class')!='bar'){
            document.getElementById('foo').setAttribute('class','bar');
        }
    },0);
    
    isHandling=false;
}


// NOTE: THE CODE BELOW IS IN THE OBSERVED CONTENT, I CANNOT CHANGE THE CODE BELOW DIRECTLY, THAT'S WHY I USE THE OBSERVER IN THE FIRST PLACE

//  Trigger a MutationObserver change
setTimeout(function(){
  document.getElementById('asd').setAttribute('class','something');
},0);

document.getElementById('foo').addEventListener('webkitTransitionEnd',animend);
document.getElementById('foo').addEventListener('mozTransitionEnd',animend);


function animend(){
    console.log('animend');
    this.setAttribute('class','bar-final');
}

#foo {
    width:0px;
    background:red;
    transition: all 1s;
    height:20px;
}
#foo.bar {
    width:100px;
    transition: width 1s;
}
#foo.bar-final {
    width:200px;
    background:green;
    transition:none;
}

<div id="foo" ontransitionend="animend"></div>
<div id="asd"></div>

Note Our use case comprises of 2 components here; one we will call contents which is any run-of-the-mill web app, with a lot of UI components and interface. And an overlay, which is the component observing the content for changes and possibly doing changes of its own.

A simple idea that is not enough is to just disable the MutationObserver while handling; or, assume every second call to handler as recursive; This does not work in the case illustrated above with the animationend event: the contents can have handlers which in turn can trigger async operations. The two most popular such issues are: onanimationend/oneventend, onscroll.

So the idea of detecting just direct (first-call) recursion is not enough, we need quite literally the equivalent of the call stack view in the debugger: a way to tell if a call (no matter how many async calls later) is a descendant of itself.

Thus, this question is not limited to just MutationObserver, as it necessarily involves a generic way to detect async calls descendent of themselves in the call tree. You can replace MutationObserver with any async event, really.

Explanation of the example above: in the example, the mutationobserver is triggering the bar animation on #foo whenever #foo is not .bar. However, the contents has an transitionend handler that sets #foo to .bar-final which triggers a vicious self-recursion chain. We would like to discard reacting to the #foo.bar-final change, by detecting that it's a consequence of our own action (starting the animation with #foo.bar).

Answer 1

One possible workaround for this could be to stop the mutation observer when one mutation is being fired

mutationObserver=new MutationObserver(handler);
mutationObserver.observe(window.document,{
    attributes:true,
    characterData:true,
    childList:true,
    subtree:true
});

//  Trigger a MutationObserver change
document.getElementById('foo').setAttribute('class','bar');
document.getElementById('foo').setAttribute('class','');

function handler(){
    console.log('Modification happend')

        mutationObserver.disconnect();
    //  Trigger a MutationObserver change
    document.getElementById('foo').setAttribute('class','bar');
    document.getElementById('foo').setAttribute('class','');

    mutationObserver.observe(window.document,{
    attributes:true,
    characterData:true,
    childList:true,
    subtree:true
});
}

See the JS fiddle

https://jsfiddle.net/tarunlalwani/8kf6t2oh/2/

Answer 2

The way I have done this in the past is to create semaphore to flag when an async function has already been called and is waiting execution on the event loop.

Here is a simple example for requestAnimationFrame

import raf from 'raf'
import State from './state'

let rafID

function delayedNotify () {
  rafID = null
  State.notify()
}

export default function rafUpdateBatcher () {
  if (rafID) return // prevent multiple request animation frame callbacks
  rafID = raf(delayedNotify)
}

In this case once you call the function, all future calls will be ignored until the first one is executed. Think of it as an async throttle function

For more complex scenarios then another solution might be this project https://github.com/zeit/async-sema

Answer 3

From what I gather from reading your comments, if action A triggered action B asynchronously, you want to be able to tell where action A was done (in general, not just in a mutation observer). I don't think there's any trick built into JavaScript to do this like it seems you're looking for, however, if you know exactly how your JavaScript works, you can track this information. Job queues in JavaScript are FIFO by definition, the event loop queue also works this way. That means you can store information corresponding to a specific event in an array at the same time you're doing the action which triggers the event, and be confident that they're getting processed in the same order as the array. Here's an example with your mutation observer.

const
    foo = document.getElementById('foo'),
    mutationQueue = [];

function handler(){
    console.log('handler');
    
    const isHandling = mutationQueue.shift();
    if(isHandling){
        console.log('Re-entry!');
        //  Throttle/debounce and completely different handling logic
        return;
    }
    
    setTimeout(()=> {
        foo.setAttribute('class','bar');
        foo.setAttribute('class','');
        mutationQueue.push(true);
    }, 1000 * Math.random());
}

mutationObserver=new MutationObserver(handler);
mutationObserver.observe(foo, {
    attributes:true,
    characterData:true,
    childList:true,
    subtree:true
});

function randomIntervals() {
    setTimeout(()=>{
        foo.setAttribute('class','bar');
        foo.setAttribute('class','');
        mutationQueue.push(false);
        randomIntervals();
    }, 1000 * Math.random())
}

randomIntervals();

<div id='foo'></div>

You have to make sure you add the appropriate value to the array at every point in your code that is going to trigger your async handler, or the entire thing will be messed up. I've never done this myself, I just thought of it for this question, but it seems pretty easy to do wrong. However, I fear this may be the only way to do what you want in general.