Building Polymorphic Components

Sometimes a button should render as a real <button>, sometimes as an <a> link, sometimes as a router link - but always look identical.

Polymorphic components solve this elegantly. This lesson covers the advanced as pattern.

Without polymorphism you end up with Button, LinkButton, ButtonLink - near-identical copies that drift apart over time.

Each must be styled, tested, and maintained separately. Polymorphism collapses them into one source of truth.

A polymorphic component accepts an as prop naming the element or component to render. The styling stays the same; only the tag changes.

The snippet shows the core idea in plain JS.

When rendering as an <a>, the component must accept href; as a <button>, it accepts type.

Polymorphic components spread the remaining props onto the underlying element so the right attributes flow through automatically.

Rendering a button as a <div> loses keyboard and screen-reader behavior. Polymorphism is powerful but can be misused.

Guide consumers toward semantic elements, and add role and tabindex fallbacks when a non-semantic element is unavoidable.

In typed codebases, polymorphic components are notoriously tricky. The props must change based on the as value - an href only makes sense for an anchor.

Advanced generic typing infers the correct prop set per element, giving consumers accurate autocomplete and errors.

The real payoff: pass a router Link as as and your styled Button becomes a client-side navigation link with zero new code.

This lets design system components work seamlessly with any app's routing library.

Many systems build a single low-level Box primitive that is polymorphic, then compose higher components on top of it.

This concentrates the tricky polymorphic logic in one place, keeping every other component simpler.

Polymorphism adds complexity. If a component only ever renders one element, do not add an as prop speculatively.

Reserve it for genuinely interchangeable cases like buttons/links. Otherwise you pay typing and cognitive cost for nothing.

Polymorphic components surprise people. Document which components support as, the allowed values, and accessibility caveats.

Clear docs prevent misuse like rendering interactive controls as non-interactive elements.

The polymorphic pattern eliminates duplicate components and integrates cleanly with any host app - but it demands careful prop forwarding, typing, and accessibility.

Used judiciously, it is one of the most elegant tools in advanced component development.

Test your grasp of polymorphic components.

You learned the advanced polymorphic component pattern:

• The as prop swaps the rendered element while keeping styling.
• Forward props correctly and preserve accessibility semantics.
• Type the prop set per element and integrate with routers.
• Use it only for genuinely interchangeable cases and document it.

Polymorphism removes duplication when applied with care.