DEV Community: Asmaa Almadhoun

Don't Make Me Think, Role of Colour in UX

Asmaa Almadhoun — Tue, 05 May 2026 13:00:37 +0000

In Don't Make Me Think, Steve Krug introduces the concept of self-explanatory design. The idea is simple: when users land on a page, they should immediately understand what it is and how to use it; without effort or confusion. There should be no need for what Krug calls “cognitive ditch-digging.”

When applying this principle to visual design, especially color, the goal shifts away from decoration and toward clarity. Color is not used just to make a page look appealing; it is used to remove ambiguity and guide users naturally.

The Reservoir of Goodwill

One of Krug’s key ideas is the “reservoir of goodwill.” This represents the patience users have when interacting with a product. Every time they encounter something confusing—such as a button that doesn’t look clickable or a color that carries no clear meaning—that reservoir begins to drain.

To preserve this goodwill, visual design must support usability:

Visual hierarchy: Color should clearly indicate what is important. If everything is bright or competing for attention, nothing stands out.
Consistency: Actions should always look the same. For example, if a “Submit” button is blue on one page, it should remain blue across the entire application. Changing colors for the same action forces users to stop and think.

The 60–30–10 Rule in UX Design

Although Krug does not specify an exact number of colors to use, modern UX practices—aligned with his philosophy—recommend keeping the color palette limited to maintain clarity.

A common approach is the 60–30–10 rule, which organizes colors as follows:

60%: Primary or background color (usually neutral)
30%: Secondary color for structure and layout
10%: Accent color for key actions and highlights

This structure helps create a balanced interface where users can easily identify priorities and actions without confusion.

Conclusion

Krug’s philosophy emphasizes that good design should feel obvious. In terms of color, this means using it deliberately to communicate meaning, reinforce consistency, and guide user attention. A restrained and purposeful color system reduces cognitive load and helps users interact with interfaces effortlessly.

Next.js Explained Using TikTok: SSR, SSG, ISR, and CSR Made Simple

Asmaa Almadhoun — Tue, 21 Apr 2026 13:00:00 +0000

TikTok looks simple on the surface: open the app, watch videos, scroll endlessly.
But behind that smooth experience is a complex system of rendering strategies, performance optimizations, and real-time interactions; exactly the kinds of problems that Next.js was designed to solve.

If TikTok were built using Next.js, it wouldn’t rely on a single rendering method. Instead, it would combine SSR, SSG, ISR, CSR, Streaming, Edge rendering, and partial rendering; each used deliberately to give users a fast, personalized experience at massive scale.
Let’s tell TikTok’s story, one Next.js concept at a time.

Chapter 1: Entering TikTok, Static First Impressions (SSG)

When someone visits TikTok for the first time, before logging in; they often see:

Marketing pages
Help center articles
About TikTok content
Community guidelines

These pages rarely change and are the same for everyone.
In Next.js terms, this is Static Site Generation (SSG).

Why SSG fits here

Content is predictable
SEO matters
Speed is critical
Millions of users access these pages

SSG allows TikTok to pre-build these pages once and serve them instantly from a CDN.

In the TikTok story, SSG represents the front door, reliable, and welcoming to everyone.

Chapter 2: The “For You” Feed, Personalization at Scale (SSR)

Once you log in, TikTok completely changes its behaviour.

Now you see:

A unique feed
Tailored recommendations
Content based on your interests, location, time, and device

No two users see the same thing.
This is Server-Side Rendering (SSR).

Why SSR is necessary

Content must be personalized
Data must be fresh
SEO may still matter (for web versions)
Security and authentication are required

With SSR, every request can generate a fully customized page before it reaches the browser.

In the story of TikTok, SSR is the brain, thinking in real time about you.

Chapter 3: Trending Hashtags, Fast but Frequently Changing (ISR)

TikTok’s Trending section is neither fully static nor fully dynamic.

Trending hashtags and sounds:

Change every few minutes
Are viewed by millions
Don’t require second‑by‑second precision

This is where Incremental Static Regeneration (ISR) shines.
Why ISR fits perfectly

Static performance
Automatic background updates
No rebuild of the entire app

Pages can update every 30–60 seconds without losing speed.

ISR is TikTok’s pulse, constantly updating, but never slowing down.

Chapter 4: Interactions; Likes, Comments, Follows (CSR)

When you:

Like a video
Post a comment
Follow a creator
Save a video

You expect instant feedback, not a page reload.
This behavior is powered by Client-Side Rendering** (CSR)**.
Why CSR is essential

High interactivity
Real-time UI updates
Minimal delay
No SEO concern for these actions

CSR handles all the living, breathing parts of TikTok that respond instantly to your touch.

CSR is TikTok’s reflex system, immediate and interactive.

Chapter 5: Videos First, Everything Else Later (Streaming SSR)

On TikTok, video content loads first.
Comments, captions, and recommendations follow.
This is intentional.
With Streaming SSR and React Suspense, TikTok can:

Render critical content immediately
Stream less important UI parts later
Improve perceived performance dramatically

The user doesn’t wait for everything, only what matters most.

Streaming is TikTok’s storytelling technique: hook the viewer first, fill in details later.

Chapter 6: Profile Pages, Static Meets Dynamic (Partial Rendering)

A creator’s profile has:
Static data: username, bio, profile photo
Dynamic data: follower count, latest videos, follow status

Using one rendering method for all of it would be inefficient.
Next.js solves this with partial rendering:

Static parts cached
Dynamic parts rendered on demand

This approach balances scalability, freshness, and cost.

Partial rendering is TikTok’s balance: efficiency without sacrificing accuracy.

The Big Picture: Why This Matters

TikTok’s success isn’t just about videos or algorithms.
It’s about choosing the right rendering strategy for the right moment.
Next.js makes this possible by allowing all these techniques to coexist in a single application:

Static where possible
Dynamic where necessary
Streaming where smart
Client-side where interactive

AI Writes What You Ask. Architecture Survives What You Didn’t Expect

Asmaa Almadhoun — Sat, 11 Apr 2026 08:35:33 +0000

Why Human Judgment Still Matters in the Age of AI‑Assisted Development

AI‑assisted coding tools have transformed modern software development. They can generate boilerplate, suggest patterns, and accelerate delivery.

Yet, as powerful as these tools are, they often fail in one critical dimension: design judgment. Being “smarter than AI” as a developer does not mean writing more complex code, it means designing systems that are resilient to ambiguity, change, and imperfect inputs.

One of the most common and painful examples of this gap appears in how systems handle unexpected variations, such as null, undefined, empty values, or missing parameters.

The Illusion of Correctness in AI‑Generated Code

AI tools typically optimize for expected behavior. They assume ideal inputs, clear contracts, and happy paths. This makes their output appear correct; until reality intervenes.

Consider your example:

If I do not send exactly null, the system crashes.

From a machine’s perspective, this may be “technically correct” code. From a human architect’s perspective, it is a design failure.

A well‑designed system should not collapse because:

null was replaced with undefined
a field was omitted
an empty string was passed
a client behaved slightly differently than expected

AI‑assisted implementations often miss these nuances because they replicate patterns rather than challenge assumptions.

Clean Architecture: Designing for Reality, Not Perfection

Robert C. Martin’s Clean Architecture: A Craftsman’s Guide to Software Structure and Design emphasizes an essential truth:

Software must be designed to survive change.

Clean Architecture teaches that systems should be:

Independent of frameworks
Independent of UI
Independent of databases
Independent of external agencies

Most importantly for your case, they should be independent of volatile input behaviour.

Why This Matters for Input Validation

In Clean Architecture, use cases define the rules of the application. That means they are responsible for deciding what is valid, acceptable, or recoverable, not controllers, not frameworks, and certainly not AI‑generated glue code.

If your system crashes because a parameter is missing or slightly different, that logic is living in the wrong place, or not living anywhere at all.

The Core Problem: Treating Inputs as Objects, Not Concepts

AI tends to treat input values literally:

null ≠ undefined ≠ empty ≠ missing

Humans, however, think conceptually:

“This value means ‘no data provided.’”

Clean Architecture encourages us to elevate that intent into the core of the system. Instead of spreading defensive checks everywhere, we define semantic boundaries:

What does “absence” mean?
Is this field required, optional, or conditional?
What is the default behavior if it’s missing?

If those questions are not answered explicitly, AI has no chance of answering them correctly.

Being Smarter Than AI: Design Principles That Matter

1. Normalize at the Boundaries

AI often mirrors whatever structure it sees. A human architect knows better.
At system boundaries (APIs, controllers, adapters), normalize inputs into a single internal representation. By the time data reaches your business rules, there should be one concept of “no value,” not five.

This aligns directly with Clean Architecture’s rule of keeping frameworks and details at the edges.

2. Move Validation into Use Cases

AI‑generated code frequently validates inputs close to the framework layer. This is convenient and wrong.
Clean Architecture insists that:

Business rules own validation
Use cases decide what is acceptable
Frameworks merely pass data along

When validation lives in use cases, handling null, missing, or empty values becomes a business decision, not a technical accident.

3. Define Explicit Contracts, Not Implicit Expectations

AI excels at following patterns, but struggles with unstated intent.
Clean Architecture favors:

Explicit input models
Clear invariants
Defined failure modes

If your system crashes when a value is not exactly null, it means the contract was never truly defined, only assumed.
Humans write contracts. AI follows them.

4. Design for Change, Not Compliance

AI optimizes for compliance with existing code. Humans optimize for change.
Your API may work today because clients send perfect inputs. Tomorrow:

a mobile app changes
a third‑party integration behaves differently
a serialization library updates its defaults

Clean Architecture prepares systems for that variability by isolating change and enforcing rules at the core.

Conclusion: Intelligence Is in the Architecture, being smarter than AI is not about rejecting AI tools, it’s about using them responsibly.
Let AI:

write repetitive code
scaffold structures
speed up implementation

Let humans:

efine boundaries
clarify intent
design for ambiguity
enforce architectural discipline

Clean Architecture provides the mental model that AI lacks: a focus on meaning, responsibility, and change. When your system gracefully handles null, undefined, empty, and missing values, not because of defensive hacks, but because of intentional design you are operating at a level AI has not yet reached.
And that is what real software craftsmanship looks like.

Reference

Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017.

Why fetch() Can Be Safer Than Axios After the 2026 Axios Hack

Asmaa Almadhoun — Wed, 01 Apr 2026 09:16:10 +0000

The question isn’t whether Axios is a “bad” library; it’s about risk surface. The Axios NPM compromise in March 2026 exposed a structural weakness in depending on third‑party libraries for something browsers already provide natively.

1. Axios was compromised; fetch() cannot be published with malware

On March 31, 2026, attackers hijacked the npm account of Axios’s maintainer and published malicious versions (1.14.1 and 0.30.4) containing an obfuscated malware dropper. The malware executed automatically during installation.

In contrast:

fetch() is built into browsers and Node.js.
It cannot be replaced or hijacked via a package manager.
There is no installation step, so no opportunity to insert post‑install malware.

Thus, fetch() has zero supply‑chain risk compared to a package like Axios.

2. Axios’ supply-chain attack vector came from its dependency distribution model
The Axios compromise happened because:

Attackers accessed the maintainer’s npm account,
Published malicious releases with a hidden dependency (plain-crypto-js),
Inserted a postinstall script that deployed a cross‑platform RAT.

fetch() has:

No dependencies
No maintainer accounts to hijack
No GitHub or npm supply chain to poison

Therefore, using fetch() eliminates an entire attack surface.

3. Axios introduced malware even though the code looked unchanged
Security investigators confirmed the attacker did not modify the Axios code directly, but only added a malicious dependency that executed during installation.

This means:

Even if you audited the Axios GitHub repo, you would not see the malicious code.
This type of attack is impossible with fetch() because it isn’t installed from npm.

4. Native fetch() is now fully supported and feature‑rich, reducing the need for Axios
Historically, Axios offered conveniences like:

automatic JSON transformation
request cancellation
simpler syntax
better error handling

But today:

Modern browsers and Node.js now support fetch() with AbortController, streaming, improved error handling, and Response.json().
The gap between Axios and native APIs has narrowed significantly.

Given this parity, adding Axios creates unnecessary dependency risk.

✔️ Summary

Fetch is “better” than Axios from a security standpoint because it is native, dependency‑free, cannot be hijacked through npm, and avoids the entire supply‑chain attack vector that enabled hackers to insert a remote‑access trojan into Axios’ malicious releases in March 2026

Code Meets Creativity: Using Google Stitch as a Frontend Developer

Asmaa Almadhoun — Tue, 24 Mar 2026 07:11:19 +0000

As frontend developers, we’re constantly exploring tools that help us move faster, from ideation to prototypes to production‑ready UI. Google Stitch has recently had a major revamp, positioning itself as an AI‑native design assistant that promises to help us explore layouts, generate UI structures, and test ideas without jumping into code immediately.
While Stitch isn’t a full replacement for real design tools or real designers, it can play a meaningful role in a modern frontend workflow. Here’s how you can practically use it as a developer.

Example: Creating a Landing Page With Google Stitch

Move from idea → layout → code in minutes. Below is a simple, practical workflow showing how you can generate a landing page using Stitch, refine it, and turn it into usable frontend code.
Each step includes a soft, rounded hybrid-style diagram to visually guide the user.

1️⃣ Step 1, Open Google Stitch
To begin, you visit Stitch and select your mode (Web or App).
This is where you pick the model and start your design session.

2️⃣ Step 2, Enter Your First Prompt
Stitch works best with clear natural‑language instructions. You describe the structure and feel of the landing page, and Stitch generates the UI.
Example prompt:

“Create a modern landing page with a hero section, feature grid, testimonials, and a CTA. Keep it clean and easy to rebuild using React + Tailwind.”

3️⃣ Step 3, Stitch Generates the Layout
Stitch analyzes your prompt and files, then produces the first version of your layout.
It typically includes full sections like the following

4️⃣ Step 4, Refine Using Follow‑Up Prompts
Just like a conversation, you can refine the design by telling Stitch what to change.
This is ideal for adjusting spacing, layout balance, color contrast, and visual hierarchy.
Examples:

“Increase spacing in the hero section.”
“Make the color palette darker.”
“Increase CTA visibility.”

5️⃣ Step 5, Export the Code

One of Stitch’s strengths is its code export ability.
After generating your design, you can extract HTML/CSS or even React‑friendly markup to speed up your build, you will find

Landing page (html)
Design file contains rules
Screen file is full Image of your landing page design

6️⃣ Step 6, Paste Into Your Code Editor
Paste the exported code into your editor (VS Code, WebStorm, etc.).
From here, you refine the structure, add Tailwind or your design tokens, and integrate real content.

🎉 Final Thoughts
Using Google Stitch as a frontend developer dramatically accelerates:

UI ideation
Layout prototyping
Early‑stage design exploration
Hand‑off between design & code
Building real landing page code faster

Stitch doesn’t replace designers or developers, but it makes frontend workflows smoother and faster, especially when you need structure before styling.

Tailwind in Micro‑Frontends

Asmaa Almadhoun — Fri, 13 Mar 2026 07:24:12 +0000

From Token Drift to a Single Source of Truth

1) Context & Problem

When you scale a Module Federation architecture (shell + multiple independently deployed micro apps), it’s tempting to let every micro app own its Tailwind config. That seems harmless until it isn’t.
Signs you likely saw:

Token drift: primary, secondary, and other design tokens differ per micro app.
Inconsistent UI: The shell and remotes looked related but not identical.
Copy‑paste debt: Colors, shadows, and breakpoints duplicated across repos.
Refactor pain: Changing a brand variable meant N pull requests.
Conflicting semantics: primary in one app wasn’t the same hex in another.

Root causes:

Each repo has its own “design system.”
No enforced tokens contract shared at build time and runtime.
Different teams tweaked Tailwind locally, with no common presence.
Pre-flight, prefixes, and naming were sometimes inconsistent.

Result:

Slower brand rollouts, visual inconsistencies, and higher QA costs.

2) Design Goals
To reverse the drift without killing micro‑app independence:

Single Source of Truth (SSOT) for tokens, colors, typography, spacing, shadows, breakpoints.
One Tailwind prepared for every micro app import, no duplication.
Runtime theming via CSS variables (dark mode, brand variants) controlled by the shell.
Module Federation‑friendly: shared version of the tokens package, and predictable CSS load order.
Minimal migration friction: Keep class names like text-primary, bg-colors, etc.

3) Target Architecture (High‑Level)

@org/tokens (npm package)

tokens.css → CSS variables for runtime theming.
tailwind.preset.cjs → Tailwind preset mapping semantic keys (colors, shadows, screens).
Optional: boxShadow, spacing, fontFamily, etc.

Shell (host)

Loads tokens.css once and sets theme attributes (e.g., data-theme="dark").
Shares @org/tokens in Module Federation to keep a single version.
Enables Tailwind preflight once (recommended) and optionally a class prefix for safety.

Remote micro apps

Import the Tailwind preset from @org/tokens.
Rely on shell‑injected tokens.css (or import defensively if shell can’t).
Use semantic classes (e.g., text-primary, bg-bg, shadow-card) that are all defined from tokens.

4) The Tokens Package

4.1 Minimal tokens.css (runtime variables & themes)

/* packages/tokens/tokens.css */color-bg: #FFF5F0;
}

/* Optional dark theme (shell can toggle) */
:root[data-theme="dark"] {
  --color-text: #F3F4F6;
  --color-bg: #0B1220;
}
``
:root {
  --color-primary: #4A90E2;
  --color-text: #1F2A37;

4.2 Minimal Tailwind preset (map variables → Tailwind theme)

// packages/tokens/tailwind.preset.cjs
/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: 'var(--color-primary)',
        text: 'var(--color-text)',
        bg: 'var(--color-bg)',
      },
    },
  },
};

5) Remote Micro App, Smallest Possible Integration

5.1 Federation config (Remote)

// apps/appA/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
const deps = require('./package.json').dependencies;

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'appA',
      filename: 'remoteEntry.js',
      exposes: {
        './Widget': './src/Widget', // whatever you expose
      },
      shared: {
        react: { singleton: true, requiredVersion: deps.react },
        'react-dom': { singleton: true, requiredVersion: deps['react-dom'] },

        // 🔑 Same tokens instance/version as shell
        '@org/tokens': { singleton: true, eager: true },
      },
    }),
  ],
};

5.2 Tailwind config (Remote)

// apps/appA/tailwind.config.cjs
const { preset } = require('@org/tokens');

module.exports = {
  presets: [preset],                    // 🔑 central config
  content: ['./src/**/*.{ts,tsx,html}'],
  prefix: 'tw-',                        // match shell if you prefix
  corePlugins: { preflight: false },    // let shell handle the reset
};
``
export default function Card() {
  return (
    <div className="tw-bg-bg tw-text-text tw-rounded-xl tw-p-4 tw-border tw-border-primary">

If you’re not 100% sure the shell always loads tokens.css, you can optionally import it in the remote entry as a fallback:

import '@org/tokens/tokens.css';

5.3 Stylesheet entry

Preferred: Let the shell load tokens.css globally.
Defensive (if shell might not): import it here too (duplicates are harmless).

/* apps/appA/src/index.css */
@import '@org/tokens/tokens.css';

@tailwind base;
@tailwind components;
@tailwind utilities;

5.4 Component usage (Remote)

// apps/appA/src/components/Card.tsx
export function Card({ title, children }: { title: string; children: React.ReactNode }) {
  return (
    <div className="tw-bg-cardbg tw-text-text tw-rounded-2xl tw-shadow-card tw-transition tw-border-t-4 tw-border-primary tw-p-6">
      <h3 className="tw-text-primary tw-font-bold tw-mb-2">{title}</h3>
      <div className="tw-text-muted">{children}</div>
    </div>
  );
}

The classes resolve to your tokens because the preset maps Tailwind theme keys to CSS variables from tokens.css. When the shell toggles data-theme or data-brand, every remote instantly follows.

7) Operational Tips

Versioning & Changelog: Treat @org/tokens like a product.

MAJOR for breaking renames/removals.
MINOR for added tokens.
PATCH for non‑breaking fixes.

Guardrails:

Lint to forbid raw hex in apps, use tokens only.
Consider codemods to migrate existing classes to semantic ones.
Visual regression tests in shell for critical flows (Chromatic/Playwright/etc).

Avoid CSS Leaks:

Use Tailwind prefix to reduce naming collisions.
Keep preflight in shell only.
If any remote uses Shadow DOM, it won’t inherit CSS variables from the document; re‑inject tokens.css inside that shadow root.

Theming Strategy:

Shell sets data-theme and data-brand at or at each micro app’s mount container if you want per‑app themes.
Tailwind utilities simply reference the semantic theme keys provided by your preset (no rebuild required at runtime).

8) Migration Plan (Practical)

Publish @org/tokens with tokens.css + tailwind.preset.cjs.
Wire shell to load tokens.css, set theme attributes, and share the package in MF.
Update each remote to use presets: [preset] and disable preflight.
Replace raw hex and local color names with text-text, bg-bg, text-primary, border-accent, etc.
Cut a brand update (change a token value) and watch all apps update without per‑repo edits.

From Context to Redux to Zustand: The New Era of React State Management

Asmaa Almadhoun — Sun, 15 Feb 2026 04:27:38 +0000

In the evolving world of React, state management has always been a central challenge. Developers first leaned on the built-in Context API to escape prop drilling, then embraced Redux for its strict patterns and enterprise-level predictability.

But as modern apps demand speed, simplicity, and flexibility, a new contender has emerged: Zustand. This lightweight library is reshaping how developers think about managing state, offering the efficiency of hooks, the clarity of minimal code, and the scalability needed for today’s React ecosystem.

🌟 Current Trend; Zustand

Zustand is a modern state management library for React and Next.js that focuses on being small, fast, and simple. Its name means “state” in German, and its logo is a bear 🐻 symbolizing strength with minimal fuss.

Why Zustand is a trend now
Zustand is gaining traction now because developers increasingly value simplicity and performance over boilerplate-heavy solutions. It’s especially popular in modern React projects, Next.js apps, and among teams that want to avoid Redux’s complexity.

👉 In short: Zustand isn’t less capable, it’s just newer, less marketed, and overshadowed by Redux’s historical dominance and Context’s built-in status.

🔑 Key Features

Hooks-based API → You create a store using create() and access it with custom hooks.
Minimal boilerplate → No reducers, actions, or complex setup like Redux.
Performance optimized → Components only re-render when the specific slice of state they use changes.
Scalable → Works for both small apps and larger projects without adding complexity.
Unopinionated → Lets you structure state however you want, unlike Redux’s strict patterns.

📦 Installation

npm install zustand 
or 
yarn add zustand

⚡ Basic Example

import { create } from "zustand";

const useStore = create(set => ({
  blogs: [],
  fetchBlogs: async () => {
    const res = await fetch("/api/blogs");
    const data = await res.json();
    set({ blogs: data });
  }
}));

function BlogList() {
  const blogs = useStore(state => state.blogs);
  const fetchBlogs = useStore(state => state.fetchBlogs);

  React.useEffect(() => {
    fetchBlogs();
  }, [fetchBlogs]);

  return (
    <ul>
      {blogs.map(blog => (
        <li key={blog.id}>{blog.title}</li>
      ))}
    </ul>
  );
}

🔴 Redux

Redux has long been the “classic” solution for managing state in React. It relies on a centralized store and a strict flow of actions and reducers, which makes state predictable and easier to debug. Its ecosystem is mature, with advanced tools and middleware that support complex applications.

Advantages:

Clear and consistent state flow.
Excellent debugging and developer tools.
Proven reliability in large-scale projects.

Drawbacks:

Requires more setup and boilerplate code.
Learning curve is steeper compared to newer libraries.
Can feel heavy for smaller applications.

📦 Installation

npm install @reduxjs/toolkit react-redux
# or
yarn add @reduxjs/toolkit react-redux

⚡Basic Example:

import { configureStore, createSlice, createAsyncThunk } from "@reduxjs/toolkit";
import { Provider, useSelector, useDispatch } from "react-redux";

// Async thunk for fetching blogs
const fetchBlogs = createAsyncThunk("blogs/fetchBlogs", async () => {
  const res = await fetch("/api/blogs");
  return await res.json();
});

const blogSlice = createSlice({
  name: "blogs",
  initialState: { items: [], status: "idle" },
  reducers: {},
  extraReducers: builder => {
    builder
      .addCase(fetchBlogs.pending, state => {
        state.status = "loading";
      })
      .addCase(fetchBlogs.fulfilled, (state, action) => {
        state.status = "succeeded";
        state.items = action.payload;
      })
      .addCase(fetchBlogs.rejected, state => {
        state.status = "failed";
      });
  }
});

const store = configureStore({ reducer: { blogs: blogSlice.reducer } });

function BlogList() {
  const blogs = useSelector(state => state.blogs.items);
  const status = useSelector(state => state.blogs.status);
  const dispatch = useDispatch();

  React.useEffect(() => {
    dispatch(fetchBlogs());
  }, [dispatch]);

  if (status === "loading") return <p>Loading...</p>;
  if (status === "failed") return <p>Error loading blogs</p>;

  return (
    <ul>
      {blogs.map(blog => (
        <li key={blog.id}>{blog.title}</li>
      ))}
    </ul>
  );
}

export default function App() {
  return (
    <Provider store={store}>
      <BlogList />
    </Provider>
  );
}

🔵 React Context API

The Context API is React’s built‑in mechanism for sharing data across components without passing props down manually. It’s part of React itself, so you don’t need to install anything extra. Developers often use it for global values like themes, authentication, or user preferences.

Strengths:

Comes bundled with React, no external library required.
Very easy to learn and implement.
Ideal for simple global state such as UI settings or logged‑in user info.

Limitations:

Can trigger unnecessary re‑renders when many components consume the same context.
Doesn’t provide advanced debugging or middleware support.
Not designed for complex or large‑scale state logic.

⚡Basic Example:

import React, { createContext, useContext, useState, useEffect } from "react";

const BlogContext = createContext();

function BlogProvider({ children }) {
  const [blogs, setBlogs] = useState([]);

  useEffect(() => {
    // Simulate fetching blogs
    fetch("/api/blogs")
      .then(res => res.json())
      .then(data => setBlogs(data));
  }, []);

  return (
    <BlogContext.Provider value={{ blogs }}>
      {children}
    </BlogContext.Provider>
  );
}

function BlogList() {
  const { blogs } = useContext(BlogContext);
  return (
    <ul>
      {blogs.map(blog => (
        <li key={blog.id}>{blog.title}</li>
      ))}
    </ul>
  );
}

export default function App() {
  return (
    <BlogProvider>
      <BlogList />
    </BlogProvider>
  );
}

🎯 Conclusion

Choosing the right state management tool in React depends on the scale and complexity of your project:

For small applications or simple global values, the Context API is more than enough. It’s built into React, easy to use, and perfect when you just need to avoid prop drilling.
For medium‑sized projects where performance and simplicity matter, Zustand shines. It offers a modern, lightweight approach with minimal boilerplate and efficient updates, making it a favorite among developers building fast, flexible apps.
For large, enterprise‑level applications, Redux remains the most reliable option. Its strict patterns, powerful devtools, and mature ecosystem make it ideal for managing complex state flows at scale.