ala-n
commented
7 months ago Introduction
The code described above is expected to track the first intersection of the observed element.
However, according to the current ESLIntersectionTarget spec, it will produce ESLIntersectionEvent (intersects) each time the IntersectionObserver callback is called.
So, the original intersects event will (and should) be produced each time the intersection observer configuration is satisfied (for both positive and negative intersections, with all of the passed ratios).
The recommended way to handle this expected behavior is as follows:
@listen({
event: 'intersects',
target: ESLIntersectionTarget.for
})
_onIntersect(e: ESLIntersectionEvent): void {
if (e.isIntersecting) {
// do something
// Unsubscribe manually
this.$$off(this._onIntersect);
}
}Note: This is the most common way to handle such scenarios and should continue to be used to handle complex intersection settings and conditions.
However, the following proposal was discussed and approved (as a POC) by the @exadel-inc/esl-core-maintainers :
The Proposal
To simplify the most common case described above, it is proposed to introduce intersects:in and intersects:out events:
intersects:in- should be triggered each time a positive intersection condition is met (including the initial call).intersects:out- should be triggered each time a negative intersection condition is met (including the initial call).
Example
@listen({
event: 'intersects:in',
target: ESLIntersectionTarget.for,
once: true
}) // Happens once a positive intersection happens
_onIntersect(e: ESLIntersectionEvent): void {
if (e.isIntersecting) {
// do something
}
}Implementation Acceptance Criteria
- Implementation should be lightweight and should not introduce too many extra steps (please consider producing events unconditionally as well as alternatively checking the criteria to start processing them earlier with awareness of the list of subscribers; please provide a clear argument for the chosen implementation strategy).
- Requests for extra settings for new event criteria are out of scope for now but can be considered if they are easy to implement.
- Please be aware that the classic check for element intersection is a little trickier than just the
isIntersectingmarker; it should be considered whether our responsibility includes checking intersection ratio as well.
Input Code
Expected behavior/code
intersectsevent should be triggered when target element intersects viewport first timeEnvironment