DEV Community: Gabriel-Ionut Enache

I Wrote a React Book So You Don't Have to Learn These Lessons the Hard Way

Gabriel-Ionut Enache — Sun, 05 Apr 2026 08:43:56 +0000

A few months ago I attended a React conference and realized something uncomfortable: I'd been writing React for years and I was doing it wrong. Not "broken" wrong — my code worked. But it was slow to maintain, hard to scale, and it wasn't taking advantage of half of what React 19 had to offer.

That realization turned into a book: React Best Practices 2026: Scalable Architecture, Design Patterns, Hooks, Performance, and Modern React 19 Techniques.

Who is this book for?

If you're a mid to senior React developer and you've ever thought "this works, so it's probably fine" — this book is for you. It's not a beginner's guide. It's for developers who already know React and want to write the best React they possibly can in 2026.

What's actually in it?

The book is split into 5 parts covering the full lifecycle of a modern React app:

Part 1 — Architecture & Patterns

How to design a scalable React architecture from day one
The composition mindset (and why it changes everything)
Mastering React without overusing useEffect

Part 2 — Hooks & State

React Context done right — when to use it, when to reach for Zustand
Writing custom hooks that are actually reusable
Data consistency with enums and constants

Part 3 — Code Quality

Functional programming in React
Modern forms with React Hook Form + Zod
Styling in 2026: Tailwind CSS v4, clsx, and the cn utility
Keeping your JSX clean

Part 4 — Performance

Efficient rendering with TanStack Virtual
Stop memoizing everything — let the React Compiler do it
React Suspense and streaming UIs
Concurrent UI and optimistic updates
New React primitives: Activity and ViewTransition

Part 5 — The Modern Workflow

Leveraging AI in your React workflow
Testing with Vitest and React Testing Library

A few things I wish I knew earlier

I used useEffect for everything. Data fetching, derived state, syncing props — all of it. It wasn't until I dug into the docs and started using TanStack Query properly that I understood how much complexity I was creating for myself.

Same with memoization. I had useMemo and useCallback scattered everywhere as a performance "just in case". The React Compiler makes most of that unnecessary, and the book walks you through why.

The chapter on architecture alone could save a team months of painful refactoring down the line.

What tools does the book recommend?

The stack covered throughout the book:

State: Zustand for global, Context for auth/theme only
Data fetching: TanStack Query with useSuspenseQuery
Forms: React Hook Form + Zod
Styling: Tailwind CSS v4 + cn utility
Virtualization: @tanstack/react-virtual
Testing: Vitest + Testing Library
Build: Vite + babel-plugin-react-compiler

These are the tools that are winning in 2026. The book shows you how to use them together, not just individually.

The honest pitch

I wrote this because attending one conference completely changed how I think about the code I write every day. I want this book to do the same for other developers — without them needing to spend two days in a conference hall in Spain to get there.

If you're serious about React, this book is worth your time.

Get the preview →
Get it on Amazon →

Enache Gabriel-Ionuț is a React developer and the author of React Best Practices 2026.

I wrote an amazing React Book

Gabriel-Ionut Enache — Fri, 13 Mar 2026 18:32:58 +0000

In October 2025, I attended the React Alicante conference in Spain.

It was the first time for me when I went to a coding conference. Everything was so beautiful and well presented that I couldn't believe my eyes.

The content was so good that inspired me and made me realize I didn't know React as well as I should.

So, I was motivated to learn more important things about React, such as the new features and the performance parts and patterns that I didn't know.

It was this moment that created a question inside my mind: What if I would create a book that describes these topics and also make me learn them in depth?

And so I did. I present you: Best Ways to Improve Your React Project.

Topics

When. you should and should not useEffect
Patterns, like the Composition pattern
Architecture and folder structure using the Fractal pattern
Handling modern forms with RHF and Zod for Validation
Introduction to React Compiler and why you shouldn't memoize manually anymore
Virtualization
Using AI in your React workflow
useTransition and useOptimistic for instant UIs ... and more.

Preview

A free 20 pages preview is available on my website, on book's section: Free Preview

Where can you find it?

EPUB and Paperback versions on Amazon: Amazon EPUB & Paperback versions

PDF version and a 40% discount, use code LAUNCH on Gumroad:
PDF version with 40% discount

Vite 8 Is Here — And It Changes Everything About Frontend Builds

Gabriel-Ionut Enache — Fri, 13 Mar 2026 12:08:35 +0000

After months of beta testing and community feedback, Vite 8 has officially landed — and it’s the most significant release since Vite rewrote the rules of frontend development. The headline?

Vite is now powered by Rolldown, a blazing-fast Rust-based bundler built by the same team behind Vite. This isn’t just a performance bump. It’s an architectural shift that sets the stage for the next generation of frontend tooling.

The Problem Vite 8 Solves

Before Vite 8, Vite used two separate tools under the hood:

esbuild — for blazing-fast development server transforms
Rollup — for production bundling

This split worked well, but it created an inherent friction: two transformation pipelines, two plugin systems, and subtle behavioral differences between dev and production builds. Debugging “it works in dev but breaks in prod” is a rite of passage no developer should have to endure.

Vite 8 eliminates this split entirely.

Enter Rolldown: One Bundler to Rule Them All

https://rolldown.rs is a Rust-powered bundler with full compatibility with the Rollup plugin API. With Vite 8, it replaces both esbuild and Rollup in the build pipeline, giving you a single, unified toolchain end-to-end.

The numbers speak for themselves:

In official benchmarks across 19,000 modules, Rolldown completed in 1.61 seconds vs Rollup’s 40.10 seconds — a 25x improvement
Linear (the project management tool) reported their production build time dropping from 46 seconds to 6 seconds
Community reports are showing 10–30x faster production builds across a wide range of project sizes
Dev server startup is ~3x faster, full reloads are ~40% faster

And this is just the beginning. The team is actively working on Full Bundle Mode, which promises 10x fewer network requests during development by shipping a single pre-bundled file instead of individual modules.

What’s New in Vite 8

Unified Toolchain

Vite, Rolldown, and Oxc (the Rust-based JS compiler) are now all built and maintained by the same team — VoidZero. This means consistent behavior, tighter integration, and a single team accountable for the full stack.

Built-in tsconfig Paths Support

No more vite-tsconfig-paths plugin for most setups. Just set:

// vite.config.ts
export default {
  resolve: {
  tsconfigPaths: true,
  },
}

Browser Console Forwarding

You can now forward browser console.log and errors directly to your terminal:

export default {
  server: {
  forwardConsole: true,
  },
}

Useful for debugging SSR and backend-heavy apps where you want a single unified log stream.

Wasm SSR Support

.wasm?init imports now work in SSR environments — a long-requested feature for teams building with WebAssembly on the server.

Integrated Vite Devtools

An opt-in devtools option adds rich in-browser debugging and analysis tooling, giving you deep insight into module graphs, plugin transforms, and build metadata.

Lightning CSS for CSS Minification

Vite 8 switches from esbuild to Lightning CSS for CSS minification by default, offering better standards support and smaller output. You can opt back to esbuild if needed:

export default {
  build: {
  cssMinify: 'esbuild',
  },
}

React Plugin Goes Oxc-Native

@vitejs/plugin-react v6 ships alongside Vite 8. Babel is no longer a dependency — React Refresh transforms now run through Oxc, meaning faster installs and faster HMR.

Breaking Changes Worth Knowing

Vite 8 was designed to minimize migration friction, but a few things changed:

Node.js 20.19+ or 22.12+ is now required — drop anything older
esbuild.minify* options moved to build.rolldownOptions.output.minify
Some manual chunk configurations and dependency optimization behaviors have changed — check the https://vite.dev/guide/migration
Plugin authors: most Rollup-compatible plugins work out of the box since Rolldown implements the same plugin API SvelteKit, React Router, and Storybook have all been tested and work without changes.

Should You Upgrade Now?

Yes, for most projects. The migration path is smooth:

npm install vite@8 — save-dev
For simple projects with minimal custom config, that’s often all you need. For complex setups with heavy plugin usage or manual chunk splitting, review the migration guide and test your production build before deploying.

The Bigger Picture

Vite 8 isn’t just a version bump — it’s the first milestone in VoidZero’s vision of a fully unified JavaScript toolchain built in Rust. Vite owns the dev experience. Rolldown owns the bundling. Oxc owns the transforms. They all speak the same language now.

The JavaScript ecosystem has been plagued by fragmented tooling for years. Vite 8 is a serious step toward ending that era.

If you haven’t upgraded yet, there’s never been a better time. Your CI pipeline will thank you.

Have you upgraded to Vite 8 yet? What build time improvements are you seeing? Drop a comment below.

If you are into React, check my book and my YouTube channel here: https://gabrielenache.com/

The Best Ways to Improve Your React Projects (Lessons I Learned the Hard Way)

Gabriel-Ionut Enache — Thu, 12 Mar 2026 06:45:45 +0000

After working on multiple React projects—some successful, some painful—I started noticing the same problems appearing again and again.

Not because React is bad.
But because most React codebases slowly become messy over time.

If you've ever opened a React project and thought:

“Why is this component 600 lines long?”
“Why are there 12 useEffects here?”
“Why is state flowing through 8 components?”

You're not alone.

Over the years I collected patterns, refactoring strategies, and architectural ideas that consistently make React projects simpler, faster, and easier to maintain.

Eventually I decided to organize everything into a practical guide.

👉 You can check it out and even a free sample:
https://gabrielenache.com

But before that, let me share a few of the most important ideas from the book.

1. Stop Building “Mega Components”

One of the biggest problems in React projects is component bloat.

A component starts small:

UserProfile.jsx

Then over time it grows to include:

API calls
validation
UI logic
state management
business logic
event handlers
conditional rendering

Suddenly the file looks like this:

UserProfile.jsx (850 lines)

This creates several problems:

Hard to read
Hard to test
Hard to reuse
Hard to debug

A better pattern

Break logic into layers:

1. UI components

UserProfileView

2. Hooks

useUserProfile()

3. Services

userService.js

Now each part has a clear responsibility.

2. Custom Hooks Are Your Superpower

Many developers underestimate custom hooks.

They are not just for reuse — they are for architecture.

Example:

Instead of this inside a component:

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

Move the logic into a hook:

const { user, loading } = useUser();

Now your component becomes:

function Profile() {
  const { user, loading } = useUser();

  if (loading) return <Spinner />;
  return <UserCard user={user} />;
}

Much cleaner.

3. State Management Is Often Overcomplicated

I’ve seen projects using:

Redux
Context
Zustand
Recoil
local state

All at the same time.

This is usually unnecessary.

A good rule:

Use the simplest state solution possible.

Typical order:

Local component state
Context
Lightweight store (Zustand / Jotai)
Redux (only for complex apps)

Most apps don’t need Redux anymore.

4. Folder Structure Matters More Than You Think

Bad structure leads to chaos.

Example of a common messy structure:

/components
/hooks
/utils
/services

The problem?

Your features get spread across the entire project.

A better approach is feature-based structure:

/features
   /auth
      LoginForm.jsx
      useAuth.js
      authService.js

   /dashboard
      Dashboard.jsx
      dashboardService.js

Now everything related to a feature lives together.

This makes scaling much easier.

5. Performance Problems Often Come From Small Mistakes

Many React performance issues come from:

unnecessary re-renders
heavy components
unstable props
poorly structured state

Examples:

Bad:

<Component data={{ value: 10 }} />

Good:

const data = useMemo(() => ({ value: 10 }), []);
<Component data={data} />

Small details like this can make a huge difference in large applications.

Why I Wrote This Book

I wrote "Best Ways to Improve Your React Project" because most React resources focus on:

syntax
hooks basics
small examples

But real-world React projects need more than that.

They need:

architecture
structure
maintainability
scalability
debugging strategies
refactoring patterns

The goal of the book is simple:

Help developers turn messy React projects into clean, maintainable systems.

Who This Book Is For

This guide is useful if you are:

a React developer working on real projects
maintaining a growing codebase
refactoring messy components
trying to improve project structure
preparing for senior-level development

If You're Curious

You can check out the book here:

👉 https://gabrielenache.com

It includes practical strategies like:

React architecture patterns
component design principles
refactoring techniques
state management strategies
performance improvements

Everything is focused on real-world React development, not toy examples.

If you're a React developer, I'm curious:

What’s the biggest problem you’ve encountered in a React codebase?

Massive components?
State management chaos?
Performance issues?

Let me know — I’d love to hear your experience.

You're Overusing useEffect. Here's How to Fix It.

Gabriel-Ionut Enache — Wed, 11 Mar 2026 08:51:46 +0000

I'm going to say something controversial: most useEffect calls I see in code reviews don't need to exist.

Not because the developer wrote bad code. But because useEffect feels like the natural answer to a lot of problems it wasn't actually designed to solve. You need to do something after state changes? useEffect. You need to reset something when a prop changes? useEffect. You need to call a function after a user clicks a button? useEffect.

I was guilty of all of these. For years. And it wasn't until I really sat down with the React docs — specifically the page called You Might Not Need an Effect — that I understood what this hook is actually for.

This article is a practical breakdown of the most common useEffect misuses I've seen, and exactly what to do instead.

What is useEffect actually for?

Before we get into the anti-patterns, let's be clear about what useEffect is designed for.

useEffect is for synchronizing your component with an external system. That's it. Browser APIs like ResizeObserver, WebSockets, third-party libraries that need to be set up and torn down, timers that need cleanup — these are legitimate use cases.

If what you're doing doesn't involve an external system, you probably don't need useEffect.

Mistake #1: Deriving state from other state or props

This is the most common one. You have some state, you want to compute something from it, and you reach for useEffect to keep them in sync.

// ❌ Don't do this
function ProductList({ products }: { products: Product[] }) {
  const [filteredProducts, setFilteredProducts] = useState(products);

  useEffect(() => {
    setFilteredProducts(products.filter((p) => p.inStock));
  }, [products]);

  return (
    <ul>
      {filteredProducts.map((p) => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  );
}

What's wrong here? This causes two renders instead of one. React renders with the old filteredProducts, then the effect runs, updates the state, and React renders again. You're also storing derived data in state, which is almost always unnecessary.

// ✅ Do this instead
function ProductList({ products }: { products: Product[] }) {
  const filteredProducts = products.filter((p) => p.inStock);

  return (
    <ul>
      {filteredProducts.map((p) => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  );
}

Just compute it during render. One render, no effect, no extra state.

If the computation is genuinely expensive (sorting 50,000 records, complex transformations), then useMemo is appropriate. But filtering a normal-sized array? Just do it inline.

Mistake #2: Resetting state when a prop changes

You want to clear a text field when the user switches to a different item. Naturally, you write this:

// ❌ Don't do this
function CommentBox({ postId }: { postId: string }) {
  const [comment, setComment] = useState('');

  useEffect(() => {
    setComment('');
  }, [postId]);

  return (
    <textarea
      value={comment}
      onChange={(e) => setComment(e.target.value)}
    />
  );
}

Same problem as before — an extra render. The component first renders with the stale comment, then the effect fires and clears it, and React renders again.

The correct solution is one of the most underused tricks in React: the key prop.

// ✅ Do this instead
<CommentBox key={postId} postId={postId} />

When key changes, React unmounts the component entirely and mounts a fresh one. All local state resets automatically. No useEffect, no extra render, one line of code.

I use this trick constantly. Once you know about it, you'll see opportunities for it everywhere.

Mistake #3: Reacting to user events inside useEffect

This one looks obviously wrong when you see it written out, but I've seen it more times than I can count:

// ❌ Don't do this
function Form({ onSuccess }: { onSuccess: () => void }) {
  const [submitted, setSubmitted] = useState(false);

  useEffect(() => {
    if (submitted) {
      onSuccess();
    }
  }, [submitted, onSuccess]);

  return (
    <button onClick={() => setSubmitted(true)}>
      Submit
    </button>
  );
}

Why would you do this? If something needs to happen because the user clicked a button, put it in the click handler. That's what click handlers are for.

// ✅ Do this instead
function Form({ onSuccess }: { onSuccess: () => void }) {
  const handleClick = () => {
    onSuccess();
  };

  return (
    <button onClick={handleClick}>
      Submit
    </button>
  );
}

The rule is simple: if it's caused by a user action, handle it in an event handler.

Mistake #4: Effect chains

This is where things get really messy. One useEffect sets some state, which triggers another useEffect, which sets more state, which triggers another...

// ❌ A chain of effects — a debugging nightmare
useEffect(() => {
  if (userId) {
    setIsLoadingUser(true);
    fetchUser(userId).then((user) => {
      setUser(user);
      setIsLoadingUser(false);
    });
  }
}, [userId]);

useEffect(() => {
  if (user) {
    setPermissions(calculatePermissions(user.role));
  }
}, [user]);

useEffect(() => {
  if (permissions) {
    setNavItems(buildNavigation(permissions));
  }
}, [permissions]);

Every link in this chain adds another render cycle. You have cascading state updates, potential race conditions, and code that's nearly impossible to trace when something goes wrong.

If you find yourself in this situation, step back and ask: can I compute this in a single place?

// ✅ Derive everything from the source of truth
useEffect(() => {
  if (!userId) return;

  fetchUser(userId).then((user) => {
    const permissions = calculatePermissions(user.role);
    const navItems = buildNavigation(permissions);

    setUser(user);
    setPermissions(permissions);
    setNavItems(navItems);
  });
}, [userId]);

Or better yet — use TanStack Query and get rid of the manual loading state management entirely (more on that below).

Mistake #5: Fetching data without proper cleanup

Data fetching is one of the legitimate uses of useEffect. But most implementations you'll find in the wild are broken in a subtle way:

// ❌ This has a race condition
function UserCard({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);

  useEffect(() => {
    fetchUser(userId).then((data) => setUser(data));
  }, [userId]);

  return user ? <div>{user.name}</div> : <p>Loading...</p>;
}

The problem: if userId changes before the first fetch resolves, both requests are in flight simultaneously. Whichever finishes last wins. You might render data for the wrong user.

The fix is to ignore stale responses:

// ✅ With cleanup — ignores stale responses
useEffect(() => {
  let cancelled = false;

  fetchUser(userId).then((data) => {
    if (!cancelled) setUser(data);
  });

  return () => {
    cancelled = true;
  };
}, [userId]);

But honestly? In 2026, you shouldn't be writing raw data fetching in useEffect at all. Use TanStack Query. It handles caching, deduplication, cancellation, and background refetching out of the box. You literally can't forget the cleanup because the library handles it:

// ✅ Just use TanStack Query
import { useQuery } from '@tanstack/react-query';

function UserCard({ userId }: { userId: string }) {
  const { data: user, isLoading } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUser(userId),
  });

  return isLoading ? <p>Loading...</p> : <div>{user?.name}</div>;
}

No cleanup, no race conditions, automatic caching, background refetching when you return to the tab. It's not even a close comparison.

So when DO you need useEffect?

Here's the short list of genuinely appropriate useEffect uses:

Setting up a WebSocket connection and cleaning it up on unmount
Subscribing to a browser API like ResizeObserver, IntersectionObserver, or addEventListener
Integrating a third-party library that directly manipulates the DOM (like a chart library or map)
Syncing with localStorage or sessionStorage on mount
Analytics page view tracking when a route changes

Notice the pattern: all of these involve talking to something outside of React. That's the rule. If you're only dealing with React state and props, you probably don't need useEffect.

The rules I follow

Let me summarize with the practical rules I've internalized:

If you can compute it during render, don't store it in state. Derived values belong in the render function, not in state + useEffect.
If it's triggered by a user event, handle it in the event handler. onClick, onChange, onSubmit — these are where your logic belongs.
If you need to reset state when a prop changes, use the key prop. Not useEffect. Just change the key.
If you're fetching data, use TanStack Query or SWR. Don't reinvent this with raw useEffect.
If you're synchronizing with an external system, useEffect is correct. That's literally what it's for.

Wrapping up

useEffect is a powerful hook that gets misused because it seems like the right tool for so many problems. But most of the time, the real solution is simpler: compute during render, handle events in handlers, or use a library that's designed for the specific problem you're solving.

Once you internalize these rules, you'll find your components getting smaller, faster, and much easier to debug. The double renders disappear. The cascading state updates disappear. The race conditions disappear.

It's one of those things where less code genuinely means better code.

This article is based on a chapter from my book "Best Ways to Improve Your React Project — 2026 Edition" — a guide for mid-to-senior React developers covering architecture, patterns, performance, React 19 APIs, testing, and more.

If you found this useful, the book has 13 more chapters like it.

→ PDF on Gumroad (use code LAUNCH for a 40% launch discount): https://gabrielenache.gumroad.com/l/best-ways-to-improve-your-react-project

The MERN Stack SaaS Guide

Gabriel-Ionut Enache — Mon, 09 Mar 2026 11:48:52 +0000

I wrote a MERN SaaS Starter Guide on GitHub and I want to share it with you for FREE.

It includes:

Architecture
Best Libraries to use
Setup
Deployment steps

Contributors are welcome! 100% open source!

https://github.com/eIonut/MERN-SaaS-Starter-Guide

Composition Pattern in React

Gabriel-Ionut Enache — Sat, 07 Mar 2026 15:38:32 +0000

What is composition in React?

Composition is a pattern where components are tied up together like building blocks to create complex UIs.

Instead of relying too much on props and foul yourself that if you add one more prop the component will then be more customizable, you should always try to use this pattern whenever possible to avoid and minimize the amount of props your component has.

Take a look at the following ConfiguredModal.tsx component, starting with the necessary types:

type ConfiguredModalProps = {
  isOpen: boolean;
  onClose: () => void;
  title?: string;
  withDelimiter?: boolean;
  withFooter?: boolean;
  children: React.ReactNode;
  headerActions?: () => React.ReactNode; // edit button, download
// ... more props
};

For the sake of simplicity and to not scare you with too much CSS, I will hide the className attributes from all the elements.

export default function ConfiguredModal({
  isOpen,
  onClose,
  headerActions,
  title,
  withDelimiter,
  withFooter,
  children,
}: ConfiguredModalProps) {
  if (!isOpen) return null;

  return (
    <div aria-modal="true" role="dialog" onClick={onClose}>
      <div onClick={(e) => e.stopPropagation()}>
        <button onClick={onClose}>
          <CircleX />
        </button>

        <div>
          {title && <h2>{title}</h2>}
          {headerActions ? headerActions() : null}
        </div>

        <div>{children}</div>

        {withDelimiter && (
          <span>
            <hr />
          </span>
        )}

        {withFooter && (
          <footer>
            <PrimaryButton onClick={() => console.log("Confirm clicked")}>
              Confirm
            </PrimaryButton>
          </footer>
        )}
      </div>
    </div>
  );
}

As you probably noticed, this component has a lot of props, even if it doesn't look like it, because you would say: "Huh, 7 props are not many, right?". Well… that depends. By just looking at the code, this component is very hard to read. And also, even on the consumer part, it looks tedious with all these props:

<ConfiguredModal
  title="My Modal Title"
  isOpen={isOpen}
  onClose={() => setIsOpen(false)}
  withDelimiter
  headerActions={() => (
    <div>
      <PrimaryButton
        variant="outlined"
        onClick={() => console.log("Edit clicked")}
      >
        Edit
      </PrimaryButton>
      <PrimaryButton
        variant="outlined"
        onClick={() => console.log("Download clicked")}
      >
        Download
      </PrimaryButton>
    </div>
  )}
  withFooter
>
  <p>Some text..</p>
</ConfiguredModal>;

Even if this is technically correct, we have too many conditionals: If title exists, then display title. If there is a HeaderActions component that should be displayed just display it or return null, show a delimiter if withDelimiter is provided or it's true, same for the footer.

Wouldn't it be nice if we would have a nice way to keep the same functionalities, but with a more readable and composable component?
Well, fortunately, there is a way.

The Donut pattern in practice

The "Donut pattern" or "The composition pattern" is one of the most fundamental yet important patterns in building complex UI. It removes the configuration needs(adding more props) and it promotes composition as its root technique. To see this pattern in action, I created the optimized composed version of the ConfiguredModal.tsx, which resides in the ComposedModal.tsx component:

export default function ComposedModal({
  isOpen,
  onClose,
  children,
}: ComposedModalProps) {
  return (
    isOpen && (
      <div aria-modal="true" role="dialog" onClick={onClose}>
        <div onClick={(e) => e.stopPropagation()}>
          <button onClick={onClose}>
            <CircleX />
          </button>
          {children}
        </div>
      </div>
    )
  );
}

This looks much clearer, right? We only keep the "skeleton" of our modal inside the component, but the interesting part comes next. Now that we defined the basic functionality of the modal, it's time to define it's parts and components like so:

type HeaderProps = {
  title: string,
  children: React.ReactNode,
};

function Header({ title, children }: HeaderProps) {
  return (
    <div>
      <h2>{title}</h2>
      <div>{children}</div>
    </div>
  );
}

function Body({ children }: { children: React.ReactNode }) {
  return <div>{children}</div>;
}

function Footer({ children }: { children: React.ReactNode }) {
  return (
    <>
      <span>
        <hr />
      </span>
      <footer>{children}</footer>
    </>
  );
}

ComposedModal.Header = Header;
ComposedModal.Body = Body;
ComposedModal.Footer = Footer;

We tell React that our ComposedModal can have 3 parts: A Header, a Body, and a Footer. For this, we write a simple component for each part of the modal, where we basically only define the required structure of the respective component. We basically tell the consumer: "We give you the structure that we want, but you can put anything in there and style it however you want".

This way, we ensure that the "final" component will be composable and we give the user the power to choose if they want to display a certain part of the modal or not by simply not putting anything in there.

Now, on the consumer part, the code is a lot clearer and it looks like a donut, because the consumer places everything that he needs as children, but in a structured and composed way:

export default function ExamplePage() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>Open Modal</button>
      <ComposedModal isOpen={isOpen} onClose={() => setIsOpen(false)}>
        <ComposedModal.Header title="My modal title">
          <div>
            <PrimaryButton
              variant="outlined"
              onClick={() => console.log("Edit clicked")}
            >
              Edit
            </PrimaryButton>
            <PrimaryButton
              variant="outlined"
              onClick={() => console.log("Download clicked")}
            >
              Download
            </PrimaryButton>
          </div>
        </ComposedModal.Header>
        <ComposedModal.Body>
          <p>Some text...</p>
        </ComposedModal.Body>
        <ComposedModal.Footer>
          <PrimaryButton onClick={() => console.log("Confirm clicked")}>
            Confirm
          </PrimaryButton>
        </ComposedModal.Footer>
      </ComposedModal>
    </>
  );
}

Conditional Rendering Caveats in React

Gabriel-Ionut Enache — Sat, 07 Mar 2026 14:50:10 +0000

When components need to display different things depending on different conditions, typically we would use the &&(logical and) operator.

Say we have a list or products and we want to display our list of products in JSX and therefore, on our web page. Pretty easy, right? Now… what happens if the list of products is empty?

Using the && operator, as you would have probably guessed, 0 is rendered on the page. That's because when Javascript evaluates products.length which is 0 with anything else, the whole result of the expression will be 0.

Solution

Use the conditional(ternary operator) so you can explicitly tell JSX what to render based on a true or false expression.
Using the ternary operator

I Used v0 as a Figma Replacement, Not a Code Generator — Here's the Workflow

Gabriel-Ionut Enache — Sat, 14 Feb 2026 11:32:05 +0000

I'm building HomeAfford, a mortgage affordability calculator, in Next.js with TypeScript and Tailwind CSS.

Before writing any code, I prompted v0 by Vercel to generate the full UI: landing page, calculator interface, pricing page, and feature sections. The result looked great — clean layout, solid component
structure, good visual hierarchy.

Then I looked at the code.

Everything was calculated on the frontend. The code was messy. Files were huge.

So I made a decision: keep the design, rewrite the code.

I treated v0's output exactly like a Figma mockup — a visual reference, not a codebase. Then I built four things from scratch:

** 1. Landing page — based on v0's layout but with real components

Google authentication — not generated by v0 at all
Mortgage calculator — actual math, real inputs, dynamic results
Pricing page — connected to real tier logic**

The 3-step workflow I'm using going forward

**1. Design with AI — use v0/similar tools to explore layouts fast

Evaluate the output — keep what works visually, ignore the code
Build it yourself — use the design as a reference and write production code**

This isn't an anti-AI take. v0 genuinely saved me time I would've spent in Figma. But knowing where AI helps and where it doesn't is the skill.

I recorded the full process: https://youtube.com/watch?v=YvLX88Fr-y0

This is the first in a series building HomeAfford from scratch. Next up: the technical deep dive into the calculator logic.