Project roadmap (re: vvo/in-viewport, IntersectionObserver) about in-view HOT 13 CLOSED

I've implemented something like this before, and have been working on updating it this week by coincidence.

One thing that is super useful is to be able to specify a threshold for visibility e.g. element must be > 50% in viewport to be counted as visible. Essentially, you calculate a ratio of visible area of element to total area of element. A value of 1 will then behave exactly as this currently does.

You can think of this problem in math terms as calculating the area of intersection between two rectangles in a coordinate system, where one rectangle is the viewport, and the other is the element.

from in-view.

@camwiegert You could start by reading the code of in-viewport and see what could be missing/what you do not get so that we discuss it then.

from in-view.

There's also this one https://github.com/russellgoldenberg/enter-view by @russellgoldenberg. It lets you specify the distance after entering in % of viewport, which is quite useful.

from in-view.

@vvo I'm definitely open to that! How would you propose that happen?

from in-view.

I was gonna make a new issue, but this seems to be a nice, healthy discussion.

Have you thought about using Intersection Observer? It's currently only implemented in Chrome, but it's built exactly for what your use case is for. Other browsers require a polyfill

from in-view.

@vvo Agreed. I'll be familiarizing myself with it very soon.

Also, as long as we're discussing the future of this library, I think we should consider where (as @dogoku mentions) the IntersectionObserver API fits in. Do we try to ape the API and extend it, or just use it under the hood when it's available?

I'm going to change the title of this issue so it can serve as a more general discussion of the roadmap.

from in-view.

Apparently you can't use markdown in issue titles 😼

from in-view.

Hi!

I think I read about using requestAnimationFrame(func) instead of event listeners somewhere in the issues. Did you consider it? I think func runs before the next render and after all scroll, resize, etc is applied. Also, I think the spec mentions that the animationFrame queue must be copied before it is processed, so

function process () {
  checkInView()
  requestAnimationFrame(process)
}

would make a nice asynchronous infinite checking loop. You could also throttle it by

let lastCheck

function process (timestamp) {
  if (lastCheck < (timeStamp - threshold)) {
    lastCheck = timeStamp
    checkInView()
  }
  requestAnimationFrame(process)
}

It might be better performance wise, but I am not sure it if it would work. I can test it if you think it's worth a chance.

Edit: Of course I suggest this as a fallback for IntersectionObserver, not as a replacement to it.

from in-view.

@WickyNilliams Agreed. That would be a useful feature and was actually originally implemented but later removed. Mind sharing your implementation? Thanks!

from in-view.

@vvo I'm working on adding support for MutationObserver. Mind taking a look at #17?

from in-view.

@vvo
How do you detect style changes on descendant/nested nodes?

from in-view.

How do you detect style changes on descendant/nested nodes?

I think that's the subtree parameter, it's already inside the PR

from in-view.

Here's where I'm at with next steps, in order of priority:

• Set offset per direction (#6)
• Set custom visibility threshold (#21)
• Allow custom container (#20)
• Cache scroll container dimensions (#19)

Thoughts and PRs appreciated. This issue is starting to sprawl a bit, so I'm going to close it now in favor of more focused discussions. Thanks everyone!

from in-view.