Closed smnbbrv closed 8 years ago
Hi, thanks. I have to look at the window scroll handler as it is fairly memory consuming. Maybe debounce it and put service in between. Also thinking about making this options optional in config. Thanks so far!
You are right. I think adding debouncer would solve the problem. Making it optional is probably not the best idea because in my opinion this is going to be confusing and inconsistent. E.g. for developer's / qa's screen size the problem won't happen but on customer's it will and you won't even recognize it until some user probably complains (most likely he just won't use the product instead). I recognized it only because I accidentally used it on a laptop, on a big screen there was no problem at all. So I would vote to make it work out-of-the-box.
What I am additionally wondering now after you've told about performance thing and debouncing is adding one more optional option which could really work good together with an offset option. This property is just a number which splits the scrolling into steps. Let's say my image height is 200px. So I definitely would not need to update the view on every pixel, right? I can set this property to e.g. 100px and then view is updated only on 100px scroll, 200px, 300px etc.
This may improve the scrolling performance.
Updated the code: added debouncer for scroll events
hello,
just applied the changes that fixed my problem with #41
Now it listens to both window and container (if specified) for both scroll and resize events