Kept running into the same problem at work: build a Button component, someone needs it as a link, now you're either duplicating styles or writing invalid html by nesting <button> inside <a>

Wrote up how polymorphic components solve this. covers:

- the as prop pattern (how chakra and mantine do it)

- making it type-safe with ComponentPropsWithoutRef<C> so typescript knows which props are valid per element

- the forwardRef gotcha where typescript loses the generic (and the fix)

- asChild pattern (how radix/shadcn does it) and why it exists

- a reusable PolymorphicProps utility type you can drop into any project

also when NOT to use any of this. not every component needs to be polymorphic.

https://www.sethi.io/blog/polymorphic-components-one-component-many-forms

Curious how others handle this in their design systems. do you go with as or asChild?

I've been writing React for about 8 years and one thing that always bugged me is how patterns like compound components, render props, and HOCs are taught. Most resources just throw code at you without giving you a mental model for when to actually reach for each one.

So I tried a different approach. I mapped each pattern to a LEGO connection type:

- Compound components = hinge pieces (two parts sharing one mechanism)

- Render props = Technic pins (one connection point, anything can plug in)

- HOCs = baseplates (invisible foundation, every structure benefits)

- Custom hooks = instruction manuals (same bricks, different build)

- Container/presentational = display stands (model and base built separately)

Each one has code examples, when to use it, and more importantly when NOT to use it. Also covered how they layer together in a real codebase.

Would love feedback from this sub. Especially curious if the analogy approach makes things clearer or if it just adds noise.

https://www.sethi.io/blog/react-component-design-patterns-the-building-blocks-lego

I built a visual frontend asset library so I can stop losing my own UI snippets

As a web developer, I often build or collect small frontend assets that are useful later: buttons, gradients, loaders, hover effects, CTAs, footers, bento grids, layout fragments and product UI patterns.

The problem is that these assets usually end up scattered across old projects, screenshots, notes, CodePens, local folders or random files. When I need one, I know I already made something similar, but finding it takes too long.

So I built UI IP Toolkit: a static visual catalog for fast access to my copy-ready frontend assets.

Live site: https://ui-ip-toolkit.vercel.app/ GitHub: https://github.com/ikerperez12/UI-IP-Toolkit-v4.0

What it is

UI IP Toolkit is a public, static frontend asset library. It is designed to be browsed visually, not as a package install.

It includes sections for:

• Buttons and interaction states
• Gradients and color systems
• Loading patterns
• Text effects
• Hover treatments
• Glass surfaces
• CTAs and pricing blocks
• Footers
• Bento grids
• Navigation patterns
• 404 and recovery pages
• Product UI patterns
• Layout fragments and reusable CSS utilities

Every card is meant to be practical: open the site, scan visually, copy the snippet, adapt it, and move on.

Why I made it static

I wanted the toolkit to be simple, fast and easy to publish:

• No backend
• No runtime framework dependency
• No account required
• No build step needed for browsing
• Self-hosted fonts and assets
• Deployed as a static site on Vercel

The goal was not to create a huge npm package or a rigid design system. I wanted a personal working library that feels visual and fast enough to use during real frontend work.

The main use case

When I am building a new page or feature, I can open the toolkit and quickly find a starting point:

• Need a loader? Go to Loading States.
• Need a CTA? Open CTA Blocks or Purchase CTAs.
• Need a footer? Open Footer Systems.
• Need a visual layout idea? Open Bento Systems.
• Need a small CSS utility? Open the utilities section.

It is basically a visual memory layer for reusable frontend work.

Tech stack

The project is intentionally simple:

• HTML
• CSS
• Vanilla JavaScript
• Local fonts
• Local media assets
• Vercel static hosting

The repository is public here:

https://github.com/ikerperez12/UI-IP-Toolkit-v4.0

The live version is here:

https://ui-ip-toolkit.vercel.app/

What I learned

The biggest improvement was not adding more components. It was making the catalog easier to navigate.

Once the toolkit had many sections, a long top nav became useless. I replaced it with a compact section menu grouped by category. That made the site feel much more like a real working tool instead of a long landing page.

I also learned that previews matter a lot. If every card looks too similar, the library feels bigger than it is useful. So I spent time making the previews more varied and more realistic while keeping the site lightweight.

Feedback welcome

I am sharing this because I think other frontend developers might have the same problem: useful assets scattered everywhere, but no quick visual way to reuse them.

Would you use a personal visual asset catalog like this in your own workflow? And what sections would you add next?

Live site: https://ui-ip-toolkit.vercel.app/ GitHub: https://github.com/ikerperez12/UI-IP-Toolkit-v4.0