loadMoreAction fires prematurely

[daniel-de-wit]

In my app I have many scrollable divs nested. This causes the loadMoreAction to fire prematurely from the component. Even when defining the scrollable attribute on the component.

I lack experience to really test en provide a working solution for everyone. By changing the way the offset is calculated when position is other than relative fixed my issue.

For relative ( original ):

var selfOffset  = this.$().offset().top;
var scrollableBottom = scrollable.height() + scrollable.scrollTop();


For fixed / absolute:

var selfOffset  = this.$().position().top;
var scrollableBottom = scrollable.height();

ember-infinity/addon/components/infinity-loader.js
Original:

_checkIfInView() {
  var selfOffset       = this.$().offset().top;
  var scrollable       = this.get("scrollable");
  var scrollableBottom = scrollable.height() + scrollable.scrollTop();

  var inView = selfOffset < scrollableBottom;

  if (inView && !this.get('developmentMode')) {
    this.sendAction('loadMoreAction');
  }
},

Edited ( works for me ):

_checkIfInView() {

  var scrollable = this.get("scrollable");
  var selfOffset;

  var scrollableBottom;



  if(scrollable.css('position') == 'relative') {

    selfOffset       = this.$().offset().top;

    scrollableBottom = scrollable.height() + scrollable.scrollTop();

  } else {

    selfOffset = this.$().position().top;

    scrollableBottom = scrollable.height();

  }



  var inView = selfOffset < scrollableBottom;



  if (inView && !this.get('developmentMode')) {

    this.sendAction('loadMoreAction');

  }

},

[hhff]

Inneresting. I think catering for every use case is outside of the scope of this library. However I think maybe we should make this hook public, so that people who want to control how this check works can easily override it.

@daniel-de-wit would u be down to submit a PR to make this public, and document your use case in the README?

[daniel-de-wit]

Thanks for your reply, I was on vacation so didn't see your message..

I believe there must be a proper way we can detect if the component is on screen. There are some jQuery plugins that work with nested scrollable divs, I think. Maybe I can extract a good solution for every use case since we just want it to fire when visible to the user on screen.

I definitely like your idea of making the hook public.

It might take me a little while to fix this as I have never actually commited something to an open-source project. But I will try to do it :)

Thanks again for making this wonderfull addon 👍

[hhff]

I wonder if we can use this somehow?
https://github.com/poteto/ember-in-viewport-demo

On Tue, 1 Sep 2015 at 15:50 Daniel de Wit [email protected] wrote:

Thanks for your reply, I was on vacation so didn't see your message..

I believe there must be a proper way we can detect if the component is on
screen. There are some jQuery plugins that work with nested scrollable
divs, I think. Maybe I can extract a good solution for every use case since
we just want it to fire when visible to the user on screen.

I definitely like your idea of making the hook public.

It might take me a little while to fix this as I have never actually
commited something to an open-source project. But I will try to do it :)

Thanks again for making this wonderfull addon [image: 👍]

—
Reply to this email directly or view it on GitHub
#82 (comment).

[hhff]

Sorry i mean this: https://github.com/dockyard/ember-in-viewport

[hhff]

Yeah! We totally can...

wanna have a go at it? I can help with the OSS stuff 👍

[daniel-de-wit]

Yes sounds like a fun challenge ;)

I wonder if the ember-in-viewport supports nested scrollable divs. I'll go fiddle with it.
I'll keep you posted.

[hhff]

awesome @daniel-de-wit !!!

[ghost]

Totally awesome, I noticed the premature loading behaviour as well but this way the user never gets to see the loading message. If this is implemented, we should also look into supporting an offset in order to maintain such behaviour.

[hhff]

pretty sure ember-in-viewport supports offsets out of the box 👍

[hhff]

jah it does

export default Ember.Component.extend(InViewportMixin, {
  viewportOptionsOverride: Ember.on('didInsertElement', function() {
    Ember.setProperties(this, {
      viewportUseRAF            : true,
      viewportSpy               : false,
      viewportScrollSensitivity : 1,
      viewportRefreshRate       : 150,
      viewportTolerance: {
        top    : 50,
        bottom : 50,
        left   : 20,
        right  : 20
      }
    });
  })
});

[ghost]

Cool :).

2015-09-01 16:16 GMT+02:00 Hugh Francis [email protected]:

jah it does

export default Ember.Component.extend(InViewportMixin, {
viewportOptionsOverride: Ember.on('didInsertElement', function() {
Ember.setProperties(this, {
viewportUseRAF : true,
viewportSpy : false,
viewportScrollSensitivity : 1,
viewportRefreshRate : 150,
viewportTolerance: {
top : 50,
bottom : 50,
left : 20,
right : 20
}
});
})
});

—
Reply to this email directly or view it on GitHub
#82 (comment).

[andrewhavens]

I also was having an issue where the loading component was not triggering the loadMoreAction when it came into view. I also tried the InViewportMixin and it worked for me! Here is the code that I used to achieve the results that I needed (note that I start loading 1500px before the loader comes into the viewport):

import Ember from 'ember';
import InfinityLoaderComponent from 'ember-infinity/components/infinity-loader';
import InViewportMixin from 'ember-in-viewport';

export default InfinityLoaderComponent.extend(InViewportMixin, {
  viewportOptionsOverride: Ember.on('didInsertElement', function() {
    Ember.setProperties(this, {
      viewportSpy: true,
      viewportTolerance: {
        bottom: 1500,
      }
    });
  }),

  didEnterViewport() {
    this.sendAction('loadMoreAction')
  },

});