"infinite rendering invalidation detected" -- option to increase the limit or disable the check entirely

In my ember-element-query addon I have this code:

    const _eqResizeHandler = () => {
      scheduleOnce('afterRender', this, this.eqUpdateSizes);
      next(this, this.eqUpdateSizes);
    };

    this.setProperties({_eqResizeHandler});
    window.addEventListener('resize', _eqResizeHandler, true);

It used to work flawlessly, but now resizing the browser tab causes the app to carsh with “infinite rendering invalidation detected”.

The problem happens when I’m the window for several seconds. The amount of time and movement required for the app to crash is arbitrary. Sometimes it crashes almost instantly, sometimes it takes like 10 seconds to crash.

I tried replacing next() with throttle() and increasing the timeout to unreasonably large values – and it was still crashing, so I’m not even sure that the crash is caused by this code.

These lines in ember-glimmer seem to be the cause:

let loops = 0;
function loopEnd(current, next) {
  for (let i = 0; i < renderers.length; i++) {
    if (!renderers[i]._isValid()) {
      if (loops > 10) {
        loops = 0;
        // TODO: do something better
        renderers[i].destroy();
        throw new Error('infinite rendering invalidation detected');
      }
      loops++;
      return backburner.join(null, K);
    }
  }
  loops = 0;
}

backburner.on('end', loopEnd);

I see three problems with this code:

1. It considers an “infinite loop” to appear when there are ten loops. Ten is quite a small number and in certain use cases it is obviously not enough. For example, JS max call stack is larger than 10’000.
2. When an “inifinite loop” is detected, this code chooses to crash the app. Why?! 😭 My addon used to work without issue and now this thing is crashing it for no reason.
3. This code is applied in a closure, so there’s no way to override it.

I’m sure there’s perfect reasoning why such a small magic number was chosen, but:

1. The user should be able to increase the number when his use case produces many loops.
2. The user should be able to opt out of arbitrary crashing.

[lolmaus]

OK, so I’ve completely rewritten my ember-element-query addon to ensure all updates are done efficiently.

With my current implementation, element query-driven components register in a tree-like structure. Only root EQ components react to a window resize event, then they tell their children to resize, and the resize event propagates recursively from parents to children.

This ensures no component has to update more than once, i. e. once for a window resize and then once after every of its EQ parents realigns.

But the issue still happens. When EQ components are nested deep enough, the infinite rendering invalidation detected error crashes the app on continuous resize.

I was able to work around the issue by wrapping event propagation from a parent to children into run.next, but this makes event propagation noticeable to naked eye: instead of all components realigning at once, you can see how they realign sequentially. This makes native Ember implementation of element queries worse than any generic implementation.

Commenting out the error throwing line (and renderer destroying line) makes it work correctly. It seems to have no practical purpose other than putting a spoke in the wheel. 😠

Please fix it.

[pixelhandler]

@dballona thanks for the comment on using query.

@lolmaus I’m curious if you still have this issue?