DEV Community: kensaadi

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

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

Latest: React 19.2 Release (October 2025)

First rule: React renders functions

Example:

Splitting code into components

Problematic example

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

State colocation

Practical rule

Component splitting vs Lazy Loading

Component Splitting

Lazy Loading

useState: values vs references

Primitive values

Objects and arrays

useEffect: it's not really componentDidMount

useEffect equivalent to didMount

Real-world example: API call on mount

When you DO need useCallback with useEffect

Why you should NOT use async directly in useEffect

Cleanup function

useEffect as didUpdate

Single dependency

Multiple dependencies

Object dependencies

useMemo: when to actually use it

Correct use case

WRONG use case

The problem with memoizing everything

Important truth

useCallback

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

Case 1 — <Child /> inside render

Child render

Case 2 — React element stabilized outside the component

Case 3 — Variable inside render

React element vs Component Function

Very common pattern: passing React elements as props

But be careful

The real React optimization

useReducer

Basic syntax

Dispatch

When to prefer useReducer

Real-world example: fetch state

React 19 & Beyond: Building on Fundamentals

Server Actions (React 19)

useActionState & useOptimistic (React 19)

useEffectEvent (React 19.2)

<Activity /> (React 19.2)

Conclusion

# The Hidden Costs of Microfrontends — Interactive Edge Cases

Why this exists

The six demos

Stack

Run it locally

Project layout

How the simulation works

Credits

Are We Overcomplicating React State? A Look at Valtio

React State Feels Simple — Until It Doesn't

The usual problem

What felt different with Valtio

Why this matters

But this doesn't remove complexity

Where this gets interesting

Final thought

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

You're wiring things together.

The Pattern We All Write

The Real Issue: Integration, Not the Libraries

What If Components Already Knew RHF?

Important: RHF Is Still There

What Changes in a Real Form

Before (RHF + MUI Vanilla)

After (dashforge-ui)

Handling Real Complexity

Conditional Fields

Cross-Field Validation

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

Case 1 — `<Child />` inside render

`<Activity />` (React 19.2)