This is partly personal taste, but I just want to make sure you know thatfindByRole basically functions as a form of assertion by itself, because if the selector fails to find the element in some period of time, the test will fail

But I feel like here, this has a problem of causing flakes in the future, if we start needing to add more tooltip content. ThefindByRole call will find the first tooltip it can, and then we assert that it has specific content. So if a new tooltip gets introduced, and it happens to be earlier in the DOM tree, this test will start breaking

Didn't know that aboutfindByRole, thank you. I could've sworn that the Radix tooltip's DOM structure made the original assertion fail, but I just reverted it back and it seems to be working again.

I was a bit rushed, so I didn't go through the full file to see what might be causing some of the infinite renders, but basically, withuseEffectEvent, you want to do two things:

1. Identify the reactive dependencies – the things thatshould be treated as synchronization cues between React and an external system. These should stay out of theuseEffectEvent callback, and should still be included in theuseEffect dependency array
2. Identify the "incidental" dependencies – the things that you need to perform all necessary calculations, but that shouldn't be treated as synchronization cues themselves. These should all go in theuseEffectEvent callback

Until we upgrade to React 19.2, weshould include the effect event callback in theuseEffect dependency array for correctness, but the value will never trigger re-renders by itself. But once we upgrade, we should be able to removeuseEffectEvent from all dependency arrays (assuming Biome updates their rules like ESLint did)

I think it's fine to have state here, but the current implementation will cause bugs. If theopen prop ever changes during re-renders, then we won't ever acknowledge it, because we'll be driving everything via theisOpen state instead

I think this will work

constMiniTooltip:FC<MiniTooltipProps>=({// No default assignmentopen,// Also destructure onOpenChange, even if it's not defined  onOpenChange,...contentProps})=>{const[isOpen,setIsOpen]=useState(false);constactiveIsOpen=open??isOpen;// Sync state change to both so that if the component ever flips from// controlled to uncontrolled, the other piece of state won't be lagging behindconsthandleOpenChange=(newOpen:boolean)=>{setIsOpen(newOpen);onOpenChange?.(newOpen);};