Open Coder3333 opened 6 years ago
Testing on an iPad Pro using Safari, the performance is pretty bad attaching inview to just a few objects. I’m using inview to add/remove classes, then animate a simple fade in/out with CSS keyframes. There’s a stutter every time before inview detects enter and exit.
@Coder3333 I'm on the same boat here. Did you manage to come up with any solutions?
For me it's a photo grid. I need to do a few things when elements scroll in / out. I'm considering attaching to every second photo or so to detect the grid, and cut the number of waypoints in half.
Unfortunately, I ended up abandoning Waypoints, along with every other framework that I tried out for the same reason. I ended up just doing it all manually with lots of math. Surprisingly, it actually worked with no noticeable lag, even with 10,000 trigger points. I need to refactor it into something more reusable, though. Currently, it is wrapped all around my code.
I might have to do exactly the same. My alt-route is to cycle through elements and set a class for those that are in view, and remove from those that left the view. It's especially a problem since the number is unknown. Essentially trying to recreate a DOM-virtualization-like system 😩
Many thanks for the quick reply! ✌🏻
@djmtype I have! Due to this being a photo grid, and multiple elements being observed, and scrollama being heavier than I need, I ended up rolling up my sleeves and coding a custom intersectionObserver version myself now. Thanks for the suggestion and timely responses however!
I have a scenario where I am adding a Waypoint to each of 2000 elements on the page, so that I can execute a behavior as each one is scrolled into view. Just calling new Waypoint on this many elements takes about 20 seconds. If I use new Waypoint.Inview, it takes something like 5 minutes. I have tried the jquery syntax, as well, but that did not change the execution speed. I need a way to attach a Waypoint to a lot of elements without impacting the user.