DEV Community: Idan Bakal

Stop Over Engineering Your Frontend State: A Developer's Guide to "Less is More"

Idan Bakal — Sat, 18 Jul 2026 19:34:19 +0000

Choosing a state management library feels a bit like walking into a candy shop. You've got Zustand, Redux Toolkit, Recoil, XState, and good old React Context. It’s easy to get caught up in the hype and introduce a massive library for a project that honestly doesn't need it.

Let’s talk about how to audit your state management and why "Less is More" should be your guiding principle for your next React + TypeScript project.

The Red Flag: "Where did this prop come from?"
We’ve all been there. You open a component, look at the props, and see something like this:

This is Prop Drilling hell, and the natural instinct is to run straight into the arms of a global state manager. But wait—before you npm install, let's break down the types of state you actually have.

Server State vs. Client State (The Great Divide) 90% of the data in your frontend application usually comes from an API. If you are fetching user profiles, financial data, or product lists, that is not client state. That is Server State.

If you use a tool like TanStack Query (React Query) or framework built-ins (like Server Components), you don't need Redux or Zustand for this data.

💡 The Rule: If it lives in a database and you're just fetching it, let your data-fetching library cache it. Keep it out of your global UI store.

UI State: Local is King Does the entire application need to know that a specific dropdown menu is open? No.

Keep your UI state as local as possible. If two sibling components need to share a tiny piece of layout state (like a sidebar toggle), React Context combined with a clean TypeScript interface is perfectly fine.

When Do You Actually Need Global State?
So, when should you use something like Zustand?

You need a dedicated global state manager when you have complex, highly interactive client-side logic that crosses multiple unrelated domains. Examples include:

A complex multi-step form wizard where users can go back and forth.

A dynamic dashboard builder where widgets interact with each other in real-time.

An e-commerce shopping cart with complex discount rules calculated on the fly.

For these cases, a lightweight store like Zustand shines because it doesn't wrap your app in providers and plays beautifully with TypeScript inference.

Summary Checklist for Your Next Project
Before writing your next line of code, ask yourself:

Is this data from an API? ➡️ Use TanStack Query / Server State.

Is this data just for this component/page layout? ➡️ Use useState or Context.

Is this dynamic, complex client logic shared globally? ➡️ Reach for Zustand.

By isolating your server state from your UI state, your code becomes modular, much easier to type with TypeScript, and significantly faster to debug.

Let's Chat! 💬
What’s your go-to state management stack? Are you team "No-Global-Store" or team Zustand? Let’s discuss in the comments below! 👇

Stop Over Engineering Your Frontend State: A Developer's Guide to "Less is More"

Idan Bakal — Sat, 18 Jul 2026 19:29:08 +0000

Let’s talk about how to audit your state management and why "Less is More" should be your guiding principle for your next React + TypeScript project.

The Red Flag: "Where did this prop come from?"

We’ve all been there. You open a component, look at the props, and see something like this:


typescript
interface DashboardHeaderProps {
  user: UserData;
  theme: 'light' | 'dark';
  isSidebarOpen: boolean;
  toggleSidebar: () => void;
  // ...10 more props passed down from 4 levels above
}
This is Prop Drilling hell, and the natural instinct is to run straight into the arms of a global state manager. But wait—before you npm install, let's break down the types of state you actually have.

1. Server State vs. Client State (The Great Divide)
90% of the data in your frontend application usually comes from an API. If you are fetching user profiles, financial data, or product lists, that is not client state. That is Server State.

If you use a tool like TanStack Query (React Query) or framework built-ins (like Server Components), you don't need Redux or Zustand for this data.

💡 The Rule: If it lives in a database and you're just fetching it, let your data-fetching library cache it. Keep it out of your global UI store.

2. UI State: Local is King
Does the entire application need to know that a specific dropdown menu is open? No.

Keep your UI state as local as possible. If two sibling components need to share a tiny piece of layout state (like a sidebar toggle), React Context combined with a clean TypeScript interface is perfectly fine.

TypeScript
export const UIProvider = ({ children }: { children: React.ReactNode }) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <UIContext.Provider value={{ isOpen, toggle: () => setIsOpen(!isOpen) }}>
      {children}
    </UIContext.Provider>
  );
};
When Do You Actually Need Global State?
So, when should you use something like Zustand?

You need a dedicated global state manager when you have complex, highly interactive client-side logic that crosses multiple unrelated domains. Examples include:

A complex multi-step form wizard where users can go back and forth.

A dynamic dashboard builder where widgets interact with each other in real-time.

An e-commerce shopping cart with complex discount rules calculated on the fly.

For these cases, a lightweight store like Zustand shines because it doesn't wrap your app in providers and plays beautifully with TypeScript inference.

TypeScript
import { create } from 'zustand'

interface CartState {
  items: string[];
  addItem: (item: string) => void;
}

export const useCartStore = create<CartState>((set) => ({
  items: [],
  addItem: (item) => set((state) => ({ items: [...state.items, item] })),
}))
Summary Checklist for Your Next Project
Before writing your next line of code, ask yourself:

Is this data from an API? ➡️ Use TanStack Query / Server State.

Is this data just for this component/page layout? ➡️ Use useState or Context.

Is this dynamic, complex client logic shared globally? ➡️ Reach for Zustand.

By isolating your server state from your UI state, your code becomes modular, much easier to type with TypeScript, and significantly faster to debug.

Let's Chat! 💬
What’s your go-to state management stack? Are you team "No-Global-Store" or team Zustand? Let’s discuss in the comments below! 👇

Stop building backends for your MVPs. (And how AI actually saved my codebase)

Idan Bakal — Mon, 06 Jul 2026 15:16:36 +0000

Let's be real for a second. Building anything related to personal finance is an absolute nightmare. 💸

The expectations are instantly sky-high: it needs to look like a polished $10M SaaS, sync data perfectly in real-time, and oh, it needs to be as secure as a bank. No pressure for a solo developer, right?

I recently shipped Nestly (you can play with the live app here: nestly1.netlify.app), a platform built to help families manage their budgets.

Instead of spending three weeks configuring an Express server, writing boilerplate auth, and messing up a database schema, I wanted to ship something robust in days. Here is the exact stack setup that made it happen, and the honest truth about how AI fit into the workflow.

The Backend: Just use Supabase 🔒

If you're still writing custom auth and basic CRUD APIs from scratch for your MVPs, you're losing time.

For Nestly, I went all-in on Supabase. When you're dealing with people's financial data, security isn't a "fix it in production" feature. I relied heavily on PostgreSQL's Row Level Security (RLS).

Pro tip: Writing RLS policies directly in the DB means your data isolation happens at the lowest level possible. Even if your frontend has a bug, users physically cannot query someone else's data.

Combined with their real-time listeners, budget updates just reflect instantly across the UI without complex polling logic.

The Frontend: Keeping it snappy 📈

For the client side, the goal was keeping things incredibly fast and responsive.

State Management: Used lightweight, modern state management to handle complex financial data streams without hammering the server with unnecessary re-renders.
Data Viz: Integrated clean charting libraries. Let's face it—if users can't see their spending patterns visually in two seconds, your finance app is just a glorified Excel sheet.

How AI Actually Saved My Codebase 🤖

We've all seen those generic "AI wrote my entire SaaS in 5 minutes" posts on Twitter. Let's be honest: that code is usually garbage and unmaintainable.

But where AI actually shines is acting as a hyper-efficient sounding board. I didn't let it blindly generate my app, but I used it to destroy dev friction:

Postgres RLS Policies: Instead of fighting with complex SQL syntax for edge-case security policies, I used AI to scaffold the query logic instantly.
Rubber Duck Debugging: When a state update wasn't triggering correctly, pasting the component into the AI caught the silent bug in 10 seconds instead of wasting my entire evening.
Architecture Sanity Checks: Asking it to review component boundaries to make sure the code stays modular and readable.

It didn't replace me, but it gave me the execution speed of a 3-person team while keeping the quality high.

Over to you 👇

I'm curious how the rest of the community is shipping nowadays.

What's your absolute go-to stack for spinning up secure, production-ready MVPs at lightning speed?
Are you actually letting AI write raw features for you, or are you using it strictly for debugging, architecture, and boilerplates?

Let's talk in the comments!

The AI Code Inflation: Why Senior Devs are Writing LESS Code in 2026

Idan Bakal — Sun, 05 Jul 2026 15:44:07 +0000

Let’s be honest for a second. In 2026, writing code is no longer the bottleneck.

With advanced AI extensions, autonomous agents, and context-aware tools, anyone can generate a 500-line React component or a fully functional Express backend in less than 30 seconds.

We went from "How do I write this?" to "How do I handle the 10,000 lines of code my team generated this week?" almost overnight.

But this hyper-productivity has a dark side. Welcome to the era of AI Code Inflation.

The Silent Killer: "Prompted" Technical Debt

Because generating code has zero friction, codebases are bloating at an unsustainable rate. Junior developers are shipping massive features without fully understanding the underlying logic. Senior developers are spending 70% of their time reviewing massive Pull Requests filled with AI-generated boilerplate that looks clean on the surface but contains subtle, structural flaws.

If you measure your productivity by the number of lines of code (LoC) you commit, you are losing the game.

In 2026, the metrics have flipped. The most valuable developers aren't the ones who use AI to write more code. They are the ones who use AI to design systems that require less code.

Shifting from "Code Generator" to "Context Architect"

To survive and thrive in this environment, your mental model needs to shift. You need to stop acting like a typist and start acting like a Context Architect.

Here is how the best engineering teams are adapting:

1. Radical Minimalism & Strict Typing

When you let an AI loose on a dynamic, loosely-typed codebase, it will hallucinate and create custom utility functions for things that already exist. By enforcing strict TypeScript interfaces and rigorous API schemas (like OpenAPI or tRPC), you create absolute guardrails.

The AI shouldn't guess what the data looks like; the architecture should dictate it.

2. The "Delete Over Create" Mindset

Before asking your AI agent to build a new feature, ask it to look at your existing codebase and see what can be refactored or reused. A great prompt isn't "Write a custom hook for this modal". A great prompt is: "Look at our current UI components. How can we abstract this new requirement into our existing design token system without adding new files?"

3. Bulletproof Unit Testing as the First Step

Since AI can write tests in seconds, the modern workflow should be strictly test-driven. Write your integration and edge-case specs first. Let the AI write the code to pass those tests. If it creates a bloated solution, the tests will still catch the regressions, allowing you to prompt for a tighter, cleaner refactor.

The 2026 Dev Stack Blueprint

If you want your projects to remain maintainable, your tech stack needs to be optimized for clarity and performance, not just speed. Teams are moving away from massive, heavy frameworks and doubling down on clean, predictable setups:

Component Level: Pure, composable functional components (React/TypeScript) styled with utility-first frameworks like Tailwind CSS to keep the CSS footprint practically at zero.
State Management: Localized state and immutable data flows. The less global state complexity you have, the fewer things an AI agent can break.
Tooling: Moving towards protocols like MCP (Model Context Protocol) to let AI tools safely read the local repository structure so they understand the architectural pattern before they suggest a single line of code.

Conclusion: Less is More

The future of software engineering belongs to developers who know how to keep systems small, fast, and highly cohesive.

The next time you open your IDE, don't ask how much code you can generate today. Ask how much code you can prevent from being written in the first place.

How is your team handling the explosion of AI-generated code? Are you experiencing repository bloat, or have you found a way to keep things lean? Let’s argue in the comments below!

Moving Beyond Chat: Why AI Agents and MCP Are the Next Big Shift for Developers

Idan Bakal — Sat, 04 Jul 2026 18:24:07 +0000

For the past two years, most of us integrated AI into our workflow using a "ping-pong" model: we write a prompt, get some code, copy-paste it, hit a bug, and paste the error back.

But in 2026, the tech stack is shifting from simple chat interfaces to Autonomous AI Agents.

We aren't just talking about smarter chatbots. We are talking about production-ready systems that can plan, use specialized tools, debug themselves, and interact with our local development environments.

The Core Blueprint of an AI Agent

Unlike a standard LLM call that finishes after a single response, an AI Agent operates in an Evaluate-Act-Learn loop. To actually build or interact with one, you need to understand its three core pillars:

State & Memory: Maintaining context across complex, multi-step tasks (both short-term session state and long-term vector-based memory).
Planning & Reflection: The ability to break down a high-level goal (e.g., "Scrape this e-commerce site and update our DB schema") into a sequence of executable tasks, and pivot if a step fails.
Tools (The Game Changer): Giving the model execution capabilities via APIs, sandboxed code execution environments, and file system access.

Enter MCP: The Architecture Connecting It All

The biggest catalyst for this shift right now is the adoption of the Model Context Protocol (MCP).

Think of MCP as an open standard that acts like a universal adapter. Instead of writing custom, brittle glue-code for every single tool you want an AI to use, MCP provides a secure, structured way for LLMs to safely read and write to local repositories, query databases, or trigger deployment pipelines.

[ AI Agent ] ──( MCP Protocol )──► [ MCP Server ] ──► [ Local Files / DB / API ]

When an agent is plugged into your workspace via MCP, it doesn't just guess what your code looks like. It can scan an entire TypeScript repository, map out your Tailwind components, identify type mismatches, and apply a refactor across multiple files simultaneously.

From Dev to Architect: How Your Role is Changing

The old debate of "Will AI replace developers?" missed the mark. It’s not replacing you; it’s shifting your role up the stack.

Instead of spending hours writing boilerplate code, configuring initial Vite configs, or tracking down missing commas in nested objects, you are becoming a System Architect and Code Reviewer.

You write the architectural spec, define strict TypeScript interfaces, set up the constraints, and let the agent do the heavy lifting of building the features and writing unit tests inside a sandboxed environment. Your job is to look at the PR, spot edge cases, and steer the ship.

The Reality Check: You aren't managing lines of code anymore; you are managing the context and the boundaries you set for your digital team.

The Dark Side: Token Bleeding and Hallucination Loops

It’s not all magic. Working with autonomous agents introduces a completely new set of engineering headaches:

Infinite Loops (Token Bleeding): If an agent encounters an unhandled runtime error and its reflection logic isn't properly gated, it can get stuck in a loop trying to fix itself. It will happily burn through millions of tokens (and your credit card) in a single night trying to solve a wedding dependency or a broken import.
Security & Blast Radius: Giving an agent write access to your local file system or staging DB is risky. Securing the agent's blast radius—using strictly isolated Docker sandboxes and read-only API keys where possible—is the new baseline for DevOps security.

How to Prepare Your Stack

If you want to stay ahead, stop thinking about how to write better prompts for a chat window. Start focusing on:

Building robust APIs that are easily consumable by machines (clear OpenAPI specs are your best friend).
Understanding Agentic Frameworks (like LangChain, AutoGen, or building raw custom loops).
Setting up strict linting and type-safety so agents have clear guardrails when writing code for you.

Are you already using autonomous agents or MCP servers in your daily development setup, or do you still prefer total control via standard IDE extensions? Let’s talk in the comments below!

From Frontend to Full-Stack: Building a Type-Safe App with React, TypeScript, and Tailwind

Idan Bakal — Wed, 01 Jul 2026 18:20:13 +0000

As frontend developers, we love the comfort zone of crafting beautiful interfaces. React gives us component structure, Tailwind CSS lets us style at lightning speed, and TypeScript keeps our props and state safe.

But there always comes a moment when your app needs to live, breathe, and persist data. You need a database, an API, and server-side logic. The leap to Full-Stack can feel intimidating—learning a new language, figuring out deployment, or worrying about API type safety.

The good news? If you already know React, TypeScript, and Tailwind, you are 80% of the way there. In this article, we’ll look at how to leverage your existing frontend stack to build a robust, production-ready Full-Stack application without losing the developer experience (DX) you love.

Step 1: The Shared Type Definitions

The biggest pain point in traditional full-stack development is the mismatch between the database schema and the frontend UI. By using TypeScript across the entire stack, we can share interfaces and achieve absolute end-to-end type safety.

Create a shared file named types.ts that both your frontend and backend can access:

Step 2: Implementing the Full-Stack Component

When mapping over server data, styling dynamic states (like loading, disabled, or error boundaries) becomes incredibly clean with Tailwind utility classes.

Here is the complete code for your frontend component ProductCard.tsx, importing the exact same type structure used by the backend layer:

Step 3: Connecting Frontend State to Backend Mutations

On the frontend, you manage view states with useState. On the backend, you manage database states with API queries. To connect them seamlessly without losing type integrity, you can handle your fetch calls like this:

Conclusion

Transitioning to Full-Stack doesn't mean forgetting everything you know about the frontend. By combining React, TypeScript, and Tailwind CSS with modern database tools and shared types, you completely eliminate structural mismatch bugs, preserve high developer velocity, and guarantee runtime data integrity.

React vs. Angular in 2026: Choosing the Right Architecture for Enterprise Applications

Idan Bakal — Sat, 27 Jun 2026 20:03:26 +0000

The debate between React and Angular has been running for over a decade. In 2026, with both ecosystems reaching peak maturity and heavily incorporating AI-driven optimizations, the question is no longer which tool is "better," but rather which architectural philosophy aligns with your organization's engineering culture and project scale.

Having architected production applications in both ecosystems, I believe the decision strictly comes down to structural control versus development flexibility.

Angular: The Enterprise Safe Haven

Angular’s greatest strength has always been its strict, opinionated nature. In a large enterprise environment with dozens of distributed developer teams, this rigidity is an asset, not a liability.

Standardization: Angular forces every developer to write code the exact same way. A service, a component, and a module look identical whether they were written by a team in New York or Tel Aviv.
Out-of-the-Box Toolkit: With robust built-in state management principles, native HTTP clients, and a powerful CLI, you rarely depend on third-party libraries. This dramatically reduces supply-chain security risks—a critical factor for enterprise platforms.

React: The Scalable Ecosystem

React approaches production from the opposite direction. It provides a lightweight component library and leaves the architectural decisions entirely up to the developer.

Flexibility & Speed: React allows senior engineers to craft highly optimized, custom state and rendering patterns (using hooks like useMemo and custom architectures) tailored specifically to the app's performance bottlenecks.
The Ecosystem Advantage: If a feature needs to be built, a world-class package already exists for it. However, this flexibility requires strong senior leadership; without it, large React codebases can quickly devolve into a chaotic mix of conflicting design patterns.

The Verdict for 2026

If your priority is cross-team predictability, long-term maintainability, and built-in architectural guardrails, Angular remains the undisputed king for massive enterprise setups.

If your application demands highly dynamic, unique user experiences, rapid UI iterations, and your team consists of disciplined developers who can manage architectural freedom without making a mess, React is your best weapon.

Conclusion

Don't choose based on syntax preferences. Analyze your team's size, your project's security constraints, and how much architectural freedom you can safely afford before making the commitment.

Why AI Won’t Replace Full-Stack Developers, But Will Re-Engineer the Role

Idan Bakal — Sat, 27 Jun 2026 19:59:19 +0000

The debate about whether LLMs and advanced AI agents will render software engineers obsolete is everywhere. Non-technical observers see AI generating functional React components or spinning up backend environments in seconds and assume the human element is fading out.

As a Full-Stack developer who integrates AI heavily into daily workflows, I view this perspective as a fundamental misunderstanding of what software engineering actually entails. AI isn't replacing developers; it is aggressively filtering out junior-level boilerplate work and transforming engineers into software architects.

Code Generation is Not Architecture

Writing syntax has always been the lowest common denominator of software development. The real value of a Full-Stack developer lies in system architecture, state management optimization, database indexing, security compliance, and understanding business logic.

An AI can write an isolated SQL query or a sleek Angular service, but it struggles significantly with:

Contextual Domain Awareness: Understanding why a specific legacy database architecture was chosen and how to safely migrate it without breaking live production systems.
Complex State Interdependencies: Scaling complex frontend state mutations across massive distributed systems without creating race conditions.
Intentional Debugging: Knowing exactly what to look for when an obscure memory leak occurs under heavy concurrent user loads.

AI handles the "how to syntax" flawlessly. Humans must still handle the "what to build and why."

The New Stack: Developer + AI Orchestration

Instead of fighting the current, elite developers are treating AI tools as highly capable junior developers. We use them to instantly generate repetitive code, draft boilerplate schemas, and run sanity checks on algorithms. This shift allows us to spend 80% of our cognitive energy on high-level system design and performance optimization rather than getting bogged down in syntax errors.

Conclusion

The developers who will lose their jobs to AI are those who only know how to copy-paste code or write basic components. Full-Stack engineers who master system design and learn to orchestrate AI tools to maximize their output will become irreplaceable 10x developers. The future belongs not to the AI alone, but to the engineer who knows how to direct it.

Building a High-Performance Dynamic Product Filter Component in React and Tailwind CSS

Idan Bakal — Tue, 23 Jun 2026 20:35:00 +0000

In modern e-commerce applications, user experience is everything. Users expect to filter through hundreds of products instantly without irritating page reloads. A lagging or poorly designed filter UI can directly impact conversion rates.

In this tutorial, we will build a production-ready, highly responsive Dynamic Product Filter Component from scratch using React (with state optimization) and Tailwind CSS for slick, modern styling.

Step 1: The Product Data Structure

First, let's define our mock product database structure. Create a file named data.js or keep it inside your component:


export const PRODUCTS_DATA = [
  { id: 1, name: "UltraFit Running Shoes", category: "Footwear", price: 120, rating: 4.8 },
  { id: 2, name: "Pro-Grip Training Gloves", category: "Accessories", price: 35, rating: 4.5 },
  { id: 3, name: "AirWeave Sports Hoodie", category: "Apparel", price: 75, rating: 4.6 },
  { id: 4, name: "Pulse Smart Fitness Watch", category: "Electronics", price: 240, rating: 4.9 },
  { id: 5, name: "Apex Cushion Sneakers", category: "Footwear", price: 150, rating: 4.2 },
  { id: 6, name: "Thermal Hydro Flask", category: "Accessories", price: 45, rating: 4.7 }
];

export const CATEGORIES = ["All", "Footwear", "Apparel", "Accessories", "Electronics"];

Step 2: Implementing the Core Filter Component

We will utilize the useMemo hook from React to ensure maximum performance. This caches the filtered results and only recalculates them when our criteria actually change, preventing unnecessary re-renders.

Here is the complete code for ProductFilter.jsx:



import React, { useState, useMemo } from 'react';

const PRODUCTS_DATA = [

  { id: 1, name: "UltraFit Running Shoes", category: "Footwear", price: 120, rating: 4.8 },

  { id: 2, name: "Pro-Grip Training Gloves", category: "Accessories", price: 35, rating: 4.5 },

  { id: 3, name: "AirWeave Sports Hoodie", category: "Apparel", price: 75, rating: 4.6 },

  { id: 4, name: "Pulse Smart Fitness Watch", category: "Electronics", price: 240, rating: 4.9 },

  { id: 5, name: "Apex Cushion Sneakers", category: "Footwear", price: 150, rating: 4.2 },

  { id: 6, name: "Thermal Hydro Flask", category: "Accessories", price: 45, rating: 4.7 }

];

const CATEGORIES = ["All", "Footwear", "Apparel", "Accessories", "Electronics"];

export default function ProductFilter() {

  const [searchQuery, setSearchQuery] = useState('');

  const [selectedCategory, setSelectedCategory] = useState('All');

  const [maxPrice, setMaxPrice] = useState(300);

  const [sortBy, setSortBy] = useState('featured');

const filteredProducts = useMemo(() => {

    let result = [...PRODUCTS_DATA];

if (searchQuery.trim() !== '') {
  result = result.filter(p =&gt; p.name.toLowerCase().includes(searchQuery.toLowerCase()));
}
if (selectedCategory !== 'All') {
  result = result.filter(p =&gt; p.category === selectedCategory);
}
result = result.filter(p =&gt; p.price &lt;= maxPrice);

if (sortBy === 'price-low') result.sort((a, b) =&gt; a.price - b.price);
else if (sortBy === 'price-high') result.sort((a, b) =&gt; b.price - a.price);
else if (sortBy === 'rating') result.sort((a, b) =&gt; b.rating - a.rating);

return result;



}, [searchQuery, selectedCategory, maxPrice, sortBy]);

return (

      <h1>Discover Products</h1>
      <p>Filter and find exactly what you need in real-time.</p>





          Search
           setSearchQuery(e.target.value)}
            placeholder="Search products..."
            className="w-full px-4 py-2 bg-slate-50 border border-slate-200 rounded-xl focus:outline-none focus:ring-2 focus:ring-blue-500 text-sm"
          /&gt;



          Category

            {CATEGORIES.map(category =&gt; (
               setSelectedCategory(category)}
                className="px-3 py-1.5 text-xs font-medium rounded-lg transition"
              &gt;
                {category}

            ))}





            Max Price
            <span>${maxPrice}</span>

           setMaxPrice(Number(e.target.value))}
            className="w-full h-2 bg-slate-100 rounded-lg appearance-none cursor-pointer accent-blue-600"
          /&gt;



          Sort By
           setSortBy(e.target.value)}
            className="w-full px-3 py-2 bg-slate-50 border border-slate-200 rounded-xl focus:outline-none focus:ring-2 focus:ring-blue-500 text-sm"
          &gt;
            Featured
            Price: Low to High
            Price: High to Low
            Highest Rated






          {filteredProducts.map(product =&gt; (


                <span>
                  {product.category}
                </span>
                <h3>{product.name}</h3>


                <span>${product.price}</span>
                <span>★ {product.rating}</span>


          ))}



);

}




  
  
  Conclusion


By leveraging optimization hooks, we ensure that sorting and filtering are computed only when dependencies update, maintaining a rock-solid user experience. This architecture scales perfectly for e-commerce needs.