Fix off-by-one frame issue causing flicker

[thecrypticace]

Right now when you press arrow up/down/etc… and change the active item we wait for two rAF call backs. This has the affect of waiting after two full paints have finished. This results in, for the react version of the Combobox, a period of 1 frame where the active item has changed and re-rendered but the scroll hasn't happened yet.

Now, it is common to have to wait 2 rAF frames for the DOM to have updated in React because of a Chrome (and possibly Safari) bug with animations. However, in this case we're not waiting for animations to start, just scrolling. As far as I know the DOM should be updated by the end of the first cal to rAF but perhaps we should check if the element exists and schedule another one if it doesn't?

I'd also be curious to see if this behavior is a problem in React 18 because it does automatic batching of updates so it's possible that the timing would end up being correct. Not sure though — because I don't know much about the new fanciness in React 18.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

headlessui-react – ./packages/playground-react

🔍 Inspect: https://vercel.com/tailwindlabs/headlessui-react/YcTpXRoeU8y8hxXJaofqvf4wYmR4
✅ Preview: https://headlessui-react-git-feature-fix-combobox-s-40e174-tailwindlabs.vercel.app

headlessui-vue – ./packages/playground-vue

🔍 Inspect: https://vercel.com/tailwindlabs/headlessui-vue/A4pCcLHXSRAWKWvSXHoW12LUn1e5
✅ Preview: https://headlessui-vue-git-feature-fix-combobox-scr-ccba32-tailwindlabs.vercel.app

[RobinMalfait]

This should indeed work just with requestAnimationFrame on its own. I know I had to use the nextFrame "hack" (double raf) for some strange animation behaviour, but in this case as you mentioned we just have to wait for the DOM flush, not for an animation.

I also added this change to the other components that suffer from the same issue.