I gave Tailwind typed props. Then it ate React Hook Form.

I spent years thinking my React forms were a CSS problem.

They weren't. They were a wiring problem — and I'd been paying for it on every single field, in every single project.

This is the story of how questioning one small thing — why is styling hidden inside strings? — led me somewhere I didn't expect: to components that already know what form they live in, who's allowed to use them, and when they should exist at all.

It started with className

Like most React developers, I've written this code thousands of times:

<div className="flex items-center justify-between gap-4 p-4 rounded-xl bg-white">

There's nothing wrong with Tailwind. It solved a real category of problems that hand-written CSS created — naming, dead styles, cascade surprises. I'm not here to relitigate that. I reach for it on every project.

But after years of building business apps, one thing kept nagging me.

React is built around props. Everything is a prop. Except styling — layout, spacing, color, visual state — which lives inside one big opaque string. No autocomplete. No type-checking. No refactor safety. The compiler has no idea what's in there.

So I asked a dumb question:

What would Tailwind components look like if every utility that mattered were a typed prop instead of a substring?

Props-first, on top of Tailwind

Instead of a className soup, I wanted the visual API to be the type system:

<Button variant="solid" color="primary" size="md">
  Save
</Button>

variant, color, size — autocompleted, type-checked, self-documenting. Behind the scenes each one still resolves to plain Tailwind utility classes (compiled with tailwind-variants), and every color and spacing value comes from design tokens wired into the Tailwind config through a preset — not magic numbers, the same scale across the whole system.

className isn't even on the component. There's exactly one override path: an sx escape hatch, where tailwind-merge guarantees your utility wins over the variant's. One way in, no specificity roulette.

Under the hood the interactive primitives are Radix (and React Aria for the hard ones), so accessibility, focus management, and keyboard behavior aren't something I reinvented badly at 11pm.

"Wait, this is just Chakra / MUI's sx."

Fair — props-first styling isn't a new idea, and I'm not going to pretend I invented it. But there's a real difference: this is build-time Tailwind utilities over headless Radix primitives, not a runtime CSS-in-JS engine. Dark mode is a CSS-variable swap from a theme layer — the same class resolves to a different value when a data- attribute flips, no dark: explosion in every recipe.

And honestly? The styling was never the interesting part. It was just the door.

Then React Hook Form happened

The first real app exposed the actual problem.

A typical RHF field looks like this:

<Controller
  name="email"
  control={control}
  render={({ field, fieldState }) => (
    <>
      <input {...field} />
      {fieldState.error && <p>{fieldState.error.message}</p>}
    </>
  )}
/>

Nothing wrong with it. But by your 50th field, the shape is undeniable. Controller, render prop, field wiring, error wiring — copy, paste, again. And again. And again.

So I asked the next dumb question: why does every developer manually re-connect every field to the form?

What if the component already understood forms?

<TextField name="email" label="Email" />
<PasswordField name="password" label="Password" />

No Controller. No render prop. No error plumbing. The field reads its value, validation state, and error directly from a form bridge via context — and it errors only after blur or submit, so you don't get red text screaming at someone mid-keystroke.

This is where I stopped thinking I'd rebuilt Tailwind. The real cost in business UIs was never CSS or even rendering. It was orchestration — the glue wiring everything to everything else.

Fields that know when they exist

Every app eventually grows dependent fields:

const customerType = watch("customerType");

useEffect(() => {
  if (customerType !== "business") setValue("vatNumber", "");
}, [customerType]);

A watch, a conditional render, a cleanup effect — per rule, times hundreds of rules. That's not business logic. It's plumbing.

What if the field described its own condition?

<TextField
  name="vatNumber"
  visibleWhen={{ field: "customerType", equals: "business" }}
/>

No watch. No effect. No manual reset. The field already knows when it should be on screen — and the engine handles the teardown.

Buttons that know who's allowed to press them

Same story with permissions, scattered across every screen:

{permissions.includes("invoice:update") && <button>Save</button>}

Why is that check outside the component? Why doesn't the button know who can use it?

<Button access="invoice:update">Save</Button>

The rule lives where it matters — on the node itself. Unauthorized can mean hide, disable, or readonly, your call. The permission logic stops being a render-time && smeared across the codebase.

The part I didn't plan

Here's the reveal, and it's the bit I'm actually proud of.

There are two component libraries: one rendered with MUI, one rendered with Tailwind + Radix. Same component names, same orchestration props — name, visibleWhen, access — different pixels.

They share zero styling code.

What they do share is one headless engine: the form bridge, the visibility engine, the RBAC layer. The application-awareness — what a field knows about the app it lives in — is a separate, framework-agnostic core. The styling layer is swappable. The intelligence underneath is not.

That's when it clicked. I wasn't building UI components anymore. I was building application-aware components — things that understand styling, forms, validation, visibility, and permissions, not because they contain business logic, but because they understand how they participate in an application.

Where this lives

This is DashForge — React + MUI + React Hook Form + Tailwind CSS, with the Tailwind track (@dashforge/tw) built on Radix and tailwind-variants. It's an early alpha; the core architecture is already running in real apps, the API surface is still settling.

If the orchestration idea resonates — if you've also written the same watch / useEffect / permission check for the hundredth time — the repo is here:

👉 https://github.com/kensaadi/dashforge
👉 https://dashforge-ui.com/tw

A star helps me gauge whether to keep pushing this. And I'd genuinely like to hear how you deal with form orchestration at scale — drop it in the comments.

推荐订阅源

DEV Community