why have both showCopiedSuccess and showCopiedText? 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 using showCopiedSuccess 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 update useClipboard 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 using showCopiedSuccess 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 update useClipboard so that the timeout is parameterized

This is gong to cause prop shadowing for all the props that clickableProps currently has (as in, if a consumer passes in any of tabIndex, role, onClick, onKeyDown or onKeyUp, they'll get dropped in favor of the clickableProps 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):

export const CopyableValue: 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);
	const clickableProps = useClickable<HTMLSpanElement>(() => {
		copyToClipboard(value);
		setTooltipOpen(true);
	});

	return (
		<TooltipProvider delayDuration={100}>
			<Tooltip
				open={tooltipOpen}
				onOpenChange={(next) => {
					if (!next && isFocused) return;
					setTooltipOpen(next);
				}}
			>
				<TooltipTrigger asChild>
					<span
						ref={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>
				<TooltipContent side={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 the onMouseEnter prop setting isFocused 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 do padding instead if it looks the same?

the name next 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.