[docs-infra] Fix bug on API prop copy experience

[oliviertassinari]

I have noticed this while I was looking at #39704:

1. When I click on prop links in dev mode http://0.0.0.0:3000/material-ui/api/dialog/#Dialog-prop-classes

⬇️

2. When I click on prop links in production is replaces my clipboard, I didn't ask him to.

The simplest solution seems to remove this behavior. If we really want to keep it, we would need to use clipboard-copy instead.

[mui-bot]

Netlify deploy preview

https://deploy-preview-39707--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 3502fc5

[danilo-leal]

I'm actually up for keeping the copying behavior — at least in my case, when I click on a heading/prop anchor, I want to copy the URL. I wonder, though, if there's a need/opportunity to improve the copying affordance.

Stripe, for example, displays a "Copied" text after clicking, which communicates better what happened. But, it doesn't necessarily explain it before clicking what will happen 🤔

[oliviertassinari]

@danilo-leal Maybe it comes to a matter of preferences, why I think it's better UX overall not to have it:

1. It's how most other website trains people for what to expect. From the benchmark of https://www.notion.so/mui-org/Docs-infra-83ba469842104927bb13606b1e859ef4?pvs=4#7647eb75870c42a79dc5bdd85cc412e2, only 2 of the 5 docs have this pattern (so far, I can only find Stripe and Mintlify to do it). When looking at websites more broadly (ones that are not so focused on UX), I find it hard to find other examples.
2. I don't like surprises, I heavily depend on the content of my clipboard, and it's frequent for me to copy, close the content source, check a few things, and paste.
3. I'm using the anchor links more than for sharing links: copying the content of headers, which with [docs-infra] Make the whole header clickable #39603 could create problems, and sometimes just reset my scroll.

A side note: it's inconsistent right now. It's only the API props that have this behavior and not all the headers in the docs.

[danilo-leal]

Uhm... I see. I think the biggest problem right now is — as you stated — "the surprise" factor. There shouldn't be any when interacting with stuff. I understand how clicking on the anchor icon button doesn't communicate that the URL is copied with it, which was what I mentioned above about the "lack of affordance". Stripe communicates what happens after you click it, but not before—and we're not doing both.

With that said, alright, let's remove it from now and I can add an issue about "more easily copying the heading URL" so we can figure out one alternative solution that possibly doesn't involve using the same button for two things (which is usually not the best approach, anyway). 🤙

[oliviertassinari]

@danilo-leal I could get behind Stripe's behavior, meaning implementing this for all headers and with a post-notification for affordance.

It's only that I expect that I would personally enjoy it more without copy. But I also didn't research this much more than what I shared before, so #suggestion.

[oliviertassinari]

A new benchmark: https://platform.openai.com/docs/guides/prompt-engineering/split-complex-tasks-into-simpler-subtasks, in the same "class" as https://developers.google.com/maps/documentation/javascript/maptypes. They never change the anchor in the URL.

I'm not sure how it feels. It makes me dubious that it actually work, the first thing I want to try is open a new window to check that the link does work 🤔

[danilo-leal]

Yeah... Open AI's docs are weird in that sense because it's similar to Stripe's, where the icon doesn't necessarily mean that the URL will be copied, but then the scroll position + URL is not changed at all. Maybe a good place is one where, by hovering a heading, you see two icon buttons: one for anchoring and another for copying the URL.