Imagine you own a small garden.
Every day you walk through it — watering, trimming, planting new seeds.

At first, it’s peaceful.
But as your garden grows, you start keeping lists — which plant needs sunlight, which one needs trimming, and which one you just planted last week.

Before you know it, your peaceful garden becomes a spreadsheet of chaos.
You’re no longer tending to your plants — you’re managing your management.

If you’ve ever used Redux for state management in React, this might sound familiar.

Enter Zustand: The Self-Tending Garden

“Zustand” means “state” in German.
It’s a lightweight, minimal, and intuitive state management library for React — one that feels like your garden finally learned to take care of itself.

Instead of endless reducers, dispatchers, and action types, you simply create a small store that holds your state and the logic to change it.

Zustand listens quietly in the background — when something changes, it updates only what’s needed, leaving the rest of your app calm and still.

Planting Your First Seeds (Creating the Store)

In this garden, your store is the soil — it holds the roots of every plant.

Here’s your first seed:

import { create } from 'zustand'

const useGardenStore = create((set) => ({
  plants: [],

  addPlant: (name) =>
    set((state) => ({
      plants: [...state.plants, { id: Date.now(), name }]
    })),

  removePlant: (id) =>
    set((state) => ({
      plants: state.plants.filter((p) => p.id !== id)
    })),
}));

Each plant is an object in your garden.
You can add or remove plants — and Zustand will handle the rest, without the ceremony of reducers or dispatchers.

Watching Your Plants Grow (Using the Store in React)

Now let’s step into the garden and see how it grows:

import React, { useState } from 'react';
import useGardenStore from './useGardenStore';

export default function Garden() {
  const { plants, addPlant, removePlant } = useGardenStore();
  const [name, setName] = useState('');

  return (
    <div>
      <input
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="Add a plant..."
      />
      <button onClick={() => addPlant(name)}>Plant</button>

      <ul>
        {plants.map((p) => (
          <li key={p.id}>
            {p.name}
            <button onClick={() => removePlant(p.id)}>Remove</button>
          </li>
        ))}
      </ul>
    </div>
  );
}

Every click, every keystroke — your garden updates instantly.
Zustand automatically re-renders only what changes, keeping your React app fast and lightweight.

Making the Garden Remember (Persistent State)

What if your garden could remember where you left off — even after you close the tab?
With Zustand’s persist middleware, it can:

import { create } from 'zustand'
import { persist } from 'zustand/middleware'

const useGardenStore = create(
  persist(
    (set) => ({
      plants: [],
      addPlant: (name) =>
        set((state) => ({
          plants: [...state.plants, { id: Date.now(), name }]
        })),
    }),
    { name: 'garden-storage' }
  )
);

Now your plants (state) will be stored in localStorage, blooming right where you left them the next time you visit.

Why Developers Love Zustand

Zustand feels alive — a quiet, self-maintaining garden of state.

• Lightweight: Less than 1 KB gzipped

• Reactive: Updates only what’s necessary

• Minimal API: One store, simple syntax

• Async-ready: Works great with API calls and side effects

It’s state management without the noise — just clean growth.

In the End: Growing Calmly with Zustand

Managing state doesn’t have to feel like pruning a jungle.
With Zustand, it’s like tending a peaceful garden — plant what you need, nurture it as it grows, and trust the system to keep it thriving.

Once you experience the quiet simplicity of Zustand, you’ll wonder how you ever gardened with spreadsheets and dispatchers.

Imagine you own a small garden shop. Every day, people visit you for plants — some want instant pick-ups, others want something fresh, and a few enjoy growing plants themselves.

You quickly realize:
How you deliver plants makes a big difference in customer happiness.

Similarly, when building websites with Next.js, how you deliver content to visitors is crucial. Developers refer to these strategies as CSR, SSR, SSG, and ISR. But in your garden shop, they’re just different ways of handing over plants.

CSR — “Do-It-Yourself Plant Kits”

In the garden, you give customers soil, seeds, and a pot, and they grow the plant themselves.

On the web, the server sends only a blank page + JavaScript, and the browser builds everything.

// pages/dashboard.js (CSR in Next.js)
import { useEffect, useState } from "react";

export default function Dashboard() {
  const [data, setData] = useState(null);

  useEffect(() => {
    // Fetching happens in the browser
    fetch("/api/user")
      .then(res => res.json())
      .then(setData);
  }, []);

  if (!data) return <p>Loading...</p>;
  return <h1>Welcome back, {data.name}</h1>;
}

Best for dashboards, chats, and private apps.
First load is slower, but once loaded, it’s very interactive.

SSR — “Freshly Picked Plants on the Spot”

In the garden: a customer asks for basil, you pick it fresh from the greenhouse, and hand it over.

On the web, the server builds HTML on request and sends it fresh every time.

// pages/news.js (SSR in Next.js)
export async function getServerSideProps() {
  const res = await fetch("https://api.example.com/news");
  const articles = await res.json();
  return { props: { articles } };
}

export default function News({ articles }) {
  return (
    <div>
      <h1>Fresh News</h1>
      {articles.map(a => <p key={a.id}>{a.title}</p>)}
    </div>
  );
}

Great for news sites, stock tickers, or e-commerce product pages.
Heavy load if many people visit at once, since the server works all the time.

SSG — “Plants Prepared in Advance”

In the garden, you prepare 100 pots of mint in the morning and place them in the shop. Customers get them instantly.

On the web, pages are pre-rendered at build time and served instantly.

// pages/blog/[id].js (SSG in Next.js)
export async function getStaticPaths() {
  const res = await fetch("https://api.example.com/posts");
  const posts = await res.json();
  const paths = posts.map(p => ({ params: { id: p.id.toString() } }));
  return { paths, fallback: false };
}

export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/posts/${params.id}`);
  const post = await res.json();
  return { props: { post } };
}

export default function BlogPost({ post }) {
  return <article><h1>{post.title}</h1><p>{post.content}</p></article>;
}

Perfect for blogs, documentation, and landing pages.
Content updates only when you rebuild the app.

ISR — “Restocking the Shelves”

In the garden: instead of preparing mint only once, you set a rule — restock every few hours to keep them fresh.

On the web, pages are pre-rendered once, then regenerated after a set time.

// pages/jobs.js (ISR in Next.js)
export async function getStaticProps() {
  const res = await fetch("https://api.example.com/jobs");
  const jobs = await res.json();

  return {
    props: { jobs },
    revalidate: 60, // Rebuild every 60 seconds
  };
}

export default function Jobs({ jobs }) {
  return (
    <div>
      <h1>Job Listings</h1>
      {jobs.map(j => <p key={j.id}>{j.title}</p>)}
    </div>
  );
}

Best for job boards, catalogs, and event listings.
New content may take a short time to appear.

The Balanced Garden Shop

Running your garden shop taught you something: there’s no single “best” way.

• DIY kits for plant lovers → CSR

• Fresh picks for special requests → SSR

• Prepped plants for speed → SSG

• Regularly restocked plants → ISR

In the same way, Next.js lets you mix and match. Some pages are static, some are dynamic, some refresh on a schedule, and some are built entirely by the browser.

🌼 Closing Thought

Your garden isn’t just about plants — it’s about how you deliver them.

Your website isn’t just about content — it’s about how you render it.

With Next.js, you can balance CSR, SSR, SSG, and ISR like a skilled gardener balancing DIY kits, fresh picks, prepped plants, and restocks. The result: a website that’s fast, fresh, and tailored to what each visitor needs.

At first, you only have a backyard. You plant a few tomatoes, maybe a rose bush, and water them with a friend. Life is simple. Everything fits into that one cozy patch. That’s a traditional frontend: one codebase, one team, one deployment.

But what happens when your backyard becomes a park? Suddenly, you want a rose garden, a greenhouse, fruit trees, and a koi pond. You hire more gardeners. One insists on compost, another on hydroponics. They bump into each other, and a pest in the roses threatens the entire yard. Suddenly, one big patch isn’t working anymore.

That’s where micro-frontends come in: breaking your park into smaller, independent gardens, each tended by its own team.

What Is a Traditional Frontend?

A traditional frontend is a single, unified application. It works best when:

• Your product is small to medium-sized.

• A single team (or small group) maintains it.

• Features are tightly connected and share logic.

Benefits:

• Easy to keep a consistent design and user experience.

• Simple deployment—one build, one release pipeline.

• Shared state and data flow are straightforward.

Drawbacks:

• As the app grows, deployments slow down.

• Coordination between teams gets messy.

• A single bug can affect the entire app.

In gardening terms, a tidy backyard is perfect when your needs are modest.

What Is a Micro-Frontend?

A micro-frontend splits your frontend into smaller, self-contained applications, each focused on a specific domain or feature. Together, they form a seamless experience for the user.

Think of it as building a neighborhood park instead of one oversized backyard.

The Key Pieces of the Park

• Plots (Individual Apps): Each team manages its own micro-frontend (checkout, profile, search, etc.). They pick their own tools and ship independently.

• Paths and Fences (Integration Layer): Routing, navigation, and shared layout keep the park coherent. Fences prevent one team’s mess from spilling into another’s.

• Water Supply (Shared Services): Authentication, sessions, and APIs are like irrigation—shared infrastructure that everyone relies on.

• The Entrance (Shell App): The shell is the front gate that pulls everything together. It provides the layout, header, and glue code for loading micro-frontends.

Why Split the Garden? The Benefits of Micro-Frontends

• Autonomy and Speed: Teams can build and release independently.

• Scalability: New “plots” can be added without redesigning the entire system.

• Fault Isolation: One bug doesn’t crash the entire app.

• Flexibility: Teams can use different frameworks or tools if necessary.

Where the Weeds Hide: Challenges of Micro-Frontends

• Inconsistent Styles: Without a shared design system, the park looks mismatched.

• Duplicate Dependencies: Multiple bundles can slow down performance if not optimized.

• Shared Concerns: Authentication, analytics, and global state require careful planning.

• Operational Overhead: More repos, more pipelines, more deployment complexity.

When to Choose Which Approach

• Go traditional (one garden):
  If you have a small product, a small team, and don’t expect rapid scaling.

• Go micro (many gardens):
  If your app is large, your teams are many, and you need to release features independently without blocking each other.

Conclusion: It’s About Scale, Not Fashion

Choosing micro-frontends isn’t about chasing trends. It’s about recognizing when your “garden” is too big for one team to manage. If your app is small, stick with a single frontend—it’s simpler and faster. If your app is sprawling and your teams are stepping on each other’s toes, it’s time to build a park with multiple gardens.

And just like a real park, the success of micro-frontends depends on shared paths, fences, and a consistent style that makes it feel like one coherent place.

In a future post, we’ll dive into the practical steps for implementing micro-frontends—using tools like Webpack Module Federation and single-spa—without losing the magic of the garden metaphor.

React gave developers the flexibility to grow anything: buttons, forms, and entire applications. But just like raw soil, React didn’t come with pathways, irrigation, or a plan. You had to bring in your own tools (like React Router for navigation, Axios for data fetching, Webpack for bundling, etc.).

That worked fine for small pots. But when your garden grew bigger, managing it became exhausting.

Enter Next.js: The Garden Around the Soil

Next.js arrived as a gardener’s dream community garden built on React’s soil. It didn’t replace React; it simply added everything you needed to actually make your garden flourish:

• File-based routing → Instead of manually laying stepping stones (React Router), each file in pages/ is already a path through the garden.

• Pre-rendering (SSG/SSR) → Some plants are grown before visitors arrive (Static Generation), others are watered fresh daily (Server-side Rendering).

• API Routes → Your own compost bin for nutrients — no need for a separate backend for small tasks.

• Image optimization & performance tweaks → Automatic irrigation, so your garden doesn’t dry out or overflow.

Why Do We Need Next.js?

React alone renders pages on the client side, meaning the browser receives minimal HTML and then builds everything using JavaScript. This leads to three challenges: SEO issues (search engines can’t always see your content), slower performance (large bundles delay first render), and extra setup work (you need separate tools for routing, SSR, and optimization). Next.js solves all of this by providing server-side rendering, static generation, file-based routing, built-in API routes, and performance optimizations out of the box. In other words, it takes React’s flexibility and turns it into a production-ready framework that’s fast, SEO-friendly, and scalable.

React vs Next.js in Nature Terms

Why This Matters

If React is where you experiment with planting seeds, then Next.js is where you build a full, flourishing garden that visitors can walk through easily.

React gave us the freedom to grow.
Next.js gave us the structure to scale.

Just like soil without sunlight can’t produce much, React without Next.js often struggles with SEO, performance, and routing. But when combined, they create a thriving ecosystem — the digital version of a lush green garden.

So the next time you open a Next.js project, think of it like stepping into a well-prepared garden. The soil (React) is still there beneath your feet, but the pathways, irrigation, and compost bins (Next.js) are what make it bloom beautifully.

Do you want to learn more about these pathways, irrigation, or the bins? Let’s grow into this garden together! We will delve more into NextJS in our blog!

Managing a garden this way is not so different from managing a React app. Just as she had her habits and tools, React provides hooks like useRef, useMemo, and useCallback to make handling values, computations, and functions efficient and predictable.

As the morning sun rose, she noticed her tallest sunflower. Curious about how much it had grown, she marked its current height on a small stick.

Days passed, and whenever the sunflower grew taller, she added a new mark for the updated height. These marks didn’t affect the plant’s growth; they were simply references to track progress.

In React, useRef works the same way. It allows you to store a value across renders without triggering re-renders, whether you’re tracking DOM elements, storing mutable values, or keeping a reference for later use.

const plantHeight = useRef(0);
plantHeight.current = 15;

By midday, the girl moved to her rose bush. She had learned the perfect amount of water to give it based on the soil and the size of the plant. Instead of calculating this every time she watered, she kept the amount fixed until either the plant or the soil required a change.

Similarly, useMemo in React, memorizes the result of a computation and only recalculates it when its dependencies change. This saves effort and ensures that expensive calculations don’t run unnecessarily, keeping everything efficient and smooth.

const waterAmount = useMemo(() => soil.moisture * plant.size * 0.5, [plant.size, soil.moisture]);

As evening approached, she prepared her daily watering routine. She had perfected the steps over time, and she didn’t want to rewrite them every day. Instead, she followed the same routine unless the plant or soil conditions changed.

In React, useCallback serves this purpose. It memorizes a function and recreates it only when dependencies change, which is particularly useful when passing functions to child components. This way, the garden runs smoothly, and no unnecessary work is repeated.

const waterPlant = useCallback(() => console.log(`Watering ${plant.name} with ${soil.moisture} moisture`), [plant.name, soil.moisture]);

Quick Reference Table

By the end of the day, the small girl’s garden thrived. Her careful habits—marking heights, fixing watering amounts, and following reusable routines—kept every plant growing beautifully.

In the same way, using useRef, useMemo, and useCallback wisely allows your React apps to run efficiently, stay organized, and “bloom” reliably, just like a well-tended garden.

Think of functions in context as the garden tools in our tree analogy.

The water (our data) flows effortlessly through the tree via context, reaching every branch and leaf. But sometimes, the tree needs more than just water — it needs actions: pruning a branch, planting a new one, or watering a specific spot. That’s exactly what these tools (functions) do.

By placing these functions in context, every part of the tree — whether it’s a branch, leaf, or flower — has access to the same set of tools. You don’t have to carry a shovel and watering can to each plant (no more prop drilling!). Instead, everything is stored in one central shed (the context), ready to use whenever and wherever it’s needed.

In our last article, we set up a context for our parent component, Tree, along with its children — Branch, Leaf, and so on. Let’s revisit that context!

Remember the button we added? Clicking it was supposed to create a new branch. To make this happen, we defined a function inside our context, which interacts with the shared state. Now, let’s break down this function step by step and understand how it works to grow our tree across all components dynamically.

To add a new branch dynamically, we create a function inside our context — think of it as a garden tool that lets us prune, plant, or nurture any part of the tree.

export const TreeProvider = ({ children }) => {
  const [tree, setTree] = useState(initialTree);

  const addBranch = (newBranch) => {
    setTree({
      ...tree,
      branches: [...(tree.branches || []), newBranch]
    });
  };

  return (
    <TreeContext.Provider value={{ tree, addBranch }}>
      {children}
    </TreeContext.Provider>
  );
};

Here’s what’s happening:

1. useState keeps track of the tree — our central water system.

2. addBranch - It acts as a gardening tool, adding a new branch to the tree without disturbing the existing ones.

   Spreading the existing tree:

    ...tree
   

   This ensures that all current branches, leaves, and flowers stay intact. Think of it as keeping the existing tree healthy while adding something new.

   Adding a new branch:

    branches: [...(tree.branches || []), newBranch]
   

   Here, we either take the existing branches array (or an empty array if none exists) and append the newBranch. In our garden analogy, this is like planting a new branch without uprooting the old ones.

   Updating the state:

    setTree(...)
   

   This is the “watering” step — it triggers React to re-render all components consuming this context, so the new branch instantly appears wherever it’s needed.

3. By passing both tree and addBranch through the provider, every component can access the tree and the tool whenever needed — no prop drilling required.

And just like that, it all comes together! The context flows like water, the functions act as handy garden tools, and suddenly, managing data across your components feels effortless. No more prop drilling, no more messy state juggling — just a clean, growing tree where every branch, leaf, and flower knows exactly what it needs.

But before we wrap up today, a quick teaser: in the next article, we’ll explore three powerful React hooks — useRef, useMemo, and useCallback. These are like special tools in our garden shed: useRef lets us tag and keep track of specific branches or flowers, useMemo helps us optimize heavy calculations like counting leaves, and useCallback ensures our action tools (functions) are always ready without unnecessary re-creation.

Get ready to take our tree to the next level — smarter, faster, and more efficient!

However, when I first examined code snippets like these, I often struggled to connect the dots and truly grasp the flow. So, in this article, let’s go a step further — from concept to code — and break down how it all works in practice.

Since useContext is all about accessing data, we’ll begin by setting up some example data. And because our analogy revolves around a tree, our dataset will be… a tree itself! At the top level, we’ll have a branch as the first key. Its value will be an object containing an id and a leaf. The leaf itself will hold another object, which finally expands into a flower:

Now that we have our tree structure, the next step is to set up some React components and files that we’ll use throughout the example. To keep things organized, we’ll create two folders: components and context. Alongside these, we’ll also have our main files — App.js and index.js — to tie everything together.

First, let’s establish the context. This would be our store, where all the variables of functions would be declared, and would be accessible from!

1. 1. Importing the essentials

   First, we’ll bring in the React libraries we need — createContext, useContext, and useState:

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

2. Declaring the context and initial tree

   Next, we declare our context and an initial tree structure (from the data model we defined earlier):

    const TreeContext = createContext();
   
    const initialTree = {
      branch: {
        id: 1,
        leaf: {
          flower: "🌸"
        }
      }
    };
   

   3. Creating the TreeProvider

   Now comes the core piece: the TreeProvider.
   Its role is to ensure that our data (the tree) is accessible throughout the React component hierarchy. In other words, it’s the “water source” that supplies data everywhere. Inside our TreeProvider, we use the useState hook to manage the tree’s data. This allows us to not only store the initial tree but also update it dynamically whenever needed. By wrapping our children with TreeContext.Provider and passing the tree (along with any helper functions like addBranch) into its value, we make the data available to every component within this provider’s scope. In short, the provider acts as the central source, ensuring that all child components can seamlessly access and interact with the tree without the hassle of prop drilling.

    export const TreeProvider = ({ children }) => {
   
      const [tree, setTree] = useState(initialTree);
   
      // Example function to add a branch (we’ll define this further later)
      const addBranch = (newBranch) => {
        setTree({ ...tree, ...newBranch });
      };
   
      return (
        <TreeContext.Provider value={{ tree, addBranch }}>
          {children}
        </TreeContext.Provider>
      );
    };
   

   4. Making the context reusable

   To simplify context usage, we’ll create a custom hook that lets any component access our tree directly:

    export const useTree = () => useContext(TreeContext);
   

   With this setup, our tree context is now ready to be shared across the app.

For starters, we set up an App.js, from where the Provider will wrap our first component, <Tree/>

import React from "react";
import { TreeProvider } from "./context/TreeContext";
import Branch from "./components/Branch";

const App = () => {
  return (
    <TreeProvider>
        <Branch />
    </TreeProvider>
  );
};

export default App;

Further, we go deeper in our tree and use our recently created context inside the <Branch/> component.

import React from "react";
import { useTree } from "../context/TreeContext";
import Leaf from "./Leaf";

const Branch = () => {
  const { tree, addBranch } = useTree();
  const branches = tree.branches;

  return (
    <div>
      <h2>Branches</h2>
      <button onClick={addBranch}>➕ Add Branch</button>
      {Object.entries(branches).map(([key, branch]) => (
        <div key={key}>
          <h3>{key} (id: {branch.id})</h3>
          <Leaf leaf={branch.leaf} />
        </div>
      ))}
    </div>
  );
};

export default Branch;

This is a simple execution of our Branch Component — let’s break down what’s happening here:

1. Importing the context import { useTree } from "../context/TreeContext";

   We bring in our custom hook, useTree, which gives us direct access to the context we created earlier.

2. Extracting values from context const { tree, addBranch } = useTree();

   Here, we deconstruct the context to get both the tree data and the addBranch function.

3. Adding a new branch <button onClick={addBranch}>➕ Add Branch</button>

   This button will trigger the addBranch function whenever clicked, allowing us to dynamically grow our tree (we’ll explore this in detail later).

4. Using the tree data

   Finally, we can access the tree object to pull out its branches, leaves, and IDs for rendering inside our component.

Finally, the Leaf and Flower components are nested inside the Branch components.

import React from "react";
import Flower from "./Flower";

const Leaf = ({ leaf }) => {
  return (
    <div>
      <h3>Leaf</h3>
      <Flower flower={leaf.flower} />
    </div>
  );
};

export default Leaf;

import React from "react";

const Flower = ({ flower }) => {
  return (
    <div}>
      <h4> Flower: {flower}</h4>
    </div>
  );
};

export default Flower;

You might be wondering — why did we use props for passing down the leaf and flower instead of putting them into the context? To answer this, let’s return to our tree analogy.

Water is essential for every part of the tree, so it flows uniformly throughout — just like our context data. But what about byproducts of the soil that are only useful to a specific part, say the stem? We wouldn’t sprinkle those byproducts everywhere because not all parts need them, and even if we tried, extracting them would be unnecessarily complicated.

Similarly, in React, not all data belongs in context. Some values (like a specific leaf or flower) are only relevant to the immediate child component. In such cases, it’s simpler and cleaner to pass them as props rather than pushing everything through context.

That’s all for today! We’ve taken our first big steps into coding with useContext and building our tree. Next time, we’ll add a fun little function to actually make our tree grow. Until then — keep your roots strong and your branches reaching out!!

Imagine a huge garden with 4–5 trees, some plants, and grass spread all around. Now, think about watering it — but with a twist. Instead of pouring water directly at the base, you can only water from the top, say, the leaves. The water droplets then have to pass downward — from leaves to branches, branches to the stem, and finally reach the roots. But here’s the problem: this method of watering can lead to a loss of water in both quality and quantity. Since the droplets take time to flow through the plant’s veins, they can deteriorate due to external factors (like sunlight evaporating them) or internal factors (like leakage along the way).

The same thing happens with props in React components. When data is passed down through multiple layers, it can get messy, harder to track, and sometimes even lose relevance by the time it reaches the component that actually needs it. This leads to a very fascinating term - prop drilling!

Imagine we have a Plant component that holds everything the plant needs: Water, Sunlight, Chlorophyll, and Minerals. The Plant component passes these props to its child component Trunk. The Trunk passes them further down to Branches, then Leaves and Roots. Finally, this can even go deeper into the Soil layer.

Here, each component has to carry the same props — even if it doesn’t directly use them — just so the next layer can get access. This is the exact problem with prop drilling.

“In React, prop drilling refers to the process of passing data from a top-level component down to deeply nested child components by passing props through every intermediary component, even if those intermediaries don’t directly use the data.”

It happens because React only allows data flow top-down (unidirectional) via props.

So how do we curb prop drilling? How do we ensure props are managed in a cleaner, more organized way while preserving the originality and essence of our data inside React components? The answer lies in React’s useContext hook, which allows us to share state seamlessly across the component tree without the hassle of manual prop passing.

Let’s circle back to our gardening parallel. Earlier, we imagined water flowing strictly from the top down through the plant, but that’s not how nature really works. In reality, when the source of water—be it a sprinkler or rainfall—appears, every part of the plant engages with it directly. The leaves soak it in, the branches get refreshed, the stem absorbs it, and even the soil drinks from the same source. Everything connects straight to the origin, without relying on a single pathway.

React mirrors this behavior with a central store. Instead of forcing props to drip down layer by layer (like our earlier top-down flow), we set up a single source of truth—using tools like useContext —where data lives at the origin. Just like the garden, every component can directly tap into that source whenever it needs nourishment.

The next big question is: how do we actually build this store? How do we access it, and how do we make our components consume the data from it? This is where React’s useContext hook comes into play. Let’s start by looking at the basic syntax of useContext and how we can use it across different components.

1. We inject the context into our React components by using -

   import { createContext, useContext } from "react";

2. Then we create our context -

   const ThemeContext = createContext();

3. Wrapping our components with the Provider, which would help us access the context -

   <ThemeContext.Provider value={theme}>

   <Layout/>

   </ThemeContext.Provider>

4. And later on in the child components, use the context created.

   const theme = useContext(ThemeContext); return

   Current Theme: {theme}

When you went through the points, a bunch of questions must have spiraled through your head: What is a Provider? What is a store? What are createContext and useContext?

When we talk about createContext, think of it as setting up a water tank for our garden. It’s the container where our shared data—the water—will live. By itself, the tank doesn’t water the plants, but it defines the store, the single source of truth for our data.

Next comes the Provider. This is like connecting a sprinkler system or opening up the rain clouds. The Provider’s job is to distribute the water (data) to every plant (component) within its reach. Any part of the garden under the sprinkler is now able to receive nourishment.

Now, here’s where useContext comes in. Each part of the plant—be it the leaves, branches, stem, or even the soil—directly absorbs the water falling on it. Similarly, any React component under the Provider can call useContext to directly access the data from the store. No middle layers are needed to pass water around, just like no unnecessary prop drilling is required in React.

It might seem a bit overwhelming at first, but as we dig deeper, you’ll discover just how powerful and organized it makes your React components. In our next blog, we’ll roll up our sleeves, create a live store, and show how to effortlessly share its data across multiple components.

Some plants require daily water, while others need it only once a month, and some patiently wait for the seasonal rains. A few flowers open beautifully under sunlight, while others shrink away from it. The gardener doesn’t treat them all the same—each plant is tended to at its own pace, in its own rhythm.

React works much the same way with useEffect. Think of it as the gardener of your component. Some effects must run every time, like daily watering. Some run only once, like planting a seed at the start. Others wait until the right condition changes—like rain arriving after a long summer. Each effect listens, responds, and nurtures the component, just as a gardener listens to the silent needs of their plants.

For example, roses need water every single day. Instead of remembering to water them manually, the gardener might set up a system so that with the arrival of each new day, the roses are automatically refreshed with water. React gives us something similar to useEffect. If we want a particular piece of code to run every time our component renders, we place it inside useEffect without a dependency array. Just like the gardener’s daily watering system, React ensures the effect is triggered on every render.

useEffect(() => {

console.log("Watering the roses 🌹 (runs on every render)");

});

Now, not every action in a garden happens daily. Take sowing seeds, for example—you only do it once when you start the garden. The gardener doesn’t keep planting the same seed again and again. In React, this is like using useEffect with an empty dependency array []. It tells React: ‘run this effect only once, when the component first mounts, and never again.’

useEffect(() => {

console.log("🌱 Sowing the seeds (runs only once when component mounts)");

}, []);

Some flowers don’t need daily watering or one-time sowing—they wait for the sunlight to change. On a cloudy day, they stay still, but when the sun shines bright, they open up in full bloom. In React, this is like using useEffect with a dependency array. The effect doesn’t run all the time, only when a specific value changes.

useEffect(() => {

console.log(Flowers react to sunlight: ${sunlight} ☀️);

}, [sunlight]);

A small summary of what we understood so far!

Doesn’t this seem simple enough? A gardening task, something so natural and intuitive, mirrors how React useEffect works. By thinking of it as watering daily, sowing seeds once, or responding to sunlight changes, the logic behind dependencies suddenly feels less intimidating and more practical.

And this is just one piece of React’s powerful hook system. In our next article, we’ll step into useContext a hook that many developers both fear and love. Where useEffect is about timing and conditions, useContext is about connection: sharing values across components without having to pass props through every layer.

Stay tuned—we’ll uncover how useContext works, why it’s so useful, and how to overcome the fear around it.

But then I wondered—what if the sky couldn’t change its colors? What if once the day began, the sky stayed the same until the next day? No gentle shifts with the wind, no golden hues at sunset, no rainbow after the rain. Just one fixed canvas, locked in place.

That’s how functional components in React used to be. Before 2019, when hooks didn’t exist, function components were only capable of rendering JSX [ “JSX (JavaScript XML) is a syntax extension for JavaScript that allows you to write HTML-like code inside your JavaScript.” ]. They could display whatever props were passed down to them, but they had no state of their own. No matter what happened—wind, rain, or sunlight—their output stayed fixed until the parent re-rendered them.

A sky that cannot change with the weather… what a sad, colorless world that would be.

But then came Hooks! With hooks, function components could finally hold state and react to changes around them. Hooks are built-in functions in React that allow functional components to access core features like state, lifecycle events, and context. They were introduced in React 16.8 (2019) to give functional components the same power as class components—without the added complexity and boilerplate that classes require.

The first and most powerful of these is useState. useState is like the color bucket of the sky—it remembers the current shade, and whenever the environment changes, React updates the view with a new one. Red shifts to orange, orange to yellow, yellow to green, and so on! Let’s delve into this deeper!

Imagine you’re building a <Cloud> component—a simple cloud shape with a button inside it. The goal is that whenever the button is pressed, the cloud’s color should change. Without hooks, the component is read-only. The <Cloud> cannot manage its own color internally. To make it dynamic, it would need props from a parent component, along with a callback function to request a color change. Without this parent-managed state, the cloud cannot alter its color on its own.

Imagine the same <Cloud> component, but now we can use hooks. With the useState hook, the cloud can manage its own color internally, without relying on a parent component.

• You declare a state variable for the color inside the <Cloud> component.

• When the button is pressed, you simply update the state, and React automatically re-renders the cloud with the new color.

• No need for props, no need for a parent callback, no extra boilerplate—everything is self-contained.

• const [color, setColor] = React.useState("blue"); - With every click, the setColor function can be called, and the color of the cloud can change within!

Hooks are like giving the cloud its own paint bucket. Before, it had to ask its parent for a new color each time. Now, it can just dip its own brush and change color instantly whenever it wants.

The Traditional Way – Class Components

Imagine sitting at a desk, ready to draw. In front of you is a pencil box filled with tools: pencils, erasers, sharpeners, a ruler, maybe even a compass.

Every time you want to add detail, you reach for a different tool.

• Want to shade? Pick a pencil.

• Want to fix a mistake? Grab the eraser.

• Want a circle? Use the compass.

It works, no doubt. But it feels heavy and procedural. You’re constantly managing tools, keeping track of steps, and making sure you don’t misplace anything.

This is what Class Components are like in React. You get structure, built-in methods, and lifecycle hooks, but there’s more overhead. Every class component requires a constructor for initializing state, explicit use of this to access props and methods, and lifecycle methods like componentDidMount, componentDidUpdate, and componentWillUnmount to manage side effects. Updating the state involves - this.setState(), merging the new state with the existing state in a controlled manner. While class components provide a clear separation of concerns and are fully capable of managing complex UI and stateful logic, they tend to be more verbose and rigid!

The Modern Way – Function Components

Now, imagine opening an iPad with a stylus. Suddenly, you don’t need a separate eraser, compass, or sharpener. Everything you need—brushes, colors, undo/redo, even layers—is right there in one place.

If you want to try something new, just switch tools with a tap. No fumbling, no extra setup. It feels lighter, faster, and modern.

This is what Function Components with Hooks are like. They give you all the power of React—state, side effects, reusability—without the weight of class syntax and lifecycle methods. React has exciting hooks, which are like a great assist while coding complex logic. Function components are lighter, more modular, and highly reusable, making them the modern standard for building React applications.

Which Should You Choose?

Both approaches let you create beautiful art. But while traditional tools (Class Components) still work, most artists today prefer the iPad (Function Components). They’re simpler, more flexible, and the recommended way forward in React.

So the next time you sit down to “draw” with React, ask yourself:
Do you want the pencil box or the digital canvas?

Before we dive into code, grab a paper and pencil, and maybe some colors. Today, we’re going to draw a tree—but not just any tree. This will be our bridge to learning React concepts like components, state, and props.

First, let’s list the elements we’ll need to draw our tree:

• Trunk

• Upper base – the main body of the tree connecting the trunk to the branches.

• Branches

• Leaves

• Fruits

Let’s quickly sketch these elements so we can see how they fit together, almost like designing a blueprint. In our tree:

The Trunk is the base component, holding everything together. The Upper Base sits on top of the trunk as a container component, organizing the parts inside it. Branches, Leaves, and Fruits are child components, nested inside the upper base. Each has its own role but comes together to form the complete tree.

While drawing the leaves, fruits, and branches, you might start feeling a bit tired or bored because each item seems repetitive and monotonous. Imagine having to draw ten identical fruits one by one—tedious, right? In React, we don’t have to repeat ourselves like that. Instead of manually drawing each fruit, we can create one “Fruit” component and then reuse it multiple times wherever we need it inside our tree.

It might sound impossible at first—how can a single drawing appear in multiple places? But that’s exactly what React allows through component re-rendering. Once a component is defined, React can render it as many times as needed, each time appearing in a different part of the UI. Not only does this save time, but it also makes your code cleaner and easier to maintain. If you decide to change the appearance of the fruit later, you only need to update it in one place, and React automatically updates every instance wherever it’s used.

In essence, React turns repetitive work into reusable building blocks, just like having a magic stamp for your fruits and leaves—draw once, reuse everywhere.

Painting the Tree: Props and State in Detail

Let’s return to our canvas. The trunk, branches, leaves, and fruits all form parts of the painting. Some elements, like the trunk, are static, while others, such as the number of fruits or the color of the leaves, can change over time. Maybe you want to erase a fruit and paint a flower in its place, or fix a fruit that didn’t turn out quite right by covering it with the base color. In React, this is exactly where props and state come in—they let your tree respond to changes without having to redraw everything from scratch. Let’s explore these basics and see how they bring your tree to life!

Props: The Brushes and Instructions

Props are like the brushes, pens, or instructions you hand to each part of the painting. They tell the component how it should appear or behave, but the component itself cannot change them.

For example:

• You tell a fruit: “You should be red.” → The fruit will paint itself red.

• You tell a leaf: “You should be green.” → The leaf will use that color.

Props are read-only and configurable from outside the component. In other words, they’re passed from a parent component to its child, like giving your child a coloring book and pencils—they can color according to your instructions, but the book’s pages don’t change themselves.

Props are perfect when you want:

• A component to looks different in different places (e.g., red apple here, yellow apple there).

• Data to flow down the component tree without the child modifying it.

State: The Living Paint

A state is like the paint on your canvas that can change over time. Unlike props, state is mutable—components can update their own state based on actions, events, or time.

For example:

• Your tree starts with 3 fruits. Picking one fruit reduces the number to 2. The state allows the component to “remember” this change and update the painting automatically.

• A leaf may change color in autumn. State keeps track of the current color and updates it on the canvas.

State is local to the component, meaning each component manages its own dynamic data. Think of it like this: props are instructions from outside, while state is the component’s internal diary—it tracks what’s happening and can update itself whenever necessary.

Props vs State: Side-by-Side

How They Work Together

Imagine a fruit on your tree:

• Props tell it “you are red and small” → the fruit renders accordingly.

• State tracks whether it’s been picked or eaten → if someone clicks it, the fruit disappears, updating only that fruit without touching the rest of the tree.

By combining props and state, React lets you:

• Reuse components everywhere (props)

• Make them interactive and responsive (state)

It’s like having a painting that’s not only beautiful but alive—the colors and objects can change over time, reacting to actions or events, without repainting the entire canvas from scratch.

Learning React can feel overwhelming at first, but breaking it down into simple concepts—like drawing a tree—makes it much more approachable. By thinking in terms of components, props, and state, you can see how complex UIs are built from small, reusable, and interactive building blocks.

In the next article, we’ll take the next step: we’ll actually code and draw our tree in React. You’ll see these concepts come to life as we build a tree from trunk to leaves, making it interactive and dynamic. Get ready to turn your paper sketch into a real, working React UI!

Over time, this has become a daily ritual for me—a form of meditation that I practice before going to sleep. It brings me peace, helps me slow down, and strengthens my mind. But in the quiet of this routine, I stumbled upon an epiphany.

Painting feels a lot like React

Painting, I realized, is a lot like coding in React. Each element—whether a tree, a river, or a house—represents a component, designed to be understood and reused independently. The brushes and colors are applied thoughtfully, much like styling, to create a cohesive design. Just as I washed and reused my brush across different parts of the canvas, React reuses hooks and components to keep things modular and efficient.

When I added shading, the scene transformed—it gained depth, mood, and realism. This felt like working with state and props in React: subtle changes that ripple through the application, giving it life.

Where the Virtual DOM comes in

But the most striking parallel came when I thought about corrections. In painting, before I repaint or adjust something, I often sketch it lightly in pencil or imagine it on a rough sheet—just to see how it fits. Only once I’m confident do I commit the final strokes on canvas.

This is exactly how React uses the Virtual DOM (V-DOM). Think of the V-DOM as a lightweight, in-memory copy of the actual UI. It exists in JavaScript memory, not in the browser’s real DOM, and acts as a “draft layer” of the interface. Meanwhile, the Real DOM (R-DOM) is the actual browser-rendered UI that the user sees.

Whenever a component’s state or props change, React first updates the Virtual DOM. This is quick because it’s just JavaScript objects being updated in memory. React then runs a diffing algorithm, comparing the new V-DOM (after the update) with the previous V-DOM. This lets React figure out exactly what has changed.

Once the differences are identified, React updates only those specific parts in the Real DOM. This is more efficient than re-rendering the entire UI—like a painter touching up only the leaves of a tree instead of repainting the entire canvas.

Interaction between V-DOM and R-DOM:

1. V-DOM exists in memory (JS objects).

2. R-DOM exists in the browser (what the user sees).

3. Updates first happen in the V-DOM.

4. React calculates the minimal set of changes (diffing).

5. Only those changes are applied to the R-DOM.

This approach is why React apps feel fast and responsive even when UIs are complex—because updating the V-DOM is cheap, and only necessary changes touch the Real DOM.

A colorful world of analogies

This realization made coding in React feel more colorful, creative, and almost artistic. It’s not just logic and syntax—it’s composition, reuse, and attention to detail, much like art. And perhaps, by exploring the world through such analogies, we can make technology not only easier to understand but also more joyful to practice.

A small tabular approach for making our newfound understanding better :)

This marks the beginning of our React analogy series. Today, we explored the concept of the Virtual DOM through the lens of painting, making it easier to connect abstract technical ideas with something more tangible. In the next posts, we’ll gradually move into the foundational concepts of React—from components and props to state management and beyond. Step by step, we’ll build not just applications, but also a colorful way of understanding them.