Generally try to keep prop definitions inlined, but Prettier's auto-formatting made the code super ugly to look at

This is the only major change for the component. The rest of the diff is just from theforwardRef call increasing the indentation

All of these changes together might be a bit overkill, but I didn't want to leave things to chance. The biggest issue before was that when the dummy input received focus, there was nothing in place to put it back on the original element once the function was done

Changed the previous markup because thenowrap styling had a risk of breaking the text rendering at smaller viewport sizes

Why do we need this?

More just for flexibility. It might be because I've been in a Backstage mindset, where we need a lot more API flexibility, but my thinking was this would let someone attach anonClick handler without overriding the main copy functionality

In the Coder app context + this component context, what would be a common use case for this?

For this context, it is over-engineering, yeah. I'll remove it

I did not understand this part. Why do we need to read something from the clipboard? I would expect to just write things in it.

Maybe listing the flow using bullet points would make things easier to understand for me.

It's mainly for setting up a way to watch the clipboard, since there isn't an observer-based API for it, like there is for a lot of other browser APIs

The main idea is thatisCopied is always a derived value that comes from checking whether the text passed into the hook matches the text currently in the clipboard. And the only way to check the current clipboard is by reading from it – if we only write to it, then we can't make any assumptions about what's actually in the clipboard, because it can also change from sources outside React

So basically, there's three main "sync cues":

1. The user copies our text to the clipboard
2. The user changes their clipboard text while in the same page
3. The user changes to a different tab, and then comes back

In all of the cases, we don't have a direct, event-based way to check the clipboard contents to verify that the content matches. You would think that writing to the clipboard would expose that information, but the event objects don't actually contain the new clipboard text. So in all three cases, the only choice is reading from it

Why do we need to check if the content in the clipboard matches the one passed into the hook? Is there a use case in the app where this can happen?

So, this is splitting semantic hairs, but I guess the question boils down to, "What do we wantisCopied to represent?

• Do we want it to indicate that we've just finished handling a copy operation, and this value represents how long we want to tell the user that the text is copied?
• Or do we want this property to act as a source of truth, whereisCopied answers the question, "Each time the component renders, is the text we provided into the hook copied into the clipboard?"
  • If we don't want to do that, maybe that's a sign we should rename the property, but because the clipboard is one of the most mutable values in web development, the only way to have 100% confidence to that question is by checking the clipboard

That mismatch between the property name and actual functionality is what led me to consider a more synchronization-based solution, but maybe this did end up putting me on a weird, wild goose chase

Hmm... why is this necessary?

Thinking about the most common use case, like the user clicking the button and the value being copied, I don't see how this could happen if the document is not in focus 🤔

I had a comment inreadToClipboard, but it's mainly to suppress errors when trying to do stuff in development mode

Do you think is there a way to improve readability without adding a comment mentioning another comment? Thinking on a named variable or function likeisDevMode?

Yeah, now that you mention it, I can use an assertion function. I'll get that swapped in

I think it's always good to share screenshots and demos when making UI changes or features. Some design improvements I see we can make:

• The space between the title, description text, and code example looks strange
• I would make the "Go to workspaces" link a normal link. I think it's not that important to be considered a secondary action like a button.
• The code example looks bigger than normal input sizes to me... I think it would be nice to have it the same height.