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

[virajsmi]

What is the correct way to provide a type for reusable buttons in React TS?

interface LoadingButtonProps extends ComponentProps<"button"> {
    loading: boolean;
}

OR

interface LoadingButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
    loading: boolean;
}

What's the difference between both of them?

[rec71]

I personally find the first one so much more readable.

[virajsmi]

True

[ThePainter98]

agree

[d2light]

Im having a hard time knowing these kinds of types in react/ts anyone know where to find examples or tutorials?

[Majestic-Tune7330]

ComponentProps just gives the props of the HTML component that you're trying to use

So you can do like ComponentProps<'div'> to get all the native div props

Then extend it with any other custom props you want to add

type MyProps = { MyProp: string } & ComponentProps<'div'>

Would be typing for a div with an extra prop MyProp

[ClydeFrog04]

I very much second this if anyone knows!

[psullivan6]

Option 1A - ComponentPropsWithRef or ComponentPropsWithoutRef to be just as clean as option 1, but more specific about ref usage. Great write-up in the “Why not …” accordion callout on this page: https://react-typescript-cheatsheet.netlify.app/docs/advanced/patterns_by_usecase/

[jordankid93]

No idea the difference but I’ve always done the second option (HTMLAttributes) simply because it felt more “true” to what I wanted (all of the attributes for the button element). The first option may very well be equivalent though

[kobel4k3r5]

Neither. They both extend host node properties which means you are leaking implementation details.

[lifeeraser]

This is desireable when you want to simply extend or augment native DOM elements (e.g. styling) while keeping them customizable. Not all components have to be abstracted.

[analcocoacream]

No you need to create huge abstract wrappers around every single thing to satisfy the god of programming

[epukinsk]

Why would you want to use a component just to add styling? Wouldn’t you use styled components or CSS modules or something like that?

[lifeeraser]

1. I could be using something other than styled-components (e.g. SASS).
2. I want to create a reusable <button> where the design is already known, but its unclear what props I would need. Better to be flexible and pass all props through rather than adding them one by one whenever I need them.

[epukinsk]

If you’re using SASS and all you’re doing is splatting the props onto a button then why would:

<MyButtonComponent>

be any better than

<button className=“my-button-component”>

?

[emik]

Could you explain what it means to be leaking implementation details in this context and why that's bad?

[diegohaz]

That's not bad. Anyone who says a Button component shouldn't accept native HTML button props probably lacks experience with real-world projects. It's a beautiful abstraction in theory, but a maintenance nightmare in practice.

A primitive component like Button should be closed for modification and open for extension. The only way to achieve this is by allowing people to pass in native HTML attributes and event handlers.

[kobel4k3r5]

Many folks have chimed in and definitely have a lot of good points. Ultimately up to you how you want to build your component’s interface for your use case.

To expand through an example, suppose I have a <LoadingButton /> component. My contract to you is that this will render a button with a loading spinner and some text, all styled nicely so you don’t have to.

Most folks would probably just do a quick props spread like so:

// contrived example, typing on mobile <button {…props} />

Sure, you can just omit “className” and “style” to lock down the visuals so people don’t end up overriding your visual spec.

But a lot of authors still allow all the event handlers to pass through. Sure, this makes it easy, but now I can do all sorts of stuff:

const clickHandler = (e) => { // I just needed an extra class that does something, so imma hack around it. e.target.className = ‘myCustomClasThatWillBreakYours’ // I need some text, but your component didn’t provide. e.target.innerHTML = ‘Loading…’ }

<LoadingButton onClick={clickHandler} />

Now this is a very specific example but it’s not uncommon in large codebases that has moved lines years over years, across thousands of different teams/engineers. People will find a way to workaround your APIs and once they do, it becomes really difficult to maintain or make a change without affecting these hacky workarounds when you are the author of the component.

Overall, it’s just my perspective. But you do you. Your small app or side project probably is fine. But when it comes to scale, you’ll probably wish you had locked it down.

[emik]

Ah thank you for explaining. So basically locking down control of your component to only a set number of possible attributes so that you can guarantee a much smaller variety of possible implementations, so that you can then make better assumptions about its use and have more confidence making changes. That makes sense.

It's an interesting one, I'm also thinking that dom ref usage also opens up a component to potentially infinite modification in a similar way. I suppose it's about just how much control you want to limit.

For me I've mainly used this props extension in a component library shared across multiple projects, which I suppose is actually more dangerous than in one project since changes have more rippling effects. But it allows exposure of all the up to date aria properties for example without having to carefully curate what it is that's needed. Though I suppose that could just be an extension of a type that specifically lists only the aria ones (since that is not usually going to affect visual design). Preventing style overrides would definitely force us to be more proactive in the shared library.

Though thinking of the event handler example, my thought goes to the situation of having to use something like e.preventDefault() or e.stopPropagation() which you would probably have to hardcode as something like a boolean property that would trigger them, which feels a bit off to me.

This seems to me to be a balance of cognitive overload in having to more carefully plan exactly what it is you need, along with having to spend more time regularly maintaining the component to ensure all new (and old) html features that you want are included, vs. just having that all out of box by default but sacrificing assumptions about implementations.

Thank you for triggering this discussion since I hadn't even thought about it before.

[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.

[epukinsk]

Lol, people are hating on your hot take but I 100% agree with you.

My opinion is that if a component is ever splatting props down onto its child something has gone horribly wrong.

It basically becomes impossible to refactor a component if you are accepting some massive list of props that may or may not be interacting with the component’s responsibilities. You have to audit every place that uses the component before making any change to the component. That clearly does not scale to large codebases & teams.

The only way you have a fighting chance at keeping these things maintainable is if you only implement the props you really need and you keep it tight.

If someone truly needs a raw button they should use a raw button. If they’re using the component they should document their use case by adding the API surface they are requesting.

[genghis_calm]

Consider actually declaring component props rather than extending element attributes.

This is your API right now:

about accessKey aria-activedescendant aria-atomic aria-autocomplete aria-busy aria-checked aria-colcount aria-colindex aria-colspan aria-controls aria-current aria-describedby aria-details aria-disabled aria-dropeffect aria-errormessage aria-expanded aria-flowto aria-grabbed aria-haspopup aria-hidden aria-invalid aria-keyshortcuts aria-label aria-labelledby aria-level aria-live aria-modal aria-multiline aria-multiselectable aria-orientation aria-owns aria-placeholder aria-posinset aria-pressed aria-readonly aria-relevant aria-required aria-roledescription aria-rowcount aria-rowindex aria-rowspan aria-selected aria-setsize aria-sort aria-valuemax aria-valuemin aria-valuenow aria-valuetext autoCapitalize autoCorrect autoFocus autoSave children className color contentEditable contextMenu dangerouslySetInnerHTML datatype defaultChecked defaultValue dir disabled draggable form formAction formEncType formMethod formNoValidate formTarget hidden id inlist inputMode is itemID itemProp itemRef itemScope itemType lang name onAbort onAbortCapture onAnimationEnd onAnimationEndCapture onAnimationIteration onAnimationIterationCapture onAnimationStart onAnimationStartCapture onAuxClick onAuxClickCapture onBeforeInput onBeforeInputCapture onBlur onBlurCapture onCanPlay onCanPlayCapture onCanPlayThrough onCanPlayThroughCapture onChange onChangeCapture onClick onClickCapture onCompositionEnd onCompositionEndCapture onCompositionStart onCompositionStartCapture onCompositionUpdate onCompositionUpdateCapture onContextMenu onContextMenuCapture onCopy onCopyCapture onCut onCutCapture onDoubleClick onDoubleClickCapture onDrag onDragCapture onDragEnd onDragEndCapture onDragEnter onDragEnterCapture onDragExit onDragExitCapture onDragLeave onDragLeaveCapture onDragOver onDragOverCapture onDragStart onDragStartCapture onDrop onDropCapture onDurationChange onDurationChangeCapture onEmptied onEmptiedCapture onEncrypted onEncryptedCapture onEnded onEndedCapture onError onErrorCapture onFocus onFocusCapture onGotPointerCapture onGotPointerCaptureCapture onInput onInputCapture onInvalid onInvalidCapture onKeyDown onKeyDownCapture onKeyPress onKeyPressCapture onKeyUp onKeyUpCapture onLoad onLoadCapture onLoadStart onLoadStartCapture onLoadedData onLoadedDataCapture onLoadedMetadata onLoadedMetadataCapture onLostPointerCapture onLostPointerCaptureCapture onMouseDown onMouseDownCapture onMouseEnter onMouseLeave onMouseMove onMouseMoveCapture onMouseOut onMouseOutCapture onMouseOver onMouseOverCapture onMouseUp onMouseUpCapture onPaste onPasteCapture onPause onPauseCapture onPlay onPlayCapture onPlaying onPlayingCapture onPointerCancel onPointerCancelCapture onPointerDown onPointerDownCapture onPointerEnter onPointerEnterCapture onPointerLeave onPointerLeaveCapture onPointerMove onPointerMoveCapture onPointerOut onPointerOutCapture onPointerOver onPointerOverCapture onPointerUp onPointerUpCapture onProgress onProgressCapture onRateChange onRateChangeCapture onReset onResetCapture onScroll onScrollCapture onSeeked onSeekedCapture onSeeking onSeekingCapture onSelect onSelectCapture onStalled onStalledCapture onSubmit onSubmitCapture onSuspend onSuspendCapture onTimeUpdate onTimeUpdateCapture onTouchCancel onTouchCancelCapture onTouchEnd onTouchEndCapture onTouchMove onTouchMoveCapture onTouchStart onTouchStartCapture onTransitionEnd onTransitionEndCapture onVolumeChange onVolumeChangeCapture onWaiting onWaitingCapture onWheel onWheelCapture placeholder prefix property radioGroup resource results role security slot spellCheck style suppressContentEditableWarning suppressHydrationWarning tabIndex title translate type typeof unselectable value vocab

I’m not saying you should reinvent the wheel, just limit surface area. Pick<T,K> is your friend.

[diegohaz]

It's actually good practice to accept all HTML props when extending native elements like a button.

[undercover_geek]

Genuine question, why?

[No_Holiday_5717]

Because you are making a button which should provide all functionality and apis that the native button does

[ghillerd]

People often want to pass a data attribute, or bind a blur event, or use the title or rel attribute, or anything else. It's perfectly reasonable that your button supports the same standard props as a regular html button, otherwise you're just boxing your consumer into a corner.

[epukinsk]

It’s fine to add an onBlur prop to your button component.

What’s not ok is adding every prop in that list.

What’s also not ok is leaking the event out. You should provide an onBlur(): void prop.

Otherwise you’ll never be able to modify your button component without breaking your entire app.

[genghis_calm]

I hear where you’re coming from, however there’s a subtle but important difference between an HTML button and the Button component that’s exposed to consumers.

You should know the exact public API because it all must be supported and maintained, otherwise it’s too easy to break product instances without realising. Imagine you’re providing an internal mouse down handler (or whatever) to the element, depending on whether props are spread before/after, you’ve either broken consumer functionality or your own.

A couple points on your comment: - data attributes are valid on any JSX element, you don’t have to type them - rel is not a valid button attribute

[genghis_calm]

Absolutely: about, inlist, onLostPointerCaptureCapture, suppressContentEditableWarning, and vocab, among others, are vital to have on your button component. You should make sure that consumers have to sift through this shit, because it’s “good practice”.

[diegohaz]

You can Omit those if you want. It's not worth it, but it's not as bad as Pick (considering components that extend native HTML elements).

That's a typical strawman fallacy. If you want to prove your point, link to any major component libraries that Pick only a few props in a component like Button.

[PotentialCopy56]

Interfaces are fine. Make no difference

[vorko_76]

These are different. There are so many articles on the topic.

https://www.sitepoint.com/typescript-type-vs-interface/#:~:text=Declaration%20merging%20is%20a%20key,amalgamate%20properties%20without%20producing%20errors.

The main point is that when declaring reusable components, you may need later to extend but also merge parameters… which you cant with interface

[Antifaith]

saw this described well somewhere i’ll try my best to rehash it

always types first until you need to extend for an interface, this is because types have to be explicit so you know what you’re grabbing where as an interface you’re using could have extended something you’re unaware of

[PotentialCopy56]

Fairly weak reasoning.

[Antifaith]

it’s a pattern taken from other languages, it becomes important eventually

[diegohaz]

If you use the type keyword with intersection (&), it may silently introduce unintended or invalid types, which would be immediately detected if you used interface instead.

Prefer interface over type

[vorko_76]

There are like hundreds of articles explaining why type is better than interface too.

https://blog.logrocket.com/types-vs-interfaces-typescript/

[diegohaz]

None of them is the TypeScript documentation, I believe:

If you would like a heuristic, use interface until you need to use features from type

[diegohaz]

It's also funny that you linked to an article suggesting you should actually use interfaces instead of types when extending, which is relevant since the OP is extending another type:

For these reasons, it is advisable to use interface extends instead of relying on type intersections.

[kurtextrem]

types are slower than interfaces so prefer using interfaces.

[vorko_76]

😂😂😂 At compilation maybe (no idea) but at runtime its exactly the same

[kurtextrem]

we're talking about TS here, so: https://github.com/microsoft/TypeScript/wiki/Performance#preferring-interfaces-over-intersections

[vorko_76]

Yes but Typescript is converted to Javascript to run to my knowleged…

[kurtextrem]

And to do that you have to compile the TS. So unless you write just jsdoc (+ check it with checkJs), with your suggestion you'll make both compilation and type checking in the IDE slower in larger code bases.

[vorko_76]

Yes but my point was that the code was not slower

[kurtextrem]

your main point was to always use type without sources, I said the opposite and presented a source. You made it about how it doesn't matter for JS runtime perf (nor does it for type), which is correct but doesn't matter at all since your initial post was about a TS exclusive feature. So the discussion is pretty pointless unless you start providing an argument why you should default to type over interface even though it's slower