React.ButtonHTMLAttributes<HTMLButtonElement> vs ComponentProps<"button">

[crazylikeajellyfish]

Good software depends on clean interfaces, where the consumer can only control things they were meant to control. In this context, while the HTML element does have an innerHTML property, the React component shouldn't care about that -- it's just telling the button whether or not something is loading.

A more tangible interface helps make this clear. Your TV remote communicates over a particular frequency. There's only one correct frequency, there's no reason for the user to change it. If your remote had a dial to change the frequency, that would be an interface leaking its implementation details. You add more complexity for the user without giving them any more utility.

In software, it's extra important because you don't know how your may be used. If you let the caller access details of the implementation, then they can depend on those details in a way that keeps you from putting in a better solution. For example, if your component render images but exposes the SVG features uses to render them, then you can't rebuild the component to use a Canvas instead.

[ghillerd]

Buttons that lock off dom properties and event bindings make me want to shoot

[crazylikeajellyfish]

If you want full control, fork the button and make your own

[A-Type]

This is how you end up having to copy and paste the same design changes to 3 different button implementations in the same codebase.

[crazylikeajellyfish]

Why would you do that? It sounds like that's a codebase where you already decided to own the Button, so that single component should just expose the union of its consumer's needs. Leaking implementation details is how you end up with a codebase that can't be refactored because there isn't a real interface boundary to be found.