DEV Community: kensaadi

RBAC in React and Node: enforce the same policy on both sides

kensaadi — Sun, 30 Aug 2026 09:05:49 +0000

The advice is everywhere: the frontend is UX, authorization belongs on the backend. It is true, and on its own it is useless — because it stops exactly where the hard part starts. Hide a button in the UI and forget the server, and the action is a curl away. Protect the server and hardcode the UI, and the two drift apart the first time the rules change. The question nobody answers is how to keep the button you hid and the endpoint you protected agreeing with each other.

The UI is an affordance, the server is the boundary

They are two different jobs. The UI decides what to show — hide or disable a control the user can't use. That is UX. The server decides what to allow — reject the request. That is security. You need both, and they must agree, but only one of them is the security boundary:

UI only → no security. The endpoint is open; the hidden button is theatre.
Server only → the app offers buttons that answer 403.

The mistake is not doing one of them. It is doing them from two different sources of truth, so they fall out of sync the moment someone edits a rule.

One policy, as data

Define the rules once. A policy is roles mapped to permissions — a resource × action pair, allow or deny:

import { createRbacEngine, type RbacPolicy } from '@dashforge/rbac';

const policy: RbacPolicy = {
  roles: [
    { name: 'admin', permissions: [{ resource: '*', action: '*' }] },
    { name: 'sales', permissions: [
      { resource: 'order', action: 'read' },
      { resource: 'order', action: 'refund', effect: 'deny' }, // explicit deny
    ] },
    { name: 'customer', permissions: [
      { resource: 'self', action: 'update' },
    ] },
  ],
};

const engine = createRbacEngine(policy);

An explicit deny overrides an allow, so you can grant broadly and carve out the exceptions. The engine is a pure function of (roles, resource, action) → decision — no framework, no I/O — which is exactly why the same policy can run on the server and in the browser.

The server: the boundary

Every mutating route consults the engine before the controller runs. The 403 is the thing that actually stops the request:

router.patch('/customer/me',
  requireAuth(secret),
  requireRole('customer'),
  rbacGate(engine, 'self', 'update'),   // resource, action
  controllers.customer.updateMe,
);

export function rbacGate(engine, resource, action) {
  return (req, res, next) => {
    if (!req.auth) {
      return res.status(401).json({ error: 'unauthenticated' });
    }
    if (engine.check(req.auth.roles, action, resource) !== 'allow') {
      return res.status(403).json({ error: 'forbidden' });
    }
    next();
  };
}

This is the line that matters. Delete every check in the UI and the app is still secure. Delete this one and no amount of hidden buttons will save you.

The UI: the affordance, from the same policy

Now the frontend renders from the same engine and the same vocabulary — resource and action — so it can never offer what the server forbids:

<Can action="refund" resource="order" fallback={<DisabledButton>Refund</DisabledButton>}>
  <RefundButton orderId={order.id} />
</Can>

or imperatively, when you need the boolean:

const canRefund = useCan({ action: 'refund', resource: 'order' });

The refund control disappears for a sales user because the policy denies order:refund — and if they forge the request anyway, rbacGate answers 403. Same rule, two enforcement points, one source of truth.

Ownership: "their own", not "any"

Most real rules are not can a customer update a customer but can a customer update **their own* record*. That is a condition on the permission, evaluated against the resource:

{
  resource: 'self',
  action: 'update',
  condition: ({ subject, resourceData }) =>
    subject.id === (resourceData as { ownerId: string })?.ownerId,
}

The server passes the loaded record as resourceData; the UI passes the same shape:

<Can action="edit" resource="order" resourceData={{ ownerId: order.ownerId }}>
  <EditButton />
</Can>

Same condition, both sides. The UI stops offering the button on someone else's record; the server refuses the request if it arrives anyway.

The honest part

<Can> and useCan are UX — they never make anything safe. The only thing that makes the app safe is rbacGate on the server; the UI just stops users from walking into a 403. If you ever have to choose, protect the server. The reason to share the policy is not to promote the UI into a security layer — it is to stop the UI and the server from disagreeing as the rules change.

The checklist

One policy, as data: roles → permissions, resource × action, explicit deny wins.
One engine (createRbacEngine), the same policy on the client and the server.
The server is the boundary: rbacGate(engine, resource, action) on every mutating route, returning 403.
The UI is the affordance: <Can> / useCan from the same policy, hiding or disabling.
Ownership as a condition on the permission, with the same resourceData shape on both sides.
Never ship a UI-only check and call it access control.

The engine is @dashforge/rbac — open source, on npm, framework-free. createRbacEngine(policy) is a pure function you run unchanged in React and in your API. The Checkout Kit demo wires the whole loop end to end — the rbacGate middleware and <Can> in the UI, mirrored in the Go and Node editions.

Originally published on dashforge-ui.com.

Availability slots across timezones and DST

kensaadi — Sun, 30 Aug 2026 08:49:50 +0000

TL;DR: 09:00 is wall-clock time in a timezone, not a UTC instant. Resolve the offset in the business's zone and convert to UTC last, or you're an hour off across zones and grow a phantom slot on the DST change.

source → https://dashforge-ui.com/guides/availability-slots-timezones-dst

An availability engine looks trivial until it ships. It works on your machine, in your timezone, on an ordinary week. Then a customer in another timezone sees every slot an hour off, or the clocks change and a Sunday grows a slot that doesn't exist. Every one of these is the same mistake: treating a wall-clock time as if it were a fixed point in time.

"09:00" is not an instant

A working window — open 09:00 to 12:00 — is wall-clock time in the business's timezone. It is not a UTC offset and not a number of minutes from midnight UTC. 09:00 in a Paris salon is 07:00 UTC in summer and 08:00 UTC in winter, because Paris is UTC+2 under DST and UTC+1 otherwise. The same "09:00" maps to two different instants depending on the date.

So the rule that makes the whole engine correct: build the window in the business's timezone, resolve the offset there, and only then convert to UTC.

The bug: computing slots in UTC (or the server's clock)

Build each boundary as a wall-clock instant in the availability timezone and let the date library resolve the offset on the resulting wall clock. Here that is luxon; the Go edition uses time.Date(y, mo, d, 0, minute, 0, 0, loc) — the same idea.

import { DateTime } from 'luxon';

// "minutes from midnight" → an instant, resolved IN `zone`.
function wallClock(year, month, day, minutesFromMidnight, zone) {
  const days   = Math.floor(minutesFromMidnight / 1440);
  const rem    = minutesFromMidnight - days * 1440; // 0..1439
  const hour   = Math.floor(rem / 60);
  const minute = rem % 60;
  return DateTime.fromObject({ year, month, day, hour, minute }, { zone })
    .plus({ days });
}

The whole trick is { zone }: luxon resolves the UTC offset for that wall clock, on that date — so 09:00 in August gets +02:00 and 09:00 in January gets +01:00, automatically. You never write an offset down.

Then step candidate starts in the zone and keep the ones that fit the window, converting to UTC only at the end:

Prove it: 09:00 in Paris in August is 07:00 UTC

This is the single assertion that pins the whole thing. Paris is UTC+2 in August, so a 09:00 window start must come out as 07:00 UTC — not 09:00 UTC:

const slots = computeSlots({
  availability: weekdayAvail('Europe/Paris', MONDAY),
  date: '2026-08-17',
  durationMinutes: 60,
  now: new Date('2026-08-01T00:00:00Z'),
});

expect(slots[0].startAt.toISOString()).toBe('2026-08-17T07:00:00.000Z');

Compute slots in UTC or the server's clock and this comes out as 09:00Z — an hour wrong, silently, for every customer, forever.

The spring-forward day

The reason to build in the zone rather than add fixed offsets is the transition days. On spring-forward night the local clock jumps 02:00 → 03:00, so the day has 23 hours and the 02:00–03:00 wall time never happens (on fall-back it happens twice). Because each boundary is resolved as a wall clock in the zone — not as "midnight UTC plus N hours" — the offset flips at the right instant and the slots land where a human expects.

That is pinned by a test. A 01:00–05:00 window on the EU spring-forward Sunday is four wall-clock hours but only three real ones, so a 60-minute service yields three slots, not four — the 02:00 local slot is absent, because that hour does not exist:

// 2026-03-29, Europe/Paris — the clock jumps 02:00 → 03:00
const slots = computeSlots({
  availability, // Sunday 01:00–05:00, Europe/Paris
  date: '2026-03-29',
  durationMinutes: 60,
  now: new Date('2026-03-01T00:00:00Z'),
});

// local 01:00, 03:00, 04:00 → UTC 00:00, 01:00, 02:00
expect(slots.map((s) => s.startAt.toISOString())).toEqual([
  '2026-03-29T00:00:00.000Z',
  '2026-03-29T01:00:00.000Z',
  '2026-03-29T02:00:00.000Z',
]);

A "midnight UTC + N hours" engine emits a phantom fourth slot here; this one does not.

The honest part: these two assertions pin the offset case and the spring-forward gap for Europe/Paris. The fall-back day (the hour that runs twice) and every other zone are the same wall-clock resolution, not special-cased code — they follow from the same property, but only these two are behind a test. Copy the wallClock approach and you inherit the property; copy an "add hours to UTC" approach and no test will save you.

Store UTC, compare on instants, render local

Slots come out as UTC instants; store bookings the same way. Conflict detection is then timezone-free — a half-open [start, end) overlap on millisecond instants:

function intervalsOverlap(aStart, aEnd, bStart, bEnd) {
  return aStart < bEnd && bStart < aEnd; // instants, location-independent
}

The customer's browser renders those instants in their timezone. The business defines availability in its timezone. Nothing in between ever stores a wall-clock string as if it were an instant.

The checklist

A working window is wall-clock time in the business's timezone, not a UTC offset.
Build each boundary with the zone attached; let the library resolve the offset on that wall clock. Never hardcode +02:00.
Step candidate starts as zoned datetimes; convert to UTC only on output.
Store bookings as UTC instants; compare with a half-open interval overlap on millis.
Render in the customer's timezone in the UI, never on the server.
Test the offset case and a spring-forward date.

A booking slot at "09:00" is not a point in time. That single wrong assumption is why availability engines ship, run fine all week, then quietly grow a slot that doesn't exist on the Sunday the clocks change.

"09:00" is wall-clock time in the business's timezone. In Paris it's 07:00 UTC in summer and 08:00 UTC in winter — same string, two different instants.

The fix is one rule: build the window in the business's timezone, let the date library resolve the offset there, and convert to UTC only at the end. Never write "+02:00" by hand.

Do the naive "midnight UTC + N hours" and two things break:
→ every customer in another timezone sees slots an hour off
→ the spring-forward day has 23 hours, so it grows a phantom slot at 02:00 — an hour that doesn't exist

I wrote it up with the real code and the two tests that pin it: the Paris offset, and a spring-forward case that returns 3 slots, not 4.

source → https://dashforge-ui.com/guides/availability-slots-timezones-dst

If you build scheduling, this is the bug you don't find until production.

useFieldArray is not updating across steps — and why it can't

kensaadi — Thu, 27 Aug 2026 20:48:19 +0000

If you have a wizard where step two appends to items and step four also appends to items, and the two steps never see each other's data — you have not misconfigured anything. Two useFieldArray instances pointed at the same name cannot observe each other, by design. Each one keeps a private snapshot of that array internally.

react-hook-form documents it plainly:

No two useFieldArray for the same field can be instantiated, as each handles its own snapshot of state internally.

For a single-page form this never surfaces. For a wizard it surfaces on day one.

Why the rule exists

This is not neglect, and it is worth understanding before you work around it.

The reason react-hook-form is fast is that state lives close to the inputs and is not centralised. Inputs are uncontrolled, the form does not re-render on every keystroke, and each useFieldArray owns its slice. Sharing one array across mounting boundaries asks for the opposite architecture — a central store that every instance subscribes to.

That tension is real. It is why the request keeps reopening rather than getting fixed.

The three shapes where it bites

Multi-page forms. Different steps need to update the same field array, and there is no first-party way to share one instance across them.

Conditional fields inside an array item. Uncontrolled inputs do not re-render when a value changes, so showing or hiding a nested field based on a sibling's value simply does not react.

Arrays that mount and unmount. Toggled sections, wizard steps and tab navigation all remount the array — the scenario most likely to lose state in a way that looks like a bug in your own code.

Fix 1 — conditional fields: subscribe narrowly with useWatch

For "show this field only when a sibling has a certain value", there is a clean first-party answer. Do not reach for watch() on the whole form: that re-renders everything and throws away the reason you picked this library.

Instead, extract the dependent field into its own component and subscribe to that one array item with useWatch:

import { useFormContext, useWatch } from 'react-hook-form';

// One component per conditional field. The subscription is narrow,
// so the re-render is narrow too.
function CourierNote({ index }: { index: number }) {
  const { control, register } = useFormContext();

  // Subscribes to exactly items.<index>.method — nothing else re-renders.
  const method = useWatch({
    control,
    name: `items.${index}.method`,
  });

  if (method !== 'courier') return null;

  return (
    <input
      {...register(`items.${index}.note`)}
      placeholder="Delivery instructions"
    />
  );
}

function ItemRow({ index, name }: { index: number; name: string }) {
  const { register } = useFormContext();
  return (
    <div>
      <input {...register(`${name}.sku`)} />
      <select {...register(`${name}.method`)}>
        <option value="pickup">Pickup</option>
        <option value="courier">Courier</option>
      </select>

      <CourierNote index={index} />
    </div>
  );
}

The whole trick is the component boundary. useWatch re-renders the component that called it, so keeping that component tiny keeps the cost tiny. You get reactivity without giving up the uncontrolled model.

Fix 2 — sharing one array across steps: own the context

For the wizard case there is no first-party answer. The pattern that circulates — and the one that actually works — is to instantiate the field array once and hand it down through your own React context, so every step reads the same instance instead of creating a second one.

import { createContext, useContext, type ReactNode } from 'react';
import {
  useFieldArray,
  useFormContext,
  type UseFieldArrayReturn,
} from 'react-hook-form';

const ItemsContext = createContext<UseFieldArrayReturn | null>(null);

export function ItemsProvider({ children }: { children: ReactNode }) {
  const { control } = useFormContext();

  // The ONLY useFieldArray('items') in the tree.
  const fieldArray = useFieldArray({ control, name: 'items' });

  return (
    <ItemsContext.Provider value={fieldArray}>{children}</ItemsContext.Provider>
  );
}

export function useItems() {
  const ctx = useContext(ItemsContext);
  if (!ctx) throw new Error('useItems must be used inside <ItemsProvider>');
  return ctx;
}

Now every step consumes the same instance:

function StepTwo() {
  const { fields, append } = useItems();
  return (
    <>
      {fields.map((f, i) => <ItemRow key={f.id} index={i} name={`items.${i}`} />)}
      <button type="button" onClick={() => append({ sku: '', method: 'pickup' })}>
        Add item
      </button>
    </>
  );
}

function StepFour() {
  // Same array, same snapshot — because it is literally the same instance.
  const { fields, remove } = useItems();
  return (
    <ul>
      {fields.map((f, i) => (
        <li key={f.id}>
          {f.id} <button type="button" onClick={() => remove(i)}>×</button>
        </li>
      ))}
    </ul>
  );
}

The detail that decides whether this works

The provider must be mounted above the step switch, not inside it.

// ✅ survives step changes
<FormProvider {...methods}>
  <ItemsProvider>
    {step === 2 && <StepTwo />}
    {step === 4 && <StepFour />}
  </ItemsProvider>
</FormProvider>

// ❌ remounts on every step change — you are back where you started
<FormProvider {...methods}>
  {step === 2 && <ItemsProvider><StepTwo /></ItemsProvider>}
  {step === 4 && <ItemsProvider><StepFour /></ItemsProvider>}
</FormProvider>

If the provider unmounts, the field array unmounts with it, and the second mount is a brand-new instance with a fresh snapshot. Which is the original bug, reintroduced by the fix.

It works. It is also a piece of state architecture you now own and maintain — in a library you adopted specifically so you would not have to.

Where we stand

I maintain a form orchestrator built on top of react-hook-form, so it would be a strange article to end with a pitch. Our own useDashFieldArray does not solve this either.

It is a thin adapter: it pre-computes the field path and exposes a live index, then delegates every operation straight through to RHF.

const { fields, append, remove } = useDashFieldArray<Item>('items');

fields.map((field) => (
  <TextField key={field.id} name={`${field.name}.sku`} />
));

Better DX — you stop hand-building items.${index}.sku strings — but two instances on the same name behave exactly as RHF's do, because underneath they are RHF's. Fixing this properly means owning array state centrally, which is a different architecture, not a wrapper.

So the honest summary for today:

Conditional fields inside an array → solved, use useWatch at the component level.
One array shared across wizard steps → not solved upstream. Own a context, and mount it above the steps.

If someone has a third pattern that holds up in production, I would genuinely like to see it.

Sources

react-hook-form — useFieldArray documentation the quoted rule
react-hook-form — useWatch documentation

This is part of Fault Lines, a set of open fronts in the React form ecosystem, each traced to primary sources and dated.

Dashforge: an application orchestrator for React

kensaadi — Thu, 20 Aug 2026 06:52:28 +0000

React solved rendering. Dashforge tries to solve orchestration — theming, forms,
permissions, and visibility moved out of your components, declaratively, predictably,
reusably. Two skins (MUI and Tailwind), one contract.

Building complex applications isn't about building components.

Inside a single module you're juggling forms, permissions, roles, visibility conditions, fields that depend on other fields, business logic. And all that logic ends up scattered across the app: a <Controller> here, an if (user.role === …) there, a useEffect watching one field to update another, a context for theming.

If React solves the rendering problem, Dashforge tries to solve the orchestration problem.

Dashforge moves that complexity out of the components and makes it declarative, predictable, and reusable. At its core it uses react-hook-form; on top of it, a stable contract — identical across the MUI and Tailwind editions. Let's go through it piece by piece.

1. Theming — token-first, build-time and run-time

Components don't hard-code colors or spacing: they consume typed design tokens (@dashforge/tw-tokens, a pure TypeScript package, zero runtime). From there, the tokens travel on two rails.

Build-time — the utilities. A Tailwind preset emits the usual utilities (bg-primary-600, text-neutral-900):

// tailwind.config.ts
import { dashforgePreset } from '@dashforge/tw-theme';
export default { presets: [dashforgePreset()], content: ['./src/**/*.{ts,tsx}'] };

Run-time — the CSS variables. The provider republishes those same tokens as CSS variables on <html>:

<DashforgeTailwindProvider>
  <App />
</DashforgeTailwindProvider>

Here's the trick: bg-primary-600 doesn't resolve to a fixed color — it resolves to var(--tw-color-primary-500). The provider sets that variable; change the variable, the color changes — no re-render, no Tailwind rebuild. The store is reactive (Valtio) with cross-tab sync, so dark mode or a live theme change is just a variable flip.

In the MUI edition the same token surface feeds a runtime MUI theme (via Emotion): same source of truth, only the delivery differs.

Concrete payoffs: dark mode is free (components don't even know it exists), a redesign is a token change rather than a sweep across a hundred files, and the design system is typed instead of being a convention your team has to remember.

2. Forms — declarative orchestration

If you use react-hook-form (and you should), you know the tax: a <Controller> for every field, and a handful of watch / useWatch / useEffect scattered through the component to react to values.

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

With Dashforge the field is bound by name to the form. Binding, errors, "touched" state: inside the component.

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

Per-field subscriptions → fewer re-renders than plain RHF, zero <Controller> at the call site. And this pattern is native to both CSS libraries: if you build admin apps all day, that alone is a reason to adopt it.

2.1 Reactions — logic outside the render

The real case: fields that depend on other fields. In an e-commerce app you pick a category and the right subcategories must appear, loaded from an API. With RHF you end up with useEffect + local state + cleanup + race-condition handling, all inside the component.

Dashforge declares it outside the render, in a reaction:

const reactions = [{
  id: 'load-subcategories',
  watch: ['category'],                 // the same "watch" as react-hook-form — not by accident
  run: async (ctx) => {
    const category = ctx.getValue('category');
    if (!category) return;

    const req = ctx.beginAsync('subs');                  // stale-response guard
    ctx.setRuntime('subcategory', { status: 'loading' });

    const options = await fetchSubcategories(category);  // external fetch, stays out of render

    if (ctx.isLatest('subs', req)) {                     // drop out-of-order responses
      ctx.setRuntime('subcategory', { status: 'ready', data: { options } });
    }
  },
}];

The reaction declares what happens between fields. The fetch never enters the render; the data lives only inside the reaction. And the classic race condition ("the user already changed the value but the previous response just arrived") is handled by beginAsync / isLatest, not hand-written.

When the form mounts, React takes over — reactions attach via a prop:

<DashForm
  defaultValues={{ category: '', subcategory: null }}
  reactions={reactions}
  onSubmit={save}
>
  <Select name="category"    label="Category" options={CATEGORIES} />
  <Select name="subcategory" label="Subcategory" /> {/* options populated by the reaction */}
</DashForm>

A few lines orchestrate a form that would take real effort to build by hand.

3. RBAC — permissions as data, not as `if`

In an enterprise app, "who can do what" isn't a UI decision: it's a rule that comes from the backend. The problem is that it usually gets re-translated by hand into dozens of scattered if (user.role === 'admin'). Dashforge keeps it in one place and lets components apply it. Three pieces.

3.1 Policy — what's allowed

An object of roles and permissions (action + resource + effect). In production you fetch it from your backend (JWT claims, a /me/policy endpoint), you don't hand-write it in the client:

import { RbacProvider, type RbacPolicy } from '@dashforge/rbac';

const policy: RbacPolicy = {
  roles: [
    { name: 'admin',  permissions: [{ action: '*',    resource: '*',       effect: 'allow' }] },
    { name: 'editor', permissions: [{ action: 'edit', resource: 'booking', effect: 'allow' },
                                    { action: 'read', resource: 'booking', effect: 'allow' }] },
    { name: 'viewer', permissions: [{ action: 'read', resource: 'booking', effect: 'allow' }] },
  ],
};

3.2 RbacProvider — who you are (the link to authentication)

The provider takes the policy and the subject: the current user with their roles — also coming from your authentication system. This is where RBAC connects to the user's real identity. It mounts once, at the top of the app:

function App() {
  const currentUser = { id: 'user-123', roles: ['editor'] }; // from your auth / backend

  return (
    <RbacProvider policy={policy} subject={currentUser}>
      <BookingForm />
    </RbacProvider>
  );
}

From here on, every component "knows" who the user is and what they're allowed to do.

3.3 access — how permissions propagate to components

Each component declares which resource/action it needs and what to do when the permission is missing (hide / disable / readonly). The object is inline, so you see exactly what's in it.

<DashForm defaultValues={{ customerName: '', status: 'pending' }} onSubmit={save}>
  {/* viewer → read-only · editor/admin → editable */}
  <TextField
    name="customerName"
    label="Customer name"
    access={{ action: 'edit', resource: 'booking', onUnauthorized: 'readonly' }}
  />

  {/* disappears entirely if you can't delete */}
  <Button access={{ action: 'delete', resource: 'booking', onUnauthorized: 'hide' }}>
    Delete booking
  </Button>
</DashForm>

The provider resolves access against the policy and the subject: change the user's role and the same form re-resolves itself — admin sees and edits everything, editor loses the admin-only fields, viewer gets a read-only name and no Save button. No if in the JSX, no permission logic duplicated page by page. And the access declaration is identical in the MUI and Tailwind editions.

4. visibleWhen — the end of scattered conditional rendering

visibleWhen is a reactive visibility predicate: return false and the component renders null. It lives in two contexts.

Inside a form — on the engine. It reaches the form engine directly and reads a field's value:

<Select
  name="subcategory"
  label="Subcategory"
  visibleWhen={(engine) => Boolean(engine.getValue('category'))}
/>

Outside a form — on state. It captures local/external state in the closure: the component decides for itself whether to show up, without the classic {condition && <Component/>} cluttering your JSX. Many display-only components expose it precisely for this.

<Alert visibleWhen={() => hasUnsavedChanges}>You have unsaved changes</Alert>

Either way, the condition is a declared property of the component, not a rendering branch you repeat by hand.

Wrapping up

There's a single thread: what are usually scattered imperative functions — <Controller>, useEffect, permission ifs, dark: variants, conditional rendering — become declarative properties of forms, components, and schema in Dashforge. Readable, testable, reusable. And because everything flows through the shared bridge, the same schema runs identically on MUI and Tailwind: you only change the import line.

import { TextField, Select, Button } from '@dashforge/tw';   // Tailwind
// import { TextField, Select, Button } from '@dashforge/ui'; // MUI

Who it's for: React/TypeScript teams, enterprise and fintech applications, back offices, complex dashboards, products with heavy business logic. If you're building a small app or a landing page, Dashforge probably won't help you — and that's fine.

Try it without installing dependencies — the CLI ships two templates, landing or dashboard:

npx dashforge-cli my-app --lib tw   # or --lib mui
cd my-app && pnpm dev

📚 Docs, live demos, and repo: https://dashforge-ui.com

If you build data-driven apps in React, the one question I care about: would orchestrating forms, permissions, and dependencies outside your components make you adopt Dashforge? Let me know in the comments — that's the feedback that steers the roadmap.

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

RBAC in React and Node: enforce the same policy on both sides

The UI is an affordance, the server is the boundary

One policy, as data

The server: the boundary

The UI: the affordance, from the same policy

Ownership: "their own", not "any"

The honest part

The checklist

Availability slots across timezones and DST

"09:00" is not an instant

The bug: computing slots in UTC (or the server's clock)

Prove it: 09:00 in Paris in August is 07:00 UTC

The spring-forward day

Store UTC, compare on instants, render local

The checklist

useFieldArray is not updating across steps — and why it can't

Why the rule exists

The three shapes where it bites

Fix 1 — conditional fields: subscribe narrowly with useWatch

Fix 2 — sharing one array across steps: own the context

The detail that decides whether this works

Where we stand

Sources

Dashforge: an application orchestrator for React

1. Theming — token-first, build-time and run-time

2. Forms — declarative orchestration

2.1 Reactions — logic outside the render

3. RBAC — permissions as data, not as if

3.1 Policy — what's allowed

3.2 RbacProvider — who you are (the link to authentication)

3.3 access — how permissions propagate to components

4. visibleWhen — the end of scattered conditional rendering

Wrapping up

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

3. RBAC — permissions as data, not as `if`

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)