Coder Legion - Recent posts tagged tutorials

SEO Basics Every Frontend Developer Should Know

Tue, 01 Sep 2026 05:00:00 +0000

Introduction

SEO gets treated like it's purely a marketing job — write good content, use the right keywords, done. But a huge chunk of what actually affects search rankings is technical, and it lives entirely in the code, meaning it's the frontend developer's job whether anyone officially assigns it or not.

Here's what I actually implement on every project, client or personal, without needing a marketing background.

1. Semantic HTML (This Matters More Than You Think)

Search engines read your HTML structure to understand what's important on the page.

<!-- Weak -->
<div class="title">Best Frontend Tools</div>
<div class="text">Content here...</div>

<!-- Semantic -->
<h1>Best Frontend Tools</h1>
<p>Content here...</p>

Rules to follow:

One <h1> per page, describing the main topic
Use <h2>, <h3> in proper hierarchical order, not just for visualsize
Use <nav>, <header>, <main>, <footer>, <article> where appropriate instead of generic <div>s everywhere

2. Meta Tags (The Basics Actually Matter)

<head>
  <title>15 Free Frontend Tools Every Developer Should Know | Your Site</title>
  <meta name="description" content="Discover 15 free frontend tools for design, CSS, icons, and testing — perfect for beginners and pros.">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

<title> should be unique per page, under ~60 characters, with your main keyword near the front
meta description doesn't directly boost ranking, but it's what shows in search results — a good one improves click-through rate, which does matter
viewport meta tag is required for mobile-friendliness, which Google explicitly factors into ranking

3. Image Alt Text

<img src="react-hooks-diagram.png" alt="Diagram showing useState and useEffect hook lifecycle in React">

Alt text serves two purposes: accessibility (screen readers rely on it) and SEO (search engines can't "see" images, only read this text). Never leave it empty on meaningful images, and never stuff it with random keywords — describe what's actually in the image.

4. Page Speed (A Direct Ranking Factor)

Google explicitly uses Core Web Vitals — loading speed, interactivity, and visual stability — as ranking signals. This connects directly to earlier articles in this series:

Optimize images with Squoosh or TinyPNG (Article 1)
Use max-width: 100% and proper responsive images instead of oversized
files (Article 6)
Lazy-load images below the fold: <img loading="lazy">
Check your score with Lighthouse and fix what it flags (Article 1)

A fast site isn't just a nice-to-have anymore — it's a direct, measurable ranking factor.

5. Mobile-Friendliness

Google uses mobile-first indexing, meaning it primarily looks at your site's mobile version when determining rankings, even for desktop search results. Everything covered in Article 6 (Responsive Design) directly affects SEO, not just user experience.

6. Clean, Descriptive URLs

Weak:  yoursite.com/page?id=4829
Better: yoursite.com/blog/free-frontend-tools

Descriptive URLs help both search engines and users understand what a page is about before even clicking.

7. Internal Linking

Link related pages/articles to each other within your site (like this series does, referencing earlier articles). This helps search engines understand your site structure and helps visitors discover more of your content — both of which support better rankings over time.

8. Structured Data (Optional but Powerful)

Adding Schema.org markup (JSON-LD format) helps search engines understand your content type — a blog post, a product, a review — and can unlock rich search result features like star ratings or FAQ dropdowns.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO Basics Every Frontend Developer Should Know",
  "author": "Muhammad Farhan"
}
</script>

This is more advanced and not essential for every project, but worth knowing it exists.

Common Beginner Mistakes

Using <div> for everything instead of semantic tags. Costs you nothing to fix and genuinely helps both SEO and accessibility.
Skipping alt text entirely. Easy to forget, meaningfully impactful when done right.
Shipping unoptimized images. The single most common performance (and therefore SEO) killer on beginner and even client projects.
Ignoring mobile experience because the desktop version "looks fine." Google mostly doesn't care how your desktop version looks.

Final Thoughts

You don't need to become an SEO specialist to meaningfully improve how a site ranks — most of the technical fundamentals are just good development practices you should be doing anyway: semantic HTML, fast load times, proper alt text, and mobile responsiveness. Build these habits into every project from the start, and SEO stops being a separate task tacked on at the end.

That wraps this 15-article series — if you've followed along from Article 1, you now have a solid, practical foundation across CSS, React, tooling, deployment, freelancing, and SEO. Go build something with it.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

How I Landed My First Freelance Client as a Frontend Developer

Fri, 28 Aug 2026 05:00:00 +0000

Introduction

I'm not going to pretend this was some overnight success story — it wasn't. It took real, unglamorous effort before anything happened. But I think that's exactly why this story is more useful than the polished "I made $10k my first month" posts you see floating around.

Here's honestly what happened, and what I'd tell any beginner developer trying to land their first client right now.

Where I Started

I had a portfolio (see Article 12 for what actually goes into a good one), a few personal projects, and zero client work. No reviews, no testimonials, nothing to point to except "trust me, I can build this."

That's a genuinely hard position to sell from — and I want to be upfront about that instead of skipping past it.

What Didn't Work

Mass-applying to generic Fiverr/Upwork gigs with a copy-pasted message. I sent probably 15-20 near-identical proposals early on. Zero responses. Clients can tell instantly when a message wasn't written specifically for their project.

Underpricing to "compete." I dropped my rate low, assuming price was the deciding factor. It wasn't — the clients I was losing to weren't choosing based on price; they were choosing based on trust, and a rock-bottom price can actually read as a red flag rather than a selling point.

What Actually Worked

Before sending a proposal, I'd actually look at the client's existing website or business, and mention something specific in my message.

Instead of: "Hi, I'm a frontend developer available for your project."

I wrote: "I checked out your current site — the mobile menu doesn't
open properly on iPhone Safari, which is likely costing you visitors.
I can fix that as part of rebuilding your homepage."

That single specific observation did more than 20 generic messages combined.

2. I Led With a Live Demo, Not Just a Portfolio Link

For one prospect, instead of just sending my portfolio, I built a quick, rough homepage mockup based on their existing brand and sent a live preview link alongside my proposal. It took maybe 90 minutes, and it was the deciding factor in getting that first "yes."

This doesn't scale to every application — but for a client you genuinely want, showing instead of just telling is worth the extra effort.

3. I Asked for a Testimonial Immediately After Finishing

The moment that first project wrapped up and the client was happy, I asked directly for a short written testimonial and permission to list the project in my portfolio. That single testimonial made every proposal after it noticeably stronger — I finally had proof, not just a promise.

4. I Treated the First Project as a Portfolio Investment, Not Just a Paycheck

I overdelivered slightly on that first project — a bit more polish, a bit more communication than strictly required. It wasn't about being a pushover; it was a deliberate decision, because that project was going to be my proof for every client after it.

What I'd Tell Beginners Specifically

Your first client won't come from volume — it'll come from one genuinely well-researched, specific pitch. Send fewer, better proposals.
A rough live demo beats a polished portfolio link for a serious prospect. It proves you can actually do the specific thing they need, not just that you can build things in general.
Don't undercharge to compete. Price confidently for the value, and let your specificity and communication build trust instead.
Ask for a testimonial the moment you finish, while the client is happiest. Don't wait — that window closes fast.
Your first project is marketing, not just income. Treat it that way, and the second client comes noticeably easier than the first.

Final Thoughts

There's no trick that skips the hard part — you do have to put in real, specific effort before that first client says yes. But once you have that first project and testimonial, everything after it gets meaningfully easier, because you're no longer selling a promise. You're selling proof.

If you're still working on landing your first client, I'd genuinely love to hear where you're stuck — drop it in the comments.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Common CSS Mistakes Beginners Make (and How to Fix Them)

Tue, 25 Aug 2026 05:00:00 +0000

Introduction

Every one of these mistakes cost me real debugging time when I was learning. Not because CSS is inherently confusing — but because nobody explained why these things happen, just that they do. Understanding the "why" is what actually prevents you from repeating them.

1. The Box Model Confusion

By default, width and height don't include padding and border — meaning a box you set to 300px wide can visually render wider once padding is added.

.box {
  width: 300px;
  padding: 20px;
  border: 2px solid black;
  /* Actual rendered width: 300 + 20+20 + 2+2 = 344px */
}

The fix: set this once, globally, at the start of every project:

* {
  box-sizing: border-box;
}

Now width: 300px means the element is always 300px total, padding and border included. This single line prevents a huge number of layout bugs.

2. Margin Collapse

Two vertical margins between sibling elements don't add together — they collapse into the larger of the two.

.first { margin-bottom: 20px; }
.second { margin-top: 30px; }
/* Actual gap between them: 30px, NOT 50px */

This confuses beginners constantly because it seems inconsistent — but it's expected browser behavior for vertical margins specifically (doesn't apply to horizontal margins, or to Flexbox/Grid gap).

The fix: use gap on a flex or grid container instead of relying on margins between children — it doesn't collapse and is far more predictable.

3. Overusing `!important`

.button {
  background: blue !important;
}

!important overrides normal CSS specificity rules — which feels like a quick fix, but it creates a mess later. Once you have several !important rules fighting each other, debugging becomes genuinely painful because normal specificity logic no longer applies.

The fix: understand specificity instead. IDs beat classes, classes beat elements. If you're reaching for !important, it usually means a more specific selector (or restructuring your CSS) would solve it more cleanly.

4. Not Understanding `position: absolute`

.tooltip {
  position: absolute;
  top: 0;
  left: 0;
}

Beginners often expect this to position relative to the whole page. In reality, position: absolute positions relative to the nearest ancestor with position: relative (or absolute/fixed) set. If no ancestor has that, it positions relative to the whole document — which is rarely what you actually want.

The fix: always set position: relative on the parent container first:

.card {
  position: relative;
}
.badge {
  position: absolute;
  top: 8px;
  right: 8px;
}

5. Fighting Flexbox/Grid Instead of Reading the Docs

A very common beginner pattern: not getting the exact spacing/alignment you want, then adding random margins and padding until it "looks right" by trial and error.

The fix: learn justify-content, align-items, and gap properly (covered fully in Article 2). Once you understand these three properties, most alignment problems have a direct, one-line solution instead of a pile of guessed margins.

6. Not Resetting Default Browser Styles

Browsers apply their own default styles to elements (<ul> gets bullet points and padding, <h1> gets specific margins, etc.), and these defaults are inconsistent across browsers.

The fix: use a simple CSS reset at the top of your stylesheet, or use Tailwind CSS, which includes a solid reset (Preflight) automatically.

7. Specificity Wars from Nested Selectors

.card .header .title span {
  color: red;
}

Deeply nested selectors like this become extremely hard to override later, since they carry heavy specificity.

The fix: keep selectors as flat as possible. A single well-named class (.card-title) is easier to maintain than four levels of nesting.

Final Thoughts

Almost every CSS mistake on this list comes down to one thing: not understanding why the browser is doing what it's doing, and reaching for a quick patch instead. Once you understand the box model, specificity, and positioning contexts properly, CSS debugging goes from guesswork to genuinely logical problem-solving.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

JavaScript ES6+ Features Every Frontend Developer Should Master

Tue, 18 Aug 2026 05:00:00 +0000

Introduction

If you learned JavaScript from an older tutorial, there's a decent chance you're writing more code than necessary without realizing it. Modern JavaScript (officially called ES6 and beyond, first released in 2015) added features that make everyday code shorter, more readable, and honestly just more enjoyable to write.

If you're using React, you're already using several of these features without knowing their names. Let's fix that.

1. Arrow Functions

// Old way
function add(a, b) {
  return a + b;
}

// Arrow function
const add = (a, b) => a + b;

For single-expression functions, you can skip the curly braces and return keyword entirely — the expression's result is returned automatically.

Where you'll actually use this: callbacks, all the time.

const doubled = numbers.map(num => num * 2);

2. Destructuring

Pulling values out of objects or arrays into individual variables.

const user = { name: "Farhan", role: "Developer" };

// Old way
const name = user.name;
const role = user.role;

// Destructuring
const { name, role } = user;

Works with arrays too:

const [first, second] = ["React", "Tailwind"];

This is exactly what's happening every time you write const [count, setCount] = useState(0) in React.

3. Spread and Rest Operators (...)

The same three dots, doing two different jobs depending on context.

Spread — expands an array or object:

const original = [1, 2, 3];
const copy = [...original, 4]; // [1, 2, 3, 4]

const user = { name: "Farhan" };
const updatedUser = { ...user, role: "Developer" };

Rest — collects multiple values into one array/object:

function sum(...numbers) {
  return numbers.reduce((total, n) => total + n, 0);
}
sum(1, 2, 3, 4); // 10

4. Template Literals

String building using backticks instead of concatenation:

const name = "Farhan";

// Old way
const greeting = "Hello, " + name + "! You have " + count + " messages.";

// Template literal
const greeting = `Hello, ${name}! You have ${count} messages.`;

Also supports multi-line strings naturally, without \n characters.

5. Optional Chaining (?.)

Safely access deeply nested properties without your code crashing if something is missing:

// Old way — risky if 'address' doesn't exist
const city = user.address.city;

// Optional chaining — returns undefined instead of crashing
const city = user?.address?.city;

Extremely useful when working with API data, where fields aren't always guaranteed to exist.

6. Nullish Coalescing (??)

Provides a fallback value, but only when the original value is null or undefined (unlike ||, which also triggers on 0, "", or false):

const count = userCount ?? 0;

If userCount is 0, || would incorrectly fall back to the default. ?? correctly keeps it as 0.

7. Array Methods: map, filter, reduce

The trio that replaces almost every manual for loop you'd otherwise write:

const users = [
  { name: "Ali", active: true },
  { name: "Sara", active: false },
];

const activeNames = users
  .filter(user => user.active)
  .map(user => user.name);
// ["Ali"]

filter keeps items matching a condition. map transforms each item. reduce combines everything into a single value (a sum, an object, whatever you need).

Common Beginner Mistakes

Mixing arrow functions and this incorrectly. Arrow functions don't have their own this — they inherit it from the surrounding scope. This trips people up in class components or event handlers occasionally.
Overusing optional chaining to hide real bugs. ?. is for genuinely optional data, not a substitute for fixing broken logic upstream.
Forgetting map returns a new array. It doesn't modify the original array — a common source of "why isn't my state updating" bugs in React.

Final Thoughts

These seven features cover probably 90% of what "modern JavaScript" actually means in day-to-day frontend work. If you're comfortable with all of them, reading React code (and most modern codebases) gets significantly easier, because this is the syntax nearly everyone writes in now.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

CSS Animations for Beginners: Transitions, Keyframes & Transforms

Tue, 11 Aug 2026 05:00:00 +0000

Introduction

CSS animations were the thing that made me actually enjoy frontend development. Building a static layout is satisfying, but the moment something moves smoothly on hover or fades in on load, a project suddenly feels alive.

The good news: you only need three concepts to cover almost every animation you'll want to build — transitions, transforms, and keyframes. Let's go through all three.

1. Transitions — Smoothing Out State Changes

A transition smooths out a property change between two states (like normal and hover).

.button {
  background-color: #3b82f6;
  transition: background-color 0.3s ease;
}

.button:hover {
  background-color: #2563eb;
}

Without transition, the color change would be instant. With it, the color smoothly shifts over 0.3 seconds.

Syntax breakdown: transition: [property] [duration] [easing];

In Tailwind:

<button class="bg-blue-500 hover:bg-blue-600 transition duration-300">

2. Transform — Moving, Scaling, Rotating

transform changes an element's position, size, or rotation without affecting the layout of surrounding elements.

.card {
  transition: transform 0.3s ease;
}

.card:hover {
  transform: translateY(-8px) scale(1.02);
}

This lifts a card slightly and grows it a tiny bit on hover — a very common effect on portfolio sites and product cards.

Common transform values:

translateY(-8px) — moves up
scale(1.05) — grows by 5%
rotate(5deg) — rotates slightly
translateX(20px) — moves right

In Tailwind:

<div class="transition hover:-translate-y-2 hover:scale-105">

3. Keyframes — Multi-Step Animations

Transitions handle two states. @keyframes handles animations with multiple steps, or ones that run automatically without needing a trigger like :hover.

@keyframes fadeInUp {
  from {
    opacity: 0;
    transform: translateY(20px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.hero-title {
  animation: fadeInUp 0.8s ease-out;
}

This makes an element fade in while sliding up slightly — a very common "page load" effect.

You can also define multiple steps with percentages:

@keyframes pulse {
  0% { transform: scale(1); }
  50% { transform: scale(1.1); }
  100% { transform: scale(1); }
}

.notification-dot {
  animation: pulse 2s infinite;
}

This creates a continuous pulsing effect, useful for notification badges or "live" indicators.

Putting It Together: A Real Example

Here's a button with a hover lift, a smooth color transition, and a subtle entrance animation on page load:

@keyframes fadeIn {
  from { opacity: 0; }
  to { opacity: 1; }
}

.cta-button {
  background-color: #3b82f6;
  transition: all 0.3s ease;
  animation: fadeIn 0.6s ease-in;
}

.cta-button:hover {
  background-color: #2563eb;
  transform: translateY(-4px);
  box-shadow: 0 10px 20px rgba(59, 130, 246, 0.3);
}

This is genuinely how most polished-feeling buttons on real websites are built — nothing exotic, just transitions and transforms combined thoughtfully.

Common Beginner Mistakes

Animating too many properties at once. Subtlety wins — one or two properties changing smoothly looks more professional than five things moving at once.
Using all in transitions carelessly. transition: all 0.3s works, but is slightly less performant than specifying exact properties like transition: transform 0.3s, background-color 0.3s.
Animating width/height/top/left instead of transform. These properties trigger layout recalculation and can feel janky. transform and opacity are GPU-accelerated and much smoother.
Overusing infinite animations. A pulsing badge is fine. A constantly bouncing hero heading gets annoying fast — use continuous animation sparingly.

Final Thoughts

You don't need a JavaScript animation library for most of what makes a website feel polished — smooth hovers, subtle lifts, and clean entrance animations are all achievable with plain CSS. Start by adding a transition to every hover state in your next project and see how much more "finished" it instantly feels.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

How to Build Your First React Component (Step-by-Step)

Fri, 07 Aug 2026 05:00:00 +0000

Introduction

Your first React component doesn't need to be complicated. In fact, the biggest mistake beginners make is trying to build something too ambitious right away and getting stuck on concepts they haven't learned yet.

We're building something practical and genuinely useful: a reusable Testimonial Card component — the kind of thing that shows up in real portfolios and client projects constantly.

Step 1: Understand What a Component Actually Is

A React component is just a JavaScript function that returns some JSX (HTML-like syntax). That's the whole concept.

function Greeting() {
  return <h1>Hello, world!</h1>;
}

You use it like an HTML tag:

<Greeting />

Step 2: Build the Static Version First

Before adding any dynamic data, get the layout right with hardcoded content:

function TestimonialCard() {
  return (
    <div className="bg-slate-800 rounded-2xl p-6 max-w-sm shadow-lg">
      <p className="text-slate-300 mb-4">
        "This developer delivered exactly what we needed, on time and with great communication."
      </p>
      <div className="flex items-center gap-3">
        <div className="w-10 h-10 rounded-full bg-blue-500"></div>
        <div>
          <p className="text-white font-semibold">Sarah Ahmed</p>
          <p className="text-slate-400 text-sm">Product Manager</p>
        </div>
      </div>
    </div>
  );
}

Notice: no state, no props, nothing dynamic. Just structure and styling. This is genuinely how you should approach every new component — get the static layout right first.

Step 3: Make It Reusable with Props

Right now this card only shows one testimonial. Props let you reuse the same component with different data:

function TestimonialCard({ quote, name, role }) {
  return (
    <div className="bg-slate-800 rounded-2xl p-6 max-w-sm shadow-lg">
      <p className="text-slate-300 mb-4">"{quote}"</p>
      <div className="flex items-center gap-3">
        <div className="w-10 h-10 rounded-full bg-blue-500"></div>
        <div>
          <p className="text-white font-semibold">{name}</p>
          <p className="text-slate-400 text-sm">{role}</p>
        </div>
      </div>
    </div>
  );
}

Now you use it like this:

<TestimonialCard
  quote="This developer delivered exactly what we needed, on time."
  name="Sarah Ahmed"
  role="Product Manager"
/>

{ quote, name, role } is destructuring the props object — same as writing props.quote, props.name, props.role, just cleaner.

Step 4: Render a List of Them

In a real project, you'd map over an array of testimonial data:

const testimonials = [
  { quote: "Great work, fast turnaround.", name: "Ali Raza", role: "Founder" },
  { quote: "Clean code and clear communication.", name: "Sarah Ahmed", role: "PM" },
  { quote: "Would hire again without hesitation.", name: "James Lee", role: "CTO" },
];

function TestimonialGrid() {
  return (
    <div className="grid md:grid-cols-3 gap-6 p-6">
      {testimonials.map((item, index) => (
        <TestimonialCard key={index} {...item} />
      ))}
    </div>
  );
}

{...item} spreads the object properties as individual props automatically — a common React pattern once you're comfortable with the basics.

Important: the key prop is required whenever you render a list. React uses it to track which items changed. In a real project, use a unique ID from your data rather than the array index if possible.

Step 5: Add a Bit of Interactivity (Optional)

Want to show a "Read more" toggle for long quotes? That's where useState comes in — covered in detail in Article 5, but here's the quick version:

function TestimonialCard({ quote, name, role }) {
  const [expanded, setExpanded] = useState(false);

  return (
    <div className="bg-slate-800 rounded-2xl p-6 max-w-sm shadow-lg">
      <p className={`text-slate-300 mb-4 ${!expanded && "line-clamp-2"}`}>
        "{quote}"
      </p>
      <button onClick={() => setExpanded(!expanded)} className="text-blue-400 text-sm mb-4">
        {expanded ? "Show less" : "Read more"}
      </button>
      {/* rest of the card */}
    </div>
  );
}

Common Beginner Mistakes

Trying to add state and interactivity before the static layout is right. Get the structure and styling working first — add logic after.
Forgetting the key prop when rendering lists. React will warn you in the console — don't ignore that warning.
Not destructuring props. Writing props.quote everywhere instead of destructuring is more typing and harder to read.
Building one giant component instead of small, focused ones. If a component is doing three different jobs, split it into three components.

Final Thoughts

Building your first real component is less about React "magic" and more about breaking a UI down into small, reusable pieces — static first, then props, then interactivity if needed. Rebuild this same pattern (static → props → list → interactivity) for your next few components and it'll start feeling automatic.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Responsive Design 101: How to Make Any Website Mobile-Friendly

Fri, 31 Jul 2026 05:00:00 +0000

Introduction

The first website I ever built looked great on my laptop and completely broken on my phone. Text overflowing, buttons cut off, images stretched way too big. That's the exact moment "responsive design" stopped being a buzzword and became something I actually had to understand.

Here's the good news: responsive design isn't complicated once you learn a handful of core habits. This article covers exactly those.

Mobile-First: Start Small, Then Grow

The most important mindset shift: design for the smallest screen first, then add complexity as the screen grows — not the other way around.

/* Base styles = mobile */
.container {
  display: flex;
  flex-direction: column;
}

/* Then adjust for larger screens */
@media (min-width: 768px) {
  .container {
    flex-direction: row;
  }
}

In Tailwind, this is built into the framework by default:

<div class="flex flex-col md:flex-row">

No media query needed — flex-col is the mobile default, md:flex-row overrides it on tablets and up.

Understanding Breakpoints

A breakpoint is a screen width where your layout changes. Tailwind's defaults are a solid starting point for almost any project:

(none) — Default styles apply to all screen sizes starting from 0px
(Mobile).
sm: — Applies styles on screens 640px and wider (Large phones).
md: — Applies styles on screens 768px and wider (Tablets).
lg: — Applies styles on screens 1024px and wider (Laptops).
xl: — Applies styles on screens 1280px and wider (Desktops).

You rarely need custom breakpoints — these five cover the vast majority of real devices.

Flexible Units Over Fixed Pixels

Fixed pixel widths break responsive layouts. Use flexible units instead:

% — relative to the parent container
rem — relative to the root font size (better than px for text)
vw / vh — relative to viewport width/height
fr — flexible fraction, used in CSS Grid

/* Breaks on small screens */
.card { width: 400px; }

/* Adapts to any screen */
.card { width: 100%; max-width: 400px; }

That second version is the pattern to remember: set a max-width for large screens, but let it shrink to 100% on smaller ones.

Responsive Images

Images are the #1 cause of layout breakage for beginners. The fix is almost always this:

img {
  max-width: 100%;
  height: auto;
}

In Tailwind:

<img src="photo.jpg" class="max-w-full h-auto" />

This ensures an image never overflows its container, regardless of screen size, while keeping its aspect ratio intact.

Testing Your Responsive Design

Don't just resize your browser window manually — use these instead:

Chrome DevTools Device Mode (Ctrl+Shift+M) — simulates real device sizes, including touch input
Responsively App — tests multiple device sizes side by side, syncing scroll and clicks (covered in Article 1)
Actually open the site on your own phone before calling it done — emulators are close, but not perfect

Common Beginner Mistakes

Designing desktop-first, then trying to "fix" mobile later. Almost always results in more work and more bugs.
Fixed-width containers. width: 1200px will always cause horizontal scrolling on smaller screens. Use max-width instead.
Text that's too small on mobile. 16px is a safe minimum for body text — anything smaller strains readability on phones.
Forgetting touch targets. Buttons and links need enough padding to be tappable with a thumb — 44px height minimum is the common accessibility guideline.

Final Thoughts

Responsive design isn't a separate skill you learn once and forget — it's a habit you build into every single component from day one. Start mobile-first, use flexible units, test on real devices, and most layout bugs simply won't happen in the first place.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

Building a Custom React Hook Library From Scratch (Complete Guide)

Wed, 22 Jul 2026 09:48:19 +0000

Introduction: Why Hooks Deserve This Much Attention

Before hooks existed, sharing stateful logic between React components meant reaching for Higher-Order Components (HOCs) or the render props pattern — both of which worked, but both of which came with real costs: wrapper hell in your component tree, awkward prop naming collisions, and code that was genuinely harder to trace through. Hooks, introduced in React 16.8, solved this cleanly. A custom hook is nothing more than a JavaScript function whose name starts with use and which is allowed to call other hooks internally. That's the entire technical definition. But the practice of writing good custom hooks — ones that are reusable, predictable, and don't leak implementation details — is a skill that takes deliberate study.

This article is a complete treatment of that skill. We're not going to stop at three toy examples. We're going to build ten real, production-worthy hooks, understand exactly why each line of each hook exists, cover the TypeScript patterns that make them safe to reuse across a large codebase, learn how to actually test them in isolation, and finish with how to package the whole thing into a publishable npm library. If you read this article fully and rebuild these hooks yourself, you will have a genuinely reusable toolkit you can drop into every project going forward — and more importantly, you'll understand the underlying patterns well enough to design new hooks confidently on your own.

Part 1: The Rules of Hooks, and Why They Exist

Before writing custom hooks, you need a proper mental model of why the "Rules of Hooks" exist, not just what they are. The two rules are:

Only call hooks at the top level of a function component or another
hook — never inside loops, conditions, or nested functions.
Only call hooks from React function components or from other custom
hooks — never from regular JavaScript functions.

These rules aren't arbitrary style preferences. React tracks hook state using call order. Internally, when your component renders, React walks through your function body and matches each useState, useEffect, useRef call to a slot in an internal linked list, purely based on the order they were called in. If you conditionally skip a hook call on one render but not another — for example, wrapping a useState call in an if statement — the order shifts, and React can no longer correctly match state to the right slot. The result is corrupted state, hooks reading the wrong values, and bugs that are maddeningly difficult to trace because they only manifest under specific conditional branches.

// This breaks React's internal bookkeeping
function BrokenComponent({ condition }) {
  if (condition) {
    const [value, setValue] = useState(0); // sometimes called, sometimes not
  }
  const [other, setOther] = useState(""); // slot position shifts depending on `condition`
}

Understanding this internal mechanism — rather than just memorizing "don't put hooks in conditionals" — is what lets you debug genuinely confusing hook-related bugs quickly, and it's essential background before writing your own hooks, since a custom hook that internally violates this rule will silently corrupt the state of every component that uses it.

Part 2: Anatomy of a Good Custom Hook

A good custom hook has three properties:

It owns its complexity. The consumer of the hook shouldn't need to understand useEffect cleanup timing, AbortController, or debounce timers to use it correctly. All of that complexity lives inside the hook.

It exposes a minimal, predictable API. Ideally a hook returns either a single value, a tuple ([value, setter], mirroring useState's own convention), or a small object with clearly named properties. Avoid returning a dozen loosely related values — that's a sign the hook is doing too many unrelated jobs and should be split.

It composes cleanly with other hooks. A hook built well can be used inside another custom hook without surprising behavior — this composability is where hooks show their real power over the HOC pattern they replaced.

With that framework in place, let's build the actual library.

Part 3: useLocalStorage — State Synced to Persistent Storage

This is one of the most commonly needed custom hooks, and also one of the easiest to get subtly wrong.

import { useState, useEffect, useCallback } from "react";

function useLocalStorage(key, initialValue) {
  const readValue = useCallback(() => {
    if (typeof window === "undefined") return initialValue; // SSR safety
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      console.warn(`Error reading localStorage key "${key}":`, error);
      return initialValue;
    }
  }, [key, initialValue]);

  const [storedValue, setStoredValue] = useState(readValue);

  const setValue = useCallback(
    (value) => {
      try {
        const valueToStore = value instanceof Function ? value(storedValue) : value;
        setStoredValue(valueToStore);
        if (typeof window !== "undefined") {
          window.localStorage.setItem(key, JSON.stringify(valueToStore));
          window.dispatchEvent(new StorageEvent("local-storage", { key }));
        }
      } catch (error) {
        console.warn(`Error setting localStorage key "${key}":`, error);
      }
    },
    [key, storedValue]
  );

  useEffect(() => {
    function handleStorageChange(event) {
      if (event.key && event.key !== key) return;
      setStoredValue(readValue());
    }
    window.addEventListener("storage", handleStorageChange);
    window.addEventListener("local-storage", handleStorageChange);
    return () => {
      window.removeEventListener("storage", handleStorageChange);
      window.removeEventListener("local-storage", handleStorageChange);
    };
  }, [key, readValue]);

  return [storedValue, setValue];
}

Let's walk through exactly why every piece of this exists, because a naive implementation misses several real-world requirements:

SSR safety. If this hook runs during server-side rendering (Next.js, Remix), window doesn't exist. The typeof window === "undefined" check prevents a hard crash during server rendering — a mistake that trips up nearly every beginner writing their first localStorage hook.

Try/catch around JSON parsing. localStorage can contain corrupted or manually-edited data (a user opening DevTools and typing garbage into storage, or an old schema version from a previous app update). Without the try/catch, a single malformed value crashes the entire hook on mount.

Functional updates. Supporting setValue(prev => prev + 1), not just setValue(5), mirrors useState's own API — and it matters because without it, any consumer needing to update based on the previous value has to read storedValue from a closure that might be stale, exactly the bug class covered in the JavaScript closures article.

Cross-tab synchronization. The native storage event fires in other tabs when localStorage changes — but critically, it does not fire in the same tab that made the change. That's why we manually dispatch a custom local-storage event after every write, and listen for both events. Without this, opening the same app in two browser tabs and updating a value in one tab wouldn't update the other tab's in-memory state, even though the underlying storage is correctly synced.

This hook alone demonstrates the core principle from Part 2: all of this complexity — SSR checks, error handling, cross-tab sync — is completely hidden from anyone using the hook. They just write const [theme, setTheme] = useLocalStorage("theme", "dark") and get correct behavior in every scenario.

Debouncing comes up constantly — search inputs, autosave, resize handlers — but there are actually two distinct patterns worth separating clearly, because conflating them is a common source of confusion.

Debouncing a value (delay reacting to a value until it stops changing):

function useDebounce(value, delay = 300) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

Debouncing a callback function (delay the function call itself, useful for things like autosave triggered by an event handler rather than a changing value):

function useDebouncedCallback(callback, delay = 300) {
  const timeoutRef = useRef(null);
  const callbackRef = useRef(callback);

  useEffect(() => {
    callbackRef.current = callback;
  }, [callback]);

  const debouncedFn = useCallback(
    (...args) => {
      if (timeoutRef.current) clearTimeout(timeoutRef.current);
      timeoutRef.current = setTimeout(() => {
        callbackRef.current(...args);
      }, delay);
    },
    [delay]
  );

  useEffect(() => {
    return () => {
      if (timeoutRef.current) clearTimeout(timeoutRef.current);
    };
  }, []);

  return debouncedFn;
}

Notice the callbackRef pattern here — it's a subtle but important detail. If we captured callback directly inside debouncedFn's closure, every time the parent component re-rendered with a new callback function reference (which happens constantly if the parent doesn't memoize it), our debounce timer logic would use a stale, outdated version of the function. By storing the latest callback in a ref and always reading callbackRef.current inside the timeout, we guarantee the most recent version of the callback runs, regardless of how many times the component re-rendered while the timer was pending. This ref-for-latest-value pattern is one of the most useful advanced techniques in custom hook design, and it reappears throughout this article.

When to use which: use useDebounce when you have a value (search input text) and want a component to re-render only after it settles — the search API call pattern from earlier in this series. Use useDebouncedCallback when you're debouncing an imperative action itself, like an autosave function triggered on every keystroke.

Part 5: useFetch — Data Fetching With Cancellation, Caching, and Retry

A production-worthy fetch hook needs to handle more than the happy path.

function useFetch(url, options = {}) {
  const [state, setState] = useState({ data: null, loading: true, error: null });
  const optionsRef = useRef(options);
  optionsRef.current = options;

  useEffect(() => {
    if (!url) return;
    const controller = new AbortController();
    let isMounted = true;

    setState({ data: null, loading: true, error: null });

    fetch(url, { ...optionsRef.current, signal: controller.signal })
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}: ${res.statusText}`);
        return res.json();
      })
      .then((data) => {
        if (isMounted) setState({ data, loading: false, error: null });
      })
      .catch((err) => {
        if (err.name === "AbortError") return; // expected during cleanup, not a real error
        if (isMounted) setState({ data: null, loading: false, error: err });
      });

    return () => {
      isMounted = false;
      controller.abort();
    };
  }, [url]);

  return state;
}

Three details worth explaining deeply:

AbortController and the race condition it prevents. Imagine a component that fetches data based on a userId prop, and that prop changes quickly (a user clicking through a list of profiles rapidly). Without cancellation, if the first fetch (for user A) is slow and the second fetch (for user B) is fast, the second response could arrive first, get set into state, and then the first (now outdated) response for user A arrives afterward and overwrites the correct state with stale data. AbortController cancels the in-flight request when the effect re-runs (because url changed) or the component unmounts, preventing this exact race condition.

The isMounted flag alongside AbortController. You might wonder why we need both. AbortController prevents the fetch from completing, but in some edge cases (particularly with certain fetch polyfills or when the abort happens mid-JSON-parsing), a .then() callback can still fire after unmount. The isMounted flag is a defensive backstop against calling setState on an unmounted component, which React will warn about in the console.

The optionsRef pattern. If we included options directly in the effect's dependency array, and the consumer passed a new object literal on every render (useFetch(url, { headers: {...} })), the effect would re-run on every single render, regardless of whether url actually changed — a very common and very subtle bug. By storing options in a ref and reading optionsRef.current inside the effect, we decouple the effect's re-run condition (only url changing) from unstable object references passed by the consumer.

Part 6: useToggle — Simple, But Illustrates a Design Principle

function useToggle(initialValue = false) {
  const [value, setValue] = useState(initialValue);

  const toggle = useCallback(() => setValue((v) => !v), []);
  const setTrue = useCallback(() => setValue(true), []);
  const setFalse = useCallback(() => setValue(false), []);

  return [value, { toggle, setTrue, setFalse }];
}

This hook is intentionally simple, but the return shape teaches an important design lesson: returning [value, actions] — an array with a value and an object of related actions — is a clean, extensible pattern. Compare this to useState's [value, setValue] tuple; we're following the same convention while accommodating more than one action, without needing a five-element array where the consumer has to remember positional ordering.

Part 7: useMediaQuery — Responsive Logic in JavaScript

Sometimes CSS media queries aren't enough — you need to conditionally render entirely different components based on screen size, not just different styles.

function useMediaQuery(query) {
  const [matches, setMatches] = useState(() => {
    if (typeof window === "undefined") return false;
    return window.matchMedia(query).matches;
  });

  useEffect(() => {
    const mediaQueryList = window.matchMedia(query);
    const listener = (event) => setMatches(event.matches);

    setMatches(mediaQueryList.matches); // sync in case it changed between render and effect
    mediaQueryList.addEventListener("change", listener);

    return () => mediaQueryList.removeEventListener("change", listener);
  }, [query]);

  return matches;
}

Usage:

function Navigation() {
  const isMobile = useMediaQuery("(max-width: 767px)");
  return isMobile ? <MobileMenu /> : <DesktopMenu />;
}

The lazy initializer in useState again avoids a server/client mismatch — computing window.matchMedia eagerly during the initial render would crash during SSR, exactly the same class of problem we solved in useLocalStorage.

Part 8: useIntersectionObserver — Lazy Loading and Scroll-Triggered Animation

function useIntersectionObserver(options = {}) {
  const [entry, setEntry] = useState(null);
  const elementRef = useRef(null);

  useEffect(() => {
    const node = elementRef.current;
    if (!node) return;

    const observer = new IntersectionObserver(([observedEntry]) => {
      setEntry(observedEntry);
    }, options);

    observer.observe(node);
    return () => observer.disconnect();
  }, [options.threshold, options.root, options.rootMargin]);

  return [elementRef, entry];
}

Usage for lazy-loading an image only when it scrolls into view:

function LazyImage({ src, alt }) {
  const [ref, entry] = useIntersectionObserver({ threshold: 0.1 });
  const isVisible = entry?.isIntersecting;

  return (
    <div ref={ref}>
      {isVisible ? <img src={src} alt={alt} /> : <div className="h-48 bg-slate-800" />}
    </div>
  );
}

This hook is a genuinely good example of hiding real complexity: the IntersectionObserver API itself is imperative and callback-based, entirely foreign to React's declarative style. Wrapping it in a hook translates that imperative browser API into a clean piece of derived state (entry) that a component can simply read.

Part 9: useEventListener — A General-Purpose DOM Event Hook

function useEventListener(eventName, handler, element = window) {
  const savedHandler = useRef(handler);

  useEffect(() => {
    savedHandler.current = handler;
  }, [handler]);

  useEffect(() => {
    const targetElement = element?.current ?? element;
    if (!targetElement?.addEventListener) return;

    const eventListener = (event) => savedHandler.current(event);
    targetElement.addEventListener(eventName, eventListener);

    return () => targetElement.removeEventListener(eventName, eventListener);
  }, [eventName, element]);
}

This uses the same savedHandler ref-for-latest-value pattern from useDebouncedCallback — critical here because otherwise, every time the consuming component re-renders with a new inline handler function (() => {...} defined directly in JSX, a very common pattern), the effect would tear down and re-attach the event listener on every single render, which is both wasteful and, in rare cases involving rapid re-renders, can cause missed events during the brief window of removal and re-attachment.

Usage:

function ResizeAwareComponent() {
  const [width, setWidth] = useState(window.innerWidth);
  useEventListener("resize", () => setWidth(window.innerWidth));
  return <p>Window width: {width}px</p>;
}

Part 10: usePrevious — Accessing the Previous Render's Value

function usePrevious(value) {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
}

This deceptively small hook is genuinely useful for comparing current and previous props or state — for example, detecting whether a value increased or decreased to conditionally show an "up" or "down" indicator:

function PriceDisplay({ price }) {
  const previousPrice = usePrevious(price);
  const direction = previousPrice != null && price > previousPrice ? "up" : "down";
  return <span className={direction === "up" ? "text-green-400" : "text-red-400"}>${price}</span>;
}

The reason this works is subtle and worth understanding fully: the useEffect (with no dependency array, so it runs after every render) updates ref.current to the current render's value — but effects run after the render completes. So during the render itself, ref.current still holds whatever was set during the previous render's effect. This timing gap between "what renders" and "when effects run" is exactly what makes usePrevious work.

Part 11: TypeScript — Making the Library Genuinely Safe to Reuse

A hook library without proper types is significantly less valuable in any serious codebase. Here's useLocalStorage fully typed with generics:

function useLocalStorage<T>(
  key: string,
  initialValue: T
): [T, (value: T | ((prev: T) => T)) => void] {
  const readValue = useCallback((): T => {
    if (typeof window === "undefined") return initialValue;
    try {
      const item = window.localStorage.getItem(key);
      return item ? (JSON.parse(item) as T) : initialValue;
    } catch {
      return initialValue;
    }
  }, [key, initialValue]);

  const [storedValue, setStoredValue] = useState<T>(readValue);

  const setValue = useCallback(
    (value: T | ((prev: T) => T)) => {
      const valueToStore = value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      window.localStorage.setItem(key, JSON.stringify(valueToStore));
    },
    [key, storedValue]
  );

  return [storedValue, setValue];
}

With this, useLocalStorage<boolean>("dark-mode", false) correctly infers that the setter only accepts a boolean or a function returning a boolean — TypeScript will flag setDarkMode("yes") as an error at compile time, before it ever becomes a runtime bug. This is the exact generics pattern discussed in the TypeScript-for-React article in this series, applied specifically to hook design.

Part 12: Testing Custom Hooks in Isolation

Hooks can't be called outside a component, which means testing them naively is awkward. The @testing-library/react package's renderHook utility solves this cleanly:

npm install --save-dev @testing-library/react

import { renderHook, act } from "@testing-library/react";
import { useToggle } from "./useToggle";

test("useToggle flips the boolean value", () => {
  const { result } = renderHook(() => useToggle(false));

  expect(result.current[0]).toBe(false);

  act(() => {
    result.current[1].toggle();
  });

  expect(result.current[0]).toBe(true);
});

renderHook mounts your hook inside a minimal, invisible test component internally, giving you result.current to inspect the hook's return value after each update. The act() wrapper is required around anything that triggers a state update — it ensures React fully flushes the update before your assertion runs, preventing flaky, timing-dependent test failures.

Testing useDebounce requires fake timers, since we don't want tests to actually wait 300ms in real time:

import { renderHook } from "@testing-library/react";
import { useDebounce } from "./useDebounce";

test("useDebounce delays the value update", () => {
  jest.useFakeTimers();
  const { result, rerender } = renderHook(({ value }) => useDebounce(value, 300), {
    initialProps: { value: "a" },
  });

  expect(result.current).toBe("a");

  rerender({ value: "b" });
  expect(result.current).toBe("a"); // still old value, timer hasn't fired

  act(() => jest.advanceTimersByTime(300));
  expect(result.current).toBe("b"); // now updated

  jest.useRealTimers();
});

This kind of test is exactly what catches regressions if someone later "simplifies" the hook and accidentally removes the debounce delay entirely — a genuine risk in any shared library as more people contribute to it over time.

Part 13: Composing Hooks Together

The real power of custom hooks shows up when you build higher-level hooks from the primitives you've already written. Here's a useDebouncedSearch hook built entirely by composing useDebounce and useFetch:

function useDebouncedSearch(query, delay = 400) {
  const debouncedQuery = useDebounce(query, delay);
  const url = debouncedQuery ? `/api/search?q=${encodeURIComponent(debouncedQuery)}` : null;
  return useFetch(url);
}

Three lines, zero new useEffect calls, zero new cleanup logic — because all of that complexity already lives inside useDebounce and useFetch. This composability is the payoff for the careful, encapsulated design discussed throughout this article. A poorly designed hook (one that leaks implementation details or has an awkward API) is painful to compose; a well-designed one nearly disappears into the next layer built on top of it.

Part 14: Common Pitfalls to Avoid

Forgetting cleanup functions. Every setTimeout, setInterval, event listener, or subscription started inside a useEffect needs a corresponding cleanup in the returned function. Skipping this is the single most common source of memory leaks and "why is this firing twice" bugs in custom hooks.

Including unstable references in dependency arrays. Passing a new object or array literal on every render, then including it in a useEffect dependency array, causes the effect to re-run every render regardless of whether the meaningful content actually changed. The optionsRef pattern from useFetch is the standard fix.

Returning too much from a single hook. If a hook returns eight loosely related values, that's a sign it's actually doing the job of two or three separate hooks and should be split for clarity and reusability.

Not handling the SSR case. Any hook touching window, document, or localStorage needs an explicit guard for server-side rendering environments, or it will crash Next.js/Remix apps during the server render pass.

Part 15: Structuring and Publishing the Library

Bringing all ten hooks together into a real, publishable package:

my-hooks/
  src/
    useLocalStorage.ts
    useDebounce.ts
    useDebouncedCallback.ts
    useFetch.ts
    useToggle.ts
    useMediaQuery.ts
    useIntersectionObserver.ts
    useEventListener.ts
    usePrevious.ts
    index.ts
  __tests__/
    useToggle.test.ts
    useDebounce.test.ts
  package.json
  tsconfig.json

// src/index.ts
export { useLocalStorage } from "./useLocalStorage";
export { useDebounce } from "./useDebounce";
export { useDebouncedCallback } from "./useDebouncedCallback";
export { useFetch } from "./useFetch";
export { useToggle } from "./useToggle";
export { useMediaQuery } from "./useMediaQuery";
export { useIntersectionObserver } from "./useIntersectionObserver";
export { useEventListener } from "./useEventListener";
export { usePrevious } from "./usePrevious";

Mark React as a peer dependency, not a direct dependency, since the consuming project already has its own React instance:

{
  "name": "@yourusername/react-hooks",
  "version": "1.0.0",
  "peerDependencies": {
    "react": ">=16.8.0"
  },
  "devDependencies": {
    "react": "^18.0.0"
  }
}

Building this with tsup (covered in depth in the npm publishing article in this series) produces both ESM and CommonJS outputs with generated type definitions, ready to npm publish.

Part 15.5: One More Pattern — useClickOutside

Dropdowns, modals, and popovers almost universally need to close when a user clicks outside their boundary. This is a small hook, but it demonstrates a technique not yet covered: attaching a listener to document while excluding clicks that originate from inside a specific ref'd element.

function useClickOutside(callback) {
  const ref = useRef(null);
  const callbackRef = useRef(callback);

  useEffect(() => {
    callbackRef.current = callback;
  }, [callback]);

  useEffect(() => {
    function handleClick(event) {
      if (ref.current && !ref.current.contains(event.target)) {
        callbackRef.current(event);
      }
    }

    document.addEventListener("mousedown", handleClick);
    return () => document.removeEventListener("mousedown", handleClick);
  }, []);

  return ref;
}

Usage:

function Dropdown({ onClose, children }) {
  const ref = useClickOutside(onClose);
  return <div ref={ref} className="absolute bg-slate-800 rounded-lg p-2">{children}</div>;
}

Two details worth calling out. First, mousedown is used instead of click — this matters because mousedown fires before mouseup/click, which means if the dropdown's own toggle button is what opened it, using click could cause a same-click open-then-immediately-close race, since the outside-click handler and the toggle handler might both fire for the same interaction depending on event bubbling order. Using mousedown avoids this specific timing collision in most real implementations. Second, this hook again uses the callbackRef latest-value pattern from Part 4 and Part 9 — by this point in the article, this pattern should feel familiar rather than mysterious, which is exactly the goal: once you've internalized why it's needed, you'll recognize the situations that call for it instinctively, rather than needing to look it up each time.

Part 16: A Real-World Example — Building useForm From These Primitives

Let's prove the composability claim with something substantial: a form-handling hook built entirely from patterns already covered in this article, plus a few new ones specific to form state.

function useForm(initialValues, validate) {
  const [values, setValues] = useState(initialValues);
  const [errors, setErrors] = useState({});
  const [touched, setTouched] = useState({});
  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = useCallback((name, value) => {
    setValues((prev) => ({ ...prev, [name]: value }));
  }, []);

  const handleBlur = useCallback(
    (name) => {
      setTouched((prev) => ({ ...prev, [name]: true }));
      if (validate) {
        const validationErrors = validate(values);
        setErrors(validationErrors);
      }
    },
    [values, validate]
  );

  const handleSubmit = useCallback(
    (onSubmit) => async (event) => {
      event.preventDefault();
      const allTouched = Object.keys(values).reduce(
        (acc, key) => ({ ...acc, [key]: true }),
        {}
      );
      setTouched(allTouched);

      const validationErrors = validate ? validate(values) : {};
      setErrors(validationErrors);

      if (Object.keys(validationErrors).length > 0) return;

      setIsSubmitting(true);
      try {
        await onSubmit(values);
      } finally {
        setIsSubmitting(false);
      }
    },
    [values, validate]
  );

  const reset = useCallback(() => {
    setValues(initialValues);
    setErrors({});
    setTouched({});
  }, [initialValues]);

  return { values, errors, touched, isSubmitting, handleChange, handleBlur, handleSubmit, reset };
}

Notice what this hook does not need to reimplement: debouncing validation calls (it could compose useDebouncedCallback around the validate call for expensive async validation), persisting draft form state (it could compose useLocalStorage to auto-save values on every change), or detecting whether the form has unsaved changes (it could compose usePrevious to compare values against the last saved state). This is the actual payoff of building a hook library methodically instead of writing one-off logic per project: a new, fairly complex piece of functionality like form handling becomes mostly composition, with very little genuinely new code.

Here's the auto-save composition made concrete:

function useAutoSaveForm(initialValues, validate, storageKey) {
  const [draft, setDraft] = useLocalStorage(storageKey, initialValues);
  const form = useForm(draft, validate);

  useEffect(() => {
    setDraft(form.values);
  }, [form.values]);

  return form;
}

Four lines on top of two existing hooks, and now every form using this pattern automatically persists drafts across page reloads and browser crashes — a feature that would otherwise require careful, hook-specific implementation.

Part 17: Performance Considerations Specific to Hook Libraries

A few performance details matter more in a shared hook library than in one-off component code, precisely because these hooks will be used dozens or hundreds of times across a real application.

Stabilize returned functions with useCallback. Every hook in this library that returns a function (toggle, setValue, handleChange) wraps it in useCallback. This isn't optional polish — if a consuming component passes toggle down to a React.memo-wrapped child (the pattern discussed in the React performance article in this series), an unstabilized function reference defeats that child's memoization on every single render of the parent, silently undoing an optimization the consumer thought they had.

Avoid creating new objects in the hook's return value on every render. Returning { toggle, setTrue, setFalse } as a fresh object literal on every render (even if the three functions themselves are individually memoized) still creates referential inequality for the object itself, which matters if a consumer passes that whole object as a prop to a memoized child. For hooks with more than one or two returned actions, consider memoizing the returned object itself with useMemo if you know it's likely to be passed as a single prop elsewhere.

function useToggle(initialValue = false) {
  const [value, setValue] = useState(initialValue);
  const toggle = useCallback(() => setValue((v) => !v), []);
  const setTrue = useCallback(() => setValue(true), []);
  const setFalse = useCallback(() => setValue(false), []);

  const actions = useMemo(() => ({ toggle, setTrue, setFalse }), [toggle, setTrue, setFalse]);

  return [value, actions];
}

Be deliberate about effect dependency granularity. In useIntersectionObserver, notice the dependency array uses options.threshold, options.root, options.rootMargin individually rather than the whole options object. This is intentional — depending on the whole object would cause the observer to be torn down and recreated on every render where the consumer passes a fresh object literal (an extremely common pattern), even when the actual threshold values never changed.

Frequently Asked Questions

Should every piece of reusable logic become a custom hook? No. If the logic is genuinely only used in one component and unlikely to be reused, extracting it into a separate hook adds an indirection cost without a corresponding reuse benefit. Extract a custom hook once you have a second real use case, or when a single component's logic has grown complex enough that separating it improves readability even without reuse.

Can custom hooks call other custom hooks? Yes, and this is exactly the composability demonstrated in useDebouncedSearch and useAutoSaveForm above. This is one of the biggest advantages hooks have over the older HOC pattern, where composing multiple HOCs together created deeply nested wrapper components that were painful to debug in React DevTools.

Do I need to prefix every internal helper function with use? No — only functions that actually call other hooks internally need the use prefix, because that's what signals to React's linter (eslint-plugin-react-hooks) and to other developers that the Rules of Hooks apply to this function. A regular helper function that doesn't call useState, useEffect, or any other hook should not be prefixed with use, since doing so misleadingly implies hook rules apply to it.

How many hooks are too many for one library? There's no fixed number, but organize by domain once you exceed roughly 15-20 hooks — separate packages or clearly divided folders for form-related hooks, data-fetching hooks, and browser/DOM hooks, rather than one flat, unorganized list that becomes hard to discover and document.

Conclusion

Every hook in this library follows the same underlying philosophy: hide complexity, expose a minimal API, and design for composability. Once you've internalized these eleven patterns — persistent state, debouncing (both value and callback variants), safe data fetching with cancellation, responsive queries, intersection observation, general event handling, click-outside detection, and previous-value tracking — you have the actual building blocks needed to solve the vast majority of stateful logic problems that come up in real frontend projects, without reaching for a third-party library every time. And because you understand exactly why each line exists, not just what it does, you're equipped to design entirely new hooks for problems this article never covered, using the same underlying principles: hide the imperative complexity, expose a small and predictable surface area, and make sure the pieces compose cleanly with one another.

It's also worth connecting this back to the rest of this series deliberately. The AbortController pattern in useFetch is the same defensive technique that matters when integrating AI APIs, covered in the chatbot integration article — a slow AI response racing against a component unmount or a rapidly changing conversation ID is exactly the same race condition useFetch prevents for ordinary data fetching. The TypeScript generics applied to useLocalStorage here are a direct, practical application of the discriminated-union and generic-component patterns from the TypeScript-for-React article. And the discipline of profiling before optimizing, discussed at length in the React performance article, applies just as much to a shared hook library as it does to individual components — don't add useMemo around your returned action objects until you've actually confirmed a memoized child is being defeated by referential inequality, rather than adding it reflexively to every hook in the library "just in case."

If you build and genuinely use even half of these hooks across a real project, you'll notice a concrete shift in how you approach new features: instead of asking "how do I write this logic," you'll increasingly ask "which of my existing hooks can I compose to get most of this for free," which is the actual mark of a mature, well-designed personal toolkit rather than a pile of one-off utility functions.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Fahan

Why You Are Not Getting Better as a Developer (And Why Courses Won't Fix It)

Wed, 29 Apr 2026 15:05:54 +0000

The Loop That Keeps Most Developers Stuck

You have the courses. You have the bookmarks. You have the "must watch" videos saved to watch later.

And still. You are not improving.

Not in any way that actually shows up in your work or your confidence.

Here is the hard truth. It was never a knowledge problem.

The Cycle You Cannot Break

It starts the same way every time.

New course. New energy. New plan.

You tell yourself, "This time I am doing it properly."

Day one is focused. Day two is still good. Day three gets busy. Day four you skip. Day five you tell yourself you will restart next week.

And just like that, you are back to scrolling and watching. You are "learning" but not really building.

Weeks pass. Sometimes months.

The worst part is that you already know what to do. That is what makes it so frustrating.

Why Another Course Will Not Save You
Most developers think they need a better course or a different tech stack. They think they are not ready yet.

But deep down, you already know the truth.

Every time you actually sat down and wrote code, even for 30 minutes, you made progress. Small progress. But real progress.

The problem is not learning. The problem is showing up consistently enough for that learning to compound.

You do not get better with six hour binge sessions once a month. You get better with 20 minutes every day, even when it feels boring.

The Uncomfortable Realization

Here is what no one really emphasizes.

Consistency is not exciting. It is repetitive. Quiet. Sometimes frustrating.

But it is the only thing that works.

Intense sprints feel productive, but they do not build real skill. Small daily actions do, because they force your brain to rewire instead of just cramming information.

Why Consistency Feels So Hard

The advice sounds simple. Just code every day.

But in reality, you run into specific problems.

You do not know what to work on each day. You overthink which topic to learn next. You set goals that are too big. You lose all momentum after missing just one day.

So you end up trapped in the same loop.

Start. Stop. Restart. Repeat.

And every restart feels heavier than the last.

What Actually Helps

At Coder Legion, we stopped thinking in terms of "I need to improve."

Instead, we started thinking, "I need a system that makes showing up easy."

Not perfect. Just easy.

A system that removes decision fatigue, overthinking, and randomness. Because willpower alone does not last. Structure does.

One Small Shift That Changes Everything

Stop telling yourself, "I will study when I have time."

Start telling yourself, "This is something I do daily, even if it is just 20 minutes."

That shift sounds small, but it changes your identity. You are no longer someone who tries to learn coding. You are someone who shows up consistently.

The Part Most Developers Skip

Everyone wants results. Better skills. A better job. More confidence.

But very few people build the one thing that actually leads there.

A simple, repeatable system they can stick to. Not for three days. Not for two weeks. But long enough to see real change.

That is why we built something for the Coder Legion community.

Free Download For Coder Legion Readers

The 30 Day Coding Consistency Tracker

This tracker gives you a simple daily 20 minute prompt. No decision fatigue. No overthinking. Just show up and code.

Get the free tracker here

If You Feel Stuck, Read This

You are not stuck because you are not smart enough. You are not stuck because you chose the wrong path. You are not stuck because you need another course.

You are stuck because your effort is inconsistent.

And inconsistent effort does not compound.

What To Focus On Instead
Do not aim for perfect days.

Aim for showing up. Aim for doing something small. Aim for not breaking the chain.

That is it.

It will not feel impressive at first. But give it a few weeks, and you will notice something.

You are not restarting anymore. You are progressing.

That is when things finally start to change.

Your Next Step

You already know what to learn. You do not need another course.

You need a system.

Here is what to do right now.

Download the free tracker. Commit to 20 minutes today. Put it somewhere visible and mark each day with an X.

Claim your free 30 Day Consistency Tracker from Coder Legion

No email required. Just the system you have been missing.

Architect's Log: AWS S3 Learning

Fri, 24 Apr 2026 10:30:51 +0000

I’ve been documenting my learning journey with Amazon Web Services—and this time, it’s S3.
Here are a few things that finally clicked for me:

ARCHITECT’S LOG | Episode 09: The Infinite Storage

"If AWS is a city, S3 is the warehouse that never runs out of space."
Before we dive into networking, we have to master Amazon S3 (Simple Storage Service). It’s the backbone of the cloud whether you're hosting a static website, storing logs, or building a massive data lake.

Here is why S3 is foundational to any architecture:

Buckets & Objects: The Basics
Think of S3 as a global file system:
Buckets: Your root containers. Remember: bucket names must be globally unique across all of AWS!
Objects: Your files. Each object can be up to 5TB, and you can store an unlimited number of them. This can be either as a file name or a folder path + file name. Example: file.txt, folder/file.txt.
Durability vs. Availability ️
AWS designed S3 for "11 nines" of durability (99.999999999%). This means your data is effectively "safe for life." Availability is then managed by choosing the right class to balance speed and cost.
The 6 Storage Classes (The Architect’s Toolkit)
An architect’s job is to optimize cost by matching the data to the right tier:

S3 Standard: Best for "Hot Data" accessed frequently with millisecond latency.

S3 Express One Zone: High-performance, single-zone storage for AI/ML workloads requiring single-digit millisecond latency.

S3 Standard-IA: Infrequent Access; lower cost for data accessed monthly.

S3 Intelligent-Tiering: The "set it and forget it" tier that automatically moves data to cheaper classes based on access patterns.

S3 Glacier Instant Retrieval: High-performance archiving for data needed in milliseconds but accessed rarely (e.g., medical records).

S3 Glacier Deep Archive: The ultimate low-cost option for long-term compliance data that can take 12–48 hours to retrieve.

Security: Locked Down
By default, all new buckets are private. We use Bucket Policies for resource-level access and IAM Policies for user-level permissions to ensure only the right identities touch our data.

https://www.linkedin.com/posts/opeyemi-ogunsanya_aws-cloudarchitecture-s3-share-7453292163850829824-nMEC

If this was helpful, feel free to react so I know to share more like this , it's also on linkedin

Python for Absolute Beginners: From Zero to Writing Real Code

Sat, 21 Feb 2026 13:16:05 +0000

Python for Absolute Beginners: From Zero to Writing Real Code

Python is one of the simplest and most powerful programming languages ever created.
If you’re new to programming, Python is the best place to start—not because it’s “easy”, but because it lets you focus on thinking, not fighting syntax.

This tutorial assumes:

❌ No coding experience
❌ No computer science background
✅ Curiosity

Let’s begin.

1. What Is Python, Really?

Python is a high-level programming language.

That means:

You write instructions in human-readable English-like syntax
Python translates them into something the computer understands
You don’t need to manage memory, registers, or hardware

Example:

print("Hello, world!")

That’s a real program.

Python is used in:

Web development
AI & Machine Learning
Automation & scripting
Data science
Game development
Cybersecurity
Scientific research

2. Installing Python

Windows / macOS / Linux

Go to python.org
Download Python 3.x
During installation (important!):
- ✅ Check “Add Python to PATH”

Check installation

Open terminal / command prompt:

python --version

If it prints something like:

Python 3.12.1

You’re ready.

3. Your First Python Program

Create a file called:

hello.py

Write this:

print("Hello, Python!")

Run it:

python hello.py

You just executed your first Python program.

4. How Python Thinks (Very Important)

Python executes code line by line, from top to bottom.

print("First")
print("Second")
print("Third")

Output:

First
Second
Third

There is no magic.
Just instructions.

5. Variables: Storing Information

A variable is a label for data.

age = 18
name = "Prasoon"
height = 5.9

Python automatically understands the type.

Common data types

int     # whole numbers → 1, 10, -3
float   # decimal numbers → 3.14
str     # text → "hello"
bool    # True or False

Example:

is_student = True

6. Printing and Input

Printing values

name = "Alex"
print(name)

Taking input from user

name = input("Enter your name: ")
print("Hello", name)

⚠️ input() always returns a string

Convert when needed:

age = int(input("Enter your age: "))

7. Basic Math in Python

a = 10
b = 3

print(a + b)   # addition
print(a - b)   # subtraction
print(a * b)   # multiplication
print(a / b)   # division
print(a // b)  # floor division
print(a % b)   # remainder
print(a ** b)  # power

8. Conditions: Making Decisions

Python uses if, elif, else

age = int(input("Enter your age: "))

if age >= 18:
    print("You are an adult")
else:
    print("You are a minor")

Important rule

Python uses indentation, not brackets {}

❌ Wrong:

if age > 10:
print("Hi")

✅ Correct:

if age > 10:
    print("Hi")

9. Loops: Repeating Work

for loop

for i in range(5):
    print(i)

Output:

while loop

count = 0

while count < 5:
    print(count)
    count += 1

Use while when you don’t know how many times you’ll loop.

10. Lists: Storing Multiple Values

numbers = [1, 2, 3, 4, 5]

Access items

print(numbers[0])   # first element
print(numbers[-1])  # last element

Modify list

numbers.append(6)
numbers.remove(3)

Loop through list

for num in numbers:
    print(num)

11. Dictionaries: Key–Value Data

student = {
    "name": "Aarav",
    "age": 17,
    "grade": "A"
}

Access values:

print(student["name"])

Add new key:

student["city"] = "Delhi"

12. Functions: Reusable Code

Functions prevent repetition.

def greet(name):
    print("Hello", name)

Call it:

greet("Prasoon")

With return value:

def add(a, b):
    return a + b

result = add(3, 5)
print(result)

13. Errors Are Normal (Don’t Panic)

Example error:

print(x)

Output:

NameError: name 'x' is not defined

This means:

Python tried
It failed
It told you exactly why

Errors are teachers, not enemies.

14. Simple Real Project: Number Guessing Game

import random

secret = random.randint(1, 10)

while True:
    guess = int(input("Guess a number (1–10): "))

    if guess == secret:
        print("Correct! ")
        break
    else:
        print("Try again")

This uses:

variables
loops
conditions
input/output

You’re officially programming.

15. What to Learn Next

After this tutorial:

Learn modules & packages
Learn file handling
Learn OOP (classes & objects)
Pick a direction:
- Web → Flask / Django
- Data → Pandas / NumPy
- Automation → Scripts
- AI → PyTorch / TensorFlow

Final Advice (Read This Twice)

Don’t chase languages.
Chase thinking clearly.

Python is not just a tool—it’s a way to train your mind to break problems into logic.

Write bad code.
Break things.
Fix them.

That’s how programmers are born.

Integrating Third Party APIs Made Easy

Fri, 20 Feb 2026 17:45:43 +0000

Integrating third-party APIs can breathe new life into your applications, making them more dynamic and engaging. Whether you're pulling in weather data, payment processing, or social media feeds, using these APIs effectively can elevate your project. This tutorial will walk you through the essential steps for integrating and utilizing third-party APIs with a focus on simplicity and practicality.

Understanding APIs

APIs (Application Programming Interfaces) allow different software applications to communicate. Using a third-party API means you're leveraging the capabilities of another service, saving time and effort in development.

Selecting the Right API

Before you start coding, choose an API that suits your project’s needs. For example:

Weather APIs like OpenWeatherMap for real-time weather updates.
Social Media APIs like Twitter API for user engagement.
Payment APIs like Stripe for hassle-free transactions.

Getting Access

Most APIs require an API key for authentication. This is usually found in your account settings on the API provider's website. Always keep this key secure to prevent unauthorized access.

Making Requests

Once you've obtained your API key, you can start making calls to the API. Here is a simple example of how to fetch weather data using fetch in JavaScript:

const apiKey = 'YOUR_API_KEY';
const city = 'London';

fetch(`https://api.openweathermap.org/data/2.5/weather?q=${city}&appid=${apiKey}`)
  .then(response => response.json())
  .then(data => {
    console.log(`Temperature in ${city}: ${data.main.temp}K`);
  })
  .catch(error => console.error('Error fetching data:', error));

Parsing Responses

APIs typically return data in JSON format. Use JavaScript's JSON.parse to convert the response into an object you can work with. This will allow you to manipulate or display the data as needed.

Handling Errors

Don't forget to handle errors gracefully. APIs can fail for various reasons, including exceeding usage limits or incorrect parameters. Implementing basic error handling ensures a better user experience.

if (!response.ok) {
  throw new Error('Network response was not ok');
}

Practical Example

Suppose you're building a random quote generator. You might use the They Said So Quotes API. Here’s how you’d integrate it:

fetch('https://quotes.rest/qod')
  .then(response => response.json())
  .then(data => {
    const quote = data.contents.quotes[0].quote;
    console.log(`Random Quote: ${quote}`);
  });

Conclusion

Integrating third-party APIs doesn’t have to be daunting. By following these steps, you can enhance your applications with dynamic functionalities. Always test your integration thoroughly and refer back to API documentation for advanced options. Happy coding!

Feel free to ask any questions or share your experiences with API integrations below. Let's make our apps chill and engaging together!

Understanding Awaitables: Coroutines, Tasks, and Futures in Python

Mon, 24 Mar 2025 18:58:34 +0000

Previously, we explored chatbot building with AsyncIO. As I am committing to publish one article a week, I am constantly on the lookout for new ideas. Then I figured it may be a good opportunity to delve deeper into asynchronous programming. The writing plan eventually expanded to a series of articles, and we are starting with the concept of Awaitables today.

An illustration from copilot on the topic

To a lot of us, our first exposure to something resembles asynchronous programming would be learning to write GUI applications. A graphical application usually responds to user events, that may happen any time while it is running. We then attach a handler function to events we are interested in, however we do not have much control when it is executed.

The JavaScript Prelude: From Callbacks to Promises

Photo by Womanizer Toys on Unsplash

I first learned programming when I was in college. The assignments were designed to train us to write code with a set of a controlled scope. I graduated in the era of web 2.0, that’s when people started to explore AJAX to add dynamic behaviour to web pages. Suddenly, despite we were plagued with inconsistencies among browser’s JavaScript implementation, webpages started to feel like a GUI application.

AJAX, which is a short for Asynchronous JavaScript and XML, opens up the possibility for us to fetch data from a web server through JavaScript. With proper use, we can get a page to fetch additional information to update the page content, responding to various events defined in the document object model, DOM. Some examples of DOM events are, clicking on elements in page, elements loaded in page, or even timed events through setInterval and setTimeout.

Despite having some experience with GUI application programming, but doing it in real enterprise setting feels very different. I was still too used to structured procedural programming, where code execution is often synchronous, in a mostly predictable order. However, when it comes to an enterprise setting, the requirements are constantly changing and time is often a luxury we cannot afford. Despite having good mentor, it still took me quite a while to have a basic grasp of asychronous programming with the delicate language construct at the time.

Let's start with event handlers. Everything we see in a web page, is represented in a Document Object Model (DOM) tree, and each element is capable of responding to events. For instance, we can click on a button, and have it pop up an alert dialog through a code snippet below.

# In HTML markup
<button id="theButton">The button</button>

# In JavaScript
const button = document.getElementById("theButton")
button.addEventListener((e) => window.alert("Button is pressed"))

Then we have callbacks, which were popularized by AJAX calls. Back then, with jQuery, we could define handlers to deal with both success or failure cases. For instance, let's say we want to fetch the HTML markup of this blog (skipping error failure callback for brevity), we do

$.ajax({
    url: "https://kitfucoda.medium.com/",
    success: (data, status, xhr) => { /* process data here */ }
})

It is worth noticing that both the event handler and the success callback we defined earlier, can only access variables that were defined before their definition. The handler and callback would have no access to new external variables. On the other hand, the code outside the callback and handler do not have access to variables within them. Essentially, we can treat the code being executed separately, completely breaking off from the normal execution flow. Therefore, we do not have a way to tell if they are executed, or when they are done (or failed).

It is also possible to combine the two together. For example, combining the two examples above, we can make the page to fetch this blog after clicking on the button.

button.addEventListener(
    (e) => $.ajax({
        url: 'https://kitfucoda.medium.com',
        success: (data, status, xhr) => { /* maybe populate this somewhere */ }
    })
)

Remember we talked about how it is not possible to know if these handlers are done executing from the outside? Yes, nesting them was the only way to ensure order. If you need to fetch my other blog https://cslai.coolsilon.com AFTER finishing fetching this blog, you can do another $.ajax call within the success handler above. The growing nested callbacks eventually led to what people call a callback hell or pyramid of doom.

I didn’t follow the development of JavaScript much, as I moved on to doing Python. However we eventually had Promise, and my first encounter with it was again through jQuery. Now, it is possible to write a sequence of AJAX calls in a chain, instead of nesting endlessly. For instance

$.ajax({url: 'https://kitfucoda.medium.com/'})
    .then((response) => {
        // do something with the response
        // Now start a new ajax
        return $.ajax({url: 'https://cslai.coolsilon.com/'})
    })
    .then((response) => {
        // Do other thing with the response
    })

No more pyramid of doom, but the callback and the code outside of it still remained separate and independent to each other.

Enter AsyncIO: Awaitables Defined

My exploration of asynchronous programming in Python, was just as chaotic. When I was working for a company that offers CDN service, I spent some time learning about gevent and greenlets. It was practically my first introduction to the asynchronous world in the language. However, I left the company soon after that and didn’t have a chance to see it in action. Years later, I hacked a chatbot that barely worked, and also did a quick exercise building an ASGI websocket chatroom, without use of any frameworks. While I managed to do it, but it wasn’t a useful introduction to AsyncIO.

This article, like the one I did on chatbot, is an article I wished I read back then.

Coroutines: The Foundation of Awaitables

Photo by Kelly Sikkema on Unsplash

As a prologue to the article I am writing next week, we cover Awaitables this week in the context of AsyncIO. Understanding what they are is core to understanding how to program with AsyncIO. However, before we start, let’s talk about coroutines. A coroutine is a function defined with an async keyword. Note that if a function has any async or await statement, it has to be defined as a coroutine.

# a normal coroutine
async def a_coroutine():
    return 42

# this is invalid
def this_should_be_a_coroutine():
    await some_awaitable()
    return 42

We often write functions doing heavy IO-bound work as coroutines, such that other CPU bound computation can still take place simultaneously. To execute these coroutines, we would need an event loop. Despite the name, I prefer seeing it as a timetable like structure, a place where it accepts Awaitables (like coroutines) to be scheduled to run.

Let’s slowly build a fictional project, as a tool to explore more about asyncio in this series of articles. We start by defining a coroutine that simulates I/O operations, and use httpx to make HTTP requests. Given a national Pokédex ID, we want to return the name of the corresponding Pokémon.

async def dex(id: int) -> str:
    assert isinstance(id, int)

    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://pokeapi.co/api/v2/pokemon/{id}/")

        return f"The pokemon with id {id} is {response.json()['name']}"

When a coroutine is called like how a function is called, it returns a Coroutine object. The returned object is still pending scheduling, hence the code isn’t executed at this point. If the coroutine does not get a chance to run, e.g. when the function calling the coroutine exits, dropping the reference to it.

The quickest way to fix it is prefixing an await before it. However, like we discussed earlier, if a function contains an await, then it has to be defined as a coroutine with async. Therefore, going asynchronous usually means an all-in commitment. This also means porting code part-by-part to be asynchronous takes enormous effort.

Using await is a way to schedule a coroutine to the event loop. The behaviour is similar to synchronous programming, it will attempt to start the execution as soon as possible, and will only execute the next line after a result is returned. But there are times we want to have more control, and that’s achieved by turning it to a task.

Tasks: Scheduling and Managing Coroutines

Photo by airfocus on Unsplash

A task can be created, by passing in the coroutine object to asyncio.create_task. It returns a asyncio.Task object referencing the scheduled coroutine. Some control is offered through the returned Task object, for example we can check if it is done, cancel the execution, or set a callback when done.

 task = asyncio.create_task(dex(6))

Photo by Halfcut Pokemon on Unsplash

Unlike the await keyword, you can call asyncio.create_task even in a function, as long as an event loop is available and running. However, being an awaitable object, you can also block execution for subsequent statements with an await too, in a coroutine. However, it is typically used when you only want to revisit the state of execution later (or forget about it).

async def foo() -> str:
    task = asyncio.create_task(dex(104)

    # proceed with other work

    return await task

Photo by Branden Skeli on Unsplash

Futures: Representing Asynchronous Results

Photo by Zulfa Nazer on Unsplash

Next, we have Futures, which is the parent class of the Task we just discussed. I personally find this tricky to explain, but while preparing for the article, I was informed that a future works the way a callback does (still remember?). Let’s say I have a very badly defined function to calculate nth Fibonacci number to simulate a CPU-bound operation

def fibonacci(nth: int) -> int:
    assert nth > 0

    result = ()

    for i in count(1):
        match i:
            case 1:
                result = (0,)

            case 2:
                result += (1,)

            case _:
                result = result[1:] + (sum(result),)

    assert len(result) > 0

    return result[-1]

Asynchronous programming is useful in scenario with a lot of I/O operations. It ensures concurrency by making it possible for CPU-bound operations to work, while waiting for I/O. However, if a CPU-bound operation is taking forever, it would end up stalling everything else. Hence, it is advisible to throw the work to another thread or process. We can use loop.run_in_executor to create an asyncio.Future object to offload the work to another thread.

future = (
    asyncio.get_running_loop()
        .run_in_executor(None, partial(fibonacci, 1500))
)

The first argument can take either a ThreadPoolExecutor or a ProcessPoolExecutor, leave it as None to use the default ThreadPoolExecutor. The second argument takes a callable, we could have rewrite fibonacci with __call__ dunder as discussed in the previous article, but using functools.partial is fine.

Alternatively we can use asyncio.to_thread which is an helpful abstraction to avoid creating a Future ourselves. However, it returns a coroutine, so it has to be awaited, or scheduled as a Task via asyncio.create_task. Also, unlike loop.run_in_executor, we do not get to choose between a ThreadPoolExecutor or ProcessPoolExecutor.

coro = asyncio.to_thread(fibonacci, 1000)

# Schedule it for execution
asyncio.create_task(coro)

# Or await directly
await coro

But we haven’t show how callbacks are possible with Futures. Let’s write a simpler example on this topic. Suppose we have a coroutine that has to be run concurrently in the background, streaming a file content over the internet, and we are interested in finding the line number of a specific line in it.

async def scan_huge_file(future, need_this_line):
    for line_num, line in enumerate(some_huge_file()):
        if line is need_this_line:
            future.set_result(line_num)

Then, when we schedule the tasks (again, we will dive deeper on this in the next article), we would have done something like this.

loop = asyncio.get_running_loop()
future = loop.create_future()

asyncio.create_task(scan_huge_file(future, 'very critical line'))

# do other high-priority tasks
...

# when we are finally done with other tasks
number = await future

The callback is done in scan_huge_file, through future.set_result. The function scheduling the coroutine, only checks if a line number is found, after it is done with other tasks. Of course we could have save a reference to the asyncio.create_task, and then make scan_huge_file return the line number so we can await the task, but this is just to show how a callback can be implemented.

Now we know the three Awaitables, it is time to revisit what it is. As you may have guessed, it is just a term to describe these three types of objects, where we can use await to get the result.

Python vs. JavaScript: Comparison

Photo by Oleksandr Chumak on Unsplash

Asynchronous programming in JavaScript modelled the problem very differently, and hence we have a complete different design. We stopped at Promise just now, and we briefly discussed that because it is the root of the implementation.

AsyncIO is doing a good job abstracting the event loop away from the users. For instance, we only started to call event loop methods, when we were discussing about Futures. The development experience is getting so much better that using await directly to the coroutine, or to the Task (which wraps a coroutine) should be sufficient for most cases.

OTOH, event loop in JavaScript, at least in browser, is almost completely abstracted away from us.

A friend came to me a few days ago, complaining how he is confused about asynchronous programming in the language. Why certain asynchronous functions were called with an await but some without. That prompted me to do a quick check on the topic, and I was quite surprised with the discovery. It turns out if I call an asynchronous function without using await, it will be scheduled in the background.

The discussion session was the main inspiration to this article, sans the Python part. I started with how event handlers led to creation of callbacks, Promise, and ultimately joining the async-await family. Similar to Python, if a function contains any async or await statement in it, then it has to be defined as async.

While on the surface both share similar syntax, but the underlying implementations are completely different. In Python asynchronous was designed around coroutines, while in JavaScript was through Promise. I hope by weaving examples from both language it helps to clarify doubts on the matter.

Looking Ahead: More AsyncIO

Photo by Andrew Ly on Unsplash

Originally I was about to write on schedule and manage tasks, alongside notes on error handling through a fictional project. However, after planning out the content, just Awaitables alone would be long enough for the week. Hence, we would start building a fictional project next week, and discuss the above mentioned topics. Feel free to subscribe to the email newsletter so you don’t miss it, and leave me messages if I have missed anything today.

Thanks for reading, and I shall write again, next week.

For transparency, I’d like to acknowledge that while the code and technical explanations presented in this article are entirely my own, I received editorial assistance from a large language model. This collaboration has helped refine the clarity and structure of my writing. If you’re interested in discussing project collaborations or job opportunities, please feel free to reach out to me here on Medium or via my LinkedIn profile. The article was originally published to Medium.

Coder Legion - Recent posts tagged tutorials

SEO Basics Every Frontend Developer Should Know

Introduction

1. Semantic HTML (This Matters More Than You Think)

Rules to follow:

2. Meta Tags (The Basics Actually Matter)

3. Image Alt Text

4. Page Speed (A Direct Ranking Factor)

5. Mobile-Friendliness

6. Clean, Descriptive URLs

7. Internal Linking

8. Structured Data (Optional but Powerful)

Common Beginner Mistakes

Final Thoughts

How I Landed My First Freelance Client as a Frontend Developer

Introduction

Where I Started

What Didn't Work

What Actually Worked

1. I Stopped Applying Blind and Started Researching the Client First

2. I Led With a Live Demo, Not Just a Portfolio Link

3. I Asked for a Testimonial Immediately After Finishing

4. I Treated the First Project as a Portfolio Investment, Not Just a Paycheck

What I'd Tell Beginners Specifically

Final Thoughts

Common CSS Mistakes Beginners Make (and How to Fix Them)

Introduction

1. The Box Model Confusion

2. Margin Collapse

3. Overusing !important

4. Not Understanding position: absolute

5. Fighting Flexbox/Grid Instead of Reading the Docs

6. Not Resetting Default Browser Styles

7. Specificity Wars from Nested Selectors

Final Thoughts

JavaScript ES6+ Features Every Frontend Developer Should Master

Introduction

1. Arrow Functions

2. Destructuring

3. Spread and Rest Operators (...)

4. Template Literals

5. Optional Chaining (?.)

6. Nullish Coalescing (??)

7. Array Methods: map, filter, reduce

Common Beginner Mistakes

Final Thoughts

CSS Animations for Beginners: Transitions, Keyframes & Transforms

Introduction

1. Transitions — Smoothing Out State Changes

2. Transform — Moving, Scaling, Rotating

Common transform values:

3. Keyframes — Multi-Step Animations

Putting It Together: A Real Example

Common Beginner Mistakes

Final Thoughts

How to Build Your First React Component (Step-by-Step)

Introduction

Step 1: Understand What a Component Actually Is

Step 2: Build the Static Version First

Step 3: Make It Reusable with Props

Step 4: Render a List of Them

Step 5: Add a Bit of Interactivity (Optional)

Common Beginner Mistakes

Final Thoughts

Responsive Design 101: How to Make Any Website Mobile-Friendly

Introduction

Mobile-First: Start Small, Then Grow

Understanding Breakpoints

Flexible Units Over Fixed Pixels

Responsive Images

Testing Your Responsive Design

Common Beginner Mistakes

Final Thoughts

Building a Custom React Hook Library From Scratch (Complete Guide)

Introduction: Why Hooks Deserve This Much Attention

Part 1: The Rules of Hooks, and Why They Exist

Part 2: Anatomy of a Good Custom Hook

Part 3: useLocalStorage — State Synced to Persistent Storage

Part 4: useDebounce and useDebouncedCallback — Two Related but Different Hooks

Part 5: useFetch — Data Fetching With Cancellation, Caching, and Retry

3. Overusing `!important`

4. Not Understanding `position: absolute`