"Calling set on destroyed object"

[rhengeveld]

Note that the InfinityModel is used inside a component.
Very similar to #145, it is however still possible to trigger in the _loadNextPageof the route mixin.

Triggering lines:

• https://github.com/hhff/ember-infinity/blob/master/addon/mixins/route.js#L328
  (via https://github.com/hhff/ember-infinity/blob/master/addon/mixins/route.js#L253)
• https://github.com/hhff/ember-infinity/blob/master/addon/mixins/route.js#L258
  (when I bypass the above trigger)

What seems to happen is that by the time the _requestNextPage finishes (due to slow response), the user has navigated away and the corresponding Infinity component has been destroyed.

I guess I have to reopen and override _loadNextPage to work around this problem.

[hhff]

Hi @rhengeveld ! I'm currently working on a "modularization" of Ember Infinity that should help with this issue.

Out of curiosity - are you using closure actions? something like action=(route-action 'infinityLoad' model.infinityModel)

[rhengeveld]

Hello @hhff. Thanks for the swift response! This modularisation intrigues me :)

I use closure actions and I used to with Ember Infinity, but in this instance the infinity-loader is used in conjunction with a component (sidebar menu).

{{infinity-loader infinityModel=calendarItems scrollable='#scrollable-menu-calendar' triggerOffset=20}}

---

I currently use this ugly (!) 😞 construction as a workaround. _onNextInfinityPage is an earlier addition to allow adding properties to the loaded items. (Much) more elegant suggestions are welcome.

    InfinityRoute.reopen({
      _loadNextPage() {
        this.set('_loadingMore', true);

        return new Ember.RSVP.Promise((resolve, reject) => {
          this._requestNextPage()
            .then((newObjects) => {
              if (!(this.isDestroying || this.isDestroyed)) {
                this._onNextInfinityPage(newObjects);
                this._nextPageLoaded(newObjects);
                return resolve(newObjects);
              }
              reject();
            })
            .finally(() => {
              if (!(this.isDestroying || this.isDestroyed)) {
                this.set('_loadingMore', false);
              }
            });
        });
      },

      _onNextInfinityPage() {}
    });

Wrapped in a Promise to prevent the then part from executing in this menu component.

      // modelPath for the load-more, this.set for setting initial state

      this.infinityModel('calendaritem', {
        startingPage: 1,
        perPage: itemsPerPage,
        modelPath: 'calendarItems'
      }).then(infinityModel => this.set('calendarItems', infinityModel));

I think that's all of the relevant code involved.

[hhff]

Oh - are you using the InfinityRoute mixin directly in a component? ie

Component.extend(InfinityRoute, {
   // ...snip
})

If so - that's an Ember anti-pattern that we don't support. Components should rarely own data. That's what routes are for! Components just take inputs, and display them, or trigger route / controller / service actions.

[rhengeveld]

Sorry, initially missed the Github update e-mail.

Yes, I had (kind of) mentioned that it's used in a component :)

... and the corresponding Infinity component has been destroyed

Thanks for mentioning it's an Ember anti-pattern. I hope to get around to changing this ... eventually.
In the meantime I've worked around it, so I'll close the issue and let this serve as a historical warning for those using Ember Infinity in a component 😉