[Ember 2.10] Uncaught Error: infinite rendering invalidation detected

2.10 introduced Glimmer 2. Glimmer 2 introduced infinite rendering invalidation detection. Not entirely sure what that is, haven’t dug enough.

We have a master detail layout in our app, and the detail panel is what uses redux. We have it carved out as an addon.

When a user clicks the first item, none of the detail components exist yet. The detail panel slides in, the detail addon top level component is rendered with a handful of inputs, it makes a few server calls and renders all the things.

When a user clicks a second item, because the panel is already open, we have ~15ish components already bound to state and listening for updates. Clicking the second item passes in a bunch of inputs which are immediately dispatch({ type: INITIALIZE: payload: inputs}) into state.

There are enough components listening to some of the inputs that handleChange is called a good number of times. Too many. And then that error happens and things explode.

There are definitely steps I can take to reduce the number of components bound into state. I can also do some work to batch some actions so that synchronous actions that happen to have some overlapping state do not get updated multiple times.

But I can absolutely foresee, post improvements, still having this issue and being forced to destroy most all of the detail before I do anything with the new inputs so that components aren’t listening for changes. In some cases this might be the ideal thing to do anyway, and I expect that’ll be one of the best improvements I can make, but in some it isn’t ideal.

Not sure exactly what ember-redux can do differently to smooth this over, but I’d guess it’ll be something other folks run into at some point.

[dbashford]

Started from scratch and added things I learned yesterday one at a time. I quickly got to the few things causing me trouble.

When the errors were first seen, the stack trace took us back to handleChanges every time. As I started eliminating redux usage yesterday, another piece of code in our app became the problem. So it isn’t ember-redux alone, more of a larger run loop usage theme.

We are using ember-spaniel for viewport tracking. We have SpanielObserver being registered on didInsertElement for a component that can be rendered 10-30 times on the page. It was being registered like this

    const observer = new SpanielObserver(([entry]) => {
      run(() => {
        this.set('viewportEntered', entry.entering);
      });
    }, options);

That run is called immediately for any components within a certain distance of the viewport. At most 16 times all at once.

Changed it to:

    const observer = new SpanielObserver(([entry]) => {
      run.scheduleOnce('afterRender', () => {
        this.set('viewportEntered', entry.entering);
      });
    }, options);

And things got better. But the app didn’t fix until this was also changed in ember-redux:

this.unsubscribe = redux.subscribe(() => {
  run(() => this.handleChange());
});

turned into this:

this.unsubscribe = redux.subscribe(() => {
  run.next(() => this.handleChange());
});

Both of the above changes are necessary to get us to a happy place, at least without making more modifications. Still re-doing a lot of tweaking from yesterday to see if I can get to a point where the run.next isn’t required.

[toranb]

@dbashford wow this is an epic find -can’t believe we didn’t take more care w/ ember.run prior to this issue 😃 thanks for the hard work/debugging effort!!! Hoping to land a fix for this tomorrow