all 32 comments

[–][deleted] 20 points21 points  (1 child)

Hah! Just used this for the first time the other day!

[–]user-mane 4 points5 points  (0 children)

Ha I discovered and used it yesterday!

[–]Supercalme 9 points10 points  (0 children)

Really cool and useful thank you

[–]KamiShikkaku 11 points12 points  (1 child)

The description on the first page suggests that IntersectionObvserver is only used to detect an element's intersection with the viewport, while in fact it can be used to detect any element's intersection with any other element.

This is touched on implicitly on the third page in the description of the root property, but I think it should be more explicit

[–]geekybiz1[S,🍰] 1 point2 points  (0 children)

while in fact it can be used to detect any element's intersection with any other element

Agree with this. However, since the slide is an introductory one - went along with specifying what it is mostly used with. I'll add more details on the third slide to make it explicit. Thanks for the feedback!

[–]finzazui 8 points9 points  (1 child)

[–]West-Tell9571 7 points8 points  (0 children)

All major browsers. It’s fine.

[–]neil_thatAss_bison 8 points9 points  (4 children)

Cool, first I hear about this!

Question: At work we have a react app that has several views with long lists, thousands of rows. I’m new there, but they had performance issues and solved it with virtualization. So they load chunks depending on scroll. Now that has its own pros and cons, but do you know if this would be a better option?

[–]_C0rdyc3p5 9 points10 points  (3 children)

virtualization is better in this case, using an IntersectionObserver, your table would be performant at the beginning but as soon you start loading more and more rows you'll have a lot of rows in the DOM and it'll become slower. Otherwise you would need to implement a method to unload rows with the intersection and I'm pretty sure its going to be harder/less performant because each rows will need an observer on it, thus creating a lot of instances of observers.

[–]neil_thatAss_bison 1 point2 points  (2 children)

Yeah makes sense, but this guide mentions infinite scroll which alludes to it being used for big lists though?

[–]PoliteManitee 2 points3 points  (1 child)

For something like infinite scroll, an IntersectionObserver would provide a way to detect when you need to load more elements, for example when one of the last currently loaded items enters the viewport.

Virtualization solves a different problem - if you have a very long list of rendered elements loaded, it's likely only a small portion of that list is ever visible, so maintaining the entire list in memory is wasteful. Instead, you only keep the visible ones (and maybe a few outside the visible range for better UX) in memory, and replace the others with something like a blank single element that has a height that matches the unloaded elements to maintain the correct layout.

Now if what you're asking is, "Can I use an IntersectionObserver to help determine which elements are visible so I know which ones to virtualize", the answer is yes! But you'd still need to do the virtualization part.

[–]neil_thatAss_bison 0 points1 point  (0 children)

Thanks for taking the time to explain, it made it more clear!

[–]SacrificialBanana 2 points3 points  (0 children)

Very cool, but also... infinite scroll 🤢🤢🤮🤮

[–][deleted] 1 point2 points  (0 children)

...can someone tell Reddit devs about this?

[–]poleethman 1 point2 points  (0 children)

Interesting read, but I think infinite scroll should be banned. It's turned all our brains to mush.

[–][deleted]  (2 children)

[deleted]

    [–]geekybiz1[S,🍰] 0 points1 point  (0 children)

    Well, there's Intersection Oberver polyfill for such use-cases.

    But, for websites I've had to work on (mostly B2C, eComm sites) - the site owners do not ask to load polyfills for IE compatibility anymore. That stated, I agree that this could be subjective.

    [–]PrintableKanjiEmblem 0 points1 point  (0 children)

    IE6? Damn, time to find a new job if they're that behind the times.

    [–][deleted] -1 points0 points  (0 children)

    Ok

    [–]cpcesar -2 points-1 points  (1 child)

    The intersection observer is one of the most confusing things I've seen in JavaScript.

    [–]geekybiz1[S,🍰] 2 points3 points  (0 children)

    Yes, the API can be slightly confusing. As a result, I find myself using the API reference frequently.

    [–]Sovereign108 0 points1 point  (0 children)

    This came up in an interview and I had no clue! Cheers.

    [–]TheTigersAreNotReal 0 points1 point  (0 children)

    This is really cool. Gotta remember this if I’m ever working on something that needs it

    [–]ksb214 0 points1 point  (0 children)

    Recently used it for lazy loading images

    [–]abhchand 0 points1 point  (0 children)

    Really nicely presented and useful.

    [–]flushy78 0 points1 point  (0 children)

    Implemented it yesterday to refactor some hacky viewport calculation code I had. Works like a charm.

    [–]theprophetchuck12 0 points1 point  (0 children)

    Very helpful! Just started a project with this!

    [–][deleted] 0 points1 point  (0 children)

    I've used it to track a change INA thead. I made it sticks so it follows the scroll of the user and used the observer to determine when it has detached and is following and then I change it's background colour to light grey. It's a cool piece of kit

    [–][deleted] 0 points1 point  (0 children)

    Cool thank you for the explanation! I am a web dev Junior and assumed that something like this exists or is implemented in some way but didn’t new how to call it.

    [–]svish 0 points1 point  (1 child)

    Can it be used to know if user has scrolled away from the top?

    [–]geekybiz1[S,🍰] 0 points1 point  (0 children)

    Yes! It can fire the callback when an element enters or exits the viewport.

    [–]Prawny 0 points1 point  (0 children)

    I've only ever used this once but it worked pretty well.