ember-in-viewport
Advanced tools
Detect if an Ember View or Component is in the viewport @ 60FPS
Detect if an Ember View or Component is in the viewport @ 60FPS
ember-in-viewport is built and maintained by DockYard, contact us for expert Ember.js consulting.
This Ember addon adds a simple, highly performant Service or modifier to your app. This library will allow you to check if a Component or DOM element has entered the browser's viewport. By default, this uses the IntersectionObserver API if it detects it the DOM element is in your user's browser – failing which, it falls back to using requestAnimationFrame, then if not available, the Ember run loop and event listeners.
We utilize pooling techniques to reuse Intersection Observers and rAF observers in order to make your app as performant as possible and do as little works as possible.
dummy-artwork for an example artwork component). Visit http://localhost:4200/infinity-modifier to see it in actionember serve): https://github.com/DockYard/ember-in-viewport/tree/master/tests/dummyember install ember-in-viewport
Usage is simple. First, inject the service to your component and start "watching" DOM elements.
import Component from '@glimmer/component';
import { action } from '@ember/object';
import { inject as service } from '@ember/service';
export default class MyClass extends Component {
@service inViewport
@action
setupInViewport() {
const loader = document.getElementById('loader');
const viewportTolerance = { bottom: 200 };
const { onEnter, _onExit } = this.inViewport.watchElement(loader, { viewportTolerance });
// pass the bound method to `onEnter` or `onExit`
onEnter(this.didEnterViewport.bind(this));
}
didEnterViewport() {
// do some other stuff
this.infinityLoad();
}
willDestroy() {
// need to manage cache yourself
const loader = document.getElementById('loader');
this.inViewport.stopWatching(loader);
super.willDestroy(...arguments);
}
}
<ul>
<li></li>
...
</ul>
<div id="loader"></div>
You can also use Modifiers as well. Using modifiers cleans up the boilerplate needed and is shown in a later example.
To use with the service based approach, simply pass in the options to watchElement as the second argument.
import Component from '@glimmer/component';
import { inject as service } from '@ember/service';
export default class MyClass extends Component {
@service inViewport
@action
setupInViewport() {
const loader = document.getElementById('loader');
const { onEnter, _onExit } = this.inViewport.watchElement(
loader,
{
viewportTolerance: { bottom: 200 },
intersectionThreshold: 0.25,
scrollableArea: '#scrollable-area'
}
);
}
}
You can set application wide defaults for ember-in-viewport in your app (they are still manually overridable inside of a Component). To set new defaults, just add a config object to config/environment.js, like so:
module.exports = function(environment) {
var ENV = {
// ...
viewportConfig: {
viewportUseRAF : true,
viewportSpy : false,
viewportListeners : [],
intersectionThreshold : 0,
scrollableArea : null,
viewportTolerance: {
top : 0,
left : 0,
bottom : 0,
right : 0
}
}
};
};
// Note if you want to disable right and left in-viewport triggers, set these values to `Infinity`.
Using with Modifiers is easy.
You can either use our built in modifier {{in-viewport}} or a more verbose, but potentially more flexible generic modifier. Let's start with the former.
{{in-viewport}} modifier on target elementoptions are optional - see Advanced usage (options)<ul class="list">
<li></li>
<li></li>
<div {{in-viewport onEnter=(fn this.onEnter artwork) onExit=this.onExit scrollableArea=".list"}}>
List sentinel
</div>
</ul>
This modifier is useful for a variety of scenarios where you need to watch a sentinel. With template only components, functionality like this is even more important! If you have logic that currently uses the did-insert modifier to start watching an element, try this one out!
If you need more than our built in modifier...
did-insert hook inside a componentNote - This is in lieu of a did-enter-viewport modifier, which we plan on adding in the future. Compared to the solution below, did-enter-viewport won't need a container (this) passed to it. But for now, to start using modifiers, this is the easy path.
import Component from '@glimmer/component';
import { action } from '@ember/object';
import { inject as service } from '@ember/service';
export default class MyClass extends Component {
@service inViewport
@action
setupInViewport() {
const loader = document.getElementById('loader');
const viewportTolerance = { bottom: 200 };
const { onEnter, _onExit } = this.inViewport.watchElement(loader, { viewportTolerance });
onEnter(this.didEnterViewport.bind(this));
}
didEnterViewport() {
// do some other stuff
this.infinityLoad();
}
willDestroy() {
// need to manage cache yourself
const loader = document.getElementById('loader');
this.inViewport.stopWatching(loader);
super.willDestroy(...arguments);
}
}
<div {{did-insert this.setupInViewport}}>
{{yield}}
</div>
Options as the second argument to inViewport.watchElement include:
intersectionThreshold: decimal or array
Default: 0
A single number or array of numbers between 0.0 and 1.0. A value of 0.0 means the target will be visible when the first pixel enters the viewport. A value of 1.0 means the entire target must be visible to fire the didEnterViewport hook. Similarily, [0, .25, .5, .75, 1] will fire didEnterViewport every 25% of the target that is visible. (https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API#Thresholds)
Some notes:
didExitViewport that the target is initially offscreen. Similarily, this is possible to notify if onscreen when your site loads.didExitViewport hook fired due to our use of the isIntersecting property. See last comment here: https://bugs.chromium.org/p/chromium/issues/detail?id=713819 for purpose of isIntersectingdidExitViewport fire, set your intersectionThreshold to [0, 1.0]. When set to just 1.0, when the element is 99% visible and still has isIntersecting as true, when the element leaves the viewport, the element isn't applicable to the observer anymore, so the callback isn't called again.didEnterViewport and didExitViewport at the appropriate time.scrollableArea: string | HTMLElement
Default: null
A CSS selector for the scrollable area. e.g. ".my-list"
viewportSpy: boolean
Default: false
viewportSpy: true is often useful when you have "infinite lists" that need to keep loading more data.
viewportSpy: false is often useful for one time loading of artwork, metrics, etc when the come into the viewport.
If you support IE11 and detect and run logic onExit, then it is necessary to have this true to that the requestAnimationFrame watching your sentinel is not torn down.
When true, the library will continually watch the Component and re-fire hooks whenever it enters or leaves the viewport. Because this is expensive, this behaviour is opt-in. When false, the intersection observer will only watch the Component until it enters the viewport once, and then it unbinds listeners. This reduces the load on the Ember run loop and your application.
NOTE: If using IntersectionObserver (default), viewportSpy wont put too much of a tax on your application. However, for browsers (Safari < 12.1) that don't currently support IntersectionObserver, we fallback to rAF. Depending on your use case, the default of false may be acceptable.
viewportTolerance: object
Default: { top: 0, left: 0, bottom: 0, right: 0 }
This option determines how accurately the Component needs to be within the viewport for it to be considered as entered. Add bottom margin to preemptively trigger didEnterViewport.
For IntersectionObserver, this property interpolates to rootMargin.
For rAF, this property will use bottom tolerance and measure against the height of the container to determine when to trigger didEnterViewport.
Also, if your sentinel (the watched element) is a zero-height element, ensure that the sentinel actually is able to enter the viewport.
| Chrome | 51 [1] |
| Firefox (Gecko) | 55 [2] |
| MS Edge | 15 |
| Internet Explorer | Not supported |
| Opera [1] | 38 |
| Safari | Safari Technology Preview |
| Chrome for Android | 59 |
| Android Browser | 56 |
| Opera Mobile | 37 |
isIntersecting until later versions.dom.IntersectionObserver.enabled.ember serveember testember test --serveember buildFor more information on using ember-cli, visit http://www.ember-cli.com/.
DockYard, Inc © 2015
Licensed under the MIT license
We're grateful to these wonderful contributors who've contributed to ember-in-viewport:
FAQs
Detect if an Ember View or Component is in the viewport @ 60FPS
The npm package ember-in-viewport receives a total of 17,568 weekly downloads. As such, ember-in-viewport popularity was classified as popular.
We found that ember-in-viewport demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 6 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.
