Stop Maintaining Manual Skeletons in React

Olebogeng Mbedzi — Tue, 20 Jan 2026 22:24:57 +0000

If you've built a React application recently, you've likely implemented "Skeleton Screens": those gray, pulsating boxes that signify content is loading.

They provide a great user experience, but a terrible developer experience.

The Problem: The "Twin Component" Trap

To implement a skeleton correctly, you typically create a separate component (e.g., <UserCardSkeleton />) that visually mimics your real component.

// The Real Component
const UserCard = ({ user }) => (
  <div className="p-4 rounded-xl border flex gap-4">
    <img src={user.avatar} className="w-12 h-12 rounded-full" />
    <div>
      <h2 className="text-lg font-bold">{user.name}</h2>
      <p className="text-gray-500">{user.role}</p>
    </div>
  </div>
);

// The Skeleton (The "Twin")
const UserCardSkeleton = () => (
  <div className="p-4 rounded-xl border flex gap-4">
    <div className="w-12 h-12 rounded-full bg-gray-200 animate-pulse" />
    <div>
      <div className="h-4 w-32 bg-gray-200 rounded mb-2 animate-pulse" />
      <div className="h-3 w-24 bg-gray-200 rounded animate-pulse" />
    </div>
  </div>
);

This works fine... until you change the design.

Scenario: You decide to move the avatar to the right side.
Result: You update <UserCard />. But if you forget to open <UserCardSkeleton />, your users see a jarring "layout shift".

You are effectively maintaining two UIs for every one component.

The Solution: Runtime DOM Measurement

What if the code could just look at our component and figure it out?

I built a library called shimmer-from-structure to do exactly that.

How it works

Instead of creating a skeleton, you wrap your real component in a <Shimmer> provider and pass it some mock data.

import { Shimmer } from 'shimmer-from-structure';

// 1. Define loading data structure
const userTemplate = {
  name: 'Loading Name...',
  role: 'Loading...',
  avatar: '/placeholder.png'
};

function Option() {
  return (
    // 2. Wrap your component
    <Shimmer 
      loading={isLoading} 
      templateProps={{ user: userTemplate }}
    >
      {/* 3. Render your REAL component */}
      <UserCard user={user || userTemplate} />
    </Shimmer>
  );
}

When loading={true}:

The library renders your UserCard with transparent text.
It uses useLayoutEffect to measure the DOM geometry.
It finds every img, text, and button node.
It overlays a pixel-perfect shimmer animation.

Why this is better

Zero Maintenance: If you move the avatar to the right, the shimmer automatically moves to the right.
Pixel Perfect: The skeleton matches the exact height/width of your text content.
Visual Stability: It preserves container backgrounds and borders.

Try it out

You can install it from NPM:
npm install shimmer-from-structure

Repo: https://github.com/darula-hpp/shimmer-from-structure

I'd love to hear your feedback in the comments! 👇

I built a tool to find where React components come from — even in big Next.js projects

Olebogeng Mbedzi — Tue, 11 Nov 2025 19:00:23 +0000

I built a tool to find where React components come from — even in big Next.js projects

Have you ever stared at a React component in the browser and thought:

“Wait… which file does this element come from again?”

That was me, almost daily, while working on large Next.js and Vite projects.

So I built react-source-lens — a small developer tool that lets you hover over any React element and instantly see the file path and line number where it was defined.

🎯 The problem

When debugging complex React apps, you often end up in this loop:

See a button, card, or modal in the browser.
Open DevTools → Components tab.
Try to guess which file it came from.
Switch to VS Code → search → open → check.
Repeat.

It’s slow, context-breaking, and frustrating — especially in large codebases with nested components.

💡 The idea

React internally stores a “Fiber tree” that connects each rendered element to its component function.

I realized that if I could read that Fiber tree and correlate it to source metadata, I could display file info right in the browser — no guessing, no searching.

So that’s what react-source-lens does.

⚙️ How it works

It traverses React’s internal Fiber tree to get component display names.
It uses optional metadata (if available) to map those components to their file paths.
Optionally, you can enable a lightweight Babel plugin that injects file + line info during build time for 100% accuracy.

🧠 I initially tried building an SWC plugin for Next.js, but ran into compatibility issues — so I started with Babel since it’s widely supported.

🚀 Quick start

Install it in your dev environment:

npm install react-source-lens --save-dev

Then wrap a part of your app:

import { useReactSourceLens } from "react-source-lens";

function App() {
  useReactSourceLens()
  return (
      <YourApp />
  );
}

Hover any element in your app, press your shortcut key, and see the file path + line appear instantly ✨

🧠 Under the hood
If you’re curious, react-source-lens works without modifying React itself.
It simply walks the React Fiber tree through the DOM node references that React attaches internally (__reactFiber$...).

From there, it reconstructs the hierarchy and, when available, displays the data-source-file and data-source-line attributes injected at build time by the Babel plugin.

It’s a neat intersection of React internals and developer tooling.

💬 What’s next
I’m currently exploring:

⚡ SWC integration (for faster builds in Next.js)

🪟 Inline overlay view for file + line info

🌳 Visual tree mode for complex UIs

If that sounds useful, drop a star ⭐ on GitHub or leave a suggestion — I’m building this for the community.

🔗 Links
📦 NPM: https://www.npmjs.com/package/react-source-lens
💻 https://github.com/darula-hpp/react-source-lens

Thanks for reading! If you’d like to follow my dev experiments and open-source work, you can find me on X OlebogengMbedzi
. 🧡

DEV Community: Olebogeng Mbedzi

Stop Maintaining Manual Skeletons in React

The Problem: The "Twin Component" Trap

The Solution: Runtime DOM Measurement

How it works

Why this is better

Try it out

I built a tool to find where React components come from — even in big Next.js projects

I built a tool to find where React components come from — even in big Next.js projects

🎯 The problem

💡 The idea

⚙️ How it works

🚀 Quick start