React developer portfolio

Hiring managers screening React talent want to see what a component looks like under the hood, not a portfolio of screenshots. The walkthrough below is one real component shipping on this site — the magnetic CTA button — and the decisions behind it. If this is the depth you screen for, the rest of my codebase looks like this.

Server-first by default, client only where motion lives

The button itself is a Server Component — pure markup, no JS shipped to the browser for the static case. The magnetic motion effect lives in a Client Component wrapper. Static buttons stay zero-JS; interactive ones pay only for the motion code. This is the App Router pattern most teams misuse by marking the whole tree client-side.

Typed component API, no any

Props are typed with a discriminated union — the button can be a link, a form submit, or a popover trigger, and the prop shape changes per variant. TypeScript catches the wrong combination at compile time. Children is ReactNode; className merges via cn(); ref forwards through with forwardRef and proper generic inference. No prop gets a default that masks a missing value.

Accessibility from the first commit

Focus ring uses :focus-visibleso keyboard users get the outline and mouse users don't. The motion effect respects prefers-reduced-motion — users with motion sensitivity get a static button, not a degraded experience. Disabled state sets aria-disabled and tabIndex=-1, not just visual opacity.

Design tokens, not magic numbers

Every color, radius, and spacing value comes from CSS variables that map to Tailwind's theme extension. When the design system changes a token, every component picks it up — no find-and-replace, no drift. The button doesn't know what “black” means; it knows what --foreground means.

Tested at the boundary that matters

Unit tests would prove the className composition works — which isn't the bug worth catching. Instead, Playwright covers the actual user paths: keyboard focus order, the popover opens, the form submits, the magnetic motion doesn't break layout. Tests at the user boundary, not the implementation boundary.

That's one component. A typical SaaS build has fifty of them. The discipline scales: typed APIs, server-first defaults, accessibility from commit one, tokens for everything, tests where users actually click.