Replace ResizeSensor with https://github.com/wnr/element-resize-detector

[bahuma20]

Just add this here as a reminder.
@m59peacemaker said in the gitter chat, he could do this when he has time.

m59peacemaker Okt. 10 07:31
@marcj Are you open to the idea of replacing your ResizeSensor with https://github.com/wnr/element-resize-detector ? I'll implement it if you like the idea and tell me how you want it done. I addeddetachto that detector and am awaiting approval for the pull request. My fork works with your demo.
Should fix marcj/css-element-queries#45
maybe fix other stuff, too

marcj Okt. 29 15:35
@m59peacemaker yeeah, seems to be a good idea actually because mine is not yet fully working. How would the deploy process look like if that css-element-query has then a dependency on your library? What do we need to adjust then?

m59peacemaker Okt. 29 18:26
If it were up to me, I would just go npm/browserify for everything.
and either use the package.json scripts or gulp to run the needed tasks
Some tests with https://github.com/substack/tape would be nice, too.

m59peacemaker Okt. 29 18:31
I'm going to be busy for a bit, but I'm interested in helping when I get a chance.

marcj Okt. 29 18:48
sounds pretty good. so do you want to prepare a PR? 

m59peacemaker Okt. 29 19:39
When I get some extra time, sure.

marcj Okt. 29 19:39
that would be really awesome =)

[m59peacemaker]

It's on my mind. Maybe around Christmas I'll have some free time.

[pesla]

@m59peacemaker @marcj

I have built a small EQ library based on @marcj's work (among others) to fit (into our) own platform. See https://github.com/procurios/ElementQueries and https://github.com/procurios/ResizeSensor. All code has been refactored to fit our needs, and the ResizeSensor works perfectly (tested in Chrome, Safari, Opera, Firefox and IE7+). We use it in production and, obviously, maintain it. The only smell it has: there are no tests yet, but they will follow soon. It's MIT licensed.

I don't mean to hijack this thread, just felt like chipping in; it might be of use to you. Feel free to use, adjust, fork, if it fits your needs. Or just ignore it if it doesn't. 👍

Thanks for your work!

[m59peacemaker]

What's the reasoning behind making another library for resize detection instead of contributing to an existing one?

[pesla]

@m59peacemaker Great question, and hopefully a satisfactory answer: because it's an important building block for creating independent, isolated (UI) components in our platform. Hence, I needed to fully understand the code, be independent of PR's or other factors, fix several issues and refactor it in a way that plays well with our own ecosystem. In that context it seemed logical to rebuild it from the ground up.

By open sourcing the code I'm hoping to return some value to the community.

[sebilasse]

👍
btw –
duplicate of:
#45
would solve as well:
#20
#21

[zowers]

good thing about procurios/ResizeSensor is that it does not hammer browser with requestAnimationFrame(), so browser's cpu utilization essentially zero when idle

[marcj]

@zowers so the same like in the current implementation of css-element-queries.

[zowers]

cool, probably another bug then, I've experienced constant dirtyChecking calls

[marcj]

It does call each frame dirtyChecking to see if there is a need to call all callbacks, this is to increase performance by limiting max executed callbacks to once each frame, so it saves CPU time. The check itself is a dead simple if(boolean) max once each 16ms. This bool conditional if is so fast you can't even measure it. So, yes it does constantly generate CPU usage, but in a range of some nanoseconds per frame, which means you would definitely not feel it nor even be able to measure it. And it lowers it even further when the browser reduce FPS when tab is inactive or on batteries.
If dirtyChecking is fired so fast and often in your case that you can measure it (means way more than 60 times each second) then you should file a bug report please.

[zowers]

dirtyChecking fires every 16ms for each element, so in my case it is 2 calls.
you are right, it's not much, in my case it was noticeable because I had a reset() patch from #46 (comment) applied to my copy of resizesensor.js, that effectively kills IE

on the other hand it's better to not use requestAnimationFrame.
if every little library on a webapp would use requestAnimationFrame for simple things then all those animation frames will grow and become slow.

[marcj]

So, it seems nobody is really interested in having this resize sensor instead. When nobody is willing to create a pull-request I'd rather want to close this issue for now.