why have bothshowCopiedSuccess andshowCopiedText? this just feels like duplicated state with messy synchronization code

Yeah, I'm struggling to wrap my head around what the code is trying to solve that isn't handled by usingshowCopiedSuccess directly.

The hook already has timeouts built in (with cleanup). Is the goal to expose a different timeout value to the rest of the component? Because if so, it feels like the better change is to updateuseClipboard so that the timeout is parameterized

My original goal was to make it so that the tooltip is removed after showCopiedSuccess returns to false as it felt like a better experience when I originally looked at this. I think after thinking over this again. The existing functionality makes sense and I will remove all of this extra logic.

Yeah, I'm struggling to wrap my head around what the code is trying to solve that isn't handled by usingshowCopiedSuccess directly.

The hook already has timeouts built in (with cleanup). Is the goal to expose a different timeout value to the rest of the component? Because if so, it feels like the better change is to updateuseClipboard so that the timeout is parameterized

This is gong to cause prop shadowing for all the props thatclickableProps currently has (as in, if a consumer passes in any oftabIndex,role,onClick,onKeyDown oronKeyUp, they'll get dropped in favor of theclickableProps versions)

I feel like we want to be more finer-grained with how we wire everything together (this just illustrates the main idea, and doesn't account for all the other code comments I made):

exportconstCopyableValue:FC<CopyableValueProps>=({value,side="bottom",children,className,role,tabIndex,onClick,onKeyDown,onKeyUp,...attrs})=>{const{ showCopiedSuccess, copyToClipboard}=useClipboard();const[tooltipOpen,setTooltipOpen]=useState(false);const[isFocused,setIsFocused]=useState(false);constclickableProps=useClickable<HTMLSpanElement>(()=>{copyToClipboard(value);setTooltipOpen(true);});return(<TooltipProviderdelayDuration={100}><Tooltipopen={tooltipOpen}onOpenChange={(next)=>{if(!next&&isFocused)return;setTooltipOpen(next);}}><TooltipTriggerasChild><spanref={clickableProps.ref}{...attrs}className={cn("cursor-pointer",className)}role={role??clickableProps.role}tabIndex={tabIndex??clickableProps.tabIndex}onClick={(event)=>{clickableProps.onClick(event);onClick?.(event);}}onKeyDown={(event)=>{clickableProps.onKeyDown(event);onKeyDown?.(event);}}onKeyUp={(event)=>{clickableProps.onKeyUp(event);onKeyUp?.(event);}}onMouseEnter={()=>{setIsFocused(true);setTooltipOpen(true);}}onMouseLeave={()=>{setTooltipOpen(false);}}onFocus={()=>{setIsFocused(true);}}onBlur={()=>{setTooltipOpen(false);}}>{children}</span></TooltipTrigger><TooltipContentside={side}>{showCopiedSuccess ?"Copied!" :"Click to copy"}</TooltipContent></Tooltip></TooltipProvider>);};

What is our goal with the focus state? Because right now, it looks like we're flipping the state within React, but we're not actually changing the focus behavior on the actual HTML element

The main area where I'm worried about drift between React and the underlying HTML is theonMouseEnter prop settingisFocused to true

Do we also want to open the tooltip here?

What situations were you running into that was causing this problem? I know that the libraries can get a little unruly and sometimes need these hacks, but I'm wondering if there's a chance we could remove the need for this

can we dopadding instead if it looks the same?

the namenext just makes this really hard to reason about for me. if I substitute it for something like this in my head it makes it clearer.