Investigate rAF scheduling - seems unnecessary

[Andarist]

It's only done in controlled mode anyway - uncontrolled doesnt use it and we dont have any issues reported with it.

[stevenla]

Without rAF, the component forces a relayout on componentDidMount. Something like fastdom would help mitigate this.

[Andarist]

Thanks for pointing out to me that I can actually use profiler to check out the difference between both implementations! Need to investigate it in free time.

[Andarist]

Could u describe how did you test that? I cannot observe this with JavaScript Profiler in Chrome.

I've tested both versions - with and without rAF:

• with rAF - https://codesandbox.io/s/x381r2xm24
• without rAF - https://codesandbox.io/s/y3qpp536qj

Keep in mind that rAF was used only in componentDidUpdate, componentDidMount was unaffected by it - calculateNodeHeight + setState were called there unconditionally.

[Andarist]

@stevenla I'd like to do a release without rAF scheduling soon, could u comment on this? If this could in fact cause a perf regression I wouldnt like to do it obviously, but at the moment I'm not able to reproduce it, so your input is extremely valuable for me

[stevenla]

let me try to get a smaller repro case—that was from the app.

[Andarist]

Cool! I'll be waiting for it then before releasing the change as latest.

[Andarist]

@stevenla any news?

[Andarist]

I've released a version without this scheduling, I couldnt find any reason to keep it - couldnt reproduce any perf issues without this scheduling. Therefore Im closing this issue now, if you bring up some data about it I will be glad to look at it and Im not strictly against having this scheduling in the library (it there is a reason behind it).