{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidsf4hf66nj5opklo42zygekfxqw3swhcj6nasqthrroqhhskrwm4",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3monv7g57ort2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihmit2426jq7km6uwnkpqkqksneu4qtr6s3cheiggr3oopxbotqz4"
    },
    "mimeType": "image/webp",
    "size": 138120
  },
  "path": "/kensaadi/i-gave-tailwind-typed-props-then-it-ate-react-hook-form-1dlj",
  "publishedAt": "2026-06-19T17:31:59.000Z",
  "site": "https://dev.to",
  "tags": [
    "react",
    "tailwindcss",
    "typescript",
    "frontend",
    "tailwind-variants",
    "Radix",
    "DashForge",
    "https://github.com/kensaadi/dashforge",
    "https://dashforge-ui.com/tw",
    "@dashforge"
  ],
  "textContent": "I spent years thinking my React forms were a CSS problem.\n\nThey weren't. They were a _wiring_ problem — and I'd been paying for it on every single field, in every single project.\n\nThis 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.\n\n##  It started with className\n\nLike most React developers, I've written this code thousands of times:\n\n\n\n    <div className=\"flex items-center justify-between gap-4 p-4 rounded-xl bg-white\">\n\n\nThere'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.\n\nBut after years of building business apps, one thing kept nagging me.\n\nReact 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.\n\nSo I asked a dumb question:\n\n> What would Tailwind components look like if every utility that mattered were a typed prop instead of a substring?\n\n##  Props-first, on top of Tailwind\n\nInstead of a className soup, I wanted the visual API to be the type system:\n\n\n\n    <Button variant=\"solid\" color=\"primary\" size=\"md\">\n      Save\n    </Button>\n\n\n`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.\n\n`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.\n\nUnder 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.\n\n> \"Wait, this is just Chakra / MUI's `sx`.\"\n\nFair — 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.\n\nAnd honestly? The styling was never the interesting part. It was just the door.\n\n##  Then React Hook Form happened\n\nThe first real app exposed the actual problem.\n\nA typical RHF field looks like this:\n\n\n\n    <Controller\n      name=\"email\"\n      control={control}\n      render={({ field, fieldState }) => (\n        <>\n          <input {...field} />\n          {fieldState.error && <p>{fieldState.error.message}</p>}\n        </>\n      )}\n    />\n\n\nNothing 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.\n\nSo I asked the next dumb question: _why does every developer manually re-connect every field to the form?_\n\nWhat if the component already understood forms?\n\n\n\n    <TextField name=\"email\" label=\"Email\" />\n    <PasswordField name=\"password\" label=\"Password\" />\n\n\nNo `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.\n\nThis 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.\n\n##  Fields that know when they exist\n\nEvery app eventually grows dependent fields:\n\n\n\n    const customerType = watch(\"customerType\");\n\n    useEffect(() => {\n      if (customerType !== \"business\") setValue(\"vatNumber\", \"\");\n    }, [customerType]);\n\n\nA `watch`, a conditional render, a cleanup effect — per rule, times hundreds of rules. That's not business logic. It's plumbing.\n\nWhat if the field described its own condition?\n\n\n\n    <TextField\n      name=\"vatNumber\"\n      visibleWhen={{ field: \"customerType\", equals: \"business\" }}\n    />\n\n\nNo `watch`. No effect. No manual reset. The field already knows when it should be on screen — and the engine handles the teardown.\n\n##  Buttons that know who's allowed to press them\n\nSame story with permissions, scattered across every screen:\n\n\n\n    {permissions.includes(\"invoice:update\") && <button>Save</button>}\n\n\nWhy is that check _outside_ the component? Why doesn't the button know who can use it?\n\n\n\n    <Button access=\"invoice:update\">Save</Button>\n\n\nThe 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.\n\n##  The part I didn't plan\n\nHere's the reveal, and it's the bit I'm actually proud of.\n\nThere are **two** component libraries: one rendered with MUI, one rendered with Tailwind + Radix. Same component names, same orchestration props — `name`, `visibleWhen`, `access` — different pixels.\n\nThey share **zero styling code**.\n\nWhat 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.\n\nThat'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.\n\n##  Where this lives\n\nThis 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.\n\nIf the orchestration idea resonates — if you've also written the same `watch` / `useEffect` / permission check for the hundredth time — the repo is here:\n\n👉 **https://github.com/kensaadi/dashforge**\n👉 **https://dashforge-ui.com/tw**\n\nA 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.",
  "title": "I gave Tailwind typed props. Then it ate React Hook Form."
}