Delay between last item being reached and lastReached being called

[kturney]

seems very similar to https://github.com/html-next/vertical-collection/issues/31

modifying https://github.com/html-next/vertical-collection/blob/5029016c6775bc2d59c4fb0090b9f48297affadf/addon/components/vertical-collection/component.js#L169

to

  _scheduleSendAction(action, index) {
    console.log('_scheduleSendAction');
    this._scheduledActions.push([action, index]);

    if (this._nextSendActions === null) {
      this._nextSendActions = setTimeout(() => {
        console.log('_scheduleSendAction setTimeout');
        this._nextSendActions = null;

        run(() => {
          console.log('_scheduleSendAction setTimeout run');
          const items = this.get('items');
          const keyPath = this.get('key');

          this._scheduledActions.forEach(([action, index]) => {
            const item = objectAt(items, index);
            const key = keyForItem(item, keyPath, index);

            this.sendAction(action, item, index, key);
          });
          this._scheduledActions.length = 0;
        });
      });
    }
  },

yields logs

18:25:39.367 component.js:160 _scheduleSendAction
18:25:42.668 component.js:165 _scheduleSendAction setTimeout
18:25:42.669 component.js:169 _scheduleSendAction setTimeout run

and

18:26:17.488 component.js:160 _scheduleSendAction
18:26:20.660 component.js:165 _scheduleSendAction setTimeout
18:26:20.660 component.js:169 _scheduleSendAction setTimeout run

so a 3ish second delay between detecting the last reached and sending the action

/editing to note that these logs are from Chrome

[kturney]

also like https://github.com/html-next/vertical-collection/issues/31 Firefox seems to work fine

logs from same in Firefox

18:42:35.453 _scheduleSendAction  vendor.js:177297:7
18:42:35.463 _scheduleSendAction setTimeout  vendor.js:177302:11
18:42:35.464 _scheduleSendAction setTimeout run  vendor.js:177306:13

and

18:43:04.202 _scheduleSendAction  vendor.js:177297:7
18:43:04.233 _scheduleSendAction setTimeout  vendor.js:177302:11
18:43:04.238 _scheduleSendAction setTimeout run

[pzuraq]

Yeah, the main issue here is Chrome is throttling us when we attempt to schedule in RAF/scroll events, which unfortunately we don't have much control over 😕 we have a few ideas for shifting things up with the way we're scheduling work, I'm planning on trying to experiment with it sometime after EmberConf

[runspired]

@pzuraq @kturney I spent some time investigating some specialized scheduling guarantees to help us here and have come up with a solution. While at EmberConf I'll try to get some upgraded scheduling landed.

[g-cassie]

I think we are seeing an issue related to this. It's difficult to recreate because of the asynchrony. Here's the exception we get:

Error: Assertion Failed: Cannot call get with 'id' on an undefined object.
    at Object.assert (ember.debug.js:13696)
    at Object.get (ember.debug.js:25088)
    at keyForItem (-private.js:32)
    at component.js:176
    at Array.forEach (<anonymous>)
    at component.js:171
    at Backburner.run (ember.debug.js:9240)
    at Object.run$1 [as run] (ember.debug.js:26853)
    at component.js:167

The action is firstVisibleChanged

The situation is this:

• we are displaying filteredList in a vertical-collection
• filteredList is filtered based on searchTerm
• There is a search term input component which throttles the updating of searchTerm like this:

Ember.run.throttle(this, function(){
   this.attrs.updateSearchTerm(this.get('searchText').toLowerCase());
}, 500, false);

So I think this is what happens:

• user starts typing 'my search' after typing 'my sea' the throttled function triggers
• vertical-collection updates and schedules firstVisibleChanged
• the throttled function triggers again with 'my search' and the list filters down to zero objects
• the scheduled sendAction triggers but now the list is empty so var item = (0, _private.objectAt)(items, index); === undefined which causes the exception above

Let me know if you want a separate issue for this, but if you are refactoring scheduling anyways then maybe you can just add some conditionals to prevent this exception?

[pzuraq]

Seems like we should be cancelling the actions sent when we reset items, if the state has changed then the actions are invalid anyways