DEV Community: kensaadi

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

kensaadi — Fri, 19 Jun 2026 17:31:59 +0000

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.

Production RBAC patterns for Go and Node startups

kensaadi — Wed, 17 Jun 2026 09:56:56 +0000

A founder told me last year:

"We need admin features shipped by Friday. Can we just hardcode the roles for now?"

That was 7 months ago. They're still paying for that decision today.

This article is the breakdown I wish I had given them before that Friday — the patterns that separate a quick MVP version of RBAC from one that won't bite you back in six months.

If you're a startup CTO, technical founder, or senior engineer about to ship admin/dashboard features for the first time, this is for you.

The 4 signs your RBAC is a time bomb

I've reviewed this exact pattern in 5+ early-stage codebases. Every one of them eventually hit the wall. Look for these signs:

1. Roles hardcoded in the JWT

{
  "sub": "user_123",
  "role": "admin"
}

Simple. Until you need to:

Add a new role → migration + token refresh strategy
Give one user a temporary elevated permission → "we'll just reissue tokens"
Audit who had admin last month → good luck

2. Permission checks scattered across 40+ controllers

// In every single handler:
if user.Role != "admin" {
    return c.Status(403).JSON(...)
}

By the time you have 30 endpoints, you've made the same mistake 30 times. Refactoring is a full sprint.

3. One admin superuser that can do everything

Until a sales rep accidentally deletes a customer record because they were elevated to admin "just for that one task last week."

4. Zero audit trail

When the data goes missing, your only investigative tool is git blame on the source code and a desperate grep through CloudWatch logs.

If you've nodded at any of these — keep reading.

The real problem: policies-as-code

Most teams treat permissions like business logic. They live in source files, gated by if statements, deployed with the rest of the code.

This is the original sin.

Code changes need deploys. Permissions change daily.

When marketing onboards a new role next quarter, when a customer success rep needs view-only access to billing, when legal asks "who could have read this customer's data on Tuesday at 3pm?" — every one of these requires a permission change. If permissions live in code, every one of these requires a deploy.

Production RBAC starts with one shift in mental model: permissions are data, not code.

Three rules for production-grade RBAC

Rule 1: Policy-as-data, not policy-as-code

Policies live in your database. Source code only knows how to check them, not define them.

A reasonable schema (Postgres flavor, equivalent in MongoDB):

-- Roles
CREATE TABLE roles (
  id         SERIAL PRIMARY KEY,
  name       TEXT UNIQUE NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Permissions (action on resource)
CREATE TABLE permissions (
  id         SERIAL PRIMARY KEY,
  resource   TEXT NOT NULL,   -- e.g., "orders", "customers"
  action     TEXT NOT NULL,   -- e.g., "read", "delete"
  UNIQUE (resource, action)
);

-- Role <-> Permission mapping
CREATE TABLE role_permissions (
  role_id        INTEGER REFERENCES roles(id),
  permission_id  INTEGER REFERENCES permissions(id),
  PRIMARY KEY (role_id, permission_id)
);

-- User <-> Role mapping
CREATE TABLE user_roles (
  user_id  INTEGER REFERENCES users(id),
  role_id  INTEGER REFERENCES roles(id),
  PRIMARY KEY (user_id, role_id)
);

In MongoDB the same idea is one document per role:

{
  "_id": "sales",
  "permissions": [
    { "resource": "customers", "action": "read" },
    { "resource": "orders",    "action": "read" },
    { "resource": "orders",    "action": "create" }
  ],
  "updatedAt": "2026-06-10T14:00:00Z"
}

The difference: now you change a permission with UPDATE, not with git push.

Rule 2: Granular permissions (action-level, not role-level)

The wrong abstraction is role === permission. The right abstraction is permission === (resource, action).

Bad:

if user.Role == "admin" { /* do everything */ }

Good:

if user.Can("orders", "delete") { /* delete the order */ }

The Can() function looks up: does this user, through any of their roles, have the permission (orders, delete)? Cache it per-request with the user's permission set loaded once on auth.

This means:

New permission? Insert one row. No deploy.
Promote a role? Add a row to role_permissions. No deploy.
Demote a user? Remove a row from user_roles. No deploy.

Rule 3: Audit trail — non-negotiable

Every sensitive action logs to an append-only table:

CREATE TABLE audit_log (
  id         BIGSERIAL PRIMARY KEY,
  actor_id   INTEGER REFERENCES users(id),
  action     TEXT NOT NULL,              -- e.g., "order.delete"
  resource   TEXT NOT NULL,              -- e.g., "orders/42"
  before     JSONB,                      -- snapshot before
  after      JSONB,                      -- snapshot after (NULL for delete)
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

Append-only. No UPDATE, no DELETE. When the customer record disappears, you have a complete trail of who, when, and what changed.

This sounds like overhead until the first time you need it. Then it's the cheapest insurance you ever bought.

RBAC vs ABAC vs ReBAC: which one do you need?

A quick decision tree:

Plain RBAC — most startups need this and nothing more.

Users have roles. Roles have permissions. Done.

ABAC (Attribute-Based Access Control) — only if your access depends on attributes of the request, not just the user.

"Sales reps can only see customers in their region"
"This document is editable only during business hours"
ABAC adds policy engines and complexity. Skip unless required.

ReBAC (Relationship-Based, Zanzibar-style) — only for sharing/multi-tenant graphs.

"User A shared this document with User B who shared a folder with Team C"
Google Docs, Notion, Figma need this. Your B2B SaaS probably doesn't.

If you're not sure — start with RBAC + audit log. You can always layer ABAC on top later.

A concrete implementation walkthrough

Here's the minimal viable production-grade RBAC in real code.

Go middleware (Fiber)

package middleware

import (
    "github.com/gofiber/fiber/v2"
)

type PermissionChecker interface {
    Can(userID int, resource, action string) (bool, error)
}

func RequirePermission(checker PermissionChecker, resource, action string) fiber.Handler {
    return func(c *fiber.Ctx) error {
        userID := c.Locals("user_id").(int)

        allowed, err := checker.Can(userID, resource, action)
        if err != nil {
            return c.Status(500).JSON(fiber.Map{"error": "permission check failed"})
        }
        if !allowed {
            return c.Status(403).JSON(fiber.Map{"error": "forbidden"})
        }
        return c.Next()
    }
}

// Usage in routes:
// app.Delete("/orders/:id",
//     RequirePermission(permChecker, "orders", "delete"),
//     handlers.DeleteOrder)

The middleware is stateless about which roles exist. It just asks: "can this user do this action on this resource?" The answer comes from the DB.

Node middleware (Express)

// middleware/requirePermission.js
function requirePermission(checker, resource, action) {
  return async (req, res, next) => {
    try {
      const allowed = await checker.can(req.user.id, resource, action);
      if (!allowed) {
        return res.status(403).json({ error: 'forbidden' });
      }
      next();
    } catch (err) {
      return res.status(500).json({ error: 'permission check failed' });
    }
  };
}

module.exports = requirePermission;

// Usage:
// router.delete('/orders/:id',
//   requirePermission(permChecker, 'orders', 'delete'),
//   handlers.deleteOrder);

Same pattern, different language. The permission set is loaded once at login and cached on the user session — checker.can() is an in-memory lookup against a Set per request.

Frontend gating: where most teams stop too early

Most articles end here with a one-component <Can> example and a "server-side check is the source of truth" disclaimer. That's correct, but it's the bare minimum of what production RBAC needs on the frontend.

A real RBAC layer on the frontend has at least 5 concerns:

Hook-level access — read user permissions anywhere without prop drilling
Inline gating — show/hide buttons, columns, table actions
Route-level gating — block entire pages, redirect unauthorized users
Admin UI — non-engineers need to view/edit roles and permissions
Audit visibility — someone needs to read the audit log without DB access

Skip any of these and you'll re-invent them six months later. Here's the shape they should have.

1. The hook

// useAuth() returns user + a Set of permission keys
const { user, permissions } = useAuth();

// usePermissions() is a focused alias when you don't need user data
const permissions = usePermissions();

permissions.has('orders:delete');  // true | false
permissions.canAny(['orders:delete', 'orders:archive']);
permissions.canAll(['customers:read', 'customers:update']);

The permission set is loaded once on auth, cached in React context, and every check is O(1).

2. Inline gating with `<Can>`

<Can resource="orders" action="delete">
  <DeleteButton onClick={handleDelete} />
</Can>

// With a fallback (shows a disabled button + tooltip instead of hiding)
<Can
  resource="orders"
  action="delete"
  fallback={<DisabledButton tooltip="You don't have permission to delete orders" />}
>
  <DeleteButton onClick={handleDelete} />
</Can>

// With multiple permissions (any of these is enough)
<Can anyOf={["orders:delete", "orders:archive"]}>
  <DangerActions />
</Can>

The fallback prop is the key detail most implementations miss. Hiding a button creates a worse UX than showing it disabled with a "why you can't" tooltip — users feel less broken when they know the rule exists.

3. Route-level gating with `<RoleGuard>`

// Inside the router
<Route
  path="/admin/orders"
  element={
    <RoleGuard
      anyOf={["orders:read"]}
      fallback={<ForbiddenPage />}
      redirect="/dashboard"
    >
      <OrderManagementPage />
    </RoleGuard>
  }
/>

Whole pages refuse to render. Better than letting the user load the page and then erroring on every API call.

4. The admin UI — the part nobody writes themselves

This is where DIY RBAC implementations fall apart. Engineers build the middleware and the hook and stop. Then someone in product asks: "Can sales also export customers?" and the answer is: "Sure, I'll deploy that change next week."

A real admin UI lets non-engineers:

See the role × permission matrix (the same diagram everyone draws on a whiteboard)
Toggle permissions per role with a click
Assign users to roles
See the audit log filterable by actor, action, date range, IP

This is what an <PermissionMatrix> admin component looks like from the consumer side:

<PermissionMatrix
  roles={roles}                  // ["customer", "sales", "admin"]
  resources={resources}          // ["orders", "customers", "products"]
  actions={["read", "create", "update", "delete"]}
  value={currentPolicy}          // current role × permission map
  onChange={handlePolicyChange}  // saves to DB, no deploy
  readonly={!permissions.has('admin:manage_roles')}
/>

Behind it: the same roles / permissions / role_permissions tables from Rule #1. Edits hit the DB directly. No code change, no deploy, no engineer in the loop.

5. The audit log viewer

<AuditLogViewer
  filters={{
    actor: userId,
    actionPrefix: "order.",       // "order.delete", "order.update", etc.
    dateRange: last30Days
  }}
  columns={["actor", "action", "resource", "before", "after", "ip"]}
  exportable                     // CSV export for compliance reviews
  paginate
/>

When the data goes missing or the auditor asks who did what, you don't psql into prod. You filter the UI.

Audit logging in two lines

Wrap your mutation handlers with a logger:

func DeleteOrder(c *fiber.Ctx) error {
    orderID := c.Params("id")
    order, _ := db.GetOrder(orderID)

    if err := db.DeleteOrder(orderID); err != nil {
        return err
    }

    audit.Log(c.Locals("user_id").(int), "order.delete",
        "orders/"+orderID, order, nil, c.IP(), c.Get("User-Agent"))

    return c.SendStatus(204)
}

Same pattern in Node. The audit log table is append-only. Months from now, when something disappears, you'll have the full trail.

The RBAC layer in Dashforge — what end-to-end actually looks like

Everything above — the schema, the middleware, the hooks, the components, the admin UI — is the actual design of the RBAC layer in Dashforge.

The reason this article exists is that every piece of this puzzle is usually built separately by separate teams, in different shapes, with different bugs. The middleware is in one repo, the React <Can> is invented case-by-case, the audit log is "TODO for next sprint", the admin panel never gets built. Six months later you have four half-finished RBAC systems that don't talk to each other.

Dashforge ships them as one coherent layer:

The full stack, day-1 ready

┌──────────────────────────────────────────────────────────────────┐
│  Admin UI (React)                                                 │
│  ── PermissionMatrix   roles × actions toggle grid                │
│  ── UserRolesEditor    assign/revoke roles per user               │
│  ── AuditLogViewer     filter, search, CSV export                 │
└─────────────────┬────────────────────────────────────────────────┘
                  │ same auth context, same permission set
┌─────────────────▼────────────────────────────────────────────────┐
│  React components                                                 │
│  ── useAuth()  /  usePermissions()  /  <Can>  /  <RoleGuard>      │
│  Available in BOTH Tailwind and MUI flavors                       │
└─────────────────┬────────────────────────────────────────────────┘
                  │ HTTP, JWT carries user_id only
┌─────────────────▼────────────────────────────────────────────────┐
│  Backend middleware                                               │
│  ── Go (Fiber) and Node (Express) — same contract                 │
│  ── RequirePermission(resource, action)                           │
│  ── Audit log middleware (auto-wraps mutations)                   │
└─────────────────┬────────────────────────────────────────────────┘
                  │
┌─────────────────▼────────────────────────────────────────────────┐
│  Database (MongoDB, Postgres-ready via provider pattern)          │
│  ── roles, permissions, role_permissions, user_roles, audit_log   │
└──────────────────────────────────────────────────────────────────┘

Single source of truth — the database. Every layer reads from the same tables. You change a permission once, the change propagates automatically:

Middleware blocks unauthorized requests
React <Can> hides UI accordingly
Audit log records everything
Admin panel reflects the new state

No code changes anywhere. No deploy.

What you get on day 1

When you open the checkout-kit, the RBAC layer is already wired up with three working roles and the full admin UI:

Backend (Go or Node — pick one):

RequirePermission(resource, action) middleware wrapping every protected route
PolicyChecker service that loads user permissions on auth, caches them per session
Audit logger that wraps mutation handlers automatically (no per-handler boilerplate)
REST endpoints for /admin/roles, /admin/permissions, /admin/users/:id/roles, /admin/audit-log

Frontend (Tailwind OR MUI flavor — both shipped):

<AuthProvider> initialized in your root component
useAuth() and usePermissions() hooks ready to import
<Can> with fallback, anyOf, allOf props — the full API documented above
<RoleGuard> for route-level protection (drop-in for React Router)
<PermissionMatrix> admin component — pre-styled, pre-wired to the API
<UserRolesEditor> — searchable user list with role assignment
<AuditLogViewer> — filterable, exportable, paginated

Three roles, pre-seeded:

customer — read their own orders, update their own profile
sales — read/create/update orders and customers, no delete
admin — everything, plus role/permission management

Extending to a fourth role is one row in the roles table and a few clicks in the admin UI. No code change required.

Why bundling matters

You can build all of this yourself. Here's the realistic timeline I've seen in startups:

Component	Time to build properly (mid-senior engineer)
DB schema + migrations	4-6 hours
Middleware Go + Node	6-10 hours
React hooks + Context	4-6 hours
`<Can>` + `<RoleGuard>` with edge cases	6-10 hours
`<PermissionMatrix>` admin UI	16-24 hours
`<UserRolesEditor>` with search/pagination	8-16 hours
`<AuditLogViewer>` with filters/export	12-20 hours
Audit middleware + before/after snapshot logic	8-12 hours
End-to-end tests, documentation, bugfixes	16-24 hours
Total realistic	80-130 hours (2-3 weeks)

That's not counting design iterations, the inevitable "wait, we forgot about row-level permissions" mid-sprint, or onboarding a new engineer who needs to understand all of it.

Dashforge ships it all on day 1, in your repo, code you own. You modify it freely. There's no SaaS subscription, no vendor lock-in, no monthly fee. Buy it once, deploy it forever.

How it composes with the rest of the kit

The checkout-kit isn't just RBAC. The same auth + permission layer also powers:

Stripe checkout flow — pricing tiers gated by role (admin sees test-mode toggles, customer sees buy CTAs only)
Product catalog — sales can create products, customer can only browse
Order management — full CRUD for admin/sales, read-only for customer
Multi-tenant ready — extend the policy with a tenant_id column and you have row-level security
Stripe webhook handlers — already protected with API-key auth, audit logged

The whole thing is one repo, one auth model, one permission set. Not five disconnected libraries glued together with hope.

If you're about to start building this from scratch — pause and take a look at the kit. You'll save 2-3 weeks of work and get a layer that's already been thought through. Drop a comment if you want me to share more on a specific piece (the schema migrations, the audit log middleware, the admin UI patterns).

Your turn

If you've shipped RBAC in production recently, I'd love to hear what tradeoffs you made:

Did you build from scratch, or use a library (Casbin, Oso, Permify)?
ABAC, ReBAC, or plain RBAC + audit?
What's the one thing you'd do differently?

Drop a comment — I'm collecting patterns for a follow-up piece on RBAC at scale (10K+ users, multi-tenant).

If you found this useful and want more deep-dives on Go/Node infrastructure patterns for startups, follow me here on dev.to.

I've built Stripe checkout from scratch 3 times. Here's what no one tells you.

kensaadi — Tue, 16 Jun 2026 08:19:44 +0000

Every time a client needs an e-commerce feature, the conversation starts the same way.

"We need Stripe checkout. How long?"
And every time I say two months, they look at me like I'm padding the estimate.

I'm not.

Here's what's actually hiding inside "just add Stripe checkout."

1. The cart is not a frontend problem

The instinct is to keep cart state in React. useState, maybe Zustand, done in an afternoon.

Then your user adds items on desktop, opens their phone, and the cart is empty.

A production cart lives on the server. Every add/remove/update hits an API. The frontend is a view, not the source of truth. That's a full Mongoose model, a set of CRUD endpoints, and session-aware middleware — before you've touched Stripe at all.

2. Stripe SCA is not Stripe Checkout

SCA (Strong Customer Authentication) is mandatory in Europe and increasingly common everywhere. It means the payment flow isn't a single redirect — it's a multi-step confirmation that your frontend has to handle gracefully.

const paymentIntent = await stripe.paymentIntents.create({
  amount: orderTotal,
  currency: 'usd',
  automatic_payment_methods: { enabled: true },
});

Then on the client, you're handling requires_action, requires_payment_method, and succeeded states separately. Each one needs a different UI path.

3. Webhooks are where things break in production

The payment succeeded on the client. Great. But your server doesn't know yet.

Webhooks are how Stripe tells your backend what actually happened — and they arrive asynchronously, out of order, and sometimes more than once.

const event = stripe.webhooks.constructEvent(
  req.body,
  req.headers['stripe-signature'],
  process.env.STRIPE_WEBHOOK_SECRET
);

switch (event.type) {
  case 'payment_intent.succeeded':
    await fulfillOrder(event.data.object);
    break;
  case 'charge.refunded':
    await handleRefund(event.data.object);
    break;
}

You need idempotency handling, signature verification, and a clear fulfillment model. Miss any of these and you'll have orders that paid but never confirmed — or confirmed twice.

4. Order management is a separate product

Once the payment goes through, you need:

A customer view (what did I order, what's the status)
An admin view (filter all orders, update status, process refunds)
Status transitions that make sense (pending → paid → shipped → delivered)

That's two full UIs and a state machine. Not complex — but a lot of screens.

5. The admin dashboard needs RBAC from day one

Without role-based access control, your admin routes are either wide open or you're scattering if (user.isAdmin) checks across the codebase. Neither scales.

A proper RBAC middleware layer means routes declare what they need and middleware enforces it:

router.get('/admin/orders',
  authenticate,
  requireRole('admin', 'sales'),
  OrderController.getAll
);

Three roles minimum: public, customer, admin. Adding more later is trivial when the pattern is in place from the start.

6. S3 image upload is a full integration on its own

Product images need to live somewhere. That means presigned URLs, upload from the admin form, and references stored in MongoDB. Works with AWS S3 or DigitalOcean Spaces — but either way it's a separate surface to wire correctly.

What this actually adds up to

Every time I've built this stack from scratch, it's taken 6–8 weeks for a senior developer. Not because any single piece is hard — because there are multiple pieces and they all have to work together correctly in production.

After doing it for the third time, I packaged everything into a kit.

Checkout Kit ships with:

React 19 frontend — MUI and Tailwind flavors, both included
Go or Node backend — same API contracts, your choice of runtime
MongoDB, Mongoose, JWT + bcrypt
All 6 surfaces above, already wired together
Mock mode for full frontend dev without a running server
17+ production screens, 35+ API endpoints

Setup to first live checkout: under 15 minutes.

Live demo (no signup): https://checkout-kit.dashforge-ui.com
Full details: https://dashforge-ui.com/starter-kits/checkout-kit

Free for the first 5 developers who want to try it

I'm giving the Developer tier away free to the first 5 developers who want to try it.

Try it. Then leave an honest comment with your impressions — what worked, what didn't. No star ratings, no forms. Just real feedback from a real developer.

Comment "interested" below and I'll DM you the link.

Back to React Fundamentals: useEffect, useState, useMemo, useCallback, useReducer

kensaadi — Sat, 09 May 2026 20:06:01 +0000

Updated for React 19.2 (2025)

Over the last few years, the React ecosystem has become increasingly complex.

Server Components, compilers, signals, state managers, meta-frameworks, cache layers, streaming, optimistic UI.

But while everyone is chasing the next big thing, many real-world React problems still come from the same places:

poorly used useEffect
misunderstood dependencies
unnecessary re-renders
premature memoization
oversized components
badly distributed state

This article is a return to fundamentals.

Not theoretical concepts, but the things that truly matter when building scalable and maintainable React applications.

Latest: React 19.2 Release (October 2025)

Concurrent rendering was introduced in React 18 via createRoot, not React 19.

React 19.2 adds several important features:

useEffectEvent — Separate reactive from non-reactive logic in effects
<Activity /> — Hide and restore UI sections with independent state management
cacheSignal — Know when server component cache lifetime is over (RSCs only)
Performance Tracks — New Chrome DevTools performance profiling
Partial Pre-rendering — Pre-render static parts and resume with dynamic content later

Key insight: These features build on the fundamentals below. Master state colocation, dependency management, and component splitting first—then layer in React 19's advanced capabilities.

First rule: React renders functions

When a React component updates:

the component function runs again
all hooks run again
objects and functions declared inside are recreated
React performs reconciliation to identify what actually changed

Example:

function Counter() {
  console.log('Counter render');

  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

Every click:

re-executes Counter
recreates the onClick function
reevaluates the JSX

This is completely normal.

The real problem starts when:

the component becomes huge
it contains too much logic
it renders expensive children
it passes unstable props
it centralizes too much state

And this leads us to the first truly important concept.

Splitting code into components

One of the most powerful ways to optimize React is not useMemo.

It's splitting components correctly.

The most common mistake is putting too much state and UI inside the same component.

Problematic example

function Dashboard() {
  const [count, setCount] = useState(0);

  console.log('Dashboard render');

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Increment: {count}
      </button>

      <ExpensiveChart />
      <ComplexTable />
      <HeavySidebar />
    </div>
  );
}

function ExpensiveChart() {
  console.log('ExpensiveChart render');

  return <div>Chart</div>;
}

function ComplexTable() {
  console.log('ComplexTable render');

  return <div>Table</div>;
}

function HeavySidebar() {
  console.log('HeavySidebar render');

  return <div>Sidebar</div>;
}

Every click updates the state of Dashboard.

As a consequence:

Dashboard re-runs
JSX is recreated
child React elements are recreated
React reevaluates the child tree

So you might see:

Dashboard render
ExpensiveChart render
ComplexTable render
HeavySidebar render

even though those components do not depend on count.

The issue is not the button.

The issue is that the state lives too high in the tree.

Solution: move state closer to where it's actually needed

function Dashboard() {
  console.log('Dashboard render');

  return (
    <div>
      <CounterSection />

      <ExpensiveChart />
      <ComplexTable />
      <HeavySidebar />
    </div>
  );
}

function CounterSection() {
  const [count, setCount] = useState(0);

  console.log('CounterSection render');

  return (
    <button onClick={() => setCount(count + 1)}>
      Increment: {count}
    </button>
  );
}

function ExpensiveChart() {
  console.log('ExpensiveChart render');

  return <div>Chart</div>;
}

function ComplexTable() {
  console.log('ComplexTable render');

  return <div>Table</div>;
}

function HeavySidebar() {
  console.log('HeavySidebar render');

  return <div>Sidebar</div>;
}

Now when you click the button:
render

This is the crucial difference:

A child state update does not automatically force parent components to re-render.

React starts the update from the component whose state changed and only re-renders the necessary part of the tree.

Before refactoring, the state lived in Dashboard, so every click forced Dashboard to run again and recreate the child tree. All children would be re-evaluated as a result.

After refactoring, the state lives inside CounterSection, so the update stays local. The state update triggers a re-render of CounterSection only.

Because Dashboard no longer updates, React has no reason to traverse and re-render those children. ExpensiveChart, ComplexTable, and HeavySidebar are not affected by this state change.

This is the core principle: state that affects only a small part of the UI should live in that part. Where state lives determines where reconciliation starts and what gets re-rendered.

This is the real value of component splitting

You didn't use:

useMemo
useCallback
React.memo

You simply:

isolated responsibilities
localized state
reduced update propagation

Note on React.memo:

React.memo has legitimate uses—wrapping expensive components that receive stable props, or protecting components that receive object/function props. But it's a second-line optimization. Component splitting solves 90% of performance problems without it.

This is one of the most important React optimizations:

State colocation

Keeping state as close as possible to where it is used.

Practical rule

If a piece of state only belongs to a small part of the UI, don't put it in the parent component.

Better:

function Page() {
  return (
    <>
      <Header />
      <SearchBox />
      <Results />
    </>
  );
}

function SearchBox() {
  const [query, setQuery] = useState('');

  return (
    <input
      value={query}
      onChange={(event) => setQuery(event.target.value)}
    />
  );
}

Worse:

function Page() {
  const [query, setQuery] = useState('');

  return (
    <>
      <Header />
      <SearchBox
        query={query}
        setQuery={setQuery}
      />
      <Results />
    </>
  );
}

In the second example, every keystroke may rerun the entire Page.

In the first one, the update stays local.

Component splitting vs Lazy Loading

These two concepts are often confused.

But they solve completely different problems.

Component Splitting

Used for:

isolating responsibilities
limiting state propagation
improving maintainability
making renders more predictable

Lazy Loading

Used for:

loading code only when needed
reducing the initial bundle size
improving initial loading performance

Example:

const AdminPage = lazy(() => import('./AdminPage'));

This does NOT optimize renders.

It optimizes bundle downloading.

useState: values vs references

Before truly understanding useEffect, you need to understand something fundamental:

in JavaScript there are:

primitive values
references

Primitive values

const a = 5;
const b = 5;

console.log(a === b); // true

Objects and arrays

const a = { name: 'Ken' };
const b = { name: 'Ken' };

console.log(a === b); // false

Why?

Because JavaScript compares memory references.

Not contents.

This concept is ESSENTIAL for understanding:

useEffect
useMemo
useCallback
React.memo
re-renders

useEffect: it's not really componentDidMount

Many developers still think of useEffect as:

componentDidMount
componentDidUpdate
componentWillUnmount

It's a useful beginner mental model.

But it's not what useEffect truly is.

useEffect exists to synchronize React with the outside world.

Examples:

APIs
timers
websockets
localStorage
browser events
analytics

useEffect equivalent to didMount

useEffect(() => {
  console.log('mounted');
}, []);

The empty dependency array means:

run the effect only on mount.

Real-world example: API call on mount

For fetch-on-mount scenarios, the nested function pattern is the modern best practice:

function UsersPage() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    async function loadUsers() {
      const response = await fetch('/api/users');

      const data = await response.json();

      setUsers(data);
    }

    loadUsers();
  }, []);

  return <UsersTable users={users} />;
}

Why this pattern?

The function is defined inside useEffect, so it doesn't need to be a dependency
No memoization overhead
Simpler and more readable
The function is isolated to where it's actually used

When you DO need useCallback with useEffect

Only reach for useCallback when loadUsers needs to be called elsewhere or exposed as a stable reference:

function UsersPage() {
  const [users, setUsers] = useState([]);

  const loadUsers = useCallback(async () => {
    const response = await fetch('/api/users');

    const data = await response.json();

    setUsers(data);
  }, []);

  // ✅ Use useCallback here because:
  // - loadUsers is a dependency of useEffect
  // - loadUsers is passed as a prop to child components
  // - loadUsers might be called from multiple places

  useEffect(() => {
    loadUsers();
  }, [loadUsers]);

  return (
    <div>
      <RefreshButton onRefresh={loadUsers} />
      <UsersTable users={users} />
    </div>
  );
}

The key difference:

Nested function: Simpler, no memoization. Use when the function only belongs inside useEffect.
useCallback: Overhead, but necessary when the function is a dependency or needs to be stable across renders.

Default approach: Start with the nested function. Only add useCallback if you actually need a stable reference.

Why you should NOT use async directly in useEffect

Common mistake:

useEffect(async () => {
  // NO
}, []);

Because useEffect expects:

void
or a cleanup function

An async function always returns a Promise.

Cleanup function

useEffect(() => {
  const interval = setInterval(() => {
    console.log('tick');
  }, 1000);

  return () => {
    clearInterval(interval);
  };
}, []);

The cleanup function runs:

on unmount
before the next effect execution

useEffect as didUpdate

Single dependency

useEffect(() => {
  console.log('count changed');
}, [count]);

The effect runs when count changes.

Multiple dependencies

useEffect(() => {
  console.log('filters changed');
}, [search, page, sort]);

It runs whenever at least one dependency changes.

Object dependencies

This is where many real-world problems begin.

const filters = {
  search,
  page,
};

useEffect(() => {
  console.log('filters changed');
}, [filters]);

This effect will run EVERY render.

Why?

Because the object is recreated every render.

Solution with useMemo

const filters = useMemo(() => {
  return {
    search,
    page,
  };
}, [search, page]);

Now the reference stays stable.

useMemo: when to actually use it

useMemo is NOT for:

"optimizing React"
"avoiding renders"
"making everything faster"

It's for memoizing expensive values or stabilizing references.

Important: useMemo is a performance optimization hint, not a semantic guarantee. React may discard memoized values in some scenarios, especially during development, concurrent rendering, or future internal optimizations. Never depend on memoization for correctness—only for performance.

Correct use case

const sortedUsers = useMemo(() => {
  return [...users].sort((a, b) =>
    a.name.localeCompare(b.name)
  );
}, [users]);

This makes sense because:

sorting may be expensive
the result gets reused

WRONG use case

const fullName = useMemo(() => {
  return `${name} ${surname}`;
}, [name, surname]);

The cost here is irrelevant.

You added unnecessary complexity.

The problem with memoizing everything

Many modern React projects look like this:

useMemo(...)
useCallback(...)
useMemo(...)
useCallback(...)

everywhere.

This often worsens:

readability
debugging
maintainability

And introduces mental overhead.

Important truth

If your code is properly split:

most of the time you do NOT need useMemo.

useCallback

useCallback memoizes a function.

const handleClick = useCallback(() => {
  console.log('click');
}, []);

It is mainly useful when:

passing callbacks to memoized children
reference stability matters
the function is a dependency of an effect

The real difference between `<Component />` and `{component}`

This is one of the least understood parts of React.

Many developers think:

<Child />

and:

{child}

are equivalent.

They are not.

The difference depends on WHERE the React element is created.

Case 1 — `<Child />` inside render

function Child() {
  console.log('Child render');

  return <div>Child</div>;
}

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>

      <Child />
    </div>
  );
}

Every update of Parent:

reruns Parent
recreates <Child />
React reevaluates the child

So:

Child render

appears on every click.

Case 2 — React element stabilized outside the component

const child = <Child />;

function Child() {
  console.log('Child render');

  return <div>Child</div>;
}

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>

      {child}
    </div>
  );
}

Here:

child is created only once
the reference stays stable
React always receives the same element

So Child does NOT rerun every parent render.

Case 3 — Variable inside render

Many developers do this:

function Parent() {
  const child = <Child />;

  return <div>{child}</div>;
}

But this changes NOTHING compared to:

<Child />

Because:

const child = <Child />;

runs again every render.

So:

new React element
new reference
new reconciliation

React element vs Component Function

This is the key concept.

This:

<Child />

is NOT the component itself.

It's a React element.

An object similar to:

{
  type: Child,
  props: {}
}

When React receives a new element:

it decides whether to render
compares the tree
performs reconciliation

Very common pattern: passing React elements as props

Many modern UI systems use this pattern:

function Layout({ sidebar }) {
  return (
    <div>
      <aside>{sidebar}</aside>
      <main>Content</main>
    </div>
  );
}

Usage:

const sidebar = <Sidebar />;

function App() {
  return <Layout sidebar={sidebar} />;
}

Here sidebar remains stable.

If App rerenders:

React receives the same React element
Sidebar may avoid unnecessary rerenders

But be careful

Do NOT overuse this pattern.

Because it may:

hurt readability
create unexpected behavior
make the component tree less natural

Stabilizing React elements outside render is an advanced optimization pattern. In most applications, proper component splitting and state colocation are significantly more important.

Most of the time:

<Sidebar />

is perfectly fine.

The real React optimization

Modern React optimization is about:

small components
localized state
stable props
simple architecture

Not:

useMemo everywhere
or const child = <Child /> everywhere

useReducer

useReducer is one of the most underrated React hooks.

It is NOT Redux

Many developers associate it with Redux.

But useReducer is simply:

local state management
reducer-based logic
excellent for complex flows

Basic syntax

const initialState = {
  count: 0,
};

function reducer(state, action) {
  switch (action.type) {
    case 'increment':
      return {
        ...state,
        count: state.count + 1,
      };

    case 'decrement':
      return {
        ...state,
        count: state.count - 1,
      };

    default:
      return state;
  }
}

Usage:

const [state, dispatch] = useReducer(
  reducer,
  initialState
);

Dispatch

dispatch({ type: 'increment' });

When to prefer useReducer

useState is perfect for simple state:

const [open, setOpen] = useState(false);

But when you start having:

multiple related states
complex transitions
dependent updates
multi-step flows

useReducer becomes much clearer.

Real-world example: fetch state

const initialState = {
  loading: false,
  error: null,
  data: null,
};

Reducer:

function reducer(state, action) {
  switch (action.type) {
    case 'fetch_start':
      return {
        ...state,
        loading: true,
      };

    case 'fetch_success':
      return {
        loading: false,
        data: action.payload,
        error: null,
      };

    case 'fetch_error':
      return {
        loading: false,
        data: null,
        error: action.payload,
      };

    default:
      return state;
  }
}

Here useReducer makes the flow:

more readable
more predictable
more scalable

React 19 & Beyond: Building on Fundamentals

React 19 introduces powerful new features. React 19.2 adds more. But they all build on the fundamentals covered above.

Server Actions (React 19)

Server Actions simplify async workflows through functions marked with 'use server':

'use server';

async function updateUser(formData) {
  const result = await db.users.update(formData);
  revalidatePath('/users');
  return result;
}

Used in a component:

function UserForm() {
  const [isPending, startTransition] = useTransition();

  return (
    <form action={updateUser}>
      <input name="email" required />
      <button type="submit" disabled={isPending}>
        Save
      </button>
    </form>
  );
}

Why fundamentals apply: Even with Server Actions, you're managing state colocation (isPending stays local), understanding dependencies, and avoiding unnecessary re-renders (React handles submission state automatically).

useActionState & useOptimistic (React 19)

React 19 introduces useActionState for form submissions and useOptimistic for optimistic updates:

function Todo() {
  const [optimisticTodos, addOptimisticTodo] = useOptimistic(todos);

  const [formState, formAction] = useActionState(addTodoAction);

  return (
    <form action={async (formData) => {
      addOptimisticTodo(formData.get('todo'));
      await formAction(formData);
    }}>
      <input name="todo" />
      <button type="submit">Add</button>
    </form>
  );
}

Why fundamentals apply: These APIs handle the complex state management patterns you'd normally need useReducer or useState for—but they're built on the same dependency and state management principles.

useEffectEvent (React 19.2)

useEffectEvent separates reactive from non-reactive logic in effects, formalizing a core concept:

function ChatRoom({ roomId, theme }) {
  const onConnected = useEffectEvent(() => {
    showNotification('Connected!', theme);
  });

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.on('connected', () => {
      onConnected();
    });
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]); // ✅ theme is NOT a dependency
}

Why fundamentals apply: This hook encodes a principle you already understand—effects depend on specific values (roomId matters), and non-reactive logic shouldn't trigger re-effects. Dependencies matter; this hook just makes it explicit.

`<Activity />` (React 19.2)

The Activity component allows sections of the UI tree to be paused, hidden, and resumed independently:

<Activity mode={isVisible ? 'visible' : 'hidden'}>
  <Page />
</Activity>

When hidden, Activity unmounts effects and defers updates. This pre-renders hidden sections without impacting visible performance.

Why fundamentals apply: Activity enables fine-grained control over which parts of the tree are active, following the same principle as state colocation—isolating state and rendering to where it matters.

Conclusion

Most modern React problems are not solved with:

more libraries
more abstractions
more custom hooks
more memoization

They are solved by returning to fundamentals.

Truly understanding:

when React renders
what changes by reference
how dependencies work
when to split components
when NOT to optimize
what referential stability means

is far more valuable than premature micro-optimizations.

Because most of the time, the best React performance does not come from useMemo.

It comes from simple architecture.

Remember: The best React developers are usually not the ones using the most hooks.

They are the ones building the simplest render trees.

Article Version: 2.1 (Updated October 2025 for React 19.2, with technical precision)

# The Hidden Costs of Microfrontends — Interactive Edge Cases

kensaadi — Thu, 07 May 2026 10:49:43 +0000

Companion app for the article "The Hidden Costs of Microfrontends Nobody Talks About."
Six interactive demos that make the architectural failure modes of microfrontends visible: design token drift, dependency mismatches, shared HTTP coupling, store synchronization issues, and the decision of whether to actually go distributed.

No real Module Federation. No real backend. Each demo simulates two or more "microfrontends" inside a single React application so the failure modes stay legible and screenshot-friendly.

Why this exists

Most microfrontend tutorials stop at loading a remote <HelloWorld />. The real problems begin when you have 5 teams, 10 microfrontends, a shared design system, drifting versions, and independent releases. This app reproduces those problems on a single laptop, in a single tab.

The six demos

#	Tab	What it shows
1	Token drift	Two MFEs with their own `tailwind.config.js`. Different primary, different radius, different scale. Toggle to centralize.
2	Shared theme	The MUI counter-example: one `<ThemeProvider>` mutated at runtime, both MFEs update in the same frame.
3	HTTP layer	Isolated vs shared Axios, side by side. Rotate one token, push a breaking interceptor, watch the blast radius.
4	Version hell	Mount four MFEs against a host shell. Mismatched `react`/`@mui/material` versions break the singleton — simulated console shows the warnings you'd see in production.
5	Shared store	A Zustand-style cart shared across two MFEs. Flip "version drift" and watch the singleton silently double into two ghost stores.
6	Should you?	Six honest questions. Live recommendation: Modular Monolith / On the fence / Microfrontends.

Stack

Vite 5 — fast HMR, no config to fight
React 18 + TypeScript 5 — strict mode on
MUI 6 with @emotion/react — both the app shell and the "good case" in demo 2
Plain CSS / inline styles in demo 1 to mimic the Tailwind-utility divergence without dual tooling

Run it locally

npm install
npm run dev      # Vite dev server on http://localhost:5173
npm run build    # tsc -b + production build
npm run preview  # serve the production build

Project layout

src/
├── main.tsx
├── App.tsx                       # tabbed shell wiring the six demos
├── theme.ts                      # canonical MUI theme + design-token contract
├── components/
│   ├── DemoSection.tsx           # title + controls + takeaway wrapper
│   ├── FakeMfePane.tsx           # bordered "microfrontend" frame
│   ├── ConsoleOutput.tsx         # styled pseudo-DevTools for simulated errors
│   └── CodeBlock.tsx             # static syntax-block component
└── demos/
    ├── DesignTokenDrift.tsx
    ├── SharedThemeAdvantage.tsx
    ├── HttpLayerComparison.tsx
    ├── VersionHell.tsx
    ├── SharedStoreMinefield.tsx
    └── DecisionMatrix.tsx

How the simulation works

Token drift / shared theme — Both MFE panes mount in the same React tree. The "isolated" demo passes a different token object to each pane; the "shared" demo wraps them in one ThemeProvider. Same DOM, different sources of truth.
HTTP layer — Two in-memory client objects (one per MFE for "isolated", one global for "shared") with a fake request() method. Buttons mutate client.token or client.broken and each pane logs what it observes.
Version hell — A static table of MFE versions plus a host record. Mounting compares them and pushes simulated React / MUI warnings into the ConsoleOutput component.
Shared store — A tiny FakeStore class with subscribe / set. Healthy mode: both MFE views point at the same instance. Drift mode: each points at its own instance, so increments don't cross.

The failure modes are real even if the runtime is staged — the same code paths exist in any Module Federation setup.

Credits

Article and demos by Ken Saadi.
LinkedIn · repo this example· show demo

Are We Overcomplicating React State? A Look at Valtio

kensaadi — Sat, 02 May 2026 21:47:46 +0000

React State Feels Simple — Until It Doesn't

React state management often feels more complex than it needs to be.

Selectors, memoization, dependency arrays…
we spend a lot of time managing how state updates, not just what the state is.

Recently, I tried Valtio — and it made me rethink some of these patterns.

The usual problem

In many React setups, especially as apps grow, state logic tends to spread:

UI state and business state get mixed
we add selectors to control updates
we optimize re-renders manually
we introduce more abstraction to keep things under control

It works — but it requires constant orchestration.

What felt different with Valtio

Valtio takes a different approach based on proxies.

Instead of thinking in terms of update triggers and subscriptions, you work directly with state:

import { proxy } from 'valtio';

const state = proxy({ count: 0 });

function increment() {
  state.count++;
}

In a component:

import { useSnapshot } from 'valtio';

function Counter() {
  const snap = useSnapshot(state);
  return <button onClick={() => state.count++}>{snap.count}</button>;
}

That's it.

No selectors
No dependency arrays
Minimal boilerplate

Why this matters

The real benefit isn't "less code".
It's less mental overhead.

With this model:

you don't think about when to re-render
you don't orchestrate updates manually
you focus on state, not the mechanics around it

It feels more reactive than controlled.

But this doesn't remove complexity

To be clear: complexity doesn't disappear.

In real-world apps, especially with:

dynamic forms
derived state
async flows

you still need structure.

But shifting complexity away from orchestration makes things easier to reason about.

Where this gets interesting

This approach becomes even more relevant in areas like:

complex forms (React Hook Form, MUI, etc.)
dynamic UIs with dependencies between fields
state that evolves frequently during development

That's usually where traditional patterns start to show their limits.

Final thought

Valtio won't replace every state management solution.

But it challenges an important assumption:

Are we managing state… or managing the complexity around it?

Curious how others are approaching state management lately.

Stop Writing Form Glue Code: MUI Components Already Connected to React Hook Form

kensaadi — Thu, 30 Apr 2026 07:53:43 +0000

If you've used React Hook Form with Material UI, you know the pattern.

It works well.
It's flexible.
But it's also… repetitive.

You're not really building forms.

You're wiring things together.

The Pattern We All Write

A simple input with RHF + MUI usually looks like this:

import { Controller } from 'react-hook-form';
import { TextField } from '@mui/material';

<Controller
  name="email"
  control={control}
  rules={{ required: 'Email is required' }}
  render={({ field, fieldState }) => (
    <TextField
      {...field}
      label="Email"
      error={!!fieldState.error}
      helperText={fieldState.error?.message}
    />
  )}
/>

Nothing wrong here.

But now multiply that by:

5 fields
10 fields
20 fields

And you start noticing something:

You're repeating the same integration logic over and over again.

The Real Issue: Integration, Not the Libraries

Material UI gives you great UI components.
React Hook Form gives you great form state.

But neither of them knows about the other.

So every time, you write the glue:

connect value / onChange
map errors
pass validation rules
keep UI consistent

That glue becomes your form.

What If Components Already Knew RHF?

Instead of connecting MUI to RHF manually…

What if your components were already connected?

That's what dashforge-ui does.

A TextField from dashforge-ui is still visually a MUI component — but it already understands React Hook Form.

So instead of this:

<Controller
  name="email"
  control={control}
  rules={{ required: 'Email is required' }}
  render={({ field, fieldState }) => (
    <TextField {...field} error={!!fieldState.error} />
  )}
/>

You write this:

import { TextField } from '@dashforge/ui';

<TextField
  name="email"
  label="Email"
  rules={{ required: 'Email is required' }}
/>

Same behavior.
Same validation.
Same form state.

But no glue code.

Important: RHF Is Still There

This is not replacing React Hook Form.

It's built on top of it.

form state → handled by RHF
validation → handled by RHF
performance → same RHF behavior

You're just not wiring it manually anymore.

Think of it as RHF + MUI, already connected.

What Changes in a Real Form

Before (RHF + MUI Vanilla)

import { useForm, Controller } from 'react-hook-form';
import { TextField, Button, Box } from '@mui/material';

interface LoginForm {
  email: string;
  password: string;
}

export function LoginForm() {
  const { control, handleSubmit, formState: { errors } } = useForm<LoginForm>({
    defaultValues: { email: '', password: '' },
  });

  return (
    <Box component="form" onSubmit={handleSubmit((data) => console.log(data))}>
      <Controller
        name="email"
        control={control}
        rules={{ required: 'Email is required' }}
        render={({ field, fieldState: { error } }) => (
          <TextField
            {...field}
            label="Email"
            error={!!error}
            helperText={error?.message}
            margin="normal"
            fullWidth
          />
        )}
      />

      <Controller
        name="password"
        control={control}
        rules={{ required: 'Password is required' }}
        render={({ field, fieldState: { error } }) => (
          <TextField
            {...field}
            label="Password"
            type="password"
            error={!!error}
            helperText={error?.message}
            margin="normal"
            fullWidth
          />
        )}
      />

      <Button type="submit" variant="contained" fullWidth sx={{ mt: 2 }}>
        Login
      </Button>
    </Box>
  );
}

That's 52 lines for 2 fields.

After (dashforge-ui)

import { DashForm, TextField, Button } from '@dashforge/ui';

type LoginForm = {
  email: string;
  password: string;
};

export function LoginForm() {
  return (
    <DashForm<LoginForm>
      defaultValues={{ email: '', password: '' }}
      onSubmit={(values) => console.log(values)}
    >
      <TextField
        name="email"
        label="Email"
        rules={{ required: 'Email is required' }}
      />

      <TextField
        name="password"
        label="Password"
        type="password"
        rules={{ required: 'Password is required' }}
      />

      <Button type="submit">
        Login
      </Button>
    </DashForm>
  );
}

That's 22 lines. 58% less code.

No Controller.
No manual mapping.
No repetition.

Handling Real Complexity

Because it still uses RHF under the hood, you keep all the power.

Conditional Fields

<TextField
  name="company"
  label="Company"
  visibleWhen={(engine) => {
    const accountType = engine.getNode('accountType')?.value;
    return accountType === 'business';
  }}
/>

Cross-Field Validation

<TextField
  name="confirmPassword"
  label="Confirm Password"
  rules={{
    validate: (value, values) =>
      value === values.password || 'Passwords do not match',
  }}
/>

Async Validation

<TextField
  name="email"
  label="Email"
  rules={{
    validate: async (value) => {
      const isAvailable = await checkEmailAvailability(value);
      return isAvailable ? true : 'Email already registered';
    },
  }}
/>

Same flexibility.
Less boilerplate.

Performance & Bundle Size Impact

React Hook Form: ~8.5kB (gzipped)
MUI TextField + Button: ~20kB (gzipped)
dashforge-ui core: ~12kB (gzipped)

Total with dashforge-ui: ~40.5kB (vs ~65kB with manual RHF + MUI setup)

The integration is actually lighter because dashforge-ui eliminates the Controller overhead and consolidates common patterns.

Developer Experience: Before vs After

Task	RHF + MUI	dashforge-ui
Add a required text field	15 lines (Controller wrapper)	4 lines
Add email validation	5 lines (rules + helperText mapping)	1 rule object
Add conditional visibility	~20 lines (JSX conditional)	1 `visibleWhen` function
Type your form data	Manual interface + wiring	Inferred from form props
Error handling	Manual fieldState mapping	Built-in, automatic
Form submission	Manual handleSubmit + wiring	Built-in `onSubmit`

When to Use dashforge-ui

✅ Perfect For:

CRUD forms (create/edit resources)
Medium to large forms (8+ fields)
Multi-step forms with conditional logic
Rapid prototyping where speed matters
Teams wanting form consistency across projects
React + TypeScript shops that value developer experience

⚠️ Consider alternatives if:

You need completely custom field rendering everywhere (dashforge-ui supports this, but with more config)
Your form is a single-field micro-interaction (vanilla RHF + MUI might be simpler)
You need drag-and-drop form builders or visual design tools

Why This Matters

This is not about saving a few lines of code.

It's about removing an entire category of repetitive work:

no more Controller wrappers
no more error plumbing
no more field wiring

You focus on:

the structure of your form
the logic between fields
the user experience

Getting Started

npm install @dashforge/ui @dashforge/forms @dashforge/ui-core react-hook-form @mui/material @emotion/react @emotion/styled

Full documentation: dashforge-ui.com

Minimal Example

import { DashForm, TextField, Button } from '@dashforge/ui';

export function ContactForm() {
  return (
    <DashForm
      onSubmit={(values) => {
        fetch('/api/contact', {
          method: 'POST',
          body: JSON.stringify(values),
        });
      }}
    >
      <TextField
        name="name"
        label="Name"
        rules={{ required: 'Name is required' }}
      />

      <TextField
        name="email"
        label="Email"
        type="email"
        rules={{
          required: 'Email is required',
          pattern: { value: /^\S+@\S+$/, message: 'Invalid email' },
        }}
      />

      <TextField
        name="message"
        label="Message"
        multiline
        rows={4}
        rules={{ required: 'Message is required' }}
      />

      <Button type="submit">
        Send
      </Button>
    </DashForm>
  );
}

Fully typed. Validated. Styled with MUI. No wiring required.

Final Thought

React Hook Form is great.
Material UI is great.

But the integration between them?

That's where most of the friction lives.

dashforge-ui removes that friction — by giving you components that already understand both.

No layer on top. No new paradigm to learn. Just RHF + MUI, finally connected at the framework level.

Beyond Simple Forms: Managing Field Dependencies

Real-world forms have dependencies between fields.

Examples:

Show a "Shipping Address" section only if the user selects "Ship to different address"
Validate a "Confirm Password" field against the password value
Populate a "City" dropdown based on the selected "Country"
Disable a "Submit" button if dependent validations haven't passed

With vanilla RHF + MUI, these become spaghetti code.

How dashforge-ui Handles Dependencies

Field visibility is straightforward with visibleWhen:

<TextField
  name="country"
  label="Country"
  rules={{ required: true }}
/>

{/* Only renders if country === 'US' */}
<TextField
  name="state"
  label="State"
  visibleWhen={(engine) => engine.getNode('country')?.value === 'US'}
/>

For more complex logic — conditional validation rules, async operations triggered by field changes, dynamic options loading — dashforge-ui uses Reactions.

A Reaction is simple:

const reactions = [
  {
    id: 'load-cities-on-country-change',
    watch: ['country'],  // Watch for country changes
    when: (ctx) => Boolean(ctx.getValue('country')),  // Only run if country has a value
    run: async (ctx) => {
      const country = ctx.getValue<string>('country');
      const cities = await fetchCities(country);
      // Update runtime state (not form values)
      ctx.setRuntime('city', { options: cities });
    }
  }
];

<DashForm reactions={reactions}>
  {/* fields here */}
</DashForm>

Think of Reactions as "When this happens, do that" — they watch field changes and run side effects.

This is the real power behind complex form dependencies: instead of manually wiring useWatch + useEffect chains, you describe what triggers what at the form level.

Want to go deeper? I've written a detailed guide on this exact problem:

📖 Building Dependent Form Fields in React: A Practical Approach

That guide covers dependency patterns, performance implications, and real-world solutions. dashforge-ui integrates those patterns into the component model.

👉 If you're using React Hook Form today, I'm curious: how much of your form code is actual logic vs wiring?

Learn more: dashforge-ui.com

GitHub: github.com/dashforge-ui

Deep dive on dependencies: Building Dependent Form Fields in React

Building Dependent Form Fields in React: A Practical Approach

kensaadi — Mon, 27 Apr 2026 15:57:12 +0000

Have you ever needed a form where changing one field updates the options of another? Like selecting a category and seeing subcategories automatically update?

Most developers reach for useEffect + manual state management. But there's a better way.

The Problem

Let's say you have two autocomplete fields:

Category - static options
Subcategory - depends on category, loads dynamically

The traditional approach requires:

Tracking category changes
Triggering updates when category changes
Manual state management for loading/error states
Clearing subcategory when category changes
Managing async operations

It gets complex fast when you add more dependencies.

The DashForge Solution

DashForge uses reactions - a declarative way to handle field dependencies:

import { useState } from "react";
import { DashForm } from "@dashforge/forms";
import { Autocomplete } from "@dashforge/ui";
import { Box, Button, Card, Stack, Typography } from "@mui/material";

interface FormValues {
  category: string | null;
  subcategory: string | null;
}

const categories = ["Electronics", "Clothing", "Books"];

const subcategoriesByCategory: Record = {
  Electronics: ["Phones", "Laptops", "Tablets", "Accessories"],
  Clothing: ["Shirt", "Pants", "Shoes", "Dresses"],
  Books: ["Fiction", "Non-Fiction", "Science", "History"],
};

async function fetchSubcategories(category: string | null) {
  await new Promise((resolve) => setTimeout(resolve, 500));
  return category ? subcategoriesByCategory[category] || [] : [];
}

export function DependencyForm() {
  const [formData, setFormData] = useState(null);

  const onSubmit = (data: FormValues) => {
    setFormData(data);
  };

  return (
        <DashForm
          onSubmit={onSubmit}
          defaultValues={{ category: null, subcategory: null }}
          reactions={[
            {
              id: "update-subcategory-options",
              watch: ["category"],
              run: async ({ getValue, setRuntime }) => {
                const category = getValue("category");

                setRuntime("subcategory", {
                  status: "loading",
                  error: null,
                  data: { options: [] },
                });

                const subcategories = await fetchSubcategories(category);

                setRuntime("subcategory", {
                  status: "ready",
                  error: null,
                  data: { options: subcategories },
                });
              },
            },
          ]}
        >
            Submit
        {formData && (
            {JSON.stringify(formData, null, 2)}
        )}
  );
}

How It Works

The key is the reactions array:

watch - Specify which fields to monitor
run - When watched fields change, execute this function
getValue - Read current field values from the form
setRuntime - Update field data at runtime (options, loading state, errors)

When category changes:

Reaction triggers automatically
Fetch new subcategories
Update subcategory field with new options
User sees updated options immediately

Why This Approach is Better

No Manual Side Effects

The form handles dependencies automatically. No need for useEffect or manual state management.

Clean Dependencies

Just declare what you're watching with the watch array. No complex dependency tracking.

Loading States Built-in

Set status: "loading" and the field knows it's fetching. Built-in support for async operations.

Type-Safe

Full TypeScript support for getValue and setRuntime.

Scales Well

Add another dependent field? Add another reaction. Complexity stays linear, not exponential.

Advanced: Multiple Dependencies

What if subcategory affects another field? Just add another reaction:

reactions={[
  {
    id: "update-subcategory-options",
    watch: ["category"],
    run: async ({ getValue, setRuntime }) => {
      // Update subcategory based on category
    },
  },
  {
    id: "update-product-options",
    watch: ["subcategory"],
    run: async ({ getValue, setRuntime }) => {
      // Update product based on subcategory
    },
  },
]}

The form orchestrates the entire dependency chain.

Real-World Scenarios

This pattern works for:

Cascading dropdowns - Country → State → City
Dynamic pricing - Product → Variant → Price
Conditional visibility - Type → Related options
Async data loading - Search field → fetch results
Complex workflows - Multi-step forms with dependencies

Getting Started

Install DashForge:

npm install @dashforge/forms @dashforge/ui

See the full documentation for API details.

Check out the starter kits for production examples.

The Point

Dependent form fields don't need to be complex. With the right abstraction, they become straightforward: declare what you're watching, declare what updates, let the form handle the rest

Check video Youtube -
React forms get messy fast — especially with dependent fields

DEV Community: kensaadi

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

It started with className

Props-first, on top of Tailwind

Then React Hook Form happened

Fields that know when they exist

Buttons that know who's allowed to press them

The part I didn't plan

Where this lives

Production RBAC patterns for Go and Node startups

The 4 signs your RBAC is a time bomb

The real problem: policies-as-code

Three rules for production-grade RBAC

Rule 1: Policy-as-data, not policy-as-code

Rule 2: Granular permissions (action-level, not role-level)

Rule 3: Audit trail — non-negotiable

RBAC vs ABAC vs ReBAC: which one do you need?

A concrete implementation walkthrough

Go middleware (Fiber)

Node middleware (Express)

Frontend gating: where most teams stop too early

1. The hook

2. Inline gating with <Can>

3. Route-level gating with <RoleGuard>

4. The admin UI — the part nobody writes themselves

5. The audit log viewer

Audit logging in two lines

The RBAC layer in Dashforge — what end-to-end actually looks like

The full stack, day-1 ready

What you get on day 1

Why bundling matters

How it composes with the rest of the kit

Your turn

I've built Stripe checkout from scratch 3 times. Here's what no one tells you.

1. The cart is not a frontend problem

2. Stripe SCA is not Stripe Checkout

3. Webhooks are where things break in production

4. Order management is a separate product

5. The admin dashboard needs RBAC from day one

6. S3 image upload is a full integration on its own

What this actually adds up to

Free for the first 5 developers who want to try it

Back to React Fundamentals: useEffect, useState, useMemo, useCallback, useReducer

Latest: React 19.2 Release (October 2025)

First rule: React renders functions

Example:

Splitting code into components

Problematic example

Solution: move state closer to where it's actually needed

State colocation

Practical rule

Component splitting vs Lazy Loading

Component Splitting

Lazy Loading

useState: values vs references

Primitive values

Objects and arrays

useEffect: it's not really componentDidMount

useEffect equivalent to didMount

Real-world example: API call on mount

When you DO need useCallback with useEffect

Why you should NOT use async directly in useEffect

Cleanup function

useEffect as didUpdate

Single dependency

Multiple dependencies

Object dependencies

useMemo: when to actually use it

Correct use case

WRONG use case

The problem with memoizing everything

Important truth

useCallback

The real difference between <Component /> and {component}

Case 1 — <Child /> inside render

Child render

Case 2 — React element stabilized outside the component

Case 3 — Variable inside render

React element vs Component Function

Very common pattern: passing React elements as props

2. Inline gating with `<Can>`

3. Route-level gating with `<RoleGuard>`

The real difference between `<Component />` and `{component}`

Case 1 — `<Child />` inside render

`<Activity />` (React 19.2)