Maybe you were asked to complete twenty fields in one go. You carefully filled everything out, hit Submit — and only then were you told that your password didn't meet some hidden, unspoken requirement. A requirement that was never communicated upfront.

Instead of helpful guidance, you were met with a vague message: “Invalid input." Invalid how, you wonder?

Required fields weren’t marked. There was no real‑time validation. No helpful red outline showing which field was wrong. Just a generic prompt telling you to “go back and correct missing information,” as if you’re supposed to magically know what the system wants.

So you scroll.

You search.

You guess.

And you're now getting frustrated.

The reason you're frustrated is simple: no one enjoys repeating a task they thought they had already completed — especially when the mistakes could've been prevented with clear guidance along the way.

You manage to fill in the form and you tap the Submit button.

Nothing happens.

No loading spinner.

No subtle animation.

No confirmation message.

No success screen.

Just silence. For a brief moment, you’re left wondering: Did it go through? So you tap again. And maybe… one more time.

At this point, you become fed up and you either postpone the signup process to when you have the time, or you may not ever return.

Even if you haven’t experienced this exact scenario, you’ve almost certainly felt the same kind of friction: that moment when a digital interface makes you pause, hesitate, or wonder what you’re supposed to do next.

These frustrations often arise because frontend developers either overlook or are unaware of the essential design principles and theories that underpin a smooth, intuitive user experience.

As a frontend developer, your interface should minimise cognitive load, provide immediate clarity, and guide users effortlessly through every task.

In this handbook, I'll introduce the academic theories that should inform and elevate your frontend decisions.

Table of Contents

• 1.0 Fitts’s Law:

  • 1.1 Use padding wisely

  • 1.2 Use infinite targets

  • Design Takeaway from Fitts Law:

• 2.0 Hick's Law:

  • Design Takeaway from Hick's Law

• 3.0 Gestalt Principles:

  • Key Gestalt Principles:

  • 3.1 Proximity

  • 3.2 Similarity

  • 3.3 Continuity

  • 3.4 Closure

  • 3.5 Figure/Ground

  • 3.6 Common Fate

  • 3.7 Focal Point

  • Design Takeaways from the Gestalt Principles

• 4.0 Von Restorff Effect (The Isolation Effect):

  • Design takeway from Von Restorff

• 5.0 Jakob’s Law

  • Design Takeaway from Jakob's Law

• 6.0 Miller’s Law

  • Design Takeaway from Miller's Law

• 7.0 The Goal-Gradient Hypothesis

  • Design Takeaway from Goal-Gradient Hypothesis

• 8.0 Zeigarnik Effect

  • Design Takeaway from Zeigarnik Effect

• 9.0 Tesla’s Law:

  • Design Takeaway from Tesla's Law

• 10.0 Peak End Rule:

  • Design takeaway from Peak End Rule

• 11.0 Postel’s Law:

  • Design Takeaway from Postel's Law

• 12.0 Doherty Threshold:

  • Design Takeaways from Doherty Threshold

• 13.0 Serial Position Effect (Primacy and Recency):

  • Design Takeaways Serial Position Effect

• 14.0 Occam’s Razor:

  • Design Takeaway from Occam's Razor

• 15.0 Parkinson's Law

  • Design Takeaway for Parkinson's law

• Conclusion

• References

You might wonder what academic theories have to do with frontend development.

The answer is simple. Academic theories aren't abstract ideas. There are the result of rigorous scientific investigation — controlled experiments, validated models, and decades of research into how humans think, learn, perceive, and interact with information.

Because these theories are grounded in evidence rather than opinion, they offer reliable guidance for building interfaces that align with how the human brain actually processes information.

Applying them to frontend development means you're not designing by guesswork or personal preference. Instead, you're applying tested, scientific insights to create clearer, faster, more humane user experiences.

In other words, when you build with academic theory in mind, your frontend becomes more than just visually appealing — it becomes cognitively efficient, behaviourally aligned, and measurably easier for users to navigate.

You can use the following laws and principles to guide your development work. Let’s start by looking at Fitt’s law.

1.0 Fitts’s Law:

Fitts’s law is the brainchild of Paul Fitts. He was among the early psychologists who recognised that many human errors result from flawed design rather than simple human weakness.

During World War II, he studied airplane cockpit layouts and concluded that numerous incidents attributed to pilot error were actually caused by poor design decisions (Hall, 2023; Budiu, 2022).

Here's the formula:

$$T = a + b \cdot \log_2\left(1 + \frac{D}{W}\right)$$

T = Movement Time

D = Distance to the target

W = Width (size) of the target

a, b = Empirically determined constants

Based on his findings, Fitts postulated that the time required to acquire/reach a target is determined by the distance to the target and the size of the target.

Fig 1.0: Illustration of Fitts Law.

From the above, between Target B and Target C, it will be faster to interact with Target C than Target B simply because of the distance (Target B is farther away). Interestingly, though Target A and Target C are at the same distance, Target C will still be faster to interact with and less error-prone because of its larger size.

In simple terms, Fitt’s Law tells us that the time required to move to a target depends on two main factors: the distance to the target and the size of the target. The farther away an element is, the longer it takes to reach. The smaller it is, the more precision it demands, which increases the interaction time and the likelihood of errors.

Conversely, closer and larger targets reduce cognitive load, motor effort, and frustration.

In a nutshell, Fitts’s main message to developers is to reduce the distance users must travel on the screen and to make important buttons large and visually dominant.

Fig 1.1: Showing Call-to-Action buttons are the largest and most visually prominent elements on each screen.

From the image above, you can see that the Call-to-Action buttons on each of the screens are the most visually dominant button and largest in size. They're also placed within the natural region. This makes them faster/easier to interact with.

You should also place your Call-to-Action button within the natural zone. This is a zone on a mobile phone where it's easy to reach with the thumb (as most people use their thumbs to select things on a phone screen). Here's a diagram showing the "natural zone" on a typical smartphone. It's much faster for a user to interact within the "natural zone" than the "hard zone" (see figure).

Fig 1.2: Showing three different zones for buttons placement (natural, stretching and hard region)

1.1 Use Padding Wisely

Fitts' law can be applied to your development by increasing padding wisely. You can also use padding to increase the interactive area. By doing this, you're increasing the size of the targets.

This is important, because imagine a menu that disappears the moment your cursor drifts a few inches away. You’re weren't trying to close it — you simply moved slightly, and suddenly the entire menu collapses. That tiny slip forces you to start the interaction all over again. It’s a small mistake, but it creates a disproportionately frustrating experience.

This happens because the interactive area is too narrow.

That’s why effective padding — or more broadly, generous interactive zones — is essential. By increasing the clickable or hoverable area around a menu, you are increasing the size of the targets, which makes the interaction more stable, more forgiving, and far less cognitively demanding.

This ensures users can move naturally without fear of accidentally “falling off” the target.

1.2 Use Infinite Targets

Another fundamental principle that emerges from Fitt’s Law is the idea of infinite targets. When an interface element is placed at the very edge or corner of a screen, it becomes effectively “infinite” because the cursor can't move beyond the screen boundary. The edge acts as a physical barrier, allowing the user to fling the mouse in that direction without precision or careful aiming.

As a result, corners and edges become the fastest, easiest, and most reliable places for users to access important controls.

This is why operating systems such as Apple’s macOS and Microsoft Windows position their most essential menus and buttons at these locations. The macOS Apple Menu sits in the top‑left corner, Windows historically placed the Start button in the bottom‑left corner, and both systems anchor taskbars, docks, and notification areas along screen edges.

These placements reduce cognitive load, minimise motor effort, and increase interaction speed because users do not need to slow down or correct their cursor movement. The screen itself “catches” the pointer.

In essence, infinite targets transform small interface elements into large, easy‑to‑hit zones simply by leveraging the geometry of the screen.

What this means for you: place your most important and frequently used actions where users can reach them with the least effort. Screen edges and corners act as natural stopping points, meaning users can't overshoot them.

Design Takeaways from Fitts Law:

Place Primary Actions Where the Task Ends:
Placing a submit button at the top‑right forces users to travel all the way back after completing a long form. This increases interaction cost and breaks flow. The best place for a submit button is at the bottom of the form — exactly where the user finishes the task. This aligns with natural reading and interaction patterns.

Keep Related Actions Physically Close:
Separating “Add to Cart” and “Check Out” across opposite sides of the screen forces unnecessary thumb movement. Group related actions to reduce effort and speed up decisions.

Make Primary Targets Large and Visually Dominant:
Your main CTAs (“Subscribe Now,” “Pay Now,” “Create Account,” “Sign Up”) should be the most recognisable elements on the screen. Large, high‑contrast targets reduce errors and improve speed.

Place High‑Value Actions at Screen Edges and Corners:
Edges and corners act as “infinite targets” because the cursor can’t overshoot them. This makes them the fastest, easiest, and most reliable places for critical controls.

A tiny icon in the middle of the screen is hard to hit. The same icon placed at an edge becomes effectively huge because the boundary “catches” the pointer. Also, actions like navigation, primary CTAs, or global controls should live where users can reach them with minimal effort. Avoid burying important actions in the centre of the screen.

Increase Target Size With Generous Padding:
Small interactive zones force users to aim with pixel‑level precision. Adding padding expands the clickable or hoverable area, making interactions easier, faster, and more forgiving.

Prevent Accidental “Fall‑Off” With Larger Hit Areas:
Menus that collapse the moment the cursor drifts slightly create frustration. A wider interactive zone keeps the menu open during natural mouse movement, reducing accidental resets.

Users don’t move perfectly. Interfaces should accommodate slight slips without punishing them. Larger targets reduce cognitive load and eliminate unnecessary frustration. so by increasing the effective size of buttons, menus, and controls, you create interactions that feel stable and predictable, and users can move confidently without fear of losing their place.

To Sum Up: The farther away an element is, the longer it takes to reach. The smaller it is, the more precision it demands, which increases the interaction time and the likelihood of errors. Conversely, closer and larger targets reduce cognitive load, motor effort, and frustration.

2.0 Hick's Law:

Hick’s Law is a psychological principle that describes the relationship between the number of choices presented to a user and the time it takes them to make a decision. It was formulated by William Edmund Hick in 1952 (Yablonski, 2022; Proctor & Scheider, 2018).

The law states that as the number of options increases, the decision time increases logarithmically. In simple terms, more choices slow users down, while fewer choices speed up decision-making.

$$T = a + b \cdot \log_2(n + 1)$$

Where:

T = time to make a decision,

n = number of choices,

b= a constant that depends on the task and the individual

Figure 2.0 illustrates the relationship between user experience, reaction time, and the number of actions.

This is how users feel, for example, when they encounter a form that asks for too much information upfront. The longer the form gets, the more frustrated they become.

Examples of this are overloading menus with too many items, presenting long, unorganised forms, giving too many calls-to-action on one screen, and building nested menus with excessive depth.

All of these create friction and can lead to cognitive overload.

Design Takeaway from Hick's Law

Avoid Overloading Users With Too Many Actions:
Too many buttons, menu items, or choices at once increases cognitive load and slows decision‑making. Users freeze when everything competes for attention.

Keep Navigation Clean and Focused:
Cluttered menus hurt both usability and SEO. Search engines struggle to track overly complex navigation structures, and users struggle to find what matters.

Use Progressive Disclosure to Reduce Complexity:
Hide advanced or rarely used options under “More” or expandable sections. Reveal complexity only when the user needs it.

Break Complex Tasks Into Smaller, Manageable Steps:
Progressive disclosure works beautifully for multi‑step forms and decision flows. Smaller steps reduce overwhelm and improve completion rates.

Group Related Options Into Logical Categories:
Organising actions into meaningful clusters helps users process information faster. For example, placing “Edit” and “Delete” together leverages natural mental grouping.

Video 2.0: Video description of Progressive Disclosure.

From the video above, instead of showing all the menu details at once, it is better to hide them initially. As you can see, the additional information only appears when the arrow down button is pressed. This approach prevents overwhelming the user and keeps the interface clean and focused.

You should also reduce decision anxiety, as too many choices create doubt and friction (as they say, the more you ask from a user, the less you get).

Beyond this, try to use recommended labels, show brief descriptions, provide visual previews, and use comparison tables wisely to show comparison between products especially when they have many characteristics. An example of a comparison table is shown below:

Figure 2.1: A comparison table being used to simplify complex information.

Also, rather than showing advanced configuration options by default, display only the most commonly used settings. Advanced options can be hidden under an expandable section like “Advanced” or “More Settings. This makes your interface less cluttered and more visually organized.

And speaking of visual organization, this is the perfect moment to introduce Gestalt principles — the psychological rules that explain how users naturally group and interpret what they see.

To Sum Up: As the number of options increases, the decision time increases logarithmically.

3.0 Gestalt Principles:

In the 1920s, a group of German psychologists – Max Wertheimer, Kurt Koffka, and Wolfgang Köhlern – introduced what are now known as the Gestalt Principles. Their work sought to understand how humans perceive and interpret visual information (Bustamante, 2023).

The word “Gestalt” is German for “unified whole,” reflecting the core idea behind the theory: people naturally perceive objects as organised patterns and complete forms rather than as separate, disconnected parts.

These principles explain how the human mind structures visual elements to make sense of the world. Over time, they have become highly influential in fields such as design, user experience (UX), psychology, and data visualization, where understanding perception is critical.

Key Gestalt Principles:

3.1 Proximity

Elements that are placed close to each other are perceived as a group, while those spaced far apart are seen as separate. This is why labels are placed directly next to their corresponding input fields.

For example: In a blog feed, the "Title," "Author," and "Date" should have small margins between them (8px), while the space between one blog post card and the next should be much larger (40px). This tells the user's brain: "These three text strings belong to this specific post."

Fig 3:0 Illustration of proximity (Gestalt Principle)

From the fig above, the spacing within the blog feed plays a powerful role in how effortlessly users interpret what they see. When elements sit close together, the brain instinctively treats them as belonging to the same unit. This is why placing the author credit just 8px beneath the title creates an immediate mental link. The viewer doesn’t need to pause or decode who wrote which article; proximity does the cognitive work automatically, forming a tight, intuitive grouping.

Equally important is the generous 40px gap between individual cards. This larger spacing introduces “visual breathing room.” Without it, a feed can quickly collapse into a dense wall of text, overwhelming the user and discouraging exploration. The wider margin establishes a clear boundary—a natural stop-and-start rhythm—that makes each card feel distinct and the entire layout more scannable.

Finally, subtle spacing differences can guide behaviour, not just perception. The slightly larger 12px margin above the read‑more link separates it from the passive information above it. This spacing cues the user that the link represents an action rather than another piece of descriptive text. It’s a small adjustment, but it shifts the element’s role from informational to interactive, helping users understand what they can do next.

Together, these spacing decisions transform a simple list of posts into a structured, intuitive, and behaviourally clear interface—one where the user never has to think about the layout, because the layout is already thinking for them.

Proximity controls meaning: move elements closer to show connection, separate them to show difference.

3.2 Similarity

We naturally group elements that share similar visual characteristics, such as color, shape, size, or orientation.

For example, even if buttons are spread across a page, if they're all the same shade of blue, the user understands they perform similar functions.

If your primary "Submit" button is blue with rounded corners, every other primary action on your site should look exactly the same. If you suddenly use a square red button for a primary action, the user will be confused because the "similarity" is broken.

Fig 3:1 : illustration of similarity (Gestalt principle)

As you can see from above, the layout clearly demonstrates how the Gestalt Principle of Similarity works by showing two different visual situations: one where everything matches, and one where a single element breaks the pattern.

All three product cards share the same visual characteristics:

• Same card shape

• Same border and shadow

• Same image size and placement

• Same blue “Add to Cart” button

• Same font style and spacing

Because these elements look alike, your brain automatically groups them as one category — “products that belong together.”
You don’t have to think about it; the similarity creates instant visual unity.

This is the Gestalt Principle of Similarity in action.

In the second row, everything is still similar except one button:

• The middle product’s button is orange, not blue

• It has square corners, not rounded

• The text is italic, not regular

• The label changes to “Quick Buy”

Because this button breaks the shared pattern, your brain immediately notices it and treats it as different or special.

Developers can use broken similarity to intentionally highlight featured items, promotions, or urgent actions.

When similarity is broken, the different element stands out and draws attention.

3.3 Continuity

The human eye prefers to follow a continuous path or curve rather than jagged or broken lines. We perceive items aligned on a line or curve as being related. This is often used in navigation menus or horizontal carousels to guide the user's gaze.

For example, you might have a horizontal carousel where the last visible card is slightly "cut off" at the edge of the screen. This visual break creates a path that encourages the user to keep scrolling as their eyes follow the line of cards.

Fig 3:2: illustration of continuity (Gestalt principle)

As you can see, all four form fields — First Name, Last Name, Email Address, and Phone Number — are perfectly aligned along one continuous horizontal path. Because the human eye naturally prefers to follow an unbroken line, your gaze moves smoothly from left to right across the fields without effort.

The final field is slightly cut off at the edge, which creates a subtle visual cue that the line continues beyond the visible area. This encourages the user to keep scrolling or swiping, because their eyes are already following the direction of the form.
when elements are arranged along a straight path, curve, or flow, the brain automatically treats them as connected and expects the pattern to continue.

Another example is Instagram Stories, which are arranged in a smooth horizontal line at the top of the app. Instagram reinforces this by slightly revealing the next story circle at the edge of the screen. That tiny “peek” acts as a continuation cue — your eyes expect the line to keep going, so your finger follows.

Fig 3:3: illustration of continuity (Gestalt principle)

As you can see from above, all the circular story icons are arranged in a straight horizontal line, and your visual system instinctively follows that line from left to right without effort.

The slight visibility of the next story at the edge of the screen strengthens this effect, signaling that the sequence continues beyond what's currently shown. Also, because the icons share the same size, spacing, and shape, there are no visual interruptions, allowing your eyes to glide across them in one continuous motion.

This seamless flow is exactly what continuity describes: the tendency of the human eye to follow the direction of a line or pattern, assuming it continues even when part of it is out of view.

Continuity is the tendency of the human eye to follow the direction of a line or pattern, assuming it continues even when part of it is out of view.

3.4 Closure

Closure refers to the mind’s ability to perceive a complete, unified form even when parts of that form are missing. Rather than requiring every boundary, line, or shape to be explicitly drawn, the brain instinctively fills in the gaps. When used intentionally, closure allows interfaces to feel cleaner, more elegant, and more cognitively efficient.

When we look at a complex arrangement of visual elements, we tend to look for a single, recognisable pattern. If an image is missing parts, our brains fill in the gaps to "close" the shape.

One of the most celebrated examples of closure in visual identity design is the panda symbol used by the World Wide Fund for Nature (WWF). This logo demonstrates how strategic omission can produce a memorable, emotionally resonant, and universally recognisable mark.

At first glance, the panda illustration appears simple, composed of a few bold black shapes arranged against a white background.

Yet a closer look reveals that the panda is not fully drawn. There are no outlines defining the body, no complete contours around the head, and no explicit boundaries separating limbs from background. Instead, the designer uses a series of carefully placed shapes (ears, eye patches, nose, and partial limbs) to imply the rest of the animal. The viewer’s mind fills in the missing information, completing the silhouette effortlessly.

This is closure at its most effective: the brain constructs a whole from fragments, creating a sense of completeness without visual overload.

Fig 3:4: illustration of closure (Gestalt principle)

For example, a "hamburger menu" (three lines) isn't a literal drawer, but our brains "close" the shape to understand it represents a menu.

Fig 3:5: illustration of closure (Gestalt principle)

An example of closure in practice can be seen in step indicators commonly used in checkout flows. These components often rely on partial shapes, implied boundaries, and incomplete outlines to guide the user through a sequence of actions.

For instance, upcoming steps may be represented by dashed circles. Although the circles aren't fully drawn, the viewer immediately recognises them as complete shapes. The brain resolves the missing segments, allowing the interface to communicate progression without heavy borders or fully rendered icons. This subtle use of closure reduces visual clutter while preserving clarity.

Closure refers to the mind’s ability to perceive a complete, unified form even when parts of that form are missing.

3.5 Figure/Ground

This principle describes the mind's tendency to separate an object (the figure) from its surrounding area (the ground or background). In web design, using a "modal" or "pop-up" relies on this: by blurring the background, you force the user to see the pop-up as the focal figure.

When a user clicks "Login" on a modal/lightbox, the background site often dims (the "Ground") while the login box stays bright and centered (the "Figure"). This immediate depth change tells the user exactly where their attention belongs.

Video 3.5.0 Video description of Figure/Ground (Gestalt Principle)

From the video above, you can see that when the Quick View button is clicked, the selected figure stands out while the background darkens. This contrast guides the user’s attention and helps them focus on the figure. Developers can use this technique to direct users’ attention to what matters most or to what they want users to notice.

This principle describes the mind's tendency to separate an object (the figure) from its surrounding area (the ground or background).

3.6 Common Fate

Elements that move in the same direction are perceived as more related than elements that are stationary or move in different directions. Think of a dropdown menu: when all sub-items slide down together, they are clearly part of the same "unit."

For example, when you click a FAQ header and five sub-items slide down at the exact same speed and direction, the "Common Fate" tells the user that all those items belong to that specific category. If they flew in from different directions, the relationship would be lost.

Video 3.6.1 Video description of common fate (Gestalt Principle)

Video 3.6.2 Video description of common fate (Gestalt Principle)

From the video shown above, the e‑commerce animation example demonstrates these principles clearly by using two distinct motion patterns: a group of regular products that move upward together, and a pair of special‑category items that enter dramatically from the left. Through these contrasting movements, the interface communicates category differences without relying on text labels or explicit instructions.

Therefore, developers can use this motion‑based differentiation as a design strategy to guide users’ perception—allowing the interface to signal hierarchy, category structure, and product importance purely through animated behaviour rather than through static visual labels.

Elements that move in the same direction are perceived as more related than elements that are stationary or move in different directions.

3.7 Focal Point

Whatever stands out visually will capture and hold the viewer’s attention first. This is essentially the principle of emphasis. A bright "Sign Up" button in a sea of gray text acts as the focal point, directing the user's primary action.

For example, an alert banner or a pricing table should stand out from its surroundings. Beyond this, in a three-tier pricing table (Basic, Pro, Enterprise), the "Pro" column is often slightly larger or a different color. This creates a focal point that draws the eye to the "recommended" option immediately.

Fig 3:7: illustration of closure (Gestalt principle)

In visual interface design, the Gestalt principle of Focal Point plays a crucial role in directing user attention toward the most important element on a screen.

A focal point is created when one element breaks the established pattern of surrounding elements, making it stand out immediately.

In e‑commerce interfaces, this principle is often applied to highlight primary actions such as purchasing, subscribing, or upgrading. The “Buy Now” button provides a clear and practical example of how focal points function within a layout.

From the example above, the first two buttons share the same visual characteristics: neutral colours, and regular weight text. This repetition establishes a visual pattern that the user quickly becomes familiar with.

But the “Buy Now” button intentionally disrupts this pattern. It uses a bright colour, which contrasts sharply with the muted tones of the other buttons. This colour difference alone is enough to draw the eye, as humans are naturally sensitive to changes in hue and saturation within a uniform environment.

The Focal Point may sound like it's similar to the principle of Similarity, but the two operate in completely opposite ways within perceptual psychology.

Similarity explains how the mind naturally groups elements that share visual characteristics – such as colour, shape, or size – into coherent units. Once this grouping is established, the interface gains structure and predictability.

Focal Point, on the other hand, works by intentionally breaking that structure. Instead of reinforcing uniformity, it introduces a deliberate contrast – through colour, scale, brightness, or motion – to draw the viewer’s attention to one specific element.

In other words, Similarity creates the background pattern, while Focal Point identifies the one element that must stand out against that pattern.

Whatever stands out visually will capture and hold the viewer’s attention first.

Design Takeaways from the Gestalt Principles

Use Spacing as Your Primary Grouping Tool:
Elements that belong together should sit closer to each other than to anything else. Spacing communicates structure faster than borders or boxes. Use tight internal spacing (6–12px) for related items and wide external spacing (24–48px) to separate groups.

Build a Strict, Consistent Visual System — and Stick to It:
Define clear rules for button types, text styles, icon sizes, and alignment patterns. Consistent left‑aligned text blocks, predictable carousel lines, and stable flow patterns reduce cognitive load and make interfaces feel trustworthy.

Guide the Brain With Spacing, Alignment, Consistency, Contrast, and Motion:
The human brain is always trying to group, follow, and prioritise what it sees. Your job is to guide that instinct through intentional layout decisions, not fight against it.

4.0 Von Restorff Effect (The Isolation Effect):

This is the brainchild of Hedwig von Restorff, posited in 1933. In principle it states: An item that stands out is more noticable and more likely to be remembered than other items (Hunt, 1995).

So unique or visually distinct elements grab attention and are more memorable – in other words, distinctiveness dictates memory. When a user interacts with an interface, their brain naturally seeks patterns to minimize cognitive effort.

While consistency is generally a virtue in design, a perfectly uniform layout can lead to "banner blindness" or habituation, where the user stops noticing details.

By strategically breaking a pattern through changes in color, size, shape, or spacing, the developer can "isolate" an element, triggering a biological response that flags the item as high-priority.

Note that although the Focal Point principle may initially seem similar to the Von Restorff Effect, they describe two different psychological processes.

Focal Point is a Gestalt visual principle that explains how one element becomes the centre of attention within a composition because it carries the strongest visual contrast – through size, colour, brightness, position, or motion. Its purpose is to guide the viewer’s eye toward the most important element in the layout.

The Von Restorff Effect comes from cognitive psychology, not Gestalt theory. It states that an item that is noticeably different from a group of similar items is not only more attention‑grabbing but also more memorable.

So Focal Point is about where the eye goes first, while the Von Restorff Effect is about what the brain remembers later.

Design takeaways from Von Restorff

Use Isolation to Make CTAs Impossible to Miss:
On a page filled with neutral text and standard links, a single high‑contrast button (like a bold “Primary Blue” or “Emergency Red”) instantly becomes the standout element. This leverages the Von Restorff Effect to pull the user’s eye toward the most important action.

Create a Visual “Hitch” in the Scan Path:
A distinct CTA interrupts the user’s natural left‑to‑right, top‑to‑bottom scanning rhythm. This makes actions like “Buy Now” or “Sign Up” the first thing they notice and the last thing they forget.

Make Critical Actions Visually Distinct:
Because users naturally notice the one element that breaks a pattern, your most important actions should use deliberate contrast — color, size, shape, weight, or motion. Isolate key information instead of letting it blend into surrounding UI noise.

Avoid Over‑Differentiation — or Nothing Stands Out: If every button is loud, animated, or uniquely styled, the interface becomes chaotic. The Von Restorff Effect only works when there is a clear, stable pattern — and you break it once, intentionally.

To Sum Up: An item that stands out is more noticable and more likely to be remembered than other items.

5.0 Jakob’s Law

Jakob’s Law states that users spend most of their time on other sites, so they expect your interface to behave like the ones they already know.

Familiar patterns — hamburger menus, top navigation, search icons, and clickable top‑left logos — reduce cognitive load because users don’t have to interpret anything new.

But while Jakob’s Law is foundational to UX, I think it can also unintentionally suppress innovation.

When developers over‑prioritise familiarity, they fall into a standardisation trap: endlessly optimising conventional patterns instead of exploring fundamentally better ones.

The Pie Menu is a perfect illustration of this. According to Fitts’s Law, the time required to reach a target depends on its distance and size. Linear menus place the last item much farther from the cursor than the first, creating uneven interaction costs.

Radial menus position every option at an equal distance from the centre, and their wedge‑shaped targets effectively grow larger as the pointer moves outward.

Mathematically, pie/radial menu are faster to interact with and more efficient — yet they remain rare in mainstream web design because they violate users’ expectations. In other words, Jakob’s Law keeps us locked into a familiar but suboptimal pattern simply because “that’s how it’s always been done.”

But the challenge is not choosing between familiarity and innovation, but balancing them.

This is where the Aesthetic–Usability Effect becomes powerful. Research shows that users perceive attractive interfaces as easier to use, and they are more forgiving of minor usability friction when the design is visually pleasing.

A beautifully crafted Pie Menu, for example, can encourage users to invest the small amount of learning required to use it. By applying aesthetic delight strategically, developers can introduce innovative patterns without overwhelming users.

The principle that emerges is simple: Be conventional where it matters, and innovative where it delights.

Design Takeaway from Jakob's Law

Keep Trust‑Critical Elements Predictable:
Navigation, search, authentication, and other high‑stakes interactions must follow established conventions. Users rely on these patterns for speed, confidence, and safety — this is where Jakob’s Law should be respected without exception.

Experiment Only in Low‑Risk, High‑Creativity Areas:
In creative or productivity‑focused zones — like editing tools in a photo app — you can safely introduce new interaction models such as radial menus, gesture wheels, or context‑aware tool selectors. These areas invite exploration and benefit from efficiency‑driven innovation.

To Sum Up: Be conventional where it matters, and innovative where it delights.

6.0 Miller’s Law

Miller’s Law originates from George A. Miller’s classic paper “The Magical Number Seven, Plus or Minus Two.” It states that the average person can hold only about 7 (±2) chunks of information in working memory at any given moment (Miller, 1956).

Crucially, Miller emphasised that the brain doesn’t store isolated items — it groups them into meaningful units called chunks. Because working memory is so limited, developers must structure information in ways that respect this cognitive boundary.

This principle has direct implications for interface design. Long, unbroken strings of information overwhelm users, whereas chunked formats are far easier to process.

For example, instead of displaying a phone number as 1234567890, formatting it as 123‑456‑7890 transforms ten digits into three manageable chunks. The same logic applies to navigation: aim for five to nine primary menu items, and if you need more, group them into categories. Users remember the category as a single chunk rather than each individual link.

Miller’s Law also explains why long forms are so intimidating. When a user sees 30 fields on one page, their brain interprets it as a single, massive task — far beyond the 7±2 limit.

A progressive stepper solves this by breaking the form into smaller stages of 5–7 fields each. This reduces cognitive load, creates a sense of progress, and significantly lowers abandonment rates.

The same principle applies to product listings or search results. Expecting users to compare 50 items at once is unrealistic. Instead, provide strong filtering tools so users can narrow the set to a manageable size — ideally within the range their working memory can meaningfully evaluate.

In essence, Miller’s Law reminds developers that humans don’t process information in bulk. They process it in structured, meaningful chunks.

Fig 6.0: Illustrating progressive stepper

In the example above, the interface uses both a progress bar and a stepper to guide the user through multiple stages of a task. After completing the first page and selecting “Continue,” the user moves to the next step, and the progress bar updates accordingly. This creates a clear sense of forward movement and accomplishment.

By breaking the process into smaller segments, the interface prevents cognitive overload. If all the information were presented on a single page, users might feel overwhelmed, unsure where to begin, or discouraged by the sheer volume of work.

A step‑by‑step flow transforms a large task into a sequence of manageable actions, increasing the likelihood of completion.

Design Takeaway from Miller's Law

Respect the 7±2 Working‑Memory Limit:
Users can only hold about seven chunks of information at once. Long, unbroken content overwhelms them, while chunked information is instantly easier to process.

Chunk Information Into Meaningful Units:
The brain doesn’t store isolated items — it groups them. Format data (like phone numbers), menus, and settings into clear, memorable chunks instead of long, flat lists.

Keep Navigation Within 5–9 Primary Items:
If you need more than nine options, group them into categories. Users remember the category as a single chunk, not each individual link.

Break Long Forms Into Smaller Steps:
A 30‑field form feels like one giant task. A progressive stepper with 5–7 fields per step keeps users below the cognitive overload threshold and dramatically reduces abandonment.

Reduce Comparison Load With Strong Filters:
Expecting users to compare 50 products at once is unrealistic. Provide filtering tools that shrink the decision set to something the working memory can actually handle.

Design for Chunked Thinking, Not Bulk Processing:
Humans don’t process information in bulk — they process structured, meaningful groups. Interfaces that respect this limitation feel lighter, faster, and more intuitive.

To Sum Up: A step‑by‑step flow transforms a large task into a sequence of manageable actions, increasing the likelihood of completion.

7.0 The Goal-Gradient Hypothesis

This is the perfect moment to introduce the Goal‑Gradient Hypothesis, originally proposed by behaviorist Clark Hull in 1932 (Yablonski, 2022). The hypothesis states that people become more motivated as they get closer to achieving a goal. In other words, users naturally accelerate their engagement when they sense they are nearing completion.

This principle is incredibly powerful in UX design, especially for progress tracking, gamification, and reward systems.

The takeaway is straightforward: Because users are more motivated near the finish line, progress indicators should be prominent and meaningful.

Percentages, progress bars, and step counters reinforce momentum. Micro‑achievements — such as badges, checkmarks, or subtle confetti — amplify motivation by celebrating small wins.

Tasks should be broken into measurable milestones so users can see themselves advancing.

This is why e‑learning platforms display messages like “You’ve completed 8 of 10 lessons — almost there!” and why fitness apps highlight progress with prompts such as “3 km done, 2 km to go.” These cues leverage the goal‑gradient effect to keep users engaged, energized, and eager to finish.

By combining progressive steppers with clear progress feedback, developers create interfaces that feel lighter, more encouraging, and far more motivating — ultimately improving completion rates and overall user satisfaction.

But what happens when a goal isn't completed? Why do we sometimes feel uncomfortable leaving things unfinished? That discomfort is explained by another psychological principle called the Zeigarnik Effect — the tendency for people to remember and feel tension about incomplete tasks. We will look at this next.

Design Takeaway from Goal-Gradient Hypothesis

Make Progress Visible to Boost Motivation:
According to the Goal‑Gradient Hypothesis, users naturally speed up as they sense they’re nearing completion. Prominent progress bars, percentages, and step counters tap into this instinct and keep momentum high.

Celebrate Micro‑Achievements to Reinforce Engagement:
Badges, checkmarks, subtle confetti, and “step completed” cues reward small wins. These micro‑rewards amplify motivation and make long tasks feel lighter and more achievable.

Break Tasks Into Measurable Milestones:
Users stay motivated when they can see themselves advancing. Divide complex flows into clear steps so progress feels tangible rather than overwhelming.

Use Progress Feedback to Drive Completion:
Messages like “8 of 10 lessons completed — almost there” or “3 km done, 2 km to go” leverage the goal‑gradient effect to energise users and pull them toward the finish line.

Combine Steppers With Clear Feedback for Maximum Impact:
Progressive steppers paired with strong visual feedback create interfaces that feel encouraging, structured, and motivating — dramatically improving completion rates.

Video 8.0 : Video illustrating goal gradient

To Sum Up: People become more motivated as they get closer to achieving a goal.

8.0 Zeigarnik Effect

The Zeigarnik Effect is a psychological principle stating that people remember unfinished or interrupted tasks better than completed ones (Cherry, 2024).

Memory begins with sensory input, which is processed into short-term memory. Unfinished tasks persist in our thoughts, leading to active recall. This ongoing engagement can turn them into long-term memories, enhancing recall until resolved. This increases engagement, encourages task completion, improves retention, and drives conversions.

So because people remember unfinished tasks better than completed ones (Zeigarnik Effect), developers use progress indicators to make users aware that something is incomplete and motivate them to finish it.

In your designs, you can break long forms into multi-step processes to encourage completion and display profile completion percentages (for example, 70% complete) to push users toward 100%.

This is the main reason why e-commerce platforms send abandoned cart reminders to bring users back to complete their purchases. It's also why apps use streak systems to encourage daily engagement and habit formation and learning platforms show course completion bars to motivate users to finish modules.

Design Takeaway from Zeigarnik Effect

Unfinished Tasks Stay Active in Memory — Use That to Drive Completion:
Because incomplete tasks linger in working memory (Zeigarnik Effect), users naturally keep thinking about what they haven’t finished. This tension boosts recall, engagement, and the likelihood of returning to complete the task.

Make Incompleteness Visible With Progress Indicators:
Progress bars, percentages, and step counters remind users that something is still unfinished. This gentle psychological pressure motivates them to continue until the task is complete.

Break Long Flows Into Multi‑Step Processes:
A massive form feels overwhelming, but a stepper with smaller chunks keeps users moving. Showing “70% complete” nudges them toward finishing the last stretch.

Use Reminders to Re‑activate Unfinished Intent:
Abandoned cart emails, streak reminders, and “continue your lesson” prompts work because the unfinished task is already active in the user’s mind. The reminder simply pulls them back into the loop.

Celebrate Completion to Close the Cognitive Loop:
Checkmarks, confirmations, and completion badges give users closure. This resolves the mental tension created by the unfinished task and reinforces positive behaviour.

To Sum Up: Unfinished tasks persist in our thoughts, leading to active recall.

9.0 Tesler’s Law:

This law was proposed by Lawrence Tesler. He was a computer scientist known for his work on human-computer interaction, and he contributed significantly to making software more user-friendly, including work on cut, copy, and paste functionality.

This law is otherwise known as the Law of Conservation of Complexity. The core Idea here is every process has a certain amount of “inherent complexity" that can't be removed. You can only decide who handles it: the user or the system.

Some examples of these inherent complexities might be:

• translating user actions into correct operations behind the scenes,

• handling unreliable or slow network connections,

• connecting with third-party APIs, services, or legacy systems,

• sorting large datasets quickly,

• performing complex search operations

• managing version changes and compatibility issues,

• managing state, interactions, and animations without confusing the user.

All of these can be inherently complex, but it's the job of the developer to deal with the complexity.

As a developer, you should always try as much as possible to push complexity to the system. For example, instead of making a user type their full address manually, use an Auto-complete API (Google’s Places and Map is best for this). The complexity of finding and validating the address still exists, but the software handles the work for them.

Here's a practical example: let’s say you're designing a student platform that requires users to enter their university name. A practical approach would be to store an array of all universities in the UK in your codebase (This is the hard part Tesla hinted at).

As the user types, they don't need to enter the full name, and their full university name is shown (relating to what they have typed). For instance, if they intend to type “University of Sheffield,” simply typing “Sheff” should prompt the system to display the full university name, which they can then select.

In Dart, you can use a package like fuzzysearch to implement this kind of intelligent matching.

The advantage of this approach is greater than it first appears. It improves data consistency because users often enter the same information in different ways. For example, some users might type “Uni of Sheff,” others “Sheffield University,” and others “Uni of Sheffield,” while all are referring to “University of Sheffield.”

This is how messy data is created, and it creates more work for data analysts. Little wonder that data analysts spend up to 70% of their time cleaning data.

If developers invested more time in structuring how data is collected to ensure consistency, there would be far less work downstream for analysts. This same logic should be applied in how we collect date, time, and other information.

So apart from people's names and email addresses, you should try to standardize the data your app collects as much as possible. Use date and time pickers, stepper controls, input masks, checkboxes, dropdown menu and radio buttons, toggle switches. and so on.

The essence of removing complexity from the user is not only about improving usability, but also about ensuring that the data collected is standardised, structured, and consistent.

Design Takeaway from Tesler's Law

Push Complexity to the System, Not the User:
Every process contains unavoidable complexity. Your job is to handle it behind the scenes so the user experiences the simplest possible interaction.

Automate Tasks Users Shouldn’t Have to Think About:
Use tools like autocomplete, fuzzy search, intelligent defaults, and validation APIs to remove manual effort. The complexity still exists — but the system absorbs it instead of the user.

Standardise Inputs to Prevent Messy Data:
Users enter the same information in wildly different ways. Use pickers, dropdowns, input masks, radio buttons, and toggles to enforce consistent, structured data collection.

Handle Inherent Technical Complexity Internally:
Network issues, API quirks, large dataset sorting, search optimisation, state management, and animation logic are all developer responsibilities. Users should never feel this complexity.

To Sum Up: Every process contains unavoidable complexity. Your job as a developer is to handle it behind the scenes so the user experiences the simplest possible interaction.

10.0 Peak End Rule:

In 1993, Daniel Kahneman, Barbara Fredrickson, Charles Schreiber, and Donald Redelmeier invited volunteers into a lab for what sounded like a simple experiment. The task was straightforward: place a hand into a container of painfully cold water (Kahneman et al., 1993)

In the first round, participants kept their hand in 14°C water for 60 seconds. It was uncomfortable, sharp, and unpleasant but after one minute, it was over.

In the second round, they again endured 60 seconds in 14°C water. But this time, they were asked to keep their hand in for an extra 30 seconds. The temperature was raised slightly to 15°C. Still cold. Still unpleasant. Just slightly less intense.

Objectively, the second experience was worse. It lasted 90 seconds instead of 60. More total pain. More suffering.

Later, the researchers asked a simple question:

If you had to repeat one of the trials, which would you choose?” Surprisingly, most participants chose the longer one.

Why would anyone choose more pain?

The researchers realised something profound: people don’t remember experiences by calculating total discomfort. Instead, the mind summarizes the experience using just two key moments — the most intense point (the peak) and the final moment (the end).

In both trials, the peak pain was the same: 14°C. But the longer trial ended slightly better, at 15°C. That small improvement at the end reshaped how the entire episode was remembered. The participants’ “experiencing self” suffered more during the longer trial. But their “remembering self” preferred it because it ended on a less painful note.

From this, the researchers introduced what became known as the Peak–End Rule: we judge experiences largely by their most intense moment and how they finish, not by how long they last.

Since people largely judge an experience by how it ends, developers should focus on designing satisfying confirmation screens and smooth exit interactions. You should concentrate less on making every single moment perfect and instead prioritise optimising the peak and final moments.

A negative ending can overshadow an otherwise good experience, so carefully avoid frustrating final steps such as unexpected fees or confusing confirmations.

Emotional intensity strongly shapes memory, which is why many apps incorporate celebration animations, rewards, or success messages at key moments to leave a lasting positive impression.

Design takeaway from Peak End Rule

People Judge Experiences by the Peak and the Ending — Not the Total Duration:
Users don’t remember every moment. They remember the most intense point and how the experience ends. A slightly better ending can completely reshape how the entire interaction is remembered.

Prioritise Strong, Positive Endings in Your UX Flows:
A smooth final step, a clear confirmation, or a satisfying success screen leaves a disproportionately strong impression. A bad ending can overshadow an otherwise great experience.

Design for Emotional Peaks at Key Moments:
Celebration animations, rewards, checkmarks, and success messages create memorable emotional spikes. These peaks anchor the experience in the user’s memory.

Don’t Try to Perfect Every Moment — Perfect the Right Moments:
Optimise the peak and the end of the journey. These two moments define how users recall the entire interaction.

Avoid Negative Surprises at the Finish Line:
Unexpected fees, confusing confirmations, or friction at the last step can ruin the memory of the whole process. Protect the ending carefully.

To Sum Up: We judge experiences largely by their most intense moment and how they finish, not by how long they last.

11.0 Postel’s Law:

Jon Postel’s famous principle – “Be conservative in what you send, be liberal in what you accept” –  is a philosophy of kindness in software design. At its core, the principle argues that systems should be generous with what they accept from users, yet disciplined and predictable in what they output.

When developers follow this approach, users feel supported and understood. When they don’t, users feel punished for being human.

A user’s input is rarely perfect. People type quickly, make mistakes, follow their own habits, or rely on formats familiar to them. A robust system embraces this reality. It accepts messy, human input and quietly transforms it into clean, standardized data.

Real people don't think in strict formats. They write dates the way they learned in school, type phone numbers the way they say them aloud, and enter names and addresses in whatever structure feels natural to them.

A rigid system will reject anything that doesn’t match its narrow expectations, but a robust system, by contrast, adapts to the user.

Consider dates. A brittle interface might demand MM/DD/YYYY and reject everything else. A more humane system accepts a wide range of formats — “1 May 2024,” “2024‑05‑01,” “05/01/24,” or “May 1st, 2024” — and quietly converts them into a standard internal representation. This is where the complex handling described by Tesla's Law comes into play (Shifting complexity to the system, rather than the user).

Phone numbers follow the same pattern. People might enter (555) 123 4567, 555‑123‑4567, 5551234567, or +1 555 123 4567. A fragile system throws errors. A robust one parses all of them using libraries like libphonenumber and moves on.

Addresses are equally varied. “221B Baker St,” “221‑B Baker Street,” and “221 Baker St., Apt B” all refer to the same place. A forgiving system normalizes these instead of rejecting them.

Even names can be surprisingly complex. Hyphens, apostrophes, multiple words, and titles are all part of real human identity. Rejecting “O’Connor,” “Jean‑Luc,” or “Dr. Sarah Lee” is not just technically incorrect — it's disrespectful to the user.

Search bars offer another clear example. A strict search bar demands perfect spelling and exact phrasing. A robust one handles typos (“restuarant”), partial words (“resta”), synonyms (“food places”), and natural language (“where can I eat nearby”). It meets the user where they are instead of forcing them to think like a machine.

Currency should be normalized to a clear format such as GBP 5.00, no matter whether the user typed “£5,” “5 pounds,” or “5 GBP.”

Even file uploads benefit from standardization: whether the user uploads .jpeg, .jpg, .JPG, or .JPEG, the system should store everything as .jpg.

Error messages follow the same principle. Vague feedback like “Invalid password” leaves users confused and frustrated.

A clear, conservative message — “Incorrect password. Please try again.” — respects the user’s time. And instead of hiding password requirements, the system should state them upfront: minimum eight characters, at least one uppercase letter, at least one number.

Predictability reduces friction.

Because users inevitably make mistakes or enter data in unexpected ways, developers should design input fields that are tolerant rather than brittle. This means accepting flexible formats, offering autocorrect or intelligent parsing, and using forgiving validation rules that interpret the user’s intent instead of rejecting their effort.

Clear instructions, tooltips, and visible requirements should appear before submission so users understand what the system expects without trial and error.

When errors do occur, the interface should handle them gently—never crashing, and never forcing the user to start over.

Even simple variations, such as phone numbers typed with spaces, dashes, or parentheses, should be accepted and normalized behind the scenes.

By embracing flexibility on the input side and clarity on the output side, developers create systems that feel humane, resilient, and respectful of the way real people actually behave.

Design Takeaway from Postel's Law

Accept Messy Human Input, Output Clean Structured Data:
Users type dates, names, phone numbers, and addresses in unpredictable ways. A humane system accepts this variability and quietly normalises it into a consistent internal format.

Rigid interfaces punish users for being human. Robust interfaces interpret intent — handling typos, partial matches, synonyms, and natural language without complaint.

Also accept variations in spacing, punctuation, casing, and structure. Let users type naturally — the system should handle the complexity, not them.

Be Flexible With Input, Be Strict With Output:
This is the heart of Postel’s Law. Let users express information naturally, but ensure your system stores and displays it in a predictable, standardised way.

Use Intelligent Parsing and Autocorrection to Reduce Errors:
Libraries like libphonenumber, fuzzy search, and natural‑language parsers allow systems to accept a wide range of formats while still producing clean, reliable data.

Normalise Everything Behind the Scenes:
Dates, phone numbers, currency, file extensions, and addresses should all be standardised internally. This prevents messy data and reduces downstream cleanup work.

Provide Clear, Predictable Feedback:
Error messages should be specific and helpful. Requirements should be visible upfront. Users should never be surprised, confused, or forced to start over.

Combine Postel’s Law With Tesler’s Law:
Shift complexity to the system. Intelligent handling of messy input reduces cognitive load, improves usability, and ensures consistent, high‑quality data.

To Sum Up: A rigid system will reject anything that doesn’t match its narrow expectations, but a robust system, by contrast, adapts to the user.

12.0 Doherty Threshold:

The Doherty Threshold is a principle in human–computer interaction which proposes that systems should respond quickly enough to keep users actively engaged (Mod 2024).

When response times stay below a certain limit, users remain focused and productive. But once performance already meets this optimal responsiveness level, making the system even faster or adding extra capability doesn't significantly enhance satisfaction or efficiency.

The idea was introduced by Walter J. Doherty in 1976 in his paper “A Comparison of Programming Systems and Doherty Threshold.” His research showed that maintaining rapid system feedback fast enough to sustain continuous interaction has a stronger impact on productivity than simply increasing system power or features beyond that point.

Doherty proposes that this shouldn't be greater than 400ms Rule: If the system responds within this window, the user feels in total control. If the response takes longer, the user's attention begins to wander, and their "train of thought" is broken.

The challenge, of course, is that not every operation can realistically complete within 400ms. Some tasks require heavy computation, large network calls, or complex rendering. This is where the concept of perceived performance becomes essential.

Even when the system can't finish the work quickly, it can feel fast by responding instantly at the UI level. Developers can achieve this illusion of speed through a combination of thoughtful design patterns and disciplined engineering practices.

On the technical side, performance begins with reducing unnecessary work. Keeping the number of HTML elements low helps the browser render faster. Rendering only the visible portion of long lists prevents the Document Oject Model (DOM) from becoming bloated. Splitting scripts and deferring non‑critical code ensures that essential interactions load first.

Using CSS transforms and opacity changes avoids expensive layout recalculations. Lazy‑loading images, videos, and scripts ensures that the interface becomes interactive long before all assets are downloaded.

These optimizations don’t just improve raw speed — they create the foundation for interfaces that feel responsive.

Design Takeaways from Doherty Threshold

Instant Feedback: When a user clicks a button, provide a visual change (like a button press animation or a spinner) immediately, even if the background task takes longer.

Skeleton Screens: Use placeholder blocks that mimic the layout of the page while data loads. This makes the app feel like it is responding instantly.

Progressive Loading: Load text and basic structures first, then "pop in" high-resolution images later.

Optimistic UI: When a user hits "Save," don't wait for the server. Update the UI instantly (Doherty) and handle the "messy" data formatting on the backend (Postel).

Live Inline Validation: Show a green checkmark or a helpful error message as the user types. This keeps them below the 400ms "thought-break" limit.

Debouncing: In search bars, start showing results after a few keystrokes so the user feels the app is "predicting" their needs.

To Sum Up: When response times stay below a certain limit, users remain focused and productive. But once performance already meets this optimal responsiveness level, making the system even faster or adding extra capability doesn't significantly enhance satisfaction or efficiency.

13.0 Serial Position Effect (Primacy and Recency):

Murdock’s study investigated how the position of a word in a list affects recall, known as the serial position effect. He presented 103 psychology students with lists of 10 to 40 words, one at a time, at either 1 or 2 seconds per word (McLeod, 2025).

Participants were divided into six groups, each experiencing a different combination of list length and presentation rate, and were asked to recall as many words as possible in any order.

The results showed that participants were most likely to remember words at the beginning of the list (primacy effect) and at the end of the list (recency effect), while words in the middle were recalled less often. The recency effect persisted even in longer lists, and the middle section of the recall curve formed a flat asymptote.

Murdock explained this using the multi-store model of memory: early words were rehearsed and transferred to long-term memory, last words remained in short-term memory, and middle words were neither sufficiently rehearsed nor retained, leading to poorer recall.

The experiment demonstrated that memory performance varies systematically with the position of information in a sequence.

This is the reason why the most important information or actions should never be buried in the middle.

As a developer, you should put your most critical navigation links (like "Home" or "Dashboard") at the far left or the top of a list. In a pricing table, put the most popular or recommended plan on the Place "Final Actions" (like "Log Out," "Cart," or "Support") at the end of a menu or the far right of a navigation bar.

In a long onboarding flow, put the most exciting benefit of the app on the very last slide so the user enters the app feeling motivated.

Avoid placing highly important buttons in the middle of a row. If you have a row of 7 buttons, the user is statistically likely to overlook the 4th one.

Design Takeaways Serial Position Effect

Place Critical Items at the Beginning or End — Never the Middle:
Users reliably remember the first and last items in any sequence (primacy and recency). Anything placed in the middle is statistically more likely to be forgotten or ignored. Also, actions such as “Log Out,” “Cart,” “Support,” or “Checkout” should sit at the far right or bottom — the natural recency position.

Put Essential Navigation Links at the Far Left or Top:
Links like “Home,” “Dashboard,” or “Overview” should appear at the start of a menu, where recall and recognition are strongest.

To Sum Up: The results showed that participants were most likely to remember words at the beginning of the list (primacy effect) and at the end of the list (recency effect), while words in the middle were recalled less often.

14.0 Occam’s Razor:

Although first articulated in the 14th century by the Franciscan friar William of Ockham, Occam’s Razor remains one of the most indispensable principles in a developer’s toolkit. In fact, skipping this law while discussing other theories and principles would be like skipping the glue that holds the entire framework together.

At its core, Occam’s Razor states that “among competing explanations, the simplest one is usually the best.”

For example, if two user interfaces achieve the same goal, the one with fewer visual elements is typically superior because it requires less processing power.

The fundamental takeaway for modern developers regarding Occam’s Razor is that complexity is a tax on the user’s cognitive resources.

In an era of information density, the developer's primary role is no longer to provide "more" features – rather, it's to curate the most direct path to a solution.

In practice, Occam’s Razor becomes a reminder to keep things as simple as possible. This “less is more” mindset shapes everything from navigation to forms.

A good rule for navigation is the Rule of Five: aim for three to five main menu items instead of a long, overwhelming list. This keeps choices clear and prevents users from freezing up when they see too many options.

The same idea applies to data entry. When you ask only for the information that truly matters, you respect the user’s time and reduce the chance of “form fatigue,” which is one of the biggest reasons people abandon sign‑ups or checkout flows.

Simplicity isn’t just elegant — it’s practical, humane, and far more effective.

Design Takeaway from Occam's Razor

Choose the Simplest Effective Solution:
When two designs achieve the same goal, the one with fewer elements is almost always better. Simplicity reduces cognitive load and speeds up user decision‑making.

Simplicity Is Not Just Aesthetic — It’s Humane:
Clear, minimal interfaces respect the user’s time, reduce friction, and make the product feel effortless. Simplicity is both a design strategy and an act of empathy.

To Sum Up: Simplicity isn’t just elegant — it’s practical, humane, and far more effective.

15.0 Parkinson's Law

Occam’s Razor teaches us to prefer the simplest solution that works. But why do we so often end up with complex systems in the first place? That tendency is explained by another principle: Parkinson’s Law.

Parkinson’s Law states that "work expands to fill the time available for its completion". In design, this means projects often become overly complex or take longer than necessary if given too much time, resulting in inefficient, over-designed, or cluttered interfaces.

In design, this manifests as Feature Creep. If you give yourself three months to build an app, you will spend three months adding "nice-to-have" animations, extra settings toggles, and niche edge cases that nobody asked for and in reality, what you have added isn’t that important.

You just succeeded in adding layers of complexity that might ends up violating some of the laws we spoke about. Occam’s Razor reminds us that the simplest solution is often the most effective.

By being aware of Parkinson’s Law and the tendency for work to expand, developers can manage their time intentionally and focus only on what truly matters.

Design Takeaway for Parkinson's law

Set Clear Constraints to Keep Designs Focused:
Intentional time limits and scope boundaries prevent over‑designing. Constraints force clarity, prioritisation, and simplicity.

Build Only What Truly Matters for the User:
Parkinson’s Law reminds you to resist the urge to fill time with unnecessary features. Focus on the core experience, not the edge cases nobody asked for.

Use Occam’s Razor to Counterbalance Parkinson’s Law:
As work expands, complexity grows. Occam’s Razor pulls you back to the simplest effective solution. Together, the two principles prevent bloated, over‑engineered products.

To Sum Up: Work expands to fill the time available for its completion

Conclusion

Human-centered design is deeply influenced by a set of psychological principles that explain how users perceive, process, and interact with digital systems.

Among these, Fitts’s Law establishes that the time required to acquire a target depends on its size and distance. In practice, this means that larger and closer elements are easier and faster to interact with.

To apply this in practice, developers should make primary call-to-action elements prominent, large, and easily reachable – especially in mobile interfaces where thumb accessibility is critical.

Closely related to decision-making is Hick’s Law, which states that the more choices a user is presented with, the longer it takes to make a decision. Excessive options can overwhelm users and lead to decision fatigue.

To address this, developers should simplify interfaces, minimise unnecessary options, and guide users through processes step-by-step rather than presenting everything at once.

Another important cognitive principle discussed is Miller’s Law, which suggests that the average person can hold approximately seven (plus or minus two) items in working memory at a time. This limitation highlights the need to present information in manageable chunks.

By breaking content into smaller groups and avoiding information overload, developers can improve comprehension and usability.

User expectations are strongly shaped by Jakob’s Law, which says that people spend most of their time on other websites and therefore expect similar patterns across digital products.

Instead of reinventing basic interactions, developers should follow familiar conventions such as placing the logo in the top‑left, the shopping cart in the top‑right, and keeping scrolling behaviour predictable.

But innovation is still possible where it truly adds value. As we discussed with the Aesthetic‑Usability Effect, users are far more tolerant of new or unusual design patterns when the interface is visually appealing and thoughtfully crafted.

The Gestalt Principles provided additional insight into how users visually organise information. The principle of proximity suggests that objects placed close together are perceived as related, so grouping related elements improves clarity. Similarity indicates that elements with consistent colours, shapes, or styles are seen as belonging together, reinforcing visual hierarchy and function. Closure explains that users can perceive incomplete shapes as complete, allowing for minimalistic designs where the brain fills in missing details. Continuity highlights that users naturally follow smooth visual paths, meaning layouts should guide the eye logically through alignment and structure.

We also looked at The Von Restorff Effect which emphasizes that elements which stand out are more likely to be remembered. By using contrast in colour, size, or design, important features such as buttons or alerts can capture user attention.

Managing complexity was addressed by Tesler’s Law, which asserts that every system has inherent complexity that cannot be eliminated but only managed.

Developers must therefore shift complexity away from the user by simplifying interfaces while handling intricate processes behind the scenes.

The Zeigarnik Effect reveals that people remember unfinished tasks better than completed ones, creating a sense of mental tension. This can be leveraged by incorporating progress indicators, checklists, and reminders that encourage users to complete tasks.

Similarly, the Peak-End Rule suggests that users judge an experience based on its most intense moment and its conclusion. Developers should create memorable highlights and ensure a smooth, satisfying ending to user journeys.

We also discussed the Goal-Gradient Effect, which explains that users become more motivated as they approach the completion of a task. By showing progress –such as indicating that a process is “80% complete” – and breaking tasks into stages, developers can encourage users to finish what they have started.

In terms of system interaction, Postel’s Law advises developers to be flexible in accepting user input while maintaining strict standards for output. This means allowing different input formats while ensuring consistent and reliable system responses.

Performance is equally important, as highlighted by the Doherty Threshold, which shows that productivity increases when system response times stay under 400 milliseconds. Fast systems keep users engaged and create a sense of ease.

This means that developers should focus on building interfaces that feel instant, even when real processing takes longer, by combining smart engineering practices with thoughtful design patterns that maintain the illusion of speed.

Memory and attention are further explained by the Serial Position Effect, where users tend to remember the first and last items in a sequence more than those in the middle. Developers should position key information or actions at the beginning or end of lists.

Simplicity is reinforced by Occam’s Razor, which argues that the simplest solution is often the most effective. Eliminating unnecessary features reduces friction and enhances usability, and we further discussed about Parkinson’s Law, which suggests that tasks expand to fill the time available, indicating the importance of setting constraints such as deadlines or timers to encourage timely action.

These principles collectively highlight the importance of simplicity, clarity, performance, and user psychology in design. By applying them thoughtfully, developers can create intuitive, efficient, and engaging user experiences that align with both human behaviour and user expectations.

References

Budiu, R. (2022). Fitts’s Law and Its Applications in UX. [online] Nielsen Norman Group. Available at: https://www.nngroup.com/articles/fitts-law/.

Bustamante, N. (2023). Gestalt Psychology? Definition, Principles, & Examples - Simply Psychology. [online] www.simplypsychology.org. Available at: https://www.simplypsychology.org/what-is-gestalt-psychology.html.

Cherry, K. (2024). The Zeigarnik Effect Is Why You Keep Thinking of Unfinished Work. [online] Verywell Mind. Available at: https://www.verywellmind.com/zeigarnik-effect-memory-overview-4175150.

DO, A.M., RUPERT, A.V. and WOLFORD, G. (2008). Evaluations of pleasurable experiences: The peak-end rule. Psychonomic Bulletin & Review, 15(1), pp.96–98. doi:https://doi.org/10.3758/pbr.15.1.96.

GUPTA, S., GUPTA, S., MAHENDRA, A. and GUPTA, S. (2006). Inverse Halo Nevus. Dermatologic Surgery, 32(6), pp.871–872. doi:https://doi.org/10.1097/00042728-200606000-00025.

‌Hall, D. (2023). Pilot Error, Chapanis and The Shape of Things to Come. [online] UX Magazine. Available at: https://uxmag.com/articles/pilot-error-chapanis-and-the-shape-of-things-to-come.

Hunt, R.R. (1995). The subtlety of distinctiveness: What von Restorff really did. Psychonomic Bulletin & Review, 2(1), pp.105–112. doi:https://doi.org/10.3758/bf03214414.

Kahneman, D., Fredrickson, B.L., Schreiber, C.A. and Redelmeier, D.A. (1993). When More Pain Is Preferred to Less: Adding a Better End. Psychological Science, 4(6), pp.401–405. doi:https://doi.org/10.1111/j.1467-9280.1993.tb00589.x.

Mod, D. (2024). Doherty Threshold: UX Law of Swift Interactions. [online] Articles on everything UX: Research, Testing & Design. Available at: https://blog.uxtweak.com/doherty-threshold/.

Miller, G.A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, [online] 101(2), pp.343–352. doi:https://doi.org/10.1037/0033-295x.101.2.343.

Proctor, R.W. and Schneider, D.W. (2018). Hick’s law for choice reaction time: A review. Quarterly Journal of Experimental Psychology, [online] 71(6), pp.1281–1299. doi:https://doi.org/10.1080/17470218.2017.1322622.

Yablonski, J. (2022). Hick’s Law. [online] Laws of UX. Available at: https://lawsofux.com/hicks-law/.

Yablonski, J. (2022). Goal-Gradient Effect. [online] Laws of UX. Available at: https://lawsofux.com/goal-gradient-effect/.

‌

‌

‌

The backend team talks about bounded contexts, eventual consistency, and service meshes. You're thinking about loading states, stale data, and why the checkout page breaks when the inventory service is slow.

This article is for frontend engineers working in microservice environments. You'll learn how to consume multiple service APIs without creating a tangled mess, how to handle partial failures gracefully in the UI, how to manage distributed state across services, and how to work effectively with backend teams on API contracts because half the battle is communication, not code.

The goal is not to turn you into a backend engineer, it's to give you the mental models and patterns that make frontend development in a microservice world less painful.

Prerequisites

To get the most out of this article, you should be familiar with:

• React or a similar component framework (the examples use React and TypeScript)

• Basic understanding of REST APIs and HTTP

• Experience fetching data in frontend applications (fetch, Axios, or React Query)

• General awareness of what microservices are (you don't need to have built one)

Table of Contents

• The Frontend's Microservice Problem

• Pattern 1: The Backend-for-Frontend (BFF)

• Pattern 2: Handling Partial Failures in the UI

• Pattern 3: Managing Distributed State

• Pattern 4: Taming Multiple API Contracts

• Pattern 5: Timeout Budgets for Page Assembly

• Pattern 6: Error Boundaries Per Service

• Working With Backend Teams on Contracts

• When to Push Back

• Conclusion

The Frontend's Microservice Problem

In a monolithic architecture, the frontend talks to one API. That API owns the database, handles the business logic, and returns exactly the shape of data the UI needs. Life is simple.

In a microservice architecture, that single API fractures into many:

Monolith:
  Browser → API → Database

Microservices:
  Browser → API Gateway → User Service
                        → Order Service
                        → Inventory Service
                        → Payment Service
                        → Notification Service

Each of those services is owned by a different team, deployed independently, and may use different data formats or conventions. As a frontend engineer, you now have several new problems:

1. Multiple contracts: Each service has its own API shape. A "product" in the inventory service has different fields than a "product" in the catalog service.

2. Partial failures: The order service might respond in 50 ms while the recommendation service times out. Your UI needs to handle both.

3. Data consistency: A user updates their address, but the order service still shows the old one because it hasn't synced yet.

4. Increased latency: Assembling a single page might require three or four API calls instead of one.

These aren't backend problems that happen to affect the frontend. They're fundamentally frontend problems that require frontend solutions.

Pattern 1: The Backend-for-Frontend (BFF)

The most impactful pattern for frontend teams in a microservice world is the Backend-for-Frontend. A BFF is a thin API layer that sits between the browser and the microservices. It's owned by the frontend team and exists to serve the frontend's specific needs.

Without BFF:
  Browser → User Service    (call 1)
  Browser → Order Service   (call 2)
  Browser → Inventory Service (call 3)
  3 round trips, 3 contracts to manage

With BFF:
  Browser → BFF → User Service
                → Order Service
                → Inventory Service
  1 round trip, 1 contract to manage

The BFF aggregates calls, transforms responses into the shapes your components need, and handles cross-service concerns like authentication token forwarding.

// BFF endpoint: GET /api/order-summary/:orderId
// Aggregates data from three services into one frontend-friendly response
import express from "express";

const router = express.Router();

router.get("/api/order-summary/:orderId", async (req, res) => {
  const { orderId } = req.params;
  const token = req.headers.authorization;

  try {
    const [order, customer, shipment] = await Promise.allSettled([
      fetch(`\({ORDER_SERVICE}/orders/\){orderId}`, {
        headers: { Authorization: token },
      }).then((r) => r.json()),
      fetch(`\({USER_SERVICE}/users/\){req.userId}`, { // userId set by auth middleware
        headers: { Authorization: token },
      }).then((r) => r.json()),
      fetch(`\({SHIPPING_SERVICE}/shipments?orderId=\){orderId}`, {
        headers: { Authorization: token },
      }).then((r) => r.json()),
    ]);

    res.json({
      order: order.status === "fulfilled" ? order.value : null,
      customer: customer.status === "fulfilled" ? customer.value : null,
      shipment: shipment.status === "fulfilled" ? shipment.value : null,
      errors: [order, customer, shipment]
        .filter((r) => r.status === "rejected")
        .map((r) => r.reason.message),
    });
  } catch (error) {
    res.status(500).json({ error: "Failed to assemble order summary" });
  }
});

Notice the use of Promise.allSettled instead of Promise.all. This is critical in a microservice environment. Promise.all fails fast: if any one service is down, the entire request fails. Promise.allSettled lets you return partial data, which leads directly to the next pattern.

When to Use a BFF

A BFF is worth the investment when:

• Your frontend aggregates data from three or more services per page

• Different clients (web, mobile, admin) need different data shapes from the same services

• You want the frontend team to control response shapes without waiting on backend teams

A BFF isn't necessary when:

• You have an API gateway that already handles aggregation (for example, Apollo Federation for GraphQL)

• You only consume one or two services

• Your backend teams already provide frontend-optimized endpoints

Pattern 2: Handling Partial Failures in the UI

In a monolith, a request either succeeds or fails. In a microservice world, it can partially succeed. The order data loads fine, but the recommendation service is down. The product details are available, but the review service is slow.

Your UI needs to handle this gracefully. The key principle: never let a non-critical service failure break a critical user flow.

// Types for partial data loading
interface ServiceResult<T> {
  data: T | null;
  status: "loaded" | "error" | "loading";
  error?: string;
}

interface OrderPageData {
  order: ServiceResult<Order>;
  recommendations: ServiceResult<Product[]>;
  reviews: ServiceResult<Review[]>;
}

Build your components to render independently based on what data is available:

function OrderPage({ orderId }: { orderId: string }) {
  const { order, recommendations, reviews } = useOrderPageData(orderId);

  // Critical: order must load or the page makes no sense
  if (order.status === "loading") return <OrderSkeleton />;
  if (order.status === "error") return <ErrorPage message={order.error} />;

  return (
    <div>
      {/* Critical section: always rendered */}
      <OrderDetails order={order.data} />

      {/* Non-critical: degrades gracefully */}
      <section aria-label="Recommendations">
        {recommendations.status === "loaded" ? (
          <RecommendationCarousel products={recommendations.data} />
        ) : recommendations.status === "error" ? (
          <EmptyState message="Recommendations Unavailable" />
        ) : (
          <CarouselSkeleton />
        )}
      </section>

      {/* Non-critical: degrades gracefully */}
      <section aria-label="Customer reviews">
        {reviews.status === "loaded" ? (
          <ReviewList reviews={reviews.data} />
        ) : reviews.status === "error" ? (
          <EmptyState message="Reviews unavailable right now" />
        ) : (
          <ReviewSkeleton />
        )}
      </section>
    </div>
  );
}

Classifying Critical vs. Non-Critical Data

Not all data on a page is equally important. Before building any page that pulls from multiple services, classify each data source:

This classification should be a conscious decision made with your product team, not something you discover when a service goes down in production.

Pattern 3: Managing Distributed State

In a monolithic world, the server is the single source of truth. In a microservice world, truth is distributed. The user service knows the user's current address. The order service has a snapshot of the address at the time of the order. These might not match.

Stale Data and Cache Boundaries

When your frontend caches data from multiple services, you need to think about cache boundaries. Data from different services goes stale at different rates.

// Configure cache times based on how frequently the underlying data changes
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 30_000, // Default: 30 seconds
    },
  },
});

// Product catalog: changes infrequently
function useProduct(productId: string) {
  return useQuery({
    queryKey: ["product", productId],
    queryFn: () => fetchProduct(productId),
    staleTime: 5 * 60_000, // 5 minutes: catalog updates are rare
  });
}

// Inventory levels: changes constantly
function useStockLevel(productId: string) {
  return useQuery({
    queryKey: ["stock", productId],
    queryFn: () => fetchStockLevel(productId),
    staleTime: 10_000, // 10 seconds: stock changes with every purchase
    refetchInterval: 30_000, // Poll every 30 seconds on active pages
  });
}

// User's own order: should reflect latest state
function useOrder(orderId: string) {
  return useQuery({
    queryKey: ["order", orderId],
    queryFn: () => fetchOrder(orderId),
    staleTime: 0, // Always refetch: user expects to see their latest action
  });
}

The mistake is treating all cached data the same. Product information from the catalog service can be cached for minutes. Stock levels from the inventory service need to be refreshed much more frequently. A user's own order data should always be fresh because they just performed an action and expect to see the result.

Cross-Service Invalidation

The trickiest part of distributed state is knowing when to invalidate. When a user places an order, you need to:

1. Invalidate the order list (order service)

2. Invalidate the stock level (inventory service)

3. Invalidate the user's loyalty points (user service)

// After a successful order placement, invalidate across service boundaries
async function placeOrder(cart: Cart): Promise<Order> {
  const order = await api.post("/api/orders", { items: cart.items });

  // Invalidate data from multiple services that this action affected
  queryClient.invalidateQueries({ queryKey: ["orders"] });
  queryClient.invalidateQueries({ queryKey: ["stock"] });
  queryClient.invalidateQueries({ queryKey: ["loyalty-points"] });

  // Optimistically update the cart (owned by the frontend)
  queryClient.setQueryData(["cart"], { items: [] });

  return order;
}

This is manual and error-prone. Every time a new service cares about order events, you need to remember to add an invalidation here.

For more robust alternatives, you can use server-sent events or WebSocket connections to let the backend push invalidation signals to the frontend, or adopt a pub/sub pattern within your client-side state layer where cache keys subscribe to domain events.

These approaches are beyond this article's scope, but worth exploring once your invalidation table grows past a dozen entries.

In the meantime, documenting these cross-service dependencies in a table helps:

Pattern 4: Taming Multiple API Contracts

In a microservice world, each service defines its own API contract. The user service returns firstName and lastName. The order service returns customerName as a single string. The notification service expects fullName. Same concept, three different field names.

The Adapter Layer

Create an adapter layer that translates each service's response into a consistent domain model that your components use:

// Domain models: what the frontend actually works with
interface User {
  id: string;
  fullName: string;
  email: string;
  address: Address;
}

// Adapter for the User Service
function adaptUserServiceResponse(raw: UserServiceResponse): User {
  return {
    id: raw.userId,
    fullName: `\({raw.firstName} \){raw.lastName}`,
    email: raw.emailAddress,
    address: {
      line1: raw.address.street,
      city: raw.address.city,
      postcode: raw.address.zipCode,
      country: raw.address.countryCode,
    },
  };
}

// Adapter for the Order Service (which embeds a different user shape)
function adaptOrderCustomer(raw: OrderServiceCustomer): User {
  return {
    id: raw.customerId,
    fullName: raw.customerName,
    email: raw.email,
    address: {
      line1: raw.shippingAddress.addressLine1,
      city: raw.shippingAddress.city,
      postcode: raw.shippingAddress.postalCode,
      country: raw.shippingAddress.country,
    },
  };
}

Your components only work with the User type. They never see the raw service responses. When a service changes its API, you update one adapter, not every component that displays a user's name.

Where to Put the Adapter Layer

If you have a BFF, the adapters live there. The browser never sees the raw service response. If you're calling services directly from the frontend, place the adapters in your data-fetching layer, between the HTTP call and the cache:

// The adapter runs before data enters the cache
function useUser(userId: string) {
  return useQuery({
    queryKey: ["user", userId],
    queryFn: async () => {
      const raw = await fetch(`/api/users/${userId}`).then((r) => r.json());
      return adaptUserServiceResponse(raw);
    },
  });
}

Pattern 5: Timeout Budgets for Page Assembly

When a page depends on multiple services, you need a timeout strategy. Without one, your page load time is determined by the slowest service, and in a microservice world, there's always a slow service.

A timeout budget allocates a maximum time for assembling all the data a page needs. If a non-critical service doesn't respond within its budget, you render without it.

In practice, this utility lives in a shared service layer (for example, lib/api.ts) rather than inline with each page's assembly logic. Here's the implementation:

// lib/api.ts: shared timeout utility
async function fetchWithTimeout<T>(
  url: string,
  options: RequestInit,
  timeoutMs: number
): Promise<T | null> {
  const controller = new AbortController();
  const timeout = setTimeout(() => controller.abort(), timeoutMs);

  try {
    const response = await fetch(url, {
      ...options,
      signal: controller.signal,
    });
    return response.json();
  } catch (error) {
    if (error instanceof DOMException && error.name === "AbortError") {
      console.warn(`Request to \({url} timed out after \){timeoutMs}ms`);
    }
    return null;
  } finally {
    clearTimeout(timeout);
  }
}

// Page assembly with tiered timeouts
async function assembleProductPage(productId: string): Promise<ProductPageData> {
  // Critical data: longer timeout, page fails without it
  const product = await fetchWithTimeout<Product>(
    `/api/products/${productId}`,
    {},
    3000 // 3 second budget for critical data
  );

  if (!product) {
    throw new Error("Product not found");
  }

  // Non-critical data: shorter timeout, page renders without it
  const [reviews, recommendations, relatedProducts] = await Promise.all([
    fetchWithTimeout<Review[]>(
      `/api/reviews?productId=${productId}`,
      {},
      1500 // 1.5 second budget
    ),
    fetchWithTimeout<Product[]>(
      `/api/recommendations?productId=${productId}`,
      {},
      1000 // 1 second budget: nice to have
    ),
    fetchWithTimeout<Product[]>(
      `/api/products/${productId}/related`,
      {},
      1000
    ),
  ]);

  return {
    product,
    reviews: reviews ?? [],
    recommendations: recommendations ?? [],
    relatedProducts: relatedProducts ?? [],
  };
}

Notice the different budgets. Critical data (the product itself) gets 3 seconds. Non-critical data (reviews, recommendations) gets 1–1.5 seconds. If recommendations are slow, you show the product without them. The user doesn't wait for a service they may not even look at.

Pattern 6: Error Boundaries Per Service

React error boundaries are especially powerful in a microservice frontend. Instead of one error boundary at the page level, place boundaries around sections that map to different backend services.

If you haven't used error boundaries before, here's a minimal implementation. Error boundaries must be class components, React doesn't support them as function components yet (see the React docs for more detail):

class ErrorBoundary extends React.Component<
  { fallback: React.ReactNode; children: React.ReactNode },
  { hasError: boolean } > {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo) {
    console.error("ErrorBoundary caught:", error, info);
  }

  render() {
    if (this.state.hasError) return this.props.fallback;
    return this.props.children;
  }
}

With that in place, scope your boundaries to individual service sections:

function ProductPage({ productId }: { productId: string }) {
  return (
    <div>
      {/* If the product service fails, show a full-page error */}
      <ErrorBoundary fallback={<ProductErrorPage />}>
        <Suspense fallback={<ProductSkeleton />}>
          <ProductDetails productId={productId} />
        </Suspense>
      </ErrorBoundary>

      {/* If the review service fails, just hide reviews */}
      <ErrorBoundary fallback={<EmptyState message="Reviews unavailable" />}>
        <Suspense fallback={<ReviewSkeleton />}>
          <ProductReviews productId={productId} />
        </Suspense>
      </ErrorBoundary>

      {/* If recommendations fail, hide silently */}
      <ErrorBoundary fallback={null}>
        <Suspense fallback={<CarouselSkeleton />}>
          <Recommendations productId={productId} />
        </Suspense>
      </ErrorBoundary>
    </div>
  );
}

Each boundary catches errors from its own data source independently. The review service crashing doesn't affect the product details. The recommendation service timing out doesn't show an error at all – the section simply doesn't render.

This maps directly to your critical/non-critical classification. Critical services get error boundaries with visible error UI. Non-critical services get boundaries that degrade silently or show a minimal empty state.

Working With Backend Teams on Contracts

The technical patterns above solve symptoms. The root cause of most frontend pain in microservice environments is poor communication between frontend and backend teams about API contracts.

Contract Conversations to Have Early

1. What fields will the frontend actually use?

Backend services often expose their entire data model. The frontend uses three fields. If the backend team knows which fields you depend on, they can maintain those fields more carefully and deprecate the ones nobody uses.

2. What is the expected latency budget for this endpoint?

If the product page has a 2-second total budget and the recommendation service averages 1.8 seconds, you have a problem before you write any frontend code. Surface this early.

3. What happens when this service is degraded?

Ask each backend team: "If your service responds with 500 errors for an hour, what should the frontend show?" This question often reveals that nobody has thought about it, which is exactly why you need to ask.

4. How will you communicate breaking changes?

Agree on a process. Whether it is OpenAPI spec diffs in pull requests, a Slack channel for API changes, or versioned endpoints, pick something and hold each other to it.

API Contracts as Shared Artifacts

Push for machine-readable contracts. OpenAPI specs, GraphQL schemas, or Protocol Buffer definitions serve as a shared source of truth between frontend and backend teams. They enable:

• Automated type generation: Tools like openapi-typescript generate TypeScript types from OpenAPI specs. When the backend changes a field, your build fails immediately, not in production.

• Contract testing: Tools like Pact let you define the expected request/response pairs from the frontend's perspective. The backend runs these tests in their CI pipeline. If their changes break the frontend's expectations, the pipeline fails.

• Mock servers: Generated mocks from the spec let you build the frontend before the backend is ready. When the real service ships, your code already works.

// Generated types from OpenAPI spec, always in sync with the backend
import type { components } from "./generated/inventory-api";

type Product = components["schemas"]["Product"];
type StockLevel = components["schemas"]["StockLevel"];

// If the backend renames "available" to "inStock",
// this code fails at compile time, not in production
function formatStockMessage(stock: StockLevel): string {
  if (stock.available > 10) return "In Stock";
  if (stock.available > 0) return `Only ${stock.available} left`;
  return "Out of Stock";
}

Testing Against Multiple Services

Contract testing catches backend-side breaking changes, but you also need to test your frontend's behavior when services respond in unexpected ways. Mock Service Worker (MSW) lets you spin up per-service mock handlers in your test environment:

import { setupServer } from "msw/node";
import { http, HttpResponse } from "msw";

// Mock each service independently
const server = setupServer(
  http.get("/api/products/:id", () =>
    HttpResponse.json({ productId: "abc-123", name: "Widget", price: 49.99 })
  ),
  http.get("/api/reviews", () =>
    HttpResponse.json([{ rating: 5, body: "Great product" }])
  )
);

// Test: what happens when the review service is down?
test("renders product page when reviews service fails", async () => {
  server.use(
    http.get("/api/reviews", () => HttpResponse.error())
  );

  render(<ProductPage productId="abc-123" />);

  expect(await screen.findByText("Widget")).toBeInTheDocument();
  expect(await screen.findByText("Reviews unavailable")).toBeInTheDocument();
});

This lets you simulate the partial failure scenarios from Pattern 2 in your test suite. Test your adapter layer (Pattern 4) with unit tests against raw service response fixtures, and use MSW for integration tests that verify the full page assembles correctly when individual services are slow, down, or return unexpected shapes.

When to Push Back

Not every microservice problem has a frontend solution. Sometimes the right answer is to push back on the architecture.

Push back when the frontend is making more than 5 API calls for a single page. This is a signal that either the services are too granular or there is a missing aggregation layer. The fix is a BFF or a composite API, not more Promise.all calls in the browser.

Push back when two services return conflicting data about the same entity. If the user service says the user's name is "Jane" and the order service says it is "Janet," this is a data consistency problem that the frontend can't solve. It needs to be fixed at the source, either through event-driven syncing between services or by establishing one service as the authoritative source for that field.

Push back when backend teams make breaking changes without notice. If your production app breaks because a service renamed a field in a minor version bump, that's a process failure. Advocate for versioned APIs, deprecation notices, and contract testing.

You're not just a consumer of APIs. You're a stakeholder in how those APIs are designed. The earlier you participate in API design conversations, the fewer surprises you deal with in production.

Conclusion

The patterns in this article give you a structured starting point, but the underlying principle is consistent across all of them:

Key takeaways:

1. Own the aggregation layer: A BFF gives the frontend team control over response shapes and lets you handle partial failures at the server level instead of the browser.

2. Classify every data source as critical or non-critical: This single decision determines your error handling, timeout budgets, and loading strategies for every section of every page.

3. Normalize at the boundary: Adapter layers between raw service responses and your components protect you from upstream API changes and give you a consistent domain model.

4. Invest in contracts: Machine-readable API contracts, generated types, and contract testing catch breaking changes at build time instead of in production.

5. Push back when needed: Not every microservice problem has a frontend solution. If the architecture creates an unreasonable burden on the UI layer, say so early.

Microservices are a backend architecture decision, but their consequences are felt most acutely in the frontend. The patterns in this article won't make that complexity disappear, but they will give you a structured way to manage it.

Sometimes you don’t need the entire document. You just need a few pages — maybe a specific section, a report summary, or selected invoice pages.

Most tools require uploading files or installing software. But modern browsers are powerful enough to handle this locally.

In this tutorial, you’ll learn how to build a browser-based PDF splitter using JavaScript, where everything runs directly in the user’s browser.

By the end, you’ll understand how to extract specific pages from a PDF, create a new document from those pages, and download the result instantly.

Table of Contents

• How PDF Splitting Works in the Browser

• Project Setup

• What Library Are We Using?

• Creating the Upload Interface

• Reading the PDF File

• Selecting Pages to Extract or Split

• Splitting the PDF Using JavaScript

• Generating and Downloading the PDF

• Demo: How the PDF Split Tool Works

• Important Notes from Real-World Use

• Common Mistakes to Avoid

• Conclusion

How PDF Splitting Works in the Browser

Splitting a PDF means taking a single document and extracting specific pages into a new file.

Traditionally, this kind of processing is handled on a server. But with modern JavaScript libraries like pdf-lib, we can do everything directly in the browser.

The process is straightforward. A user uploads a PDF file, the browser reads it, and we can display a preview of its pages to help users understand what they’re working with. Based on the selected split mode or page input, we then extract only the required pages and copy them into a new PDF document.

All of this happens locally in the browser, which makes the process faster and ensures that user files never leave their device.

Project Setup

We’ll keep this project simple.

You only need:

• an HTML file

• JavaScript

• a PDF processing library

No backend or server is required.

What Library Are We Using?

We’ll use pdf-lib, a lightweight JavaScript library for working with PDFs.

Add it using a CDN:

<script src="https://unpkg.com/pdf-lib@1.17.1/dist/pdf-lib.min.js"></script>

This library allows us to:

• load PDFs

• copy pages

• create new documents

Creating the Upload Interface

Start with a simple file input:

<input type="file" id="upload" accept="application/pdf">
<input type="text" id="pages" placeholder="Enter pages (e.g. 1-3,5)">
<button onclick="splitPDF()">Split PDF</button>

<a id="download" style="display:none;">Download Split PDF</a>

This interface allows users to upload a PDF file, specify which pages they want to extract, and trigger the splitting process with a single click. Once the process is complete, the download link becomes visible so they can save the new PDF.

Reading the PDF File

Now let’s read the uploaded file:

const fileInput = document.getElementById("upload");

if (!fileInput.files.length) {
  alert("Please upload a PDF file");
  return;
}

const file = fileInput.files[0];
const arrayBuffer = await file.arrayBuffer();

This converts the file into a format the library can use.

Selecting Pages to Extract or Split

Users can control how the PDF is split in multiple ways.

They can manually enter page ranges like 1-3,5, which allows precise selection of pages. For example, entering 1-3 extracts pages 1 to 3, while 5 selects only page 5.

In addition to manual input, the tool also provides predefined options such as splitting all pages, extracting only even or odd pages, or splitting the document into fixed-size ranges. These options make it easier for users who don’t want to type page ranges manually.

To support manual input, we use a simple parser that converts the user’s input into valid page indexes:

function parsePages(input, totalPages) {
  const pages = [];

  input.split(',').forEach(part => {
    if (part.includes('-')) {
      const [start, end] = part.split('-').map(Number);
      for (let i = start; i <= end; i++) {
        if (i <= totalPages) pages.push(i - 1);
      }
    } else {
      const num = parseInt(part);
      if (num <= totalPages) pages.push(num - 1);
    }
  });

  return pages;
}

This approach gives flexibility, allowing both simple and advanced ways to select pages depending on the user’s needs.

Splitting the PDF Using JavaScript

Now comes the main logic:

async function splitPDF() {
  const fileInput = document.getElementById("upload");
  const pageInput = document.getElementById("pages").value;

  if (!fileInput.files.length || !pageInput.trim()) {
    alert("Please upload a PDF and enter page numbers");
    return;
  }

  const file = fileInput.files[0];
  const arrayBuffer = await file.arrayBuffer();

  const { PDFDocument } = PDFLib;

  const originalPdf = await PDFDocument.load(arrayBuffer);
  const totalPages = originalPdf.getPageCount();

  const selectedPages = parsePages(pageInput, totalPages);

  const newPdf = await PDFDocument.create();

  const copiedPages = await newPdf.copyPages(originalPdf, selectedPages);

  copiedPages.forEach(page => newPdf.addPage(page));

  const pdfBytes = await newPdf.save();

  const blob = new Blob([pdfBytes], { type: "application/pdf" });

  const link = document.getElementById("download");
  link.href = URL.createObjectURL(blob);
  link.download = "split.pdf";
  link.style.display = "inline";
  link.innerText = "Download Split PDF";
}

This:

• loads the original file

• extracts selected pages

• creates a new PDF

• prepares it for download

Generating and Downloading the PDF

Once the PDF is created:

link.href = URL.createObjectURL(blob);
link.download = "split.pdf";

The browser handles the download instantly — no server needed.

Demo: How the PDF Split Tool Works

Here’s how the full flow looks in practice using the tool:

Step 1: Upload Your PDF

Start by dragging and dropping your PDF file into the upload area, or click the button to select a file from your device. Once uploaded, the tool instantly processes the document and prepares it for splitting.

Step 2: Preview Pages

After uploading, all pages of the PDF are displayed as thumbnails. This gives you a clear visual overview of the document so you can decide how you want to split it.

Step 3: Choose Split Mode and Options

Next, choose how you want to split the PDF. You can select options like splitting by page range, extracting all pages, splitting odd or even pages, or dividing the document into fixed-size sections. This flexibility makes it easy to handle different use cases without manually selecting every page.

Step 4: Split the PDF

Once your settings are ready, click the split button. The browser processes the file locally and generates the new PDFs based on your selected mode.

Step 5: Download the Results

After processing, the split files are displayed with download options. You can download individual files or download all of them at once. Everything happens instantly in the browser without uploading your files anywhere.

Important Notes from Real-World Use

When working with PDF splitting, input validation is important.

Users may enter invalid ranges or page numbers that don’t exist. Always validate and limit input to available pages.

Handling large PDFs can also affect performance. Instead of processing everything at once, you can handle operations step by step to keep the browser responsive.

Another key consideration is privacy. Since all processing happens in the browser, files never leave the user’s device. This makes the tool safer for sensitive documents.

In real-world applications, it’s important to clearly communicate that files are not uploaded or stored anywhere.

Common Mistakes to Avoid

One common issue is not validating user input. If users enter incorrect page ranges, the tool may fail or produce unexpected results.

Another mistake is forgetting that page indexes start at zero internally. If you don’t adjust for this, you may extract the wrong pages.

Also, skipping edge cases like empty input or large files can make the tool unreliable.

Conclusion

In this tutorial, you built a browser-based PDF splitter using JavaScript.

You learned how to read PDF files, extract specific pages, and generate a new document entirely in the browser.

This approach removes the need for a backend and keeps everything fast and private.

If you’d like to see a complete working version of this idea, you can try it here: Split PDF

Once you understand this pattern, you can extend it further to build more advanced PDF tools like merging, compression, or editing.

And that’s where things start getting really interesting.

Most developers either rely on external tools or assume this requires backend processing. That’s usually where things get slower, more complex, and harder to maintain.

But modern browsers have quietly become powerful enough to handle this entirely on their own.

In this tutorial, you’ll build a barcode generator that runs completely in the browser. It won’t upload data anywhere, and it won’t require any server logic. Everything happens instantly on the client side.

Along the way, you’ll also learn how barcode formats work, how to validate inputs properly, and how to create a real-time preview experience that feels responsive and practical.

Table of Contents

1. How Barcode Generation Works

2. Project Setup

3. What Library Are We Using?

4. Creating the HTML Structure

5. Adding JavaScript for Barcode Generation

6. How the Barcode Is Generated

7. Types of Barcodes You Can Generate

8. Adding Real-Time Preview

9. How to Validate Input Properly

10. How to Download the Barcode

11. Important Notes from Real-World Use

12. Common Mistakes to Avoid

13. Demo: How the Barcode Generator Works

14. Conclusion

How Barcode Generation Works

A barcode is simply a visual encoding of data. Instead of displaying text directly, it represents that data using a pattern of lines and spaces.

Different barcode formats use different encoding rules. Some support only numbers, while others allow full text input. When you generate a barcode in the browser, you’re essentially converting user input into a structured visual pattern.

The key idea here is that we don’t draw these lines manually. A library takes care of encoding the data and rendering it as an SVG element, which the browser can display instantly.

Project Setup

We’ll keep this project intentionally simple so the focus stays on understanding how it works.

All you need is a basic HTML file, a small JavaScript file, and a barcode library. There’s no backend involved, and nothing gets stored or uploaded.

This makes the tool fast, private, and easy to integrate into other projects.

What Library Are We Using?

In this project, we use the JsBarcode library.

It’s a lightweight JavaScript library that can generate barcodes directly inside the browser using SVG. It supports multiple formats and works without any external dependencies.

You can include it using a CDN:

<script src="https://cdn.jsdelivr.net/npm/jsbarcode@3.11.5/dist/JsBarcode.all.min.js"></script>

Creating the HTML Structure

The interface is simple but practical. It includes an input field where users can enter data, a dropdown to choose the barcode format, and a preview area where the barcode is rendered.

<input type="text" id="text" placeholder="Enter text or number">

<select id="format">
  <option value="CODE128">Code128</option>
  <option value="EAN13">EAN13</option>
</select>

<button onclick="generateBarcode()">Generate</button>

<svg id="barcode"></svg>

This structure is enough to handle input, display output, and connect everything through JavaScript.

Adding JavaScript for Barcode Generation

Now we'll connect the user input to barcode generation.

function generateBarcode() {
  const text = document.getElementById("text").value;
  const format = document.getElementById("format").value;

  if (!text) {
    alert("Please enter a value");
    return;
  }

  JsBarcode("#barcode", text, {
    format: format,
    width: 2,
    height: 100,
    displayValue: true
  });
}

This function reads the input, checks if it exists, and then generates the barcode using the selected format.

How the Barcode Is Generated

When you call the JsBarcode function, the library handles everything behind the scenes.

It encodes the input into a barcode standard, converts that into a pattern of lines, and renders it as an SVG element. Because SVG is vector-based, the barcode remains sharp even when resized.

All of this happens instantly in the browser, which is why the experience feels fast.

Types of Barcodes You Can Generate

Different barcode formats are used in different industries, and understanding them helps you build more practical tools.

1. Code128 is the most flexible format. It supports letters, numbers, and special characters, which makes it ideal for general-purpose use.

2. EAN-13 is commonly used in retail products. It works only with 13-digit numbers, so it requires strict validation.

3. UPC is similar to EAN and is widely used in billing systems, especially in the US. It also expects numeric input with a fixed length.

4. Code39 is simpler and supports uppercase letters and numbers, but it’s less compact compared to Code128.

5. ITF-14 is mostly used in logistics and packaging. It’s designed for numeric data and is common in shipping environments.

In most cases, starting with Code128 is the safest option unless you have a specific requirement.

Adding Real-Time Preview

One of the biggest improvements you can make to a tool like this is real-time feedback.

Instead of requiring users to click a button every time, you can generate the barcode as they type.

document.getElementById("text").addEventListener("input", generateBarcode);
document.getElementById("format").addEventListener("change", generateBarcode);

This small change makes the tool feel much more responsive.

As soon as the user types or changes the format, the barcode updates automatically. This is the same kind of interaction you see in polished production tools.

How to Validate Input Properly

Validation is where many simple tools break.

Since different barcode formats have different rules, if you don’t validate input correctly, the barcode may fail silently or produce incorrect output.

Here’s a simple example:

function isValidInput(text, format) {
  if (format === "EAN13") {
    return /^\d{13}$/.test(text);
  }

  if (format === "UPC") {
    return /^\d{12}$/.test(text);
  }

  return text.length > 0;
}

Then use it inside your generator:

if (!isValidInput(text, format)) {
  alert("Invalid input for selected format");
  return;
}

This ensures users get immediate feedback instead of confusion.

How to Download the Barcode

Once the barcode is generated, you can allow users to download it.

function downloadBarcode() {
  const svg = document.getElementById("barcode");
  const serializer = new XMLSerializer();
  const source = serializer.serializeToString(svg);

  const blob = new Blob([source], { type: "image/svg+xml" });
  const url = URL.createObjectURL(blob);

  const link = document.createElement("a");
  link.href = url;
  link.download = "barcode.svg";
  link.click();
}

This converts the SVG into a file that can be downloaded directly from the browser.

Important Notes from Real-World Use

When building tools like this in production, small details matter.

Large input values can sometimes affect readability, so it’s important to test how dense the barcode becomes. Choosing the right format also makes a difference depending on whether you need flexibility or strict standards.

Another important detail is rendering quality. Using SVG instead of raster formats ensures that the barcode remains sharp even when printed.

Common Mistakes to Avoid

One common issue is skipping validation. This leads to broken or unreadable barcodes, especially with strict formats like EAN or UPC.

Another mistake is relying too much on button-based interactions. Real-time updates create a much better user experience.

Finally, developers sometimes forget to include the library correctly, which leads to silent failures. Always verify that your CDN is loaded.

Demo: How the Barcode Generator Works

To better understand how everything comes together, here’s a quick walkthrough of how the tool works in the browser.

Step 1: Select a Barcode Type

Start by choosing the barcode format. In most cases, Code128 is a good default since it supports both text and numbers.

Step 2: Enter Your Data

Next, enter the value you want to encode. This could be a product ID, URL, or any text depending on the selected format.

Step 3: Customize the Design

You can adjust things like bar width, height, and colors. These settings help control how the barcode looks and how readable it is in different use cases.

Step 4: Generate and Preview

As you type or change settings, the barcode updates instantly. This real-time preview makes it easier to experiment and see results immediately.

Step 5: Download the Barcode

Once you're satisfied with the result, you can download the barcode in formats like PNG, JPG, or SVG.

This entire process happens in the browser, without uploading any data to a server.

Conclusion

In this tutorial, you built a browser-based barcode generator using JavaScript.

More importantly, you learned how to think about building tools that run entirely on the client side. This approach reduces complexity, improves performance, and gives users a faster experience.

Once you understand this pattern, you can apply it to many other tools like QR generators, image converters, and file processors.

And that’s where things start to get interesting.

A plugin architecture allows an application to load external modules that extend its functionality at runtime. Instead of embedding every feature directly in the core application, the system exposes a controlled interface (the host API) that plugins use to integrate with the platform. These plugins can register UI components, contribute functionality, or interact with application services while remaining isolated from the core codebase.

This architectural pattern is widely used across software ecosystems. Platforms such as IDEs, content management systems, and browser extensions rely on plugins to allow third-party developers to extend their functionality without compromising stability.

In a web application context, a similar approach allows large frontend systems to evolve modularly, enabling multiple teams to ship features independently.

In this tutorial, you'll learn how to design a type-safe, lazy-loaded, and secure plugin architecture in React — complete with lifecycle management, independent bundling, hot-loading, and real TypeScript examples.

By the end, you'll have everything you need to transform your React application into a modular platform capable of hosting independent extensions without sacrificing maintainability, performance, or security.

Table of Contents

• A Common Pain Point: Scaling Frontend Platforms

• What This Article Will Cover

• Prerequisites

• Why a Plugin Architecture?

• Core Concepts of a React Plugin Architecture

• High-Level Architecture of a React Plugin System

• Real TypeScript Example: A Chat Plugin

  • Chat Plugin Implementation

  • Host Application Usage

  • 1. How to Define the Host API

  • 2. How to Define the Plugin Lifecycle

  • 3. How to Bundle Plugins Separately

  • 4. How to Lazy-Load Plugins

  • 5. Security & Permission Model

  • 6. Plugin Hot-loading

  • 7. CI & Deployment Considerations

  • Putting It All Together

• Best Practices

• When NOT to Use a Plugin Architecture

  • Small or Single-Team Applications

  • Tightly Coupled Features

  • Performance-Critical Systems

  • Limited Security Controls

  • Early-Stage Products

• Future Enhancements

• Conclusion

A Common Pain Point: Scaling Frontend Platforms

Consider a large internal admin dashboard used by multiple teams across an organization. Each team wants to add its own functionality, like analytics dashboards, workflow management tools, user administration panels, and domain-specific reporting modules.

If all these features are implemented directly in the main React application, several problems quickly emerge. Merge conflicts in the core repository become frequent, unrelated features grow tightly coupled, and release cycles slow down because every change requires redeploying the entire application. Worse, adding new features carries a constant risk of breaking existing functionality.

A plugin architecture solves this problem by allowing each feature to be developed as an independent plugin. The host application provides a stable platform and a controlled API, while teams can ship their own plugins without modifying the core system.

What This Article Will Cover

This guide walks you through how to design a type-safe, lazy-loaded, and secure plugin architecture in React using TypeScript. You'll learn how to design a host API that plugins can safely interact with, how to define a plugin lifecycle for initialization, mounting, updates, and cleanup, and how to bundle plugins independently so they can be developed and deployed separately.

You'll also learn how to lazy-load plugins at runtime to improve performance, how to implement a security model that prevents plugins from accessing sensitive application state, and how to enable hot-loading during development while enforcing safety through CI/CD pipelines.

By the end of this article, you'll understand how to build a flexible plugin system that allows your React application to grow into a modular platform capable of hosting independent extensions without sacrificing maintainability, performance, or security.

Prerequisites

Before following along with this guide, you should be familiar with several core technologies and concepts used throughout the examples.

React Fundamentals
A basic understanding of React components, hooks, and JSX is required. The examples assume familiarity with functional components, useState, and useEffect.

TypeScript Basics
Since the plugin architecture relies heavily on type contracts between the host application and plugins, you should understand TypeScript interfaces, generics, and module exports.

Modern JavaScript Modules
Knowledge of ES modules (import / export) and dynamic imports will help when working with lazy-loaded plugins.

React Tooling (Vite or Webpack)
The examples reference modern frontend build tools such as Vite. Familiarity with how bundlers compile React applications and manage dependencies will help when configuring plugin builds.

Basic Web Security Concepts
Some sections discuss sandboxing and restricted APIs. A general understanding of browser security concepts such as iframes, same-origin policies, and API boundaries is helpful but not strictly required.

Why a Plugin Architecture?

Imagine you're building an internal admin platform where multiple teams need to ship independent features as plugins without risking the core application. A plugin architecture allows each team to contribute functionality safely, while the host maintains type safety, security, and performance.

This guide targets React/TypeScript engineers who want to design a plugin system capable of hosting third-party extensions without compromising maintainability.

The benefits of this approach are significant. Extensibility means developers or third parties can add features without touching core code. Isolation allows plugins to be sandboxed so they can't affect unrelated parts of the application. Lazy loading ensures only the features a user actually needs are fetched, keeping the application fast. TypeScript enforces a strict contract between plugins and the host, catching errors at compile time rather than at runtime. Finally, controlled APIs and permission boundaries prevent malicious or poorly written plugins from interfering with the rest of the system.

A well-architected plugin system balances all of these qualities – flexibility, safety, and maintainability – without forcing unnecessary trade-offs between them.

Core Concepts of a React Plugin Architecture

Before diving into code, it helps to understand the key building blocks that make up a React plugin system.

At a high level, a plugin architecture in React revolves around five concerns.

1. The Host API is the interface the core application exposes to plugins.

2. The Plugin Lifecycle defines methods for initialization, mounting, updating, and cleanup.

3. Bundling means compiling each plugin separately to avoid coupling it to the host.

4. The Security Model covers permissions and sandboxing to prevent misuse.

5. Finally, Hot-loading and CI streamline the development and deployment experience.

We'll explore each of these concepts in detail in the sections that follow. First, let's look at how they fit together visually.

High-Level Architecture of a React Plugin System

The following diagram illustrates how the host application interacts with independently bundled plugins. The host exposes a controlled API, loads plugins dynamically, and manages their lifecycle while maintaining security boundaries.

The core application serves as the runtime environment for all plugins, housing the plugin loader, lifecycle manager, and the host API.

The plugin loader dynamically imports plugin bundles at runtime using import(), while the host API ensures plugins interact with the application through a controlled interface rather than accessing internal state directly.

Each plugin is compiled as a separate bundle and registers itself with the host during initialization. A dedicated security layer enforces all of these boundaries, ensuring plugins cannot directly manipulate internal state or sensitive resources.

Together, these pieces ensure that plugins remain independent, lazy-loadable, and secure, while the host application retains full control over lifecycle management and platform stability.

Real TypeScript Example: A Chat Plugin

Now that you have a mental model of the architecture, let's look at a minimal working example before diving into each concept individually. This example demonstrates how a plugin registers itself with the host application and exposes a UI component through the host API.

The following plugin implements a simple chat feature that registers a React component with the host platform.

Chat Plugin Implementation

// plugins/chat-plugin/src/plugin.ts

import { Plugin, HostAPI } from '../../src/plugins';

const ChatPlugin: Plugin = {
  name: 'ChatPlugin',
  version: '1.0.0',
  init(host: HostAPI) {
    host.registerComponent('Chat', () => (
      <div>Welcome to the Chat Plugin!</div>
    ));
    host.log('ChatPlugin initialized');
  },
};

export default ChatPlugin;

Host Application Usage

The host application loads the plugin and renders the component it registered.

const Chat = hostAPI.getComponent('Chat');

return (
  <div>
    {Chat ? <Chat /> : 'Loading Chat Plugin...'}
  </div>
);

In this example, the plugin doesn't directly modify the host application. Instead, it interacts through the Host API, registering a component that the host can render dynamically. The sections below break down exactly how each piece of this system is built.

1. How to Define the Host API

The host API is the contract between the core app and its plugins. It defines what functionality plugins can access. Before plugins can do anything useful, the host must expose a controlled interface, establishing the contract between the core application and its extensions.

Example: TypeScript Host API

// src/plugins/host.ts

export interface HostAPI {
  // Using ComponentType instead of FC<any> reinforces type-safety while allowing class/function components
  registerComponent: (name: string, component: React.ComponentType<any>) => void;
  getComponent: (name: string) => React.ComponentType<any> | undefined;
  log: (message: string) => void;
}

// Note: We still use `any` for props here for extensibility; plugins can define stricter props locally if needed.

export const hostAPI: HostAPI = { 
    registerComponent(name, component) { 
        console.log(Registered component: ${name}); 
        componentRegistry[name] = component; 
    }, 
    getComponent(name) { 
        return componentRegistry[name]; 
    }, 
    log(message) { 
        console.log([PLUGIN LOG]: ${message}); 
    }, 
};

const componentRegistry: Record<string, React.ComponentType<any>> = {};

This API allows plugins to register UI components and log messages, without giving them unrestricted access to the application state.

2. How to Define the Plugin Lifecycle

A plugin lifecycle ensures consistent behavior across all extensions. Once the host API exists, plugins need a structured way to initialize, render, and clean up resources.

Lifecycle Interface

// src/plugins/plugin.ts

import { HostAPI } from './host';

export interface Plugin {
  name: string;
  version: string;
  init: (host: HostAPI) => void;
  mount?: () => void;
  update?: () => void;
  unmount?: () => void;
}

// Typically, the host calls mount/update/unmount based on route changes, feature flags, or user interactions.

The init method is called when the plugin is first loaded and receives the host API as its argument. mount is called when the plugin's UI is displayed, while update is an optional hook triggered when props or state change.

When a plugin is removed, unmount is called to clean up any resources the plugin was holding, preventing memory leaks and side effects in the host application.

3. How to Bundle Plugins Separately

Each plugin should be packaged as an independent module so that it can be developed, versioned, and deployed without tightly coupling it to the host application.

Modern build tools such as Vite or Webpack make it possible to compile plugins into standalone bundles that the host can load dynamically at runtime.

Example Vite Configuration for a Plugin

// vite.config.ts

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  build: {
    lib: {
      entry: 'src/plugin.ts',
      name: 'MyPlugin',
      fileName: 'my-plugin',
      formats: ['es'],
    },
    rollupOptions: {
      external: ['react', 'react-dom'],
    },
  },
});

The external option ensures the plugin uses the host's React, preventing duplicate React versions in memory.

4. How to Lazy-Load Plugins

Even when plugins are bundled independently, loading all of them during application startup would significantly increase initial load time. Instead, plugins should be loaded on demand using dynamic imports so that functionality is only fetched when the user actually needs it.

// src/plugins/loader.ts

export async function loadPlugin(url: string): Promise { 

    // Using /* @vite-ignore */ because the URL is dynamic and cannot be         statically analyzed by Vite.
    // Tradeoff: plugin cannot be pre-bundled; ensure URLs are trusted to avoid security risks.

    const module = await import(/ @vite-ignore */ url); 
    return module.default as Plugin; 
}

Usage in React:

const [plugin, setPlugin] = React.useState<Plugin | null>(null);

React.useEffect(() => {
  loadPlugin('/plugins/my-plugin.js').then((p) => {
    p.init(hostAPI);
    setPlugin(p);
  });
}, []);

This pattern allows applications to scale without preloading all plugins, improving initial load time.

5. Security & Permission Model

Because plugins run code that originates outside the core application, security boundaries are essential. Even though plugins interact through the host API, the platform must still restrict what capabilities they can access in order to prevent misuse or accidental interference with application state.

Example: Restricted API

export interface SecureHostAPI {
  log: (message: string) => void;
  registerComponent: (name: string, component: React.ComponentType<any>) => void;
  fetchData?: (endpoint: string) => Promise<any>; // Only if allowed
}

You can enhance security further using iframe sandboxing or Web Workers for heavier isolation.

// Example of a sandboxed iframe plugin

<iframe
  src="/plugins/my-plugin.html"
  sandbox="allow-scripts"
  style={{ width: '100%', height: '400px', border: 'none' }}
/>

// Advanced isolation notes:
// - You can define different SecureHostAPI shapes for internal vs. third-party plugins,
//   exposing more capabilities to trusted plugins while restricting untrusted ones.
// - For stronger isolation, use message passing (postMessage) with iframes or Web Workers
//   so plugins cannot access the DOM or host state directly.

This approach prevents DOM and network access outside the API.

6. Plugin Hot-loading

Hot-loading is essential for developer productivity. Tools like Vite's HMR let you see plugin updates immediately, speeding up iteration and reducing friction.

React Example with HMR:

if (import.meta.hot) {
  import.meta.hot.accept('/plugins/my-plugin.js', (newModule) => {
    const updatedPlugin = newModule.default as Plugin;
    updatedPlugin.init(hostAPI);
    setPlugin(updatedPlugin);
  });
}

With hot-loading, developers can update plugins without restarting the host app.

7. CI & Deployment Considerations

To deploy safely, plugins must be verified and tested. CI/CD pipelines enforce type safety, bundling, and security checks automatically. For a production-grade plugin system, continuous integration pipelines should:

1. Lint and type-check each plugin using TypeScript.

2. Run automated tests to ensure plugin compliance.

3. Bundle plugins independently with versioned outputs.

4. Deploy plugins to a secure CDN or internal repository.

5. Verify signatures or hashes to prevent tampering.

GitHub Actions Example for Plugin CI:

name: Build Plugin

on:
  push:
    paths:
      - 'plugins/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps: 
      - uses: actions/checkout@v3 
      - uses: actions/setup-node@v3 
      with:
        node-version: 20
      - run: npm install 
      - run: npm run build --workspace plugins/my-plugin 
      - run: npm run test --workspace plugins/my-plugin
      # Optional: sign plugin artifacts or generate a checksum to verify integrity before loading in the host

This ensures every plugin is type-safe, tested, and ready for deployment.

Putting It All Together

At this point, you have walked through each architectural layer independently. Here's how all the pieces map to a real project structure:

src/
├── plugins/ 
│ ├── host.ts ← Host API definition 
│ ├── plugin.ts ← Plugin lifecycle interface 
│ └── loader.ts ← Dynamic plugin loader 
plugins/ 
└── chat-plugin/ 
    └── src/ 
        └── plugin.ts ← Chat plugin implementation

Each file has a single, clear responsibility. host.ts owns the contract, plugin.ts owns the lifecycle shape, loader.ts handles runtime importing, and the plugin itself lives entirely outside the core src/ tree – deployable and versioned independently.

Best Practices

At this point, you have a host API, a well-defined plugin lifecycle, isolated bundles, lazy-loading, and a security model. These foundations ensure plugins are robust, type-safe, and maintainable — ready to be extended with versioning, testing, and CI/CD pipelines.

1. Type safety: Always define TypeScript interfaces for host APIs and plugin contracts.

2. Lazy loading: Only load plugins when required.

3. Security: Expose a minimal API and avoid giving plugins unrestricted access.

4. Isolated state: Keep plugin state isolated to prevent accidental interference.

5. Versioning: Maintain plugin versions to ensure compatibility with the host.

6. Testing: Unit-test plugins against host API mocks.

7. CI/CD: Automate linting, testing, and bundling for plugins.

When NOT to Use a Plugin Architecture

In some cases, introducing a plugin system can add unnecessary complexity without delivering meaningful benefits.

Small or Single-Team Applications

If a project is maintained by a small team and the feature set is relatively stable, a plugin architecture may be excessive. A simpler modular structure within the main codebase is usually easier to maintain and reason about.

Tightly Coupled Features

Plugin systems work best when features can operate independently. If new functionality requires deep access to application state or tightly integrated workflows, forcing it into a plugin model may introduce unnecessary abstractions and complexity rather than solving a real problem.

Performance-Critical Systems

Although lazy-loading can mitigate performance issues, plugin architectures still introduce additional runtime complexity. Applications with strict performance constraints may benefit from a more tightly optimized architecture rather than dynamic plugin loading.

Limited Security Controls

Allowing external code to run inside an application always introduces security risks. If the platform can't enforce strong API boundaries, sandboxing, or validation of plugins, it may be safer to avoid a plugin architecture altogether.

Early-Stage Products

In early product development, requirements often change rapidly. Designing a plugin system too early can slow development because engineers must maintain abstraction layers before the product's core architecture has stabilized. It's usually better to wait until the platform's boundaries are well understood before introducing this level of extensibility.

Future Enhancements

As the platform matures, there are several directions worth exploring.

Dynamic permissions would allow plugins to explicitly request capabilities, with the host deciding whether to grant them. This makes the security model more granular and auditable.

A plugin marketplace could serve as a central registry of verified plugins, making discovery and distribution easier for teams.

For use cases that require stronger isolation, Web Workers or iframes offer more robust sandboxing than API boundaries alone.

An event bus is another useful addition, allowing plugins to communicate with each other through a shared message system rather than direct API calls, which keeps inter-plugin dependencies loose and manageable.

Conclusion

Designing a plugin architecture in React is ultimately about treating your application as a platform rather than a single codebase. By defining clear contracts between the host application and its extensions, you enable teams to ship features independently while preserving stability, security, and performance.

If you are building a system that multiple teams (or even third-party developers) need to extend, start by establishing a minimal host API and plugin contract. Focus on strong TypeScript interfaces, clear lifecycle boundaries, and strict API access rules. These foundations ensure that plugins remain predictable and safe as the ecosystem grows.

As your platform evolves, you can gradually introduce more advanced capabilities such as plugin versioning, capability-based permissions, sandboxed execution environments, or an internal plugin marketplace.

Observability and monitoring also become increasingly important as the number of plugins grows, allowing you to detect compatibility issues or performance regressions early.

The key takeaway is to start simple but intentional. A small, well-defined plugin interface combined with lazy loading and secure API boundaries is often enough to support the first generation of extensions. From there, your architecture can expand naturally into a full ecosystem where features are delivered as modular, independently deployable plugins.

When implemented thoughtfully, a React plugin architecture transforms a single application into a scalable, extensible platform capable of supporting long-term growth and collaboration across teams.

To make things even worse, how about a CORS error that completely prevented you from showing the page?

It happens, right? Going back to the backend team and getting a quick fix for these issues would be ideal, but may not be realistic in most cases. It depends on the availability of the backend developers, the priority items they're working on, communication protocols between teams, and even interpersonal relationships.

Now, the question is, can you afford to wait? Wait for things to work in your favour within the given deadline so that you can show that demo or deliver the work to your customer? The answer is NO. You may not have that luxury.

Today, in this article, you'll learn a couple of mind-blowing tips and tricks that will save you from these situations. You'll understand how to set up your Chrome browser so that you can continue with your frontend development even when the backend API returns an incorrect response or a CORS error.

This is a step-by-step guide that'll help make you comfortable with all the required configurations and get you set up to use it on your web projects. This guide is also available as a video tutorial as part of the Thinking in Debugging series. You can check it out if you’d like:

Let's get started with the problems and their solutions.

Table of Contents

1. Problem 1: The Backend Response Is Wrong

2. Problem 2: Validating a UI Scenario Without Backend Changes

3. Problem 3: Handling CORS Errors

4. Additional Tips

   • Applying Overrides Globally

   • Disabling or Removing Overrides

5. Learn More From the Thinking in Debugging Mindset

6. Before We End…

Problem 1: The Backend Response Is Wrong

Here is a classic case of a wrong API response, but you still need to continue with your frontend work.

Take a look at the image below. Do you see that something is off? Yeah, on the first card, the spelling of Banana seems to be misspelled as Banananana. This user interface is constructed using the data we have received as an API response.

We can go to the backend team and request that they fix it as soon as possible. But it may not happen until the next sprint starts, which might be 15 days from now.

So, what can we do to continue with our work and all the validations on the frontend side? We can use the Content Overriding feature of the Chrome browser to mitigate this situation.

How to Use Content Overriding

First, open up the DevTools of your Chrome browser by pressing the F12 (on Mac, Cmd+F12) key. Then move to the network tab and inspect the API request that returns the incorrect response.

Next, right-click on the API request and select the Override content option from the context menu.

You may wonder what content means here, and what I am overriding? You're overriding the API response so that it can reflect on the UI locally.

This will bring up a UI at the top where you can select a folder to store override files. It's important to understand that all the content overrides are locally stored on your machine's hard disk. This means you can use these persisted overrides again and again until someone fixes the issue permanently at the backend.

Now click on the Select folder button.

This will open up the folder explorer for you. Create a new folder and select it, or select an existing folder where you want to save the overrides. In my case, I've named the folder as debug_devtools.

Now, Chrome DevTools will ask for confirmation that you're allowing DevTools to edit files on your local system. Just click on the Allow button.

That's all for the setup. Now, you'll find the same response in the editable mode under the Sources tab of DevTools. Let's take a deeper look at the image below:

1. The Local overrides are listed under the Sources > Oveerides tab of the DevTools.

2. On the left side, the Enable Local Overrides checkbox is selected, and the overrides are listed below. You can find the same folder you created before, and under that, you'll see another folder called localhost:3001 and a file called edibles under it. The localhost:3001 folder name is related to the API endpoint namespace we're connecting to. The edibles file name under it goes with the request name.

3. On the right side, you can see the content (that is, the response to the edibles request) in editable mode.

You can even cross-check now by traversing to the file system's debug_devtools folder. You should find the same folders and files as you saw in the DevTools.

You can open up the edibles file. The file content should match exactly the response you saw before.

Now, it's time to override. Coming to the Sources tab's editable response panel, you can fix the spelling. Save your changes using Ctrl + S (or Cmd + S).

Now, hard refresh your browser. You should be able to see your change reflected on the UI.

Awesome!! You can now share this overridden response (the edibles file) with other developers to point to from their Chrome DevTools to get the same local fix until the backend fixes it.

Problem 2: Validating a UI Scenario Without Backend Changes

Imagine you need to validate that certain items are low in stock on an item listing page. If the stock quantity of an item hits 50 or below, you want to show a Low Stock label for that item.

Now, what if the API response doesn't return a quantity of 50 or below? Content overriding can come to the rescue once again!

You can edit the response to set the quantity value to 50 or below and follow the same process as before to reflect the change on the UI. Look at the image below:

1. We have edited the quantity on the right-side panel.

2. Once saved and refreshed, we not only see the updated count on the UI, but it also runs the underlying JavaScript logic to show the Low Stock label automatically. This is a superpower.

Problem 3: Handling CORS Errors

Cross-Origin Resource Sharing (CORS) is a browser security feature that allows a web server to explicitly grant requests coming from a domain other than its own. By default, browsers don't allow these cross-origin requests and follow a strict rule called Same Origin Resource Sharing.

In many cases, your API server and the web server could be hosted on different domains. In those cases, when the web application attempts to access an API, it faces the CORS error.

On the server side, you need to have explicit configurations to allow cross-origin requests. For example, you need to add the following response headers:

Access-Control-Allow-Origin: http://localhost:5174
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: *

So, again, it may not be guaranteed that your CORS error will be resolved at the server side as soon as you want. But you cann't afford to get blocked due to it. So, what's the way around? Yes! The overriding, but this time, overriding the response header.

Go to the network tab of the Chrome DevTools and right-click on the request that has the CORS error. Now, select the Override headers option from the context menu.

By the way, have you noticed that the Override content option is disabled here? This is because we don't have any response as content from this request, as it got an error.

Clicking on the Overriding headers will take you to the Headers tab where you can find the option to add additional headers to the response headers. Click on the + Add header button to add the CORS-related headers.

Add all three headers with their respective values one by one:

Access-Control-Allow-Origin: http://localhost:5174 
Access-Control-Allow-Methods: GET 
Access-Control-Allow-Headers: *

Each of these headers has its own important use:

1. With the Access-Control-Allow-Origin header, you can specify the origin domains that are allowed to have a cross-origin request to the server. In this case, the value is http://localhost:5174 where we're running a Vite-based ReactJS app.

2. The header Access-Control-Allow-Methods specifies what kind of HTTP methods are allowed from the originating domain. In this case, we're allowing only the GET method.

3. The Access-Control-Allow-Headers HTTP response headers specify which HTTP headers can be safely used during a cross-origin request.

Alright, let's add them all and save.

Like overriding content, overriding the header will also create a folder with the context of the server domain, and under that, a file called .headers. As the file name starts with a dot(.), it may be treated as a hidden file by most operating systems. So make sure you go through the OS settings to view the hidden files to view this file.

Once you view and open the file, you'll see the headers you have added with overriding.

Now, hard refresh your browser, and try to perform the same operation that was giving you the CORS error before. Wow, the error has gone now! You should be able to see the request success and the response coming back from the server.

Just imagine, not a single line of server-side code changes, and you're unblocked so you can move forward with your client-side UI work. Fantastic, isn't it?

Additional Tips

Before we end, let's learn about a couple more handy tips.

Applying Overrides Globally

We applied the CORS error-related header overriding only on the /user API endpoint. What if you need to apply the same overriding for other endpoints, too? You can do it easily by following these simple steps:

1. Navigate to the Sources tab.

2. Select the Overrides sub-tab.

3. Click on the .headers override.

4. On the right-side panel, change the value of the Apply to to *.

That's it. Now, the same response headers will be applied as overrides for all the endpoints.

Disabling or Removing Overrides

Sometimes, you might want to disable or remove overrides. To disable overrides without removing them, just uncheck the Enable Local Overrides checkbox. To remove all the overrides permanently, click on the stop icon at the top-right corner. Also, to selectively remove an override, right-click on it and delete.

Learn More From the Thinking in Debugging Mindset

If you've liked this practical, example-driven guide, you'll enjoy my other debugging-related content from the Thinking in Debugging series. Please check it out.

Before We End…

That’s all! I hope you found this insightful.

Let’s connect:

• Subscribe to my YouTube Channel.

• Check out my courses, 40 Days of JavaScript and 15 Days of React Design Patterns

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Join my Discord Server, and let’s learn together.

• Follow my work on GitHub.

See you soon with my next article. Until then, please take care of yourself and keep learning.

Caching is great for performance, but it becomes a pain when you don’t realize which layer is reusing old data.

If you’ve ever seen this:

• You update a profile name, but the screen still shows the old one.

• You delete an item, but it stays in the list.

• Your API returns fresh JSON, but the page refuses to change.

• You deploy a fix, but your teammate still sees the old behavior.

You’re probably hitting a cache.

What makes this especially confusing is that not all stale UI comes from “real” caches. Modern web apps have multiple places where data can be reused, saved, or replayed between your UI, your API and when your app is deployed. When you don’t have a clear mental model of these layers, debugging turns into guesswork.

This article lays out a practical guide of the five most common caching layers that cause stale UI, plus one non-cache trap that looks exactly like one. The goal is to help you quickly identify where stale data is coming from, so you can fix the right thing instead of “refreshing harder.”

Why it Matters

I first ran into this while building an app where the UI wouldn’t update after a successful change. The API returned 200 OK, the database was correct, but the screen stayed stale. I assumed something was wrong with my code or state logic. Instead, the issue was coming from a caching layer I hadn’t invalidated. That’s the real problem with stale UI, you can’t debug it effectively unless you know which layer might be serving cached data.

When you understand where caching happens:

• You debug faster by identifying the layer instead of guessing.

• You avoid production-only bugs caused by caching defaults.

• You stop chasing React issues when the data was never fresh.

This article gives you a simple mental model to pinpoint the layer and fix the right thing.

Table of Contents

• Why it Matters

• The Mental Model

• Non-Cache Cause

• Cache 1: React Query Cache

• Cache 2: Next.js fetch() Caching

• Cache 3: Browser HTTP Cache (a Saved Copy in Your Browser)

• Cache 4: CDN/Hosting Cache

• Cache 5: Service Worker Cache (Only if Your Site is a PWA)

• 10-Second Debug Guide

• Prevention: Set Caching Intentionally

• Recap

The Mental Model

When your UI shows data, it feels like it comes straight from your API. In reality, the request/response path can hit multiple reuse points.

Non-Cache Cause

Duplicated React local state (same symptoms as caching). This one isn’t a formal cache, but it causes a lot of “why didn’t it update?” bugs especially for beginners.

The common trap:

const [name, setName] = useState(user.name) // initialized once

useState only uses its argument during the initial render. On every subsequent render, React ignores this value and preserves the existing state.

If user.name later changes (for example, after fresh API data arrives), the name state will not update automatically. At that point, name becomes a stale copy of user.name, and the UI renders outdated data unless you manually synchronize it.

This happens because you have duplicated state:

• user.name is the source of truth.

• name state is a local snapshot taken once.

React does not keep duplicated state in sync for you.

Correct patterns:

1. Render directly from the source when possible.

If the value is not being edited locally, do not copy it into state:

<span>{user.name}</span>

This guarantees the UI always reflects the latest data.

2. Explicitly synchronize local state when editable state is required.

If you need local, editable state (for example, a controlled input), you must opt in to synchronization:

const [name, setName] = useState(user.name);  

    useEffect(() => {    
        setName(user.name); 
     }, [user.name]);

This effect runs only when user.name changes, explicitly updating local state to match the new source value.

Cache 1: React Query Cache

React Query (TanStack Query) stores query results in a QueryClient cache (in memory by default) so your UI can render quickly and avoid unnecessary network requests. When a component needs data, React Query can return cached data immediately and then decide whether to fetch the data again based on options like staleTime and “refetch” behaviors (on mount, window focus, reconnect).

Common failure mode: mutation succeeds, but the UI stays old

A 200 OK only confirms the mutation request succeeded. It does not automatically update the cached query data your UI is rendering.

After a mutation, one of these usually happens:

• The query that renders the screen was not invalidated/fetched

• You invalidated the wrong query key (the UI reads from a different key)

• The UI is rendering local React state that’s out of sync (not the query result)

The simplest “safe” pattern is: invalidate the exact query key your UI uses, so it fetches fresh data.

import { useMutation, useQueryClient } from "@tanstack/react-query";

function useUpdateProfile(userId: string) {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: updateProfileRequest,
    onSuccess: () => {
      // Invalidate the same key your UI query uses (example: ["user", userId])
      queryClient.invalidateQueries({ queryKey: ["user", userId] });
    },
  });
}

If your UI uses a different key (for example ["me"] or ["user", userId, "profile"]), you must invalidate that key instead, React Query won’t “figure it out” from the URL.

Query Keys: React Query Caches by Key, not URL

React Query does not cache by endpoint URL. The query key is the identity of the cached data. If two different requests share the same key, React Query treats them as the same data and they can overwrite each other.

You should avoid keys like ["user"] (too broad), and use keys like ["user", userId] and ["users", { page, search, filter }].

Two settings that control “when it will refetch”:

• staleTime: how long cached data is treated as fresh. While data is fresh, React Query is less likely to refetch automatically.

• gcTime (formerly cacheTime): how long unused query data stays in memory after it’s no longer used by any component, before it’s garbage collected.

Cache 2: Next.js fetch() Caching

This is the one that surprises a lot of frontend devs. Next.js can cache results to speed things up. That means your server might return a previously saved copy of:

• The API data it fetched, or

• The page it already built

This is often the first time frontend developers encounter server-side caching behavior that affects UI correctness. So, even if your database has the new value, you can still see the old one, because Next.js didn’t fetch the API again, or didn’t rebuild the page this time.

This mainly applies to the App Router (Next.js calls these saved copies the Data Cache and Full Route Cache).

What you’ll notice when this happens

• You refresh the page and it still shows the old value.

• Your API is correct (Postman/curl shows the new email), but the UI is stuck.

• Sometimes it “fixes itself” after a short wait (because the saved copy refreshes on a timer).

For example: “I updated my profile email, but prod still shows the old one”

The page (reads email on the server):

// app/settings/page.tsx
export default async function SettingsPage() {
 const res = await fetch("https://api.example.com/users/42", {
  method: "GET",
})
  const user = await res.json();

  return (
    <main>
      <h1>Settings</h1>
      <p>Email: {user.email}</p>
    </main>
  );
}

You submit an “Update email” form, the API returns 200 OK, the database is updated, but /settings still shows the previous email in production.

That usually means you’re seeing a saved copy somewhere on the server side.

How to debug it

Step 1: Reproduce in a production-like run

Caching can behave differently in development. Run:

next build && next start

Then test again.

Step 2: Confirm whether the request is reaching your Next.js server at all

Add a log inside the page:

console.log("Rendering /settings at", new Date().toISOString());

Then reload settings twice.

• If you see a new timestamp every reload, the request is reaching your server and the page code is running.

• If you don’t see logs in production, your request may not be reaching your server at all (often because a hosting/CDN layer is serving a saved copy before Next.js runs). You’ll confirm that in the CDN section later.

Step 3: Force Next.js to ask your API every time

Change the fetch to:

const res = await fetch("https://api.example.com/me", {
  method: "GET",
  cache: "no-store",
});

This means: don’t save this response – always fetch it again.

If this fixes the stale email then the problem was a saved copy of the API response (Data Cache).

Step 4: If the email is still stale, force Next.js to rebuild the page every request

Add this to the page file:

// app/settings/page.tsx
export const dynamic = "force-dynamic";

This means: don’t serve a saved copy of the page; rebuild it per request.

A “beginner-safe” setup for the user settings pages with some of the suggestions:

// app/settings/page.tsx
export const dynamic = "force-dynamic";

export default async function SettingsPage() {
  const res = await fetch("https://api.example.com/me", { cache: "no-store" });
  const me = await res.json();
  return <p>Email: {me.email}</p>;
}

When you want caching for speed, but still need real time updates, these are some options you can take:

Option A: Refresh the saved copy every N seconds

Good for public pages, not ideal for “my settings must update now.”

await fetch(url, { next: { revalidate: 60 } });

This means: “You can reuse a saved copy, but refresh it at most every 60 seconds.”

Option B: Refresh right after the update (best for “update email” flows)

If you update the email on the server (Server Action or API route), tell Next.js to throw away the saved copy for /settings page so the next visit is fresh:

// app/settings/actions.ts
"use server";

import { revalidatePath } from "next/cache";

export async function updateEmail(email: string) {
  await fetch("https://api.example.com/me/email", {
    method: "PUT",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ email }),
  });

  // Tell Next.js: next request to /settings should be rebuilt
  revalidatePath("/settings");
}

Note: Next.js caching details can differ by version and by App Router vs Pages Router. Instead of trying to memorize defaults, debug by setting the behavior explicitly (no-store, revalidate, force-dynamic) and observe what changes.

Cache 3: Browser HTTP Cache (a Saved Copy in Your Browser)

Sometimes the browser reuses a saved copy of an API response (from memory or disk), so it doesn’t fully fetch it again.

What you’ll notice

You open DevTools, and the network shows (from memory cache) or (from disk cache).

Fast check

DevTools → Network

• Turn on Disable cache (only works while DevTools is open)

• Reload and retry

Why it happens

Usually your server allows caching via headers like Cache-Control or ETag (which can lead to 304 Not Modified).

Cache 4: CDN/Hosting Cache

This is often a production-only cache, which is why frontend bugs can appear “impossible” to reproduce locally. In production, a CDN/hosting layer can serve a saved copy of a response before your request reaches your server. That’s why “prod is stale, local is fine” happens.

What you’ll notice

• Prod is stale, local is fine

• Different users see different results (different regions/POPs)

• Pages are very fast even right after data changed

Fast check

Open DevTools → Network → click the request → Response Headers

• Age: if present and increasing, it’s strong evidence you’re getting a cached response from an intermediary cache

• Provider headers can hint HIT/MISS (examples: x-vercel-cache, cf-cache-status)

• Source (Age header, HTTP caching): https://www.rfc-editor.org/rfc/rfc9111

Quick diagnostic check

Change the URL slightly by adding this to the end of the URL:

?debug=1700000000000

If the new URL shows fresh data, the edge was likely caching the original URL. This doesn’t fix it for everyone, you’d still need correct cache settings or a purge/invalidation on your CDN.

Cache 5: Service Worker Cache (Only if Your Site is a PWA)

If your site has a service worker, it can return a saved response before the network runs. This can make new deployments or new data seem “ignored.”

What you’ll notice

• Works in Incognito but not normal mode

• Hard refresh doesn’t help

• DevTools “Disable cache” doesn’t fully explain it

Fast check (Chrome)

Open DevTools → Application → Service Workers

• enable Bypass for network, or Unregister temporarily

• reload and retest

10-Second Debug Guide

Stale data is rarely random: it usually means a cache layer is doing its job, just not in the way you expect. Modern applications stack multiple caches, so debugging is less about fixing code immediately and more about locating the layer responsible.

Think of this as a quick cheat sheet to figure out which cache layer might be serving stale data, so you can focus your debugging on the right layer.

• No request in Network? Go to Cache 1 (React Query), then Local state, then Cache 5 (Service worker).

• Request exists, but response is old? Go to Cache 3 (Browser), Cache 4 (CDN), then Cache 2 (Next.js).

• Response is fresh, UI is old? Go back to Cache 1 (invalidating / query keys) and Local state.

Once you know the likely layer, use the Fast check in that section to confirm it.

Prevention: Set Caching Intentionally

Most stale-data bugs happen because caching settings were never chosen but the defaults were.

• User-specific pages (settings/admin/dashboard): default to fresh: Next.js: use cache: "no-store" on important fetches, and/or force dynamic routes when needed.

• Public pages (marketing/blog/docs): saving + revalidate is usually fine: Decide a revalidate window that matches the business need (seconds/minutes/hours).

• React Query: set staleTime based on how often the data actually changes, and make query keys match the inputs.

• APIs: set Cache-Control / Vary intentionally so shared caches don’t mix user-specific responses.

Recap

Caching itself isn’t the problem. Stale UI happens when a cache exists but you didn’t choose it intentionally or align it with the data’s freshness requirements.

If the UI won’t update, it’s usually because you’re seeing a saved copy from React Query, Next.js, the browser, a CDN, or a service worker. And sometimes it’s not a cache at all, it’s local React state

And the main difficulty isn’t necessarily what went wrong – it’s pinpointing where it went wrong.

React offers powerful ways to change state, but it doesn’t specify who or what caused those changes. In large apps with many layers of components, hooks, and contexts, this lack of insight can turn simple bugs into frustrating, time-consuming puzzles.

This is where more innovative debugging methods become crucial. Before now, the go-to solution was to sprinkle console.log calls at key points or to fall back to DevTools.

But these days, you can write a small but powerful utility function that can catch the criminal involved in the crimes against your codebase. This utility function can log changes, display meaningful stack traces, and work smoothly with useState, useReducer, Context providers, and custom hooks. And all of the above can occur while remaining invisible in production.

This article guides you through how to use this helper function to improve clarity, minimise guesswork, and debug efficiently without affecting performance or code cleanliness in your live environment.

Table of Contents

• The Problem

• Why This Problem Exists

• My Solution: createDebugSetter

  • Practical Examples of createDebugSetter

• Best Practices for using createDebugSetter

• Things to Avoid

• Bonus: How to Convert createDebugSetter to a Hook

• Conclusion

The Problem

React’s state system is powerful, but it hides too much information when something goes wrong – for example, when an unexpected update happens or a component re-renders endlessly. React doesn’t tell you what triggered the update, what changed, or why it happened. This lack of visibility creates several challenges.

The first is that you can’t easily see which component, function, or effect initiated a state update. In large applications, where the same state may be modified from multiple places, this quickly turns debugging into guesswork. Without clear traces, developers often sprinkle console.log throughout their code to find the source of a single update.

Secondly, React lacks a built-in method for directly comparing previous and current values. This complicates diagnosing whether a bug stems from an incorrect calculation, a faulty API response, or erroneous business logic. The challenge increases with nested objects, arrays, or shared context.

Thirdly, Context updates can trigger re-renders across the entire tree, even for components wrapped in memoisation. But React doesn’t explain why a particular provider changed, leaving teams to wonder what triggered the cascade.

Finally, infinite loops caused by effects, unstable dependencies, or repeated setState calls provide no clues in the console. You only see symptoms like “loading…” repeating endlessly, with no indication of the source.

All of this makes debugging complex React apps frustrating, slow, and often misleading without additional tools or structured techniques.

Why This Problem Exists

React intentionally conceals its internal update process to keep the framework fast and predictable.

Because of this:

• setState() doesn’t report where it was called from

• Context re-renders can originate from anywhere.

• State overrides can happen silently.

• Debugging often relies on manually adding console logs.

In large applications, this lack of visibility makes it nearly impossible to trace unexpected state changes.

My Solution: createDebugSetter

A small helper function, createDebugSetter, wraps your state setter and logs:

• The label of the state

• The new value

• A complete stack trace showing exactly where the update originated

And best of all, it automatically disables itself in production using NODE_ENV so there’s no impact on your live app.

createDebugSetter

export function createDebugSetter(
  label: string,
  setter:
    | React.Dispatch<React.SetStateAction<unknown>>
    | React.Dispatch<unknown>
): React.Dispatch<React.SetStateAction<unknown>> | React.Dispatch<unknown> {
  // In production, return the original setter unchanged
  if (import.meta.env.PROD /* vite-react */) {
    return setter;
  }

  // Create a wrapper that logs before calling the original setter
  return (value: React.SetStateAction<unknown> | unknown) => {
    // Log the state change
    console.groupCollapsed(
      `%c🔄 [${label}] State Update`,
      "color: #adad01; font-weight: bold;"
    );
    console.log("🆕 New value:", value);
    console.trace("📍 Update triggered from:");
    console.groupEnd();

    // Call the original setter
    setter(value);
  };
}

The function above is a debugging wrapper for React state setters that logs during development.

It takes two parameters: a label for identification and the setState function you want to debug. In development mode, every state update triggers a collapsible console log that shows the new value and the stack trace of the update's origin. In production, the hook skips entirely and returns the original setter unchanged, ensuring zero runtime overhead in deployed applications.

How it does it:

 // In production, return the original setter unchanged
  if (import.meta.env.PROD /* vite-react */) {
    return setter;
  }

In production, the createDebugSetter function returns the React setState as-is. This is because we don’t want to log anything when our code is running in a production environment. Here, we’re using the import.meta.env.PROD from React-vite. It returns a Boolean value that tells us if it’s in the production environment or not.

If it’s not in production, we return the modified setter below.

// Create a wrapper that logs before calling the original setter
  return (value: React.SetStateAction<unknown> | unknown) => {
    // Log the state change
    console.groupCollapsed(
      `%c🔄 [${label}] State Update`,
      "color: #adad01; font-weight: bold;"
    );
    console.log("🆕 New value:", value);
    console.trace("📍 Update triggered from:");
    console.groupEnd();

    // Call the original setter
    setter(value);
  };

This new setter function first logs a collapsible console group with the label and emoji. Then it shows the new value being set. After that, it displays a stack trace showing where the update was triggered. Lastly, it calls the original setter to actually update the state.

Practical Examples of createDebugSetter

Let’s now see how createDebugSetter can be used in several places within a codebase.

Context Providers

You can use createDebugSetter within a Context provider to log state changes when setState is called. This can help log and trace state changes whenever setState is called in a Context Provider anywhere in the application.

import { createContext, useContext, useState, type ReactNode } from "react";
import { createDebugSetter } from "../utils/createDebugSetter";

interface User {
  name: string;
  email: string;
  role: string;
}

interface UserContextType {
  user: User | null;
  setUser: React.Dispatch<React.SetStateAction<User | null>>;
  login: (name: string, email: string) => void;
  logout: () => void;
}

const UserContext = createContext<UserContextType | undefined>(undefined);

export function UserProvider({ children }: { children: ReactNode }) {
  const [user, setUserOriginal] = useState<User | null>(null);

  // Wrap setter with debug functionality
  const setUser = createDebugSetter(
    "UserContext",
    setUserOriginal
  ) as React.Dispatch<React.SetStateAction<User | null>>;

  const login = (name: string, email: string) => {
    setUser({
      name,
      email,
      role: "user",
    });
  };

  const logout = () => {
    setUser(null);
  };

  return (
    <UserContext.Provider value={{ user, setUser, login, logout }}>
      {children}
    </UserContext.Provider>
  );
}

In the above code sample, we create a modified setUserOriginal called setUser that uses createDebugSetter under the hood. We then expose it to the context value instead of setUserOriginal .

Whenever setUser is called, it triggers createDebugSetter which does its job of checking the environment the code is running in, and returns a modified setter that will call setUserOriginal after the logging process, or will return setUserOriginal as-is.

This is useful because Context updates can trigger many re-renders. This reveals exactly who changed the shared state.

useState

As you saw in the Context provider example above, we can use the same technique in regular components that use React state setters (just as in Context providers). We log and trace the value. It also shows where it was triggered from within the component or application.

import { useState } from "react";
import { useDebugSetter } from "../hooks/useDebugSetter";

export function UseStateExample() {
  const [count, setCountOriginal] = useState(0);
  const [name, setNameOriginal] = useState("React");

  // Wrap setters with debug functionality
  const setCount = useDebugSetter("Counter", setCountOriginal);
  const setName = useDebugSetter("Name", setNameOriginal);

  const handleIncrement = () => {
    setCount(count + 1);
  };

  const handleDecrement = () => {
    setCount(count - 1);
  };

  const handleNameChange = () => {
    setName(name === "React" ? "Vite" : "React");
  };

  return (
    <div
      style={{
        padding: "20px",
        border: "1px solid #ccc",
        borderRadius: "8px",
        margin: "10px",
      }}
    >
      <h2>useState Example</h2>
      <p>Open the console to see debug logs when state changes.</p>

      <div style={{ marginTop: "15px" }}>
        <p>
          Count: <strong>{count}</strong>
        </p>
        <button onClick={handleIncrement} style={{ marginRight: "10px" }}>
          Increment
        </button>
        <button onClick={handleDecrement}>Decrement</button>
      </div>

      <div style={{ marginTop: "15px" }}>
        <p>
          Name: <strong>{name}</strong>
        </p>
        <button onClick={handleNameChange}>Toggle Name</button>
      </div>
    </div>
  );
}

This works exactly like the Context providers example. The only differences are that the component uses the setCount and setName functions out of the box in buttons and related components. Also, unlike the Context provider, this component has local state that can be passed to its child components if needed.

This is ideal for monitoring unforeseen local state changes or loops triggered by effects.

useReducer

React reducers are used to calculate complex logic before updating the state. This can introduce unwanted side effects during the complex phase. createDebugSetter can help in debugging, as shown below:

import { useReducer } from "react";
import { createDebugSetter } from "../utils/createDebugSetter";

interface CounterState {
  count: number;
  step: number;
}

type CounterAction =
  | { type: "increment" }
  | { type: "decrement" }
  | { type: "reset" }
  | { type: "setStep"; step: number };

function counterReducer(
  state: CounterState,
  action: CounterAction
): CounterState {
  switch (action.type) {
    case "increment":
      return { ...state, count: state.count + state.step };
    case "decrement":
      return { ...state, count: state.count - state.step };
    case "reset":
      return { ...state, count: 0 };
    case "setStep":
      return { ...state, step: action.step };
    default:
      return state;
  }
}

export function UseReducerExample() {
  const [state, dispatchOriginal] = useReducer(counterReducer, {
    count: 0,
    step: 1,
  });

  // Wrap dispatch with debug functionality
  const dispatch = createDebugSetter("CounterReducer", dispatchOriginal);

  return (
    <div
      style={{
        padding: "20px",
        border: "1px solid #ccc",
        borderRadius: "8px",
        margin: "10px",
      }}
    >
      <h2>useReducer Example</h2>
      <p>Open the console to see debug logs for reducer actions.</p>

      <div style={{ marginTop: "15px" }}>
        <p>
          Count: <strong>{state.count}</strong>
        </p>
        <p>
          Step: <strong>{state.step}</strong>
        </p>

        <div style={{ marginTop: "10px" }}>
          <button
            onClick={() => dispatch({ type: "increment" })}
            style={{ marginRight: "10px" }}
          >
            Increment (+{state.step})
          </button>
          <button
            onClick={() => dispatch({ type: "decrement" })}
            style={{ marginRight: "10px" }}
          >
            Decrement (-{state.step})
          </button>
          <button
            onClick={() => dispatch({ type: "reset" })}
            style={{ marginRight: "10px" }}
          >
            Reset
          </button>
          <button
            onClick={() =>
              dispatch({ type: "setStep", step: state.step === 1 ? 5 : 1 })
            }
          >
            Toggle Step ({state.step === 1 ? "1→5" : "5→1"})
          </button>
        </div>
      </div>
    </div>
  );
}

dispatchOriginal, which is the main dispatch function, is replaced with a custom function called dispatch that uses createDebugSetter. When the custom dispatch function is called, it does the job of createDebugSetter and by extension, the job of dispatchOriginal .

This is perfect for logging reducer actions and understanding complex state transitions.

Custom Hooks

Custom hooks are not left out of the equation, as they can use setState in some cases. They’re also capable of running complex logic that could backfire when updating state.

import { useState, useEffect } from "react";
import { useDebugSetter } from "../hooks/useDebugSetter";

// Custom hook that manages a timer
function useTimer(initialSeconds: number = 0) {
  const [seconds, setSecondsOriginal] = useState(initialSeconds);
  const [isRunning, setIsRunningOriginal] = useState(false);

  // Wrap setters with debug functionality
  const setSeconds = useDebugSetter("Timer.seconds", setSecondsOriginal);
  const setIsRunning = useDebugSetter("Timer.isRunning", setIsRunningOriginal);

  useEffect(() => {
    if (!isRunning) return;

    const interval = setInterval(() => {
      setSeconds((prev) => prev + 1);
    }, 1000);

    return () => clearInterval(interval);
  }, [isRunning, setSeconds]);

  const start = () => setIsRunning(true);
  const stop = () => setIsRunning(false);
  const reset = () => {
    setSeconds(0);
    setIsRunning(false);
  };

  return {
    seconds,
    isRunning,
    start,
    stop,
    reset,
  };
}

export function CustomHookExample() {
  const timer = useTimer(0);

  const formatTime = (seconds: number) => {
    const mins = Math.floor(seconds / 60);
    const secs = seconds % 60;
    return `${mins.toString().padStart(2, "0")}:${secs
      .toString()
      .padStart(2, "0")}`;
  };

  return (
    <div
      style={{
        padding: "20px",
        border: "1px solid #ccc",
        borderRadius: "8px",
        margin: "10px",
      }}
    >
      <h2>Custom Hook Example</h2>
      <p>Open the console to see debug logs for internal hook state changes.</p>

      <div style={{ marginTop: "15px" }}>
        <p style={{ fontSize: "24px", fontWeight: "bold" }}>
          {formatTime(timer.seconds)}
        </p>
        <p>
          Status: <strong>{timer.isRunning ? "Running" : "Stopped"}</strong>
        </p>

        <div style={{ marginTop: "15px" }}>
          <button
            onClick={timer.start}
            disabled={timer.isRunning}
            style={{ marginRight: "10px" }}
          >
            Start
          </button>
          <button
            onClick={timer.stop}
            disabled={!timer.isRunning}
            style={{ marginRight: "10px" }}
          >
            Stop
          </button>
          <button onClick={timer.reset}>Reset</button>
        </div>
      </div>
    </div>
  );
}

As shown in previous examples, setSecondsOriginal and setIsRunningOriginal are replaced with setSeconds and setIsRunning. The latter uses the createDebugSetter helper function. This enables console log statements to be printed every second for better visualisation.

Custom hooks often hide multiple internal updates, making it hard to see exactly where each begins.

Best Practices for Using createDebugSetter

When using helper functions like createDebugSetter, it’s best to keep in mind why you’re actually using them. For our purpose here, we’re using it to debug a React application. So I’ll share some tips that will help with this debugging process.

Use Clear Labels

Using labels that can say where createDebugSetter was triggered from is a step in the right direction. Detailed labels will help you better understand where and why the issue may be occurring. Also, keep in mind that the createDebugSetter utility function could be used in several places in your application, and improper labelling could make debugging difficult.

Using the name of the component or area that calls it as the label for createDebugSetter can also be a good pointer for clear labelling, as shown below.

// Bad
createDebugSetter("aaa", setUser)
createDebugSetter("1", setUser)

// Good 
createDebugSetter("UserContextProvider", setUser)
createDebugSetter("From UserContextProvider", setUser)
// Too long but can still work
createDebugSetter("From UserContextProvider in user-context.tsx file", setUser)

Use createDebugSetter Only in Dev Mode

Using createDebugSetter only in a development environment can prevent many headaches. It’s not a good practice to mistakenly expose or log sensitive data in production. Also, logging in production can cause cluttering.

Use createDebugSetter with React DevTools

The createDebugSetter may not be enough for some complex bugs. You can use createDebugSetter and React DevTools for a more powerful/thorough debugging session. Although createDebugSetter cannot be directly integrated with React DevTools, it shows who triggered the update, whereas React DevTools displays what was re-rendered.

Place createDebugSetter in utils

createDebugSetter is a utility function, as I have mentioned above. This means you should place it in a utils folder so any team member can access and use it when needed across your React application.

Things to Avoid

1. Avoid using debug setters in production builds. While they are safe, unnecessary logs can slow down debugging tools. Also, sensitive credentials could be logged mistakenly. There are professional tools you can use, such as Sentry, that let you trace errors and debug your app effortlessly.

2. Don’t conditionally wrap setter functions within components. Perform wrapping outside renders to prevent the creation of new setter identities.

3. Don’t rely on it to replace proper state architecture. This tool helps identify issues, but doesn’t fix poor state design.

4. Don’t depend solely on console logs. Use it as part of a broader debugging workflow, not as the only strategy.

Bonus: How to Convert createDebugSetter to a Hook

Converting to a Hook

The plain createDebugSetter function works, but it creates a new wrapper function on every render when used inside React components. By converting it into a custom hook with useCallback, we can ensure that the wrapper function maintains a stable reference across re-renders, preventing unnecessary performance overhead and making it safe to use in dependency arrays.

Here’s the hook version:

import { useCallback } from "react";

export function useDebugSetter<T>(
  label: string,
  setState: React.Dispatch<React.SetStateAction<T>>
): React.Dispatch<React.SetStateAction<T>> {
  const debugSetter = useCallback(
    (newValue: React.SetStateAction<T>) => {
      // Only log in development
      if (!import.meta.env.PROD) {
        console.groupCollapsed(
          `%c🔄 State Update: ${label}`,
          "color: #2fa; font-weight: bold;"
        );
        console.log("🆕 New value:", newValue);
        console.trace("📍 Update triggered from:");
        console.groupEnd();
      }

      setState(newValue);
    },
    [label, setState]
  );

  // In production, return the original setter (no wrapping overhead)
  // In development, return the debug wrapper
  return import.meta.env.PROD ? setState : debugSetter;
}

How the Hook Version Works

The core difference between the useDebugSetter hook and createDebugSetter is that the function is wrapped in a useCallback that logs debug information before calling the original setter. Apart from this, all other components of the functions remain the same.

Why the Hook Version is Better

The hook version is superior for component usage because it leverages useCallback memoisation of the debug wrapper. This means the function reference stays the same across renders, avoiding potential re-render cascades when the setter is passed to child components or used in useEffect dependencies.

The plain function, by contrast, generates a brand new wrapper on every render, which can break React's optimisation strategies and cause subtle bugs. In production, both versions simply return the original setter, so there's no performance difference there – but in development, the hook prevents unnecessary work.

When to Use the Hook

Use useDebugSetter whenever you're inside a React component and need to debug state updates. This covers the vast majority of cases: wrapping useState setters, passing debug setters to child components, or including them in effect dependencies.

Only reach for the plain createDebugSetter function when you're working outside React components entirely, such as in utility modules, global stores, or configuration files where hooks can't be used. For day-to-day component debugging, the hook is the right choice.

Conclusion

Debugging React state doesn’t have to be guesswork. With a simple helper, you can instantly see what changed, who changed it, where the change originated, and how your app reached that state – all without touching your production environment.

This small utility function can save hours spent searching through your codebase, making you faster, more precise, and more confident in your React application’s behaviour.

Once you adopt this approach, you’ll never debug state the old way again. 🚀

In this article, you’ll learn what the tailwind-sidebar NPM package is, how it works internally, and how to install and configure it in a real project. We’ll walk through setting up a responsive sidebar using Tailwind CSS, explore its key features with practical examples, and see how you can customize and control the sidebar behavior to fit different layouts and screen sizes.

If you’re building a React or Next.js application and want a lightweight yet powerful sidebar solution, tailwind-sidebar is an excellent choice.

Table of Contents

• Prerequisites

• Introduction to the tailwind-sidebar NPM Package

• Why Choose Tailwind Sidebar?

• How to Get Started with Tailwind Sidebar

• Features of Tailwind Sidebar:

• Wrapping Up

Prerequisites

• Basic knowledge of JavaScript (ES6+)

• Familiarity with React fundamentals (components, props, JSX)

• Basic understanding of Next.js project structure and routing

• Experience using npm or yarn for package installation

• Working knowledge of Tailwind CSS

Introduction to the tailwind-sidebar NPM Package

The tailwind-sidebar NPM package is a modern, developer-friendly sidebar component that’s built entirely with Tailwind CSS. It’s designed to help developers create responsive, customizable, and accessible sidebars without the overhead of heavy UI frameworks.

Understanding Tailwind Sidebar

tailwind-sidebar is a lightweight utility package designed to simplify building responsive sidebars using Tailwind CSS. Instead of manually handling sidebar state, transitions, and responsive behavior, the package provides a small JavaScript layer that works alongside Tailwind’s utility classes.

At its core, the package toggles Tailwind classes to control whether the sidebar is open or closed. This makes it framework-agnostic - it works with plain HTML, as well as frameworks like React, Vue, or Next.js, as long as Tailwind CSS is available.

Because it relies on Tailwind utilities rather than custom CSS, the sidebar stays easy to customize, extend, and maintain.

What is Tailwind CSS?

Tailwind CSS is a utility-first CSS framework that lets you build modern, responsive user interfaces directly in your markup. Instead of predefined components, Tailwind provides low-level utility classes that give you full design control without leaving your HTML.

Tailwind Sidebar is built on top of Tailwind CSS, offering a clean, flexible, and highly customizable sidebar solution for modern web applications.

Why Choose Tailwind Sidebar?

Optimized Performance

Tailwind Sidebar relies on utility classes instead of heavy JavaScript logic. This means that it delivers fast load times and smooth interactions, and is ideal for performance-critical applications.

Developer-Friendly

It doesn’t have any complex configuration or component APIs. If you know Tailwind CSS, you already know how to customize the sidebar.

Easy Maintenance

With a simple and predictable structure, updates and custom changes are straightforward, making it suitable for both small projects and large-scale applications.

Growing Tailwind Community

Tailwind CSS has a massive and active community. This means better tooling, regular updates, and a wealth of learning resources to support your development workflow.

How to Get Started with Tailwind Sidebar

This section will walk you through installing and setting up tailwind-sidebar in a React and Next.js application. You’ll learn how to add a sidebar, create menus, add a logo, and customize navigation.

Step 1: Install tailwind-sidebar

To begin, you’ll need to install tailwind Sidebar into your React and Next.js project. You can do this using either npm or yarn.

Using npm:

npm i tailwind-sidebar

Using yarn:

yarn add tailwind-sidebar

This will add tailwind-sidebar and its dependencies to your project.

Step 2: Import the Tailwind Sidebar Component

Once the package is installed, you can import the necessary components from tailwind-sidebar into your project. These components will allow you to customize the sidebar with menus, submenus, and even a logo.

import {

  AMSidebar,

  AMMenuItem,

  AMMenu,

  AMSubmenu,

  AMLogo,

} from "tailwind-sidebar";

Adding Styles to Tailwind Sidebar

To use the default styles of tailwind-sidebar, you need to import its CSS file at the top of your project:

import "tailwind-sidebar/styles.css";

Step 3: Routing Setup for React and Next.Js

To enable navigation inside tailwind-sidebar components like AMMenuItem or AMLogo, you need to pass a link component from either react-router or next/link using the component prop inside the corresponding component, like what’s shown in the below example:

If you're using React:

import { Link } from "react-router-dom";

<AMSidebar width={"270px"}>

     <AMLogo img="https://adminmart.com/wp-content/uploads/2024/03/logo-admin-mart-news.png"
        component={Link}
        href="/"
      >
        Adminmart

      </AMLogo>
      <AMMenu subHeading="HOME">
        <AMMenuItem
         icon={<Home />}
          link="/"  // Passing link to component for routing
          badge={true}
          badgeType="default"
          badgeColor={"bg-secondary"}
          isSelected={true}
        >
          {/* text for your link */}
          Link Text
        </AMMenuItem>
      </AMMenu>
   </AMSidebar>

And if you're using Next.js:

import  Link  from "next/link";<AMSidebar width={"270px"}>
  <AMLogo img="https://adminmart.com/wp-content/uploads/2024/03/logo-admin-mart-news.png"
        component={Link} // Passing link to component for routing
        href="/"
      >
        Adminmart
      </AMLogo>
        AdminMart
      </Logo>
      <AMMenu subHeading="HOME">
         <AMMenuItem
          icon={<Home />}
          link="/tes"
          component={Link}
          isSelected={true}
        >
           Link Text {/* text for your link */}
        </AMMenuItem>
      </AMMenu>
    </AMSidebar>

Step 4: Initializing the Sidebar

Now we’ll set up the AMSidebar component in your application. You can set the width of the sidebar using the width prop. Here’s a simple example:

<AMSidebar width={"270px"}> // pass the width you want your sidebar to have

{/* Sidebar Content Goes Here */}

</AMSidebar>

This initializes the sidebar with a width of 270px. You can adjust this width based on your design requirements.

Step 5: Adding a Logo to the Sidebar

You can add a logo inside the sidebar by using the AMLogo component. To do so, you can provide an img prop to link to a CDN logo image. You can also make the logo clickable by passing a navigation link using the component and href props. Here’s how you can include a logo:

<AMSidebar width={"270px"}>

<AMLogo img="https://adminmart.com/wp-content/uploads/2024/03/logo-admin-mart-news.png"
component={Link}
href="/" 
>        
Adminmart
</AMLogo>

</AMSidebar>

In this example, we’ve added a logo from a CDN using the img prop, used the component prop to pass the Link, and set the navigation path to (/) homepage using the href prop and set the text “AdminMart” as the name of the application.

Step 6: Creating a Menu Inside the Sidebar

Now let’s create a menu inside the sidebar using the AMMenu component. You can specify a submenu heading using the subHeading prop. Inside the AMMenu, you can add AMMenuItem components for each item.

You can also provide a link prop along with the component prop to the AMMenuItem to turn the item into a clickable link.

Here’s how you can structure the menu:

<AMSidebar
 width={"270px"}>
  <AMMenu subHeading="HOME">
  <AMMenuItem  component={Link}  link="/"  badge=”true”  isSelected={true} >
      Modern
    </AMMenuItem>
    <AMMenuItem>eCommerce</AMMenuItem>
    <AMMenuItem>Analytical</AMMenuItem>
  </AMMenu>
</AMSidebar>

In this example:

• We’ve added a AMMenu with the heading “HOME”.

• The first AMMenuItem has a link prop, so clicking it will navigate to the homepage (/).

• The second and third AMMenuItem components are simple text items without links.

You can use the badge="true" prop to indicate a badge or notification on the AMMenuItem. The isSelected={true} prop marks this menu item as currently selected or active (though you can customize this feature according to your needs).

Step 7: Adding Submenus (Optional)

To add submenus inside the main menu, use the AMSubmenu component. The AMSubmenu can be nested inside the AMMenu component and contains its own set of AMMenuItem. Use the title prop to set the submenu heading

Here’s an example of adding a submenu:

<AMSidebar  width={"270px"}>
    <AMMenu subHeading="SERVICES">
      <AMMenuItem  component={Link}   link="/web-development">Web Development</AMMenuItem>
      <AMMenuItem component={Link}  link="/seo-services">SEO Services</AMMenuItem>
      <AMSubmenu title="Marketing">
            <AMMenuItem component={Link}  link="/digital-marketing">Digital Marketing</AMMenuItem>
           <AMMenuItem component={Link}  link="/content-marketing">Content Marketing</AMMenuItem>
      </AMSubmenu>
  </AMMenu>
</AMSidebar>

In this example:

• A submenu under the "Marketing" heading is added inside the "SERVICES" menu.

• The submenu contains two AMMenuItem with links to different service pages.

Features of Tailwind Sidebar:

Utility-First & Lightweight

Tailwind Sidebar is built entirely using Tailwind CSS utility classes. This means there’s no heavy JavaScript logic or extra styling framework, keeping your bundle size small and performance fast.

Code Example:

<AMSidebar width="260px" className="bg-gray-900 text-white">
     <AMMenu>
           <AMMenuItem>Dashboard</AMMenuItem>
      </AMMenu>
 </AMSidebar>

What’s going on here:

• bg-gray-900 text-white: Applies a dark background and white text directly via Tailwind classes (no separate CSS file).

• width="260px": The component prop sets the sidebar width. Here, it shows how Tailwind utilities combine with props to control layout.

Because all spacing and colors are from Tailwind classes, you don’t need additional custom styles.

Fully Responsive Design

The sidebar adapts seamlessly to different screen sizes. Whether you’re building for desktop, tablet, or mobile, Tailwind Sidebar ensures a smooth and consistent navigation experience.

Example usage:

<AMSidebar width="260px" className="hidden md:block">
  <AMMenu>
           <AMMenuItem>Home</AMMenuItem>
      </AMMenu>
</AMSidebar>

What’s going on here:

• hidden md:block: Uses Tailwind responsive utility classes to hide the component (hidden) on mobile screens and show it starting at the md breakpoint (md:block).

This pattern is Tailwind’s common way of controlling visibility across breakpoints without media queries.

Highly Customizable

Tailwind Sidebar allows full customization of colors, hover states, spacing, and typography directly through Tailwind classes. You can customize layout and animations – all without touching custom CSS files.

Example usage:

 <AMMenuItem className="hover:bg-blue-600 rounded-lg px-4 py-2”>
      Analytics
  </AMMenuItem>

What’s going on here:

• hover:bg-blue-600: When you hover the menu item, the background changes to blue, purely via Tailwind.

• rounded-lg: Adds rounded corners.

• px-4 py-2: Controls horizontal (px) and vertical (py) padding to adjust spacing.

Together, these utilities show how Tailwind gives control of design details directly at the HTML/JSX level.

Integration with React & Next.Js:

Tailwind Sidebar seamlessly integrates with both React & Next.js, offering a familiar and efficient development experience.

The sidebar works natively with both React Router and Next.js routing by passing the Link component.

React Example
{
  /* if you are using react then import link from  */
}

import { Link } from "react-router-dom";
<AMMenuItem component={Link} link="/dashboard">
            Dashboard 
</AMMenuItem>

Next.js Example
{
  /* if you are using nextjs then import link from  */
}

import Link from "next/link";

<AMMenuItem component={Link} link="/dashboard">
         Dashboard
</AMMenuItem>

What’s going on here:

• component={Link} link="/dashboard": Shows how you pass your framework’s routing component into AMMenuItem, turning it into a real navigational link.

This means Tailwind Sidebar adapts to both React Router and Next.js routing without boilerplate.

Menu & Submenu Support

Organize your navigation with:

• Main menu items

• Nested submenus

This makes it easy to manage complex navigation structures while keeping the UI clean and intuitive.

Example usage:

<AMMenu subHeading="MANAGEMENT">
             <AMMenuItem>Users</AMMenuItem>
                <AMSubmenu title="Reports">
                   <AMMenuItem>Sales</AMMenuItem>
                      <AMMenuItem>Revenue</AMMenuItem>
                    </AMSubmenu>
</AMMenu>

What’s going on here:

• subHeading="SERVICES": Adds a labeled grouping for menu items.

• The nested <AMSubmenu> demonstrates how nested navigation is rendered and structured in JSX.

This example clearly shows hierarchical menus without additional CSS – structure and Tailwind classes handle layout.

Icon Support

The sidebar comes with built-in support for icons, allowing developers to enhance the visual appeal and usability of their application. Developers can use any icon library and provide the icon component.

Example using lucide-react:

import { Home } from "lucide-react";

<AMMenuItem icon={<Home size={18} />}>
     Home
</AMMenuItem>

What’s going on here:

• icon={<Home size={18} />}: Here, an icon component is passed as a prop.

• You control the size directly via the icon library (Lucide here) and Tailwind handles spacing/placement next to text.

This illustrates how icons and text combine in the sidebar component.

Smooth Transitions

Tailwind Sidebar provides built-in animation support through the animation prop. When enabled, menu items and submenus animate smoothly, improving the overall user experience without requiring custom CSS or JavaScript.

Example Usage:

<AMSidebar width="270px" animation={true}>
           <AMMenu subHeading="SETTINGS">
                  <AMMenuItem>Profile</AMMenuItem>
                  <AMMenuItem>Security</AMMenuItem>
             </AMMenu>
</AMSidebar>

What’s going on here:

• animation={true}: Enables built-in animation support.

The example shows how adding this prop triggers smooth transitions defined by the component itself (still relying on Tailwind utilities internally). You don’t have to write CSS keyframes or transition utilities manually.

Wrapping Up

You have now successfully integrated a fully functional sidebar in your React and Next.js application using tailwind-sidebar. You can further customize the sidebar by:

• Modifying the width and design.

• Adding more submenus, menu items, or icons.

• Using links to navigate between pages.

This setup provides a flexible, responsive, and easy-to-use sidebar, which is perfect for most web applications.

If you want to see how this kind of sidebar fits into a real dashboard layout, you can explore an open-source Tailwind CSS admin template at https://tailwind-admin.com/.

Try It Out:

You can view the working demo of the tailwind-sidebar here: View Demo.

Note: in this tutorial, we utilized lucide-react to construct this sidebar. Feel free to choose an alternative library or use different icons based on your specific requirements.

Other Sidebar NPM Packages

You can also try Next.js Tailwind Sidebar – a simple and responsive sidebar built for Next.js, and React Tailwind Sidebar – a lightweight Tailwind-based sidebar for React applications.

Figma MCP exposes design metadata to AI clients, while Kombai is a frontend-first agent that integrates with editors and existing stacks.

In this article, we’ll feed the same two Figma files into both tools, review how close the output is to the designs, and look at the code structure in a real editor.

Table of Contents

1. What's the Deal?

2. Meet the Tools

   • Kombai

   • Figma MCP

3. Frontend Comparison with Figma

4. Test 1: Simple Portfolio Design

   • Figma MCP

   • Kombai

5. Test 2: Complex Learning Dashboard

   • Figma MCP

   • Kombai

6. What You Should Know Before Using These Tools

7. Final Verdict and What's Next?

8. Conclusion

What's the Deal?

Cloning complex Figma designs by hand isn’t fun anymore, nor is writing your CSS line by line with exact precision.

And sure, you can attach a screenshot or whatever to GPT, but it often ends up with something that barely looks like your design. That's where Kombai or the Figma MCP come in.

They actually get your Figma design metadata and give you frontend code that's super close to the real thing.

So now, instead of spending hours rebuilding what's already in your design file, you can focus more on small tweaks and what actually matters.

Meet the Tools

Kombai

Kombai is an AI agent designed for frontend work. It takes input from Figma (like text, images, or your existing code), understands your stack, and converts it into clean, production-ready UI.

💡 It’s made specifically for frontend work, so you can expect it to be very good at that (unlike more generic tools like ChatGPT or Claude).

Kombai also handles large repositories easily. It doesn't just convert Figma designs into code. It actually understands your entire frontend codebase, even if it's huge.

So, even if you're working on a small side project or a very large production app, it can read, change, and write code that fits perfectly into your existing project.

Note: Kombai isn’t just good at cloning Figma designs and writing clean code. It actually understands your whole repo, too. You can chat with it like GPT, but it already knows your frontend. It can help refactor code, clean things up, or make changes without ever touching your backend logic.

Pretty handy, right?

No backend code is ever touched, which ensures none of your business logic is mistakenly changed.

You can also add Kombai right inside your editor. It works with VSCode, Cursor, Windsurf, and Trae. Just grab it from the extension marketplace, launch it, and you’re ready to go.

With Kombai, you can:

• Turn Figma designs into code (React, HTML, CSS, and so on) using the component library your project already uses.

• Work with a frontend-smart engine that understands 30+ libraries including Next.js, MUI, and Chakra UI.

• Stay in your editor, follow your own conventions, and ship faster with good accuracy.

• And most importantly, preview the changes in a sandbox so you can approve or reject the change before committing it to the files.

You can be up and running in under a minute. Here are the steps to get started:

• Install the extension for your editor

• Sign in and connect your project

• Paste a Figma link or describe what you want to build

• Review the output and commit your code

You can find it in the Extension marketplace of your IDE.

Now, using it is just as simple as accessing it from the left sidebar and having a chat similar to how you would with ChatGPT. (Optionally, you can add your tech stack, but Kombai handles it automatically.)

Head to the docs to get started and find the setup for your editor.

Pricing Note: Kombai is a paid tool but gives you a free plan with 300 credits per month, which is great for personal projects. For more advanced workflows, you can move up to the Pro plan or the Enterprise plan.

If you spend most of your time on the frontend, Kombai may be a good fit.

Figma MCP

Figma MCP (Model Context Protocol) lets AI agents connect directly to your Figma files. It closes the gap between your designs and your AI tools by giving them structured access to real design data instead of relying on screenshots or rough estimates.

It works by exposing your design's node tree, styles, layout rules, and component structure so the model can build the UI with actual design data.

That means tools like Claude Code, Gemini CLI, Cursor, and VSCode can actually read your designs, including layers, components, colors, spacing, and text, and use that context to generate accurate, production-ready code or design updates.

With Figma MCP, you can:

• Let AI tools pull live data from your Figma files, so your code suggestions always match your latest designs

• Ask your AI assistant to inspect components, layouts, or styles directly from Figma

• Generate UI code that reflects real design and structure instead of guessing from an image

• Keep designers and developers in sync without constantly sending files back and forth.

Setting it up is simple:

• Run the Figma MCP server locally

• Authorize your Figma workspace

• Connect your editor or AI tool (Cursor, Claude Code, Gemini CLI, and so on)

For this test, I'll be using Figma MCP inside Claude Code in Linux, and setting it up is as simple as adding the following JSON in your Claude configuration file ~/.claude.json:

{
  "mcpServers": {
    "Framelink MCP for Figma": {
      "command": "npx",
      "args": ["-y", "figma-developer-mcp", "--figma-api-key=YOUR-KEY", "--stdio"]
    }
  }
}

For Windows users:

{
  "mcpServers": {
    "Framelink MCP for Figma": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "figma-developer-mcp", "--figma-api-key=YOUR-KEY", "--stdio"]
    }
  }
}

Pricing Note: To use Figma MCP, you need to have a paid Figma plan, either Professional, Organization, or Enterprise. But there's a community-maintained open-source MCP server, Figma-Context-MCP, that you can test out for free – which I'll be using for this test.

Once it’s running, any MCP-supported tool can understand your design files, making frontend coding development much more accurate.

Check the Figma MCP Guide to get started.

Frontend Comparison with Figma

For this test, we'll be comparing Kombai with Figma MCP using two Figma designs: one is a simple portfolio design, and the other is a more complex learner dashboard.

NOTE: For this test with Figma MCP, I'll be using Sonnet 4, which, in my experience, has been the best model for coding the frontend. I've also tested with the recent GPT-5 and Opus 4, but Sonnet 4 seems to be the best for frontend work. If you want to try other models, feel free to do so and see if you notice much difference in the results.

💁 Prompt: Clone this Figma design from this Figma frame link attached. Write clean, maintainable, and responsive code that matches the design closely. Keep components simple, reusable, and production-ready.

Quick note about the videos in the next section: The demo recordings are pretty long because I kept them raw. The idea is to show how the tools behave in real time. If you only care about the final output, feel free to skip to the end of each video.

Test 1: Simple Portfolio Design

Let's start with a simpler design that doesn't have much going on in the UI.

You can find the Figma design template here: Personal Portfolio Template

Figma MCP

Here's the response from Figma MCP:

This is pretty decent. The overall UI looks good, and the colors and fonts are all accurate. The biggest visual issues are with the hero image and a few icon placements, which are a bit off compared to the original Figma file.

The overall implementation took just about 5 minutes of coding and achieved this entire result in one go, as you see in the video demo. The time it takes isn't really dependent on the MCP itself but mostly on the model, so the timings will vary based on the model you choose to work with. The timing is something you can simply ignore here.

The whole page is split into sensible components (Header, Hero, Projects, ProjectCard, Footer) and composed in a clean page.tsx.

export default function Home() {
  return (
    <div className="min-h-screen bg-bg-gray">
      <Header />
      <main>
        <Hero />
        <Projects />
      </main>
      <Footer />
    </div>
  );
}

That is a nice, readable starting point for a Next app.

You can find the code it generated here.

But here are some issues I noticed right away:

1. The hero decoration is positioned with pretty brittle absolute values:

<div className="hidden lg:block absolute right-0 top-0 w-[720px] h-[629px] pointer-events-none">
  <div className="relative w-full h-full">
    <div className="absolute left-0 top-0 w-[777px] h-[877px] -translate-y-[248px] bg-brand-yellow" />
    <div className="absolute left-0 top-0 w-full h-full">
      <img
        src="/images/hero-decoration-58b6e4.png"
        alt="Decorative"
        className="w-full h-full object-cover"
      />
    </div>
  </div>
</div>

This achieves the desired look at one screen size, but it can easily become misaligned when you resize. When compared side by side with the Figma frame, the hero image and yellow shape do not align as they should.

2. Fixed Header

For a simple portfolio page with a short hero, a fixed header is not always worth the complexity.

The problem here is that since the header is fixed to the top, the rest of the content also starts from the top. On smaller devices, this might cover parts of the content when scrolling.

return (
  <header className="fixed top-0 left-0 right-0 bg-bg-gray z-50 h-14">
    {/* ... */}
    <button
      onClick={() => scrollToSection("about")}
      className="font-raleway ..."
    >
      About
    </button>
    {/* more buttons */}
  </header>
);

This is still a great head start, though it is not quite at the level where I would add it to a production repo without tidying up some of the layout changes.

Kombai

Here's the response from Kombai:

Visually, this one is extremely close to the Figma template. Apart from the hero image being slightly off from the Figma design, I see no other differences. It actually feels like the design is exactly copy-pasted.

Notice that the font, images, and icons are exactly the same, which to me is insane.

You can find the code it generated here.

Here are the specific things it does better in this simple example.

1. It mirrors the Figma typography and colors as real tokens

Kombai sets up globals.css with Figma-like tokens and even defines utility classes for the text styles:

:root {
  /* ... */
}

@theme inline {
  /* ... */
}

@utility text-heading-large {
  /* ... */
}

@utility text-subtitle {
  /* ... */
}

That is very similar to how a designer would set up styles in Figma, and it means you can reuse these utilities in new screens instead of retyping Tailwind font sizes everywhere.

2. Components are cleaner and more reusable

All the other components, like Hero or some smaller button components, use the same styles set up in styles.css.

const baseClasses =
  "text-button px-6 py-3 rounded-sm transition-all hover:opacity-90";

const variantClasses =
  variant === "primary"
    ? "bg-(--primary-yellow) text-(--foreground)"
    : "bg-transparent border-2 border-(--foreground) text-(--foreground) hover:bg-(--foreground) hover:text-white";

The footer pulls each icon into its own component:

import InstagramIcon from "./icons/InstagramIcon";
import LinkedInIcon from "./icons/LinkedInIcon";
import MailIcon from "./icons/MailIcon";

In practice, that means if the designer swaps the mail icon or tweaks the size, there is a single place to update it.

So for this simple test, Kombai’s output is both closer to the visual design and a bit nicer structurally for a real project. I would still tweak naming and some minor details, but I would happily keep most of this as is. How crazy is that?

Test 2: Complex Learner Dashboard

So, for the second one, let's create a slightly more complex design with a lot happening in the UI.

You can find the Figma design template here: Learning Dashboard

Figma MCP

Here's the response from Figma MCP:

This is good, considering the complexity of the design. It’s able to put all the images and assets in place. This is much better than what I expected. But there's a slight inconsistency in the placement of images between the original design and the implementation, as you can see for yourself.

If I compare the time, this got it done super fast, in just about 8 minutes, whereas Kombai took over 15 minutes to get it done (but with a better result).

You can find the code it generated here.

Here's what I like and dislike about a few things it did here:

1. Great smaller components, but everything is still quite page-centric

It does break things into logical components like Sidebar, Input, Button, StatCard, CourseCard, and Icons. The main page then stitches them together:

export default function Home() {
  const mentors = [
    {
      id: 1,
      name: "John Doe",
      subject: "UI/UX Design",
      color: "bg-purple-500",
    },
    // ...
  ];

  return (
    <div className="flex items-center gap-8 w-full max-w-[1440px] h-[933px] bg-white rounded-[20px] mx-auto overflow-hidden">
      {/* Sidebar */}
      <Sidebar />

      {/* Main content */}
      <main className="flex flex-col items-center gap-6 pt-5 pb-0 flex-1 h-full overflow-hidden">
        {/* Search, hero, cards, mentor table */}
      </main>
    </div>
  );
}

The separation into components is nice, but everything is still wired directly inside one big page component with inline mock data. For a real app, I would want that data in its own module, ideally typed, so it is not mixed with layout logic.

2. Hard-coded dimensions tied to the original frame

The outer container is pinned to a specific height:

<div className="flex items-center gap-8 w-full max-w-[1440px] h-[933px] bg-white rounded-[20px] mx-auto overflow-hidden">

That’s fine if you are literally recreating a 1440 by 933 frame for a screenshot, but in a live app, it means:

• You get weird empty space on taller screens.

• Anything that grows vertically (longer course titles, more mentors) will either overflow or get clipped.

The hero banner has the same kind of pixel-exact positioning:

<div className="relative w-full h-[181px] bg-primary rounded-[20px] overflow-hidden">
  <Image
    src="/images/star1.svg"
    alt="Star"
    width={80}
    height={80}
    className="absolute top-[45px] left/[683px] opacity-25"
  />
  {/* four more star images with fixed top/left */}
</div>

This is great for matching the specific Figma design, but as soon as the width changes, these positions stop lining up perfectly.

So overall, I would call this result surprisingly good for a single prompt, but a bit rigid and template-like once you start thinking about real data and using it in production.

Kombai

Here's the response from Kombai:

You will see in the video that I had to fix a small error with an extra prompt, but after that, it produced a fully working dashboard. The visual match is very strong, given how complex the layout is.

You can find the code it generated here.

Here is what stands out compared to the MCP output.

1. It treats the Figma file like a real product, not just a static screen.

Instead of wiring everything in a single page with inline arrays, Kombai creates proper domain types and a mock-data.ts:

import { UserProfile, Friend, Course, ProgressCard, Mentor } from "./types";

export const courses: Course[] = [
  {
    id: "1",
    title: "Beginner's Guide to becoming a professional frontend developer",
    category: "Frontend",
    thumbnail: "/images/course-coding.jpg",
    instructor: {
      name: "Prashant Kumar singh",
      role: "software Developer",
      avatar: "/images/avatar-prashant.jpg",
    },
  },
  // ...
];

That looks much closer to what you would expect in a production codebase: clear types, data separated from layout, and a page component that just composes everything.

2. Better mapping of the smaller UI pieces

The course card is similar to the MCP one, but now it is fully driven by a Course object:

export function CourseCard({ course }: { course: Course }) {
  return (
    <div className="flex flex-col gap-2.5 rounded-[20px] bg-white shadow-[0px_14px_42px_rgba(8,15,52,0.06)] overflow-hidden min-w-[268px]">
      <div className="relative">
        <Image
          src={course.thumbnail}
          alt={course.title}
          width={244}
          height={113}
          className="w-full h-28 object-cover rounded-t-xl"
        />
        <button className="absolute top-3 right-3 w-2 h-2 bg-white rounded-full" />
      </div>
      <div className="px-3 pb-4 flex flex-col gap-2.5">
        <span className="text-[8px] font-normal uppercase text-primary px-3 py-1 bg-purple-50 rounded w-fit">
          {course.category}
        </span>
        <p className="text-[14px] font-medium text-text-primary leading-tight">
          {course.title}
        </p>
        <div className="w-full h-1.5 bg-gray-100 rounded-full overflow-hidden">
          <div
            className="h-full bg-primary rounded-full"
            style={{ width: "60%" }}
          />
        </div>
        {/* instructor avatar and name */}
      </div>
    </div>
  );
}

The structure and text styles are very close to the original design, and because the card is fully data-driven, you can plug in real data without touching the JSX.

3. Design tokens and typography utilities again

Just like in the portfolio example, Kombai sets up a proper token layer for the dashboard:

:root {
  /* ... */
}

@utility heading-section {
  /* ... */
}

@utility text-caption {
  /* ... */
}

The components then reuse these utilities, which keeps the code close to the design system instead of scattering font sizes and colors everywhere.

4. Things I would still tweak

It is not perfect:

• The Next layout.tsx is still using the default Geist fonts and “Create Next App” metadata, so you would want to align that with the Inter font and real app title.

• Some of the mock data has inconsistent casing in names and roles, which you would clean up in a real project.

• The play button on the course card is just a white dot button for now, so you would still plug in the real icon.

But even with those issues, it is very close to something I would actually keep in a production repo after a quick pass.

Now, this is not as perfect as the previous Kombai implementation, and it did not run into errors. But considering how complex this design is, with multiple different cards with images and all, it's still really impressive to me.

For this one, it took a bit longer to code, but in my opinion, the extra time was worth it.

Imagine you're building something similar and get a response this good already. Then it's not that big of a deal to iterate a little bit, right? You don't have to start from scratch. Just make a few changes if required, and you're done.

What You Should Know Before Using These Tools

As good as these tools are, they’re not something you can just trust blindly. They’ll get you off to a solid start, but you’ll still need to tweak a few things before calling it production-ready.

Kombai does a great job cloning Figma designs and writing clean, modular code. It breaks components into smaller files and generally follows good structure.

The only issue I noticed is that it sometimes slips on naming conventions. Since it scans your entire codebase to stay consistent with your setup, it can be a bit slower to generate code, but that’s also what makes it smarter. You’re not just getting a Figma cloner, you’re getting an assistant that actually understands your frontend.

Figma MCP is fast and does a decent job matching the UI, although the results depend a lot on the model you use for generation. If your main goal is to clone Figma designs quickly and you don’t mind refining the output, it’s a good option.

In short, both tools can save you a ton of time, but they’re not plug-and-play replacements for a frontend workflow. Treat them as part of your toolkit, and you’ll get the best results.

Final Verdict, and What's Next?

Now that you’ve got the gist of what these tools can do, go ahead and try them out. You can turn your Figma designs into working frontends in just a few minutes without all the endless play with CSS.

To sum up, here’s the quick rundown:

• If you want production-ready code that actually looks like your Figma design and you mostly live in VS Code, Cursor, or any GUI IDE, go with Kombai. It nails the details and even understands your codebase, which is completely missing in Figma MCP.

• If you just want to clone a Figma design quickly and don’t mind if things are slightly off, Figma MCP is totally fine. It gets the job done pretty well.

Basically, choose Kombai if you care about precision and code quality with codebase understanding.

Choose Figma MCP if you want something quick, that works and looks decent enough. 🤷‍♂️

Conclusion

So, what do you think? Pretty cool, right? This was a fun little experiment to see how close tools like Figma MCP and Kombai can get to cloning real frontends straight from Figma.

If you’re into building frontends and want to save yourself a few hours of CSS pain, definitely give them a try. Just don’t expect them to be perfect in one try – their output still needs review and likely a little refining.

That’s all for this one. Thank you for reading! ✌️

Behind these experiences, front-end developers play a pivotal role. They don’t just turn mockups into functioning code – they shape the bridge between design and functionality, making user experiences come to life.

To do this effectively, front-end developers need to understand UI (User Interface) and UX (User Experience) design.

• UI focuses on the look and feel of the product, including colors, typography, buttons, layouts, and visual consistency.

• UX focuses on how users interact with the product, including ease of use, accessibility, responsiveness, and overall satisfaction.

In today’s competitive digital landscape, knowing only code isn’t enough. Let’s explore why UI/UX knowledge is crucial for front-end developers and how it impacts both the developer’s career and the end-user experience.

Table of Contents:

• Why Front-End Devs Should Understand UX/UI

• Key UI/UX Principles Every Front-End Developer Should Know

• Benefits of UI/UX Knowledge for Front-End Developers

• How Developers Can Learn UI/UX

• What to Keep in Mind about UX/UI

• Conclusion

Why Front-End Devs Should Understand UX/UI

Front-end development is not just about writing clean code. It’s also about creating experiences. A developer might know every JavaScript framework and CSS trick, but if they don’t understand UI (User Interface) and UX (User Experience) principles, their work risks feeling clunky, confusing, or unappealing.

Why UI/UX Knowledge Matters

1. Bridging the gap between design and development: Front-end developers act as the bridge between design mockups and functional applications. By understanding UI/UX principles, developers can implement designs more accurately, while also identifying potential improvements in usability or accessibility.

2. Improving usability: UI/UX knowledge helps developers think beyond visuals. They consider user flow, navigation, responsiveness, and accessibility. For example, a button’s size, contrast, and placement affect how easily users interact with it.

3. Creating consistent experiences: Without consistency, users get frustrated. Developers who understand design systems and UX patterns ensure that spacing, typography, colors, and interactions feel uniform across the app.

4. Boosting collaboration with designers: Developers who know UI/UX can speak the same language as designers. This leads to smoother handoffs, fewer revisions, and faster delivery. Instead of just “coding what’s given,” they can proactively suggest alternatives when something won’t scale well.

5. Improving user satisfaction and business goals: Ultimately, great UI/UX translates to happy users. An application that is visually appealing, easy to navigate, and responsive encourages engagement, reduces bounce rates, and drives conversions.

Key UI/UX Principles Every Front-End Developer Should Know

A website or application may be powered by complex logic in the background, but what users truly experience is the interface. This is where understanding UI/UX principles becomes essential. Let’s explore some of the core ideas every developer should master.

Consistency Builds Trust

One of the most fundamental principles of good UI/UX is consistency. When layouts, typography, buttons, and navigation behave the same way across an application, users instantly feel more confident.

Imagine a scenario where a “Sign Up” button looks completely different on each page – one rounded, another outlined, another square. This inconsistency doesn’t just look unprofessional, it breaks trust and forces users to pause and think. A consistent interface, on the other hand, feels reliable and predictable.

Example:

The image below compares two sets of buttons to highlight the importance of design consistency. On the left, the "Consistent Buttons" example shows "Sign Up" and "Login" buttons that look identical in color, shape, and style, making the user interface appear clear and professional. On the right, the "Inconsistent Buttons" example displays the same buttons but with different colors, shapes, and text styles, which can make the interface confusing and visually unappealing.

Guiding Users with Visual Hierarchy

Users rarely read web pages word by word. Instead, they scan for what matters. That’s why visual hierarchy is so important. By adjusting size, contrast, color, and spacing, developers can subtly guide attention. Headlines should naturally stand out from body text, and primary actions like “Buy Now” or “Sign Up” should be visually stronger than secondary options.

A great example of this is a pricing page where the recommended plan is highlighted with a brighter color and a slightly larger card, drawing the eye instantly.

Example:

The image below shows three pricing plans Base, Pro, and Enterprise, with the Pro plan visually highlighted in the center. The design uses size, color contrast, and placement to guide users attention toward the Pro plan, illustrating the concept of visual hierarchy for easier decision-making.

Accessibility for Everyone

A beautiful interface is meaningless if it’s not usable by all. Accessibility ensures that people with disabilities can interact with your site just as easily as others. This means paying attention to color contrast so text remains readable, using semantic HTML so screen readers can interpret content, and adding descriptive alt text to images.

Even small improvements – like ensuring forms have proper labels – can transform usability. A login form without labels may look clean, but it excludes users who rely on assistive technology.

Example:

The picture below compares two login forms to show the difference between poor and good form design. The "Bad Form" on the left lacks clear labels for its input fields and has a dull, hard-to-see login button, making it less user-friendly. The "Good Form" on the right uses visible labels for each field and a prominent, easy-to-find login button, which improves clarity and usability for users.

Designing for All Screens

With most traffic now coming from mobile devices, responsive design is no longer optional. A layout that looks perfect on desktop but breaks on mobile will drive users away.

Mobile-first thinking encourages developers to start small and then expand layouts for larger screens. This ensures that buttons are touch-friendly, text remains readable, and navigation adapts naturally. A dashboard that stacks neatly into a single column on mobile but expands gracefully on desktop provides a consistent experience everywhere.

Example:

The image below shows how pricing plans are tailored for various screen sizes. On the left, the "Desktop Design" displays multiple plans side by side, allowing easy comparison. On the right, the "Mobile Design" stacks the plans vertically, making them easy to read and navigate on smaller screens.

Clear Feedback and Interaction

Users should never be left guessing. Every interaction must provide feedback – whether that’s a hover animation on a button, a loading indicator when submitting a form, or a success/error message after an action.

Consider a “Submit” button: if it does nothing after being clicked, the user may think the site is broken. But if it shows a spinner followed by a success message, the experience feels reassuring and complete.

Example:

The gif below demonstrates clear user feedback during a button interaction. When the "Submit" button is clicked, a loading spinner appears to show that the action is being processed, followed by a success message once the process is complete. This ensures users know their action is registered and provides reassurance, preventing confusion or uncertainty.

Designing with the User in Mind

At the heart of UI/UX is empathy. A developer must always ask: “Is this intuitive for someone seeing it or using it for the first time?”

Placing the search bar at the top of a page makes sense because that’s where users expect it. Hiding it deep inside a menu might seem clever, but it often frustrates users. The best interfaces are designed around user expectations, not developer preferences.

Example:

The GIF image below demonstrates the impact of user-centered design in UI/UX. The "Good UX" example places the search bar at the top of the page, making it immediately visible and easy for users to find. In contrast, the "Bad UX" example hides the search bar inside a menu, which makes it harder to access and can frustrate users.

Benefits of UI/UX Knowledge for Front-End Developers

Front-end developers often see themselves as the builders, the ones who transform design files into functional web pages and applications. But those who also understand UI and UX principles unlock a significant advantage. Their work doesn’t just “look like the design” – it feels intuitive, efficient, and enjoyable for the end user.

Bridging the Gap Between Design and Code

Designers create mockups with a vision in mind, but many of those details get lost when moving into code. A developer with UI/UX knowledge understands why spacing is generous, why a button changes color on hover, or why a particular layout improves navigation.

Instead of copying pixels mechanically, they preserve the intent of the design. Without this understanding, designs may look “close enough” but feel awkward in practice.

Example:

The image below compares bad versus good UI design. The left side shows a messy header with mismatched buttons that have different shapes, sizes, and colors, demonstrating poor design consistency. The right side shows the same header redesigned properly with uniform blue buttons that are consistently sized and aligned, creating a much cleaner and more professional appearance.

Building for Usability, Not Just Functionality

Functionality answers the question: Does this work? Usability asks: Does this feel natural to use? Developers who understand UI/UX instinctively add helpful touches like loading indicators, clear error messages, and accessible labels.

Without this mindset, users encounter confusing flows, tiny buttons, hidden actions, or forms with no feedback. The product works, technically, but it doesn’t work well.

Example:

The image below shows a login form comparison between poor and improved UX design. The left side demonstrates bad UX with empty input fields that have no placeholder text, a bland gray login button, and unclear help text that says "Forgot password? Not obvious." The right side shows the improved version with helpful placeholder text like "Enter your email" and "Enter your password," a prominent blue login button that's more visually appealing, and clearer, actionable help text that says "Forgot password? Click here to reset."

Faster Collaboration and Fewer Iterations

When developers understand design language, they can talk specifics, “The spacing here should follow the 8px grid,” instead of vague complaints like “This looks off.” This cuts down on revisions, keeps teams aligned, and builds trust between designers and developers.

Without this shared language, collaboration slows. Misinterpretations multiply, feedback loops drag on, and projects risk missing deadlines.

Stronger Problem-Solving and Adaptability

Projects rarely stick to the original plan. Edge cases and new requirements always emerge. Developers with UI/UX insight can make smart, user-centered choices on the fly, selecting layouts, typography scales, or navigation patterns that enhance the experience.

Without this knowledge, fixes tend to be purely technical, functional, but clunky, leaving users to struggle through awkward flows.

Example:

The image below demonstrates dashboard navigation design. The left side shows a "Cluttered Dashboard" with nine separate menu items scattered randomly (Users, Settings, Reports, Analytics, Notifications, Billing, Integrations, Logs, Support), making it overwhelming and difficult to navigate. The right side shows a "UX-Improved Dashboard" that organizes the same options into three logical categories: "User Management" (Users, Roles), "Settings" (General, Billing, Integrations), and "Analytics & Support" (Reports, Analytics, Support). The improved version reduces cognitive load by grouping related functions, making the interface much easier to understand and navigate.

Competitive and Professional Advantage

In today’s job market, many developers can code a responsive layout. What makes someone stand out is their ability to think about both aesthetics and usability. Employers and clients value these hybrid professionals who bridge two traditionally separate worlds.

Without UI/UX awareness, developers risk blending into the crowd. Their work may be solid, but it lacks the polish and empathy that win user trust and give products a competitive edge.

Missed Opportunities for User Trust

Users form judgments about applications within seconds. If the interface looks clunky or confusing, it signals to them that the product may not be reliable. Developers who overlook UI/UX miss this psychological layer of trust. An intuitive, visually consistent interface not only helps users accomplish their tasks but also assures them that the product is worth relying on.

Without UI/UX, developers often:

• Push out features that confuse rather than guide.

• Create inconsistent layouts that erode confidence.

• Overwhelm users with unnecessary complexity.

Example:

The image below illustrates how UI/UX design affects user trust. The left side shows "Missed Trust" with a poorly designed interface that has inconsistent styling - a basic input field, a small gray "Continue" button, and a confusing pink "Next Step?" button that creates uncertainty about what action to take. The right side shows "Built for Trust" with a clean, professional design featuring a well-styled input field with placeholder text and a prominent, clear "Continue" button that gives users confidence in their actions.

Inclusivity and Accessibility

Accessibility is a core part of good UX. Developers with this awareness naturally consider screen reader support, keyboard navigation, and high-contrast modes. This ensures products welcome all users.

Without it, developers unintentionally exclude large groups of people and may even face compliance issues. The result isn’t just a less usable product, it fails to respect and include its audience.

How Developers Can Learn UI/UX

For a long time, developers and designers were seen as working on two separate islands. Developers wrote code, designers crafted interfaces, and the two worlds met somewhere in the middle. But today, the line is much blurrier. Employers and teams increasingly expect developers to have at least a foundational understanding of UI/UX.

The good news is that UI/UX isn’t a mysterious art that only designers can master. Developers can learn it step by step, much like they learned programming languages or frameworks. It requires observation, practice, and empathy for the end user.

Start with Observation

One of the simplest ways to begin learning UI/UX is by observing products you already use every day. Pay attention to how you navigate your favorite apps or websites. Notice how buttons are placed, how forms are structured, or how feedback is given when you complete an action. Ask yourself: Why does this feel easy to use? Why does this frustrate me?

Observation builds awareness. Once you start noticing design decisions in your daily digital life, you’ll begin to understand the invisible rules that shape user experiences.

Understand the Basics of UX Principles

Before diving deep, you should familiarize yourself with some core UX principles. These aren’t abstract theories but practical guidelines for making products usable. To review them:

• Consistency: Users expect familiar patterns. A back button should always go back, not do something unpredictable.

• Clarity: Every element should serve a purpose. If it confuses, it doesn’t belong.

• Feedback: Users need to know when an action has been registered, whether it’s a loading spinner, a success message, or an error prompt.

• Accessibility: Interfaces should be usable by everyone, including people with disabilities.

Learning these basics gives you a strong foundation for evaluating and improving your work.

Practice Through Side Projects

Theory alone won’t help – as a dev, you need to practice. A simple way to start is by taking small side projects and focusing not just on functionality but also on experience. Build a to-do app, for instance, but pay attention to how tasks are added, how the interface responds, and how information is displayed.

Treat each project as a learning ground for experimenting with usability, not just coding. You’ll begin to notice where users get stuck and how small tweaks can create big improvements.

Learn Design Tools, But Don’t Get Overwhelmed

You don’t need to become a master of Figma or Sketch overnight, but learning the basics of design tools can help you bridge the gap between development and design. Being able to open a Figma file, understand layout grids, or inspect spacing gives you a significant advantage when collaborating with designers.

The goal isn’t to replace designers but to communicate better with them and reduce misinterpretations.

Follow Real-World UI/UX Examples

Another powerful way to learn is by studying existing products. Look at how popular apps like Spotify, Airbnb, or Notion structure their interfaces. Read UX case studies where designers explain their decisions. These real-world examples give context to abstract principles and help developers see how theory translates into practice.

Seek Feedback from Designers and Users

Learning UI/UX isn’t just about self-study. It’s also about listening. Share your projects with others, especially designers or actual users, and ask for feedback. What felt easy? What was confusing? As a developer, you may overlook usability issues because you’re too close to the code. External feedback helps you see the product with fresh eyes.

Build Empathy Through Testing

Nothing teaches UI/UX faster than watching someone use your product. Conduct informal usability tests with friends, colleagues, or even strangers. Observe where they hesitate, where they click instinctively, and where they get frustrated. This direct exposure helps developers understand that design isn’t just about what looks good, it’s about what feels natural in practice.

Keep Learning from Design Communities

UI/UX is a constantly evolving field. You can grow by engaging with design communities, reading blogs, or following design challenges. Platforms like Dribbble, Behance, and UX Collective provide inspiration and practical lessons. Over time, this exposure sharpens your design instincts and keeps you aligned with industry trends.

Some Helpful Resources to Learn UI/UX:

📚 Books:

• Refactoring UI (Adam Wathan & Steve Schoger): https://refactoringui.com/book (I’ve read this book, and the feedback is awesome)

• The Design of Everyday Things (Don Norman): https://jnd.org/the-design-of-everyday-things/

• Laws of UX (Jon Yablonski): https://lawsofux.com/

🌐 Blogs & Guides:

• Smashing Magazine: https://www.smashingmagazine.com/category/uxdesign/

• UX/UI Design Tutorial: https://www.freecodecamp.org/news/ui-ux-design-tutorial-from-zero-to-hero-with-wireframe-prototype-figma/

• UX Collective: https://uxdesign.cc/

• Nielsen Norman Group (NNG): https://www.nngroup.com/articles/

🎥 YouTube:

• DesignCourse (Gary Simon): https://www.youtube.com/c/DesignCourse

• Flux Academy: https://www.youtube.com/c/FluxWithRanSegall

• Steve Schoger (Design Tips): https://www.youtube.com/c/SteveSchoger

• Kevin Powell: https://www.youtube.com/kepowob

🛠️ Tools & Practice:

• Figma: https://www.figma.com/

• Dribbble: https://dribbble.com/

• Behance: https://www.behance.net/

• Mobbin: https://mobbin.com/

What to Keep in Mind about UX/UI

Some of these tips might feel counterintuitive to anyone who lives in code all day. Yet they explain why users behave the way they do, and why some products succeed where others fail. Here are some of the weird but true things about UI/UX that every developer should know.

Users Rarely Read. They Scan….

You may spend hours ensuring error messages, tooltips, or onboarding text are written clearly. But here’s the strange reality: most users don’t actually read them. They scan. Their eyes dart across headings, buttons, and visuals, often skipping over entire paragraphs.

This means your beautifully worded instructions may never be read. Instead, design needs to be built around visual cues and intuitive flows that guide users without relying on text.

Example:

The image contrasts verbose versus concise user instructions. The left side shows "Wordy Instructions" with a lengthy paragraph that overwhelms users with unnecessary details about clicking settings, navigating tabs, selecting preferences, and remembering to save changes. The right side demonstrates "Quick Setup" with a clean, numbered three-step process: "1. Open Settings, 2. Choose Preferences, 3. Click Save" followed by a clear "Save & Continue" button. The improved version eliminates cognitive overload by presenting the same information in a scannable, actionable format that's much easier for users to follow and complete successfully.

A Button’s Size Can Outweigh Its Functionality

From a developer’s perspective, a button either triggers a function or it doesn’t. But in UX, the size, placement, and color of that button can matter more than the functionality behind it.

For example, two buttons may perform the same action, but if one is too small, hidden, or styled poorly, users might not notice it at all. The function exists in code, but in practice, it doesn’t exist for the user.

Example:

The image shows how button size and design affect usability. The left side has a small, gray "Save" button that's hard to notice and might be missed by users. The right side has the same "Save" button but larger, darker, and more prominent, making it much more likely that users will see and click it. Same function, but better design leads to better user interaction.

More Features Often Mean Less Usability

It feels logical to think that giving users more options and features adds value. But weirdly, the opposite is often true. The more you add, the harder the product becomes to use.

This is called the paradox of choice: too many options create decision fatigue. Developers love shipping features, but good UX often means stripping things away until only the essentials remain.

“Ugly” Designs Sometimes Work Better

Developers may assume a slick, modern UI always wins, but there are cases where “ugly” or “dated” designs perform better because they feel familiar and trustworthy. Think of Craigslist: it hasn’t changed much in decades, but people use it because it feels simple. This shows that usability can beat aesthetics when it comes to building trust.

Example:

The image illustrates that modern aesthetics don't always equal better usability. The left side shows a "Modern & Slick" design with a sleek, dark "Explore" button that looks impressive and cutting-edge but might feel unfamiliar or untrustworthy to some users. The right side shows an "Old-School & Familiar" design with a simple gray "Continue" button that appears outdated but feels trustworthy and familiar to users.

Users Don’t Think Like Developers

This might be the weirdest truth of all: users don’t care about code efficiency, data structures, or the elegant architecture behind the app. They only care about what’s on their screen and whether it makes sense.

For example, a developer might proudly optimize a search algorithm, but if the search bar is hidden in a menu instead of being front and center, users will complain that “the app doesn’t have search.” The feature exists, but in their minds, it doesn’t.

Example:

The GIF image demonstrates the impact of user-centered design in UI/UX. The "Good UX" example places the search bar at the top of the page, making it immediately visible and easy for users to find. In contrast, the "Bad UX" example hides the search bar inside a menu, which makes it harder to access and can frustrate users.

Small Delays Feel Bigger Than They Are

From a technical side, shaving 300 milliseconds off a request may not feel like a huge deal. But to a user, even slight delays feel magnified. A loading spinner that lingers for a second can feel like forever. UX research shows that anything beyond 2–3 seconds risks losing the user’s attention.

This means developers must think not only about raw performance but also about perceived performance using skeleton screens, micro-animations, or progress indicators to make waits feel shorter.

Example:

The image compares the loading experience design. The left side shows "Feels Slow" with just a basic spinner and "Loading..." text that makes even short delays feel endless to users. The right side shows "Feels Faster" using skeleton screens - gray placeholder blocks that mimic the content structure while loading, making the same delay feel much shorter because users can see that progress is happening and get a preview of what's coming.

Accessibility Isn’t Just for “Some” Users

Developers sometimes assume accessibility features (like screen reader support, keyboard navigation, or high-contrast modes) are niche concerns. But here’s the reality: everyone benefits.

Captions help people in noisy environments, large touch targets help on small screens, and good color contrast improves readability for everyone. Accessibility isn’t just about inclusivity – it’s about creating universally better experiences.

Conclusion

In modern web development, understanding UI/UX isn’t optional. It’s essential. Front-end developers aren’t just programmers – they are the architects of user experience. By learning design principles, developers improve collaboration, write smarter code, and create products that truly serve users.

Whether you’re just starting or already experienced, investing time in UI/UX knowledge will set you apart and open new opportunities. Explore design resources, collaborate closely with designers, and experiment with small design tasks in your projects.

At the end of the day, the best front-end developers don’t just write code, they create experiences users love.

This loop, known as tutorial hell, is where many aspiring developers get stuck. It feels productive, but over time, you start to realize you’re not really learning how to think or build like a developer. You’re just getting better at following instructions.

In this guide, I’ll walk you through exactly how to break free from that cycle. This is not a pseudo-motivational guide. It’s practical steps based on personal experience, so you can finally start building projects with confidence.

Table of Contents

• Why Tutorials Are Not Enough

• How I Broke Free

• Step 1: Accept That You Know Nothing – Yet

• Step 2: Start Simple

• Step 3: Break Down the Project Into Smaller Parts

• Step 4: Don’t Fear Bugs – They’re Signs of Progress

• Step 5: Show Others Your Work

• Step 6: Build More Similar Projects

• Final Thoughts

Why Tutorials Are Not Enough

Tutorials are a great way to get started. They provide structure, simplify complexity, and offer quick wins that make you feel like you’re making progress. In the early stages, that sense of momentum is crucial.

But tutorials can be deceptive. When you’re following along, you’re not solving problems, you’re just replicating solutions that have been worked out for you. It feels productive, but it’s passive learning. You’re learning how to follow instructions, not how to think through a problem or make decisions on your own – that’s the real trap.

Tutorials teach you how to code, but not how to build. You might learn the syntax, but you’re not learning how to build from scratch, troubleshoot unexpected bugs, or take ownership of a project. Over time, after multiple tutorials, this creates a false sense of mastery. It makes you believe that you’re knowledgeable enough, even though you haven’t tested your skills yet.

I know this because I was stuck there too.

How I Broke Free

Breaking free from tutorial hell was not easy. I had to change my mindset and accept something uncomfortable: I didn’t know as much as I thought I did. That realization stung, but it was freeing. I stopped trying to build big, impressive projects – like a Facebook or Netflix clone – and focused instead on small, achievable ones. Projects that challenged me just enough to learn, but not so much that I would burn out.

I also changed how I approached learning. Instead of trying to absorb everything up front, I started with a goal and only learned what I needed to achieve it. This made my learning process more purposeful and, surprisingly, more enjoyable.

What follows are the exact steps that helped me transition from relying on tutorials to building confidently on my own.

Step 1: Accept That You Know Nothing – Yet

It’s natural to feel confident after completing a few tutorial-based projects. But it’s important to manage your expectations and honestly evaluate your skill level. One pitfall I had was overestimating my ability because of the projects I had built following tutorials.

I had to pause and ask myself an important question: Was the success of those projects dependent on me?

After some reflection, the answer was disappointing but clear – they weren’t. I didn’t possess the knowledge I assumed I had. I was just good at following the carefully laid out instructions from the tutorial.

In hindsight, I realized that building a project is more than just writing code. It involves research, planning, and critical thinking – things tutorials often don’t teach or focus on. Writing code is usually the last thing that’s done. This explains why a common complaint from new developers is, “I know the syntax, but I don’t know what to do when building a project”.

Think of tutorials as training wheels. They help you ride a bicycle (build a project) by providing balance (the tutorial), but they don’t teach you how to maintain that balance on your own. When the training wheels come off – when you try to build independently – you fall off the bicycle because you never learned how to ride one without it.

It’s hard to admit that weeks (or months) of following tutorials have not prepared you as well as you thought. But accepting that truth is the first step toward breaking free from tutorial hell. I had to face this reality, and while it wasn’t easy, that moment of clarity became the turning point in my journey.

Step 2: Start Simple

Choosing a good first project was tricky. The common advice I got was to build a project I liked or that solved a personal problem. While that sounded reasonable, it didn’t work for me as a beginner. After several failed attempts, I realized those ideas required more knowledge than I had, so it led to frustration and self-doubt.

Problem-solving is a vital skill for programmers, but in the early stages, choosing a project based on a personal problem can be counterproductive. The complexity often outweighs your current abilities, creating unnecessary pressure.

As a beginner, your priority should be building confidence. The easiest way to do that is by starting with simple projects. A simple project is one you can do without feeling overwhelmed. For me, that was this project on building a QR code generator.

How did I choose it? I used a simple rule: if I looked at the design or the general idea for a project and had no clue on how to build it, I assumed it was beyond my skill level and looked for something simpler. It was not a quick 2-minute decision – I usually gave myself up to 2 two hours to brainstorm. If I was still stuck after that, it was a sign that the project might be too advanced for me.

Platforms like FrontendMentor and iCodeThis offer free project designs categorized by difficulty. They helped me focus on writing code without worrying about what to build from scratch.

At this stage, my goal was not to build something impressive – it was to build something that worked.

Step 3: Break Down the Project into Smaller Parts

When starting a project, it’s easy to feel overwhelmed by its scope. The key to overcoming that feeling is to break up the project into small, manageable pieces. By starting with the easier tasks, you ease into the process, gain momentum, and build confidence before tackling the harder parts.

For my first project, I divided it into two major sections: the background and the card component. Then I split each section into even smaller parts. Here’s an image of the project:

I started by dividing the card component into clear sections:

• The card background.

• The card size.

• The card contents.

Then I broke the card contents even further:

• The QR image

• The heading text

• The subtext

Next, I turned each of those items into a simple to-do list of actionable tasks:

1. Add a background color to the body element.

2. Create the card component.

3. Give the card a fixed width and height.

4. Center the card component.

5. Add the background color of the card component.

6. Add the QR image.

7. Add the heading text.

8. Add the sub-text.

9. Make the card component responsive.

Here’s how that looked in practice for the first few steps:

Task 1: Add a background color to the body

body {
  background: rgb(220, 220, 220);
}

Task 2: Create the card component

<section class="parent">
  <div class="container">
    <!-- content -->
  </div>
</section>

Task 3: Give the card a fixed width and height

.parent {
  width: 320px;
  height: 500px;
}

Task 4: Center the card component

body {
  display: flex;
  align-items: center;
  justify-content: center;
  height: 100vh;
}

After this, I continued with the same approach for the remaining tasks: adding the card’s background, QR image, heading text, subtext, and finally making the card responsive.

Each small win built my confidence and kept me motivated to move forward. By the end, the entire project felt much less intimidating because I could see steady progress at every step.

Breaking a project into smaller parts is not just about staying organized – it's about making the project feel doable. Focusing on one small task at a time, I moved steadily towards completing the project.

You can see the full source code for this project on my GitHub: View the repo here.

Step 4: Don’t Fear Bugs – They’re Signs of Progress

When I finally started building projects, one of the things I dreaded most was encountering an error. Logical errors were fine by me – they were quiet. No red text in the console to feed my insecurities. But those console errors, written in red, were my nightmare. They made me feel like programming wasn’t for me. Like I should give up and do something else.

It took a while, but eventually I learned to see bugs for what they represented at that stage of my journey: signs of progress. Because if I had a bug, it meant I had written enough code for something to go wrong. That was a big step forward from not knowing where to begin.

When you encounter a bug in your code, start by isolating the problem. Check the error message in your console – it’s usually the best clue on what went wrong. Read it carefully to understand what’s causing the issue. If you’re unsure after reading the error message, copy and search the message online. You will likely find solutions on platforms like Stack Overflow.

Then try out the solutions you find, and once the bug is fixed, take the time to understand both the mistake and the solution. This step is crucial. If you don’t know why the error happened, you are more likely to repeat it.

If there is no error message, you’re likely dealing with a logic bug. Review your code for typos, incorrect variable names, or missed function calls. If everything looks fine, try reverting to the last working version of your project, then reapply your changes one step at a time, testing after each update. This approach helps you pinpoint where the bug was introduced.

If you are still stuck, ask for help. A more experienced developer or a colleague can offer a fresh perspective. If you’re working alone and don’t have anyone to ask, take a break. Go for a walk, or do something completely unrelated. Sometimes, you are just mentally tired, and the solution becomes clear once you return with fresh eyes.

And if nothing works, the project may simply be too complex for your current skill level – and that’s okay. Shift your focus back to something simpler to improve your understanding. You can always return to the project later when you are more experienced.

Step 5: Show Others Your Work

Learning is hard – and learning without feedback is even harder. In this journey, it’s difficult to thrive in isolation. Sometimes, the difference between crossing the finish line and giving up lies in the people around us. That is why it’s essential, especially in the early stages, to join programming communities and consistently share your work online.

When I started, I was building in a bubble for a while, but I always felt I wasn’t making enough progress. Eventually, I joined a few tech communities – Frontend Mentor and Javascript.info on Discord – and that helped me tremendously. I met other developers and even collaborated on a project with two of them. Although the group later dissolved due to circumstances beyond our control, the experience was invaluable.

That project taught me things I couldn’t have learned working alone. I learned how to collaborate with teammates across different time zones, use Git more effectively, resolve merge conflicts, and improve my understanding of the DOM traversal methods.

It’s not an easy step, especially if you are not social media inclined, but it is an important one. These communities are made up of people at different stages of their tech careers. Sharing your struggles and encouraging one another creates a much needed support system. On days when your code doesn’t work and you feel like giving up, these communities will remind you that you are not alone.

Another benefit is access to free code reviews and feedback from more experienced developers. Their insights can accelerate your growth, boost your confidence, and help you approach challenges with a fresh perspective.

Step 6: Build More Similar Projects

Completing your first project is a significant milestone. I remember feeling a strong sense of accomplishment and immediately wanted to take on something more complex. But that decision backfired. The next project I chose, an ecommerce site, was well beyond my current ability. I got stuck halfway, lost momentum, and eventually abandoned it. That experience forced me to reassess how I approached my learning.

I realized that the goal at this stage wasn’t to build something impressive, it was to build consistently. So I returned to simpler projects. I built another card component, landing page, and variations of UI components I had already worked on. These may have seemed repetitive, but each one helped me improve and cement my knowledge. I understood layout better, debugged faster, and wrote cleaner code.

By the time I had built several similar projects, I could feel the difference. I wasn’t just building things, I understood what I was doing and why. The growth gave me the confidence to take on more advanced challenges.

If you’ve just completed your first project, don’t rush to build something complex. Focus on projects that align with your current skill level. Repetition will reinforce what you’ve learned, improve your understanding, and give you the confidence to handle more difficult projects when the time comes.

Final Thoughts

At this point, you have built multiple projects, and your confidence as a developer has grown. That progress deserves acknowledgement. Before jumping into the next big challenge, take time to pause and reflect.

Look back on what you've built. Consider how much you've improved. If there are areas where your approach could have been better, refine them. If not, take a moment to appreciate how far you’ve come. That reflection helps you take stock of what you've learnt and prepares you for what comes next.

When you're ready for your next project, choose it carefully. Choose a project more challenging than your last, but not so complex that it disrupts your momentum. Aim for projects that stretch you just enough to push you forward. Sustainable growth is key.

Breaking free from tutorial hell isn't about quitting tutorials altogether. It's about knowing when to stop relying on them and start thinking for yourself. If you stay consistent and keep building, you will grow into a confident, independent developer.

This beginner-friendly tutorial is designed for junior developers and anyone new to React. You'll learn how to fetch data from an API, then store and display it in your React app. No advanced knowledge required – we'll break everything down step by step, so you can follow along and build confidence as you go.

We'll be using React, Vite, Axios, and Tailwind CSS to build a simple app that retrieves and displays data from a public API. First, we’ll fetch data using the built-in fetch method. Then we’ll refactor it using Axios, a popular library that simplifies HTTP requests.

Prerequisites

To follow along with this article, you should:

• Be familiar with basic React concepts like components and useState

• Know what an API is and that it returns data (usually in JSON)

• Have some experience with JavaScript promises and the .then() method. (If you’ve seen or used .then() before, that’s enough – we'll build on that).

• Be comfortable using map() to render lists from arrays (the data we get from the API)

• Be able to run a React project using tools like Vite or Create React App

Table of Contents

1. What is an API and Why Do We Need it?

2. Types of APIs You’ll Encounter

3. Tools We’ll Use

4. How to Fetch Data with React

   • How to Fetch Data with fetch()

   • Refactor with Axios

5. How to Handle Loading and Error States

   • What is a Loading State?

   • What is an Error State?

6. How to Keep Your API Keys Safe

   • Why it's Important:

7. Fun Public APIs to Practice With

8. Conclusion

What is an API and Why Do We Need it?

An API, or Application Programming Interface, is a way for different systems to communicate. Think of it like a waiter at a restaurant. You tell the waiter what you want from the menu (the request), they take that order to the kitchen (the server), and then bring your food back to the table (the response).

In web development, APIs let your frontend application talk to a backend service. Most of the time, this communication happens through HTTP requests. You make a request to a specific URL (called an endpoint), and you get a response, usually in JSON (JavaScript Object Notation) format. JSON is lightweight, easy to read, and works well with JavaScript.

Here’s a basic GET request example:

GET https://jsonplaceholder.typicode.com/users

This GET request asks the server for a list of users. The response will look something like this:

[
  {
    "id": 1,
    "name": "John Doe",
    "email": "JohnDOe@email.com",
  },
  {
    "id": 2,
    "name": "Jane Doe",
    "email": "JaneDoe@email.com",
  },
   //...more users
]

Your React app can grab this JSON, store it in state, and display it in the browser. That’s the basic API cycle you’ll see again and again in real-world applications:

• Make the request

• Wait for the response

• Parse the JSON

• Use the data in your UI

Understanding APIs and JSON is essential. You’ll use them to fetch user profiles, submit forms, update dashboards, search databases, and so much more.

Types of APIs You’ll Encounter

Not all APIs are the same. Understanding the types of APIs you'll come across will help you know what tools or steps you’ll need to work with them.

1. Public APIs (No Key Required)

These are open-access APIs that anyone can use. They don’t require authentication or an API key. They're great for testing, learning, and building demo apps.

Example:

GET https://jsonplaceholder.typicode.com/users

2. Public APIs (With API Key)

Some APIs are public, but still require an API key. This helps the provider track usage and prevent abuse. You'll usually sign up to get a free key.

Example:

GET https://newsapi.org/v2/top-headlines?country=us&apiKey=YOUR_API_KEY

• https://newsapi.org/v2/top-headlines – the actual API endpoint

• country=us – a query parameter specifying you want “US headlines”

• apiKey=YOUR_API_KEY – this is your personal API key you get after signing up on newsapi.org

To use these APIs, you’ll need to:

• Sign up on the provider’s site

• Store your key (safely) in your app (we will explore that later on)

• Pass it as a query parameter or header

3. Private APIs

These are usually used internally in companies. They often require more advanced forms of authentication, like OAuth tokens or session cookies. You won’t typically use these unless you’re working on the backend or within a team project.

4. Using Bearer Tokens for API Authentication

When working with modern APIs, it's common to encounter APIs that require authentication using a Bearer token instead of a simple API key in the URL. The only difference here is that you pass in an object that contains the Bearer token instead of just the api key variable (for example, The Movie Database (TMDB) API).

This approach is more secure because it keeps the token out of the URL and browser history. It also aligns with token-based authentication standards like OAuth 2.0.

Note: When working with third-party APIs, always check the documentation to see how authentication should be handled. Authentication methods vary – some APIs require passing the key in the URL, others expect it in the headers.

Tools We’ll Use

• React: our JavaScript UI library of choice

• Tailwind CSS: For quick styling

• fetch: Native browser method for making HTTP requests

• Axios: Optional library that makes requests more convenient

Learning how to use these tools and methods will make it easier to adapt to different production methods and environments.

How to Fetch Data with React

Now you need to understand the basic structure and tools you need in order to fetch data with React and store that data to use in your components. To do this properly, you'll need to understand a few core tools and concepts:

• useState hook: Lets you create and manage local state inside your component. You'll use it to hold the data you fetch, and track things like whether you're still loading or if there was an error.

• useEffect hook: Allows you to perform operations that need to run after the component renders, such as fetching data, subscribing to events, or updating the DOM.

• HTTP Requests: These are how you talk to APIs. You can use the browser-native fetch() method or third-party tools like Axios.

A basic data fetching flow looks like this:

• Set up state to hold your data when it arrives

• Use the useEffect() hook to make the API call

• Handle loading and error states

• Store and display the data once it arrives

Now that you’ve got the fundamentals, let’s walk through two ways to fetch data: first using fetch(), then using Axios.

How to Fetch Data with fetch()

The fetch() method is a native browser feature that allows you to send HTTP requests directly from the frontend. It’s useful for making basic API calls without any additional libraries.

To use fetch() in React, you'll typically follow this pattern:

• Use the useEffect() hook to ensure the fetch call only runs once when the component mounts.

• Call fetch('url') to send the HTTP GET request.

• Use .json() to parse the JSON response.

• Store the response in state using useState().

Let’s see an example:

Import the necessary hooks and make the fetch call inside useEffect.js:

import { useEffect, useState } from 'react';

function App() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch('https://jsonplaceholder.typicode.com/users')
      .then(res => res.json())
      .then(data => setUsers(data));
   // res.json() converts the raw response into JSON.
   // setUsers(data) updates the React state with that JSON and stores it in state so you can access it.

  }, []);

  return (
    <div className="p-6 max-w-4xl mx-auto">
      <h1 className="text-2xl font-bold mb-4">User List (using fetch)</h1>
      <ul className="grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 gap-4">
        {users.map(user => (
          <li key={user.id} className="bg-white shadow p-4 rounded-xl">
            <h2 className="text-lg font-semibold">{user.name}</h2>
            <p className="text-sm text-gray-600">{user.email}</p>
            <p className="text-sm text-gray-600">{user.company.name}</p>
          </li>
        ))}
      </ul>
    </div>
//Map through the stored data in the state and display the contents
// in a list and access the properties from the data(user.name)
  );
}

export default App;

Refactor with Axios

Axios is a third-party library that makes HTTP requests easier and more reliable. While fetch() is built into the browser, Axios simplifies several things, like automatic JSON parsing and cleaner error handling.

Why Use Axios Over fetch:

• Axios automatically converts the response to JSON – you don’t need to call .json() manually.

• It has built-in support for request and response interceptors.

• It makes it easier to send headers, handle errors, and work with non-GET requests (POST, DELETE, and so on).

First, install Axios in your project via the terminal:

npm install axios

Import the necessary hooks and Axios and make the API call inside useEffect.

import { useEffect, useState } from 'react';
import axios from 'axios';

function App() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    axios.get('https://jsonplaceholder.typicode.com/users')
      .then(response => setUsers(response.data);
      // response.data contains the parsed JSON from the API.
      // setUsers(data) updates the React state with that JSON and stores it in state so you can access it.
  }, []);

  return (
    <div className="p-6 max-w-4xl mx-auto">
      <h1 className="text-2xl font-bold mb-4">User List (using Axios)
      </h1>
      <ul className="grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 gap-4">
        {users.map(user => (
          <li key={user.id} className="bg-white shadow p-4 rounded-xl">
            <h2 className="text-lg font-semibold">{user.name}</h2>
            <p className="text-sm text-gray-600">{user.email}</p>
            <p className="text-sm text-gray-600">{user.company.name}</p>
          </li>
        ))}
      </ul>
    </div>
//Map through the stored data in the state and display the contents
// in a list and access the properties from the data(user.name)
  );
}

export default App;

How to Handle Loading and Error States

When working with data fetching in React, things don't always go perfectly. Sometimes data takes time to arrive and other times the request fails. Loading and Error states come in handy because they give you feedback and make it both user and developer friendly.

What is a Loading State?

A loading state is used to show that data is being fetched. Without it, users might not know what is happening and think the request did not go through or the app isn't working. You typically use a boolean to track this.

What is an Error State?

An error state tells you something went wrong – maybe the API is down, or the URL was incorrect. Catching and displaying these errors helps you debug faster and gives users clear feedback.

Code Snippet:

Here's how you might add loading and error handling to a basic fetch() request:

const [users, setUsers] = useState([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
  fetch('https://jsonplaceholder.typicode.com/users')
    .then(res => {
      if (!res.ok) throw new Error('Network response was not ok');
      return res.json();
    })
    .then(data => {
      setUsers(data);
      setLoading(false);
    })
    .catch(err => {
      setError(err.message);
      setLoading(false);
    });
}, []);

if (loading) return <p>Loading...</p>;
if (error) return <p>Error: {error}</p>;

This gives you a smoother user experience and makes your app more reliable.

How to Keep Your API Keys Safe

If you're using an API that requires a key, it's critical to keep that key secure. Never hardcode your API keys directly into your React components or push them to public repositories. Instead, store them in a .env file at the root of your project(the same directory as your package.json file). In your .env file do this:

VITE_API_KEY=your_actual_key_here

To access it in your app, use:

const apiKey = import.meta.env.VITE_API_KEY;

You can then use this key in your API requests. Here's how you would include it in the Axios example:

axios.get(`https://api.example.com/data?apikey=${apiKey}`)
  .then(response => {
    setUsers(response.data);
    setLoading(false);
  })
  .catch(error => {
    setError(error.message);
    setLoading(false);
  });

Note: In Vite, all environment variables must start with VITE_ to be accessible in the browser. Make sure to add .env to your .gitignore file so it doesn’t get pushed to GitHub.

Hiding your key helps prevent exposing your it to the public, especially if your project is shared on GitHub or deployed online.

Why this is important:

• Exposed keys can be abused, leading to overages or bans from the API provider

• You could lose access or rack up charges depending on the service

• In secure apps, exposed keys can be a major security vulnerability

Always treat your keys like passwords. If a key does get exposed, revoke it and generate a new one from your API provider’s dashboard.

Fun Public APIs to Practice With

Here are some fun and free APIs you can use to build practice projects.:

1. JSONPlaceholder: Fake data for testing: users, posts, comments, todos. No key required.

2. The Dog API: Get random pictures, breed info, and search by breed. Requires a free API key.

3. The Cat API: Just like the Dog API, but for cats. Great for image-heavy apps. Free API key.

4. PokeAPI: Fetch detailed Pokémon data. Great for cards, search filters, or games. No key required.

5. TMDB API: Get movie data, trending shows, cast details, posters, and more. Requires a free API key from TMDB( You can clone popular streaming sites with this).

6. REST Countries API: Retrieve country names, capitals, regions, flags, and populations. No API key required.

7. Bored API: Get random activity suggestions for when you're bored. No key required.

8. JokeAPI: Fetch jokes by category or type (safe for work, programming, dark humor). No key needed.

9. Rick and Morty API: Explore characters, locations, and episodes. Perfect for fans. No key required.

10. NASA APIs: Explore images, astronomy data, and space facts. Requires free API key from NASA.

Play around with different data formats, add filters or search, and combine multiple APIs into one project. It's great practice for real-world app development.

Conclusion

What you've just built is the foundation of countless real-world applications. The ability to fetch, manage, and display data from APIs is essential in web development.

From here, you can extend this app to:

• Add search or filter functionality

• Paginate the results

• Display details on a separate page

As you continue to grow as a developer, the patterns you practiced here will show up again and again. Mastering them now sets you up for success later.

In this tutorial, we will break down how to build a chat application using modern technologies like Angular and Supabase. Building this chat application will help you learn features such as Google OAuth 2.0 for authentication, Angular router for navigation, the CanActivate route guard for route protection, and how to call Supabase functions to create, fetch and delete chats.

On the backend, you will learn how to create database tables in Supabase. You’ll also learn about Supabase functions and Supabase triggers.

Table of Contents

• Table of Contents

• Prerequisites

• Installations and Account Configuration:

• How to Create the User Interface of the Angular Application

• How to Set Up a New Supabase Project

• How to Set Up Google OAuth 2.0 for Authentication and Authorization

• How to Configure the Router of the Angular Application

• How to Set Up the Authentication Service

  • How to Create the Service Functions for Login and Sign Out Functionality

  • How to Integrate the Authentication Service Function in the Template

• How to Create Route Protection in Angular

• How to Create and Setup the Users Table in Supabase using the SQL Editor

  • How to Configure Row Level Security Policies in Supabase with the SQL Editor

  • How to Configure Supabase Functions in Supabase with the SQL Editor

  • How to Configure Supabase Trigger in Supabase with the SQL Editor

• How to Create and Setup the Chat Table in Supabase using the User Interface

• How to Create and Setup the Chat Table Policies in Supabase

• How to Integrate Functionality to Create a New Chat Message in the Angular Application

• How to Fetch Data in the Angular Application from Supabase

• How to Delete Data in the Angular Application

• How to Implement Logout Functionality in the Angular Application

• Conclusion

Prerequisites

• HTML

• JavaScript

• TypeScript

Installations and Account Configuration:

Before we begin, make sure you have the following installed and ready:

• Node.js and npm: Angular requires Node. You can check to see if you have it (and what version you have) by running node -v in your terminal.

• Angular CLI: This is the command-line tool to scaffold and manage Angular projects. If you don’t have it, install it with npm install -g @angular/cli. Verify with ng version.

• A Supabase account: Supabase offers a free tier. Sign up on the Supabase website if you haven’t already.

You can also watch the video version of this article below, or on my YouTube channel:

How to Create the User Interface of the Angular Application

To create the user interface of the application, we’ll use Bootstrap 5. In the index.html file of the Angular application, you are going to paste the Bootstrap 5 CDN link as seen below:

<!doctype html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <title>NgChat</title>
  <base href="/">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="icon" type="image/x-icon" href="favicon.ico">
  <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css" rel="stylesheet"
    integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC" crossorigin="anonymous">

</head>

<body>
  <app-root></app-root>
  <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.bundle.min.js"
    integrity="sha384-MrcW6ZMFYlzcLA8Nl+NtUVF0sA7MsXsP1UyJoMp4YLEuNSfAP+JcXn/tWtIaxVXM"
    crossorigin="anonymous"></script>

</body>

</html>

Above, you have two CDN links from Bootstrap 5. The first is the <link> tag within the head section, while the second is the <script> tag which is right below the <app-root></app-root> tag.

Now that you have the Bootstrap 5 CDN link setup within the project, the next step is to create two new components called chat and login, respectively, within a pages folder. You can do that using the command below:

ng g c pages/chat-component && ng g c pages/login-component

The login-component.html is going to contain the code below:

<section class="login-block">
  <div class="container">

    <div class="row">
      <div class="col-md-12">
        <a class="btn btn-lg btn-google btn-block text-uppercase btn-outline" href="#"><img
            src="https://res.cloudinary.com/dz4tt9omp/image/upload/v1712537582/google-logo.png"> Signup Using Google</a>
      </div>
    </div>
  </div>
</section>

While the login-component.css will contain the code below:

.login-block {
  width: 300px;
  margin: 0 auto;
  display:flex;
  justify-content:center;
  align-items:center;
  height:100vh;
}

.btn {
  border-radius: 2px;
  text-transform: capitalize;
  font-size: 15px;
  padding: 10px 19px;
  cursor: pointer
}


.btn-google {
  color: #545454;
  background-color: #ffffff;
  box-shadow: 0 1px 2px 1px #ddd;
}

To see how the user interface looks, you can call the <app-login /> tag with the app.component.html file, since the route navigations have not yet been configured. The user interface should look like the screenshot below:

How to Set Up a New Supabase Project

To set up Supabase, you will need to create a new account on Supabase.com by using either a GitHub account, or the traditional email and password. Once you’ve done this, you will be presented with a form to create a new organization as you can see in the image below:

The organization will be created as fast as your internet speed. Once that is done, the next form you’ll see will allow you to create a new Supabase project.

As you can see from the image above, all you need to do to create a new project is to set a database password and select a region close to where you think most of your users will be. This will help reduce latency. With that you can now click on the create button to create a new project.

Once the project creation is complete, you will be navigated to the dashboard below:

With that, you have now set up your new Supabase project.

How to Set Up Google OAuth 2.0 for Authentication and Authorization

To set up Google OAuth 2.0, you need to create an account on Google Cloud Console. Once you create an account, you will be navigated to the dashboard, where you can create a new project by clicking on the select project button on the top left-hand side of the dashboard.

Once you’ve selected the newly created project, you can now begin implementing Google OAuth 2.0 by following these steps:

• Click on the hamburger menu on the left-hand side of the dashboard and hover over APIs and services.

• Click on Credentials, on the Credentials page, select Create Credentials at the top menu of the dashboard. A dropdown menu will appear. Select Create OAuth client ID.

• On the Client ID page, you’ll get a warning message that says “To create an OAuth client ID, you must first configure your consent screen.” Click on the Configure consent screen button.

Next, you’ll be directed to the Branding page. Click on the getting Started button, and you’ll be presented with a form on the overview page as you can see below. Then just fill out the form:

You can now create the OAuth Consent Screen by heading to the Clients tab on the left-side of the dashboard and filling out the details for your application type, the name of your OAuth 2.0 client, as well as the Authorized JavaScript origins.

For the Authorized JavaScript origins, you can enter the URL (http://localhost:4200), since that is the development URL for our Angular application. Then click on the create button. You may get a warning saying “Note: It may take five minutes to a few hours for settings to take effect.”

Once the configuration is complete, you will get a modal that contains a Client ID and a Client Secret, as you can see below:

Make sure you copy the Client ID and Client secret, as you will use this in the Supabase dashboard.

To complete the authentication and authorization setup, head to the Supabase dashboard. Then navigate to the Authentication menu, which is located in the items on the left-side of the dashboard. On this part of the dashboard, you will select Sign In / Providers.

On the Sign In / Providers page, scroll down to the Auth Providers, then select and enable Google. This is where you will paste in the credentials of the Client ID and Client Secret created on the Google Cloud Console. Then click on the save button – and make sure you copy the Callback URL (for OAuth).

The final step in this process is to head back to the GCP dashboard, and under the Clients tab, click on the edit icon of the OAuth 2.0 Client IDs you created previously.

Under the Authorized redirect URIs, click on the Add URI button. An input box will appear. Paste in the link of the Callback URL (for OAuth) you grabbed in the Supabase dashboard and click save.

How to Configure the Router of the Angular Application

Earlier in this tutorial, you created two components: Chat and Login. At this point, you need to setup the route configuration in the app.routes.ts. In this file, add the code below:

import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: 'chat',
    loadComponent: () =>
      import('./pages/chat/chat-component').then((com) => com.ChatComponent),
  },
  {
    path: 'login',
    loadComponent: () =>
      import('./pages/login/login-component').then((com) => com.LoginComponent),
  },
  {
    path: '',
    loadComponent: () =>
      import('./pages/login/login-component').then((com) => com.LoginComponent),
  },
];

Above, you can see the two components now have their separate routes called chat and login, respectively. They can be accessed anywhere in the application.

How to Set Up the Authentication Service

To setup the authentication service in the Angular application, use the following command:

ng g s services/auth-service

Next, you’ll generate the environments folders to setup the environment variables using the below command:

ng g environments

The final configuration you need to do from the terminal before you begin creating the function for the Angular authentication service is to install Supabase with the command below:

npm i @supabase/supabase-js

And with that, you now have Supabase installed in the project and you can begin integrating the functions in the service. Start from the environment.development.ts file. The current structure of this file should look this way by default:

export const environment = {};

To configure this file, you need to head to the Supabase dashboard. Locate and select the settings menu on the left hand panel of the dashboard. Under the Configuration tab, click on Data API.

You can now grab both the Project URL and anon public key (the arrow is pointing to it in the image above). You can now head over to the environment.development.ts file and paste in the values of the copied link following the format below:

export const environment = {
  production: false,
  supabaseUrl: 'https://zktqzszvllbxvjfzkhvk.supabase.co',
  supabaseKey:
    'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InprdHF6c3p2bGxieHZqZnpraHZrIiwicm9sZSI6ImFub24iLCJpYXQiOjE3NDcyNTg3MDgsImV4cCI6MjA2MjgzNDcwOH0.qf3MA-La6se8QijzLFALKc_XdiISmzDk7AZw4-na0uA',
};

With the environment variables all in place, you can now create the functions for the authentication service.

In the auth-service.ts which you created previously, start by importing the Supabase package as well as the environments file as you can see below:

import { Injectable } from '@angular/core';
import { SupabaseClient, createClient } from '@supabase/supabase-js';
import { environment } from '../../environments/environment.development';

Next, complete the injection of the Supabase npm package by injecting it into your constructor:

import { Injectable } from '@angular/core';
import { SupabaseClient, createClient } from '@supabase/supabase-js';
import { environment } from '../../environments/environment.development';

@Injectable({
  providedIn: 'root',
})
export class AuthService {
  supabase!: SupabaseClient;

  constructor() {
      this.supabase = createClient(
      environment.supabaseUrl,
      environment.supabaseKey
    );
  }
}

How to Create the Service Functions for Login and Sign Out Functionality

The final step in setting up the Authservice is to create the functions which will later be called in the template. You are going to create four functions which you can see in the code below:

  private router = inject(Router);
  private _ngZone = inject(NgZone);

  constructor() {
    this.supabase = createClient(
      environment.supabaseUrl,
      environment.supabaseKey
    );

    this.supabase.auth.onAuthStateChange((event, session) => {

      localStorage.setItem('session', JSON.stringify(session?.user));

      if (session?.user) {
        this._ngZone.run(() => {
          this.router.navigate(['/chat']);
        });
      }
    });
  }

  get isLoggedIn(): boolean {
    const user = localStorage.getItem('session') as string;

    return user === 'undefined' ? false : true;
  }

  async signInWithGoogle() {
    await this.supabase.auth.signInWithOAuth({
      provider: 'google',
    });
  }

  async signOut() {
    await this.supabase.auth.signOut();
  }
}

The first function created is within the constructor. This is the onAuthStateChange callback function which is derived from Supabase and allows us to listen to Auth changes. It accepts two parameters called event and session.

Here, two conditions were instantiated within the onAuthStateChange callback function. They say that when the session?.user exists, you proceed to set the value to the local storage, and then navigate the user to the dashboard using the Angular router (which has been imported and injected using the inject() function).

The second function, isLoggedIn(), is a getter function that returns a Boolean. It returns either true or false, depending on if it is able to retrieve the user session from localStorage. This function will be used in the authentication guard which you’ll create later.

The third function, signInWithGoogle(), allows the user log into the dashboard using the signInWithOAuth() method provided by Supabase. This allows the user to log into the dashboard using a Google Gmail account.

The final function, signOut(), allows users to logout of the dashboard by resetting the state of the user session to null.

With all these functions created, the final code base in the auth-service.ts should look like this:

import { Injectable, NgZone, inject } from '@angular/core';
import { SupabaseClient, createClient } from '@supabase/supabase-js';
import { environment } from '../../environments/environment.development';
import { Router } from '@angular/router';

@Injectable({
  providedIn: 'root',
})
export class AuthService {
  private supabase!: SupabaseClient;

  private router = inject(Router);
  private _ngZone = inject(NgZone);
  constructor() {
    this.supabase = createClient(
      environment.supabaseUrl,
      environment.supabaseKey
    );

    this.supabase.auth.onAuthStateChange((event, session) => {
      console.log('event', event);
      console.log('session', session);

      localStorage.setItem('session', JSON.stringify(session?.user));

      if (session?.user) {
        this._ngZone.run(() => {
          this.router.navigate(['/chat']);
        });
      }
    });
  }

  get isLoggedIn(): boolean {
    const user = localStorage.getItem('session') as string;

    return user === 'undefined' ? false : true;
  }

  async signInWithGoogle() {
    await this.supabase.auth.signInWithOAuth({
      provider: 'google',
    });
  }

  async signOut() {
    await this.supabase.auth.signOut();
  }
}

You can now utilize these functions anywhere in the Angular project as a form of state management.

How to Integrate the Authentication Service Function in the Template

The first function we’ll use is the signInWithGoogle() function. We’ll use it in the login-component.ts file to allow users log into the application as you can see below:

import { Component, inject } from '@angular/core';
import { AuthService } from '../../services/auth-service';

@Component({
  selector: 'app-login',
  standalone: true,
  imports: [],
  templateUrl: './login-component.html',
  styleUrl: './login-component.css',
})
export class LoginComponent {
  private auth = inject(AuthService);

  async handleAuth() {
    const response = await this.auth.signInWithGoogle();
  }
}

Above, you implemented three features:

• Importing AuthService into the LoginComponent

• Injecting AuthService using the Inject function into the LoginComponent

• Creating the handleAuth() function that allows you call the signInWithGoogle() from the AuthService file.

Now you can head to the login-component.html file and call the handleAuth() function as below within the <a> tag:

<section class="login-block">
  <div class="container">

    <div class="row">
      <div class="col-md-12">
        <a (click)="handleAuth()" class="btn btn-lg btn-google btn-block text-uppercase btn-outline" href="#"><img
            src="https://res.cloudinary.com/dz4tt9omp/image/upload/v1712537582/google-logo.png"> Signup Using Google</a>
      </div>
    </div>
  </div>
</section>

Before you test the implementation, you will need to set the URL configuration in the Supabase dashboard. The URL configuration allows the URLs that authentication providers permit to redirect and post authentication, including wildcards.

As you can see in the above image, the two Redirect URLs provided are localhost, since we are still currently creating the app in our local machine.

With this, you can test the Google OAuth 2.0 configuration by typing the localhost URL (http://localhost:4200) in the browser, clicking on the Signup Using Google button, and selecting a Gmail account you want to sign up/login with. Then you should get navigated to the Chat component.

How to Create Route Protection in Angular

To create route protection in Angular, you can use an in-built mechanism called a Route Guard. The Route Guard is used to control access to certain parts of the Angular application using certain conditions before a route is activated or accessible to the user.

In our case, you will be generating the Route Guard as a function (which is the default in our current version of Angular (20), instead of as a class) using the command below:

ng generate guard auth-guard

You will then see this prompt that asks “Which type of guard would you like to create?”:

Use the spacebar to select CanActivate, and then press the Enter key to generate the Guard. Two files will be generated: the auth-guard.spec.ts file (for testing), and the auth-guard.ts file. Within the auth-guard.ts file, you will see the boilerplate code below:

import { CanActivateFn } from '@angular/router';

export const authGuard: CanActivateFn = (route, state) => {
  return true;
};

You can start modifying the above template by importing the Angular Router, the AuthService file that you created earlier, as well as the Inject function:

import { CanActivateFn, Router } from '@angular/router';
import { AuthService } from './services/auth-service';
import { inject } from '@angular/core';

Next, use the isLoggedIn getter that you created earlier in the AuthService file (which returns a Boolean) to conditionally activate the Chat dashboard for the user based on their login status using the code below:

import { CanActivateFn, Router } from '@angular/router';
import { AuthService } from './services/auth-service';
import { inject } from '@angular/core';

export const authGuard: CanActivateFn = (route, state) => {
  if (inject(AuthService).isLoggedIn === false) {
    inject(Router).navigate(['/login']);
    return false;
  } else {
    return true;
  }
};

To complete the Guard integration, head over to the app.routes.ts file and import and inject the Authentication Guard as you can see below:

import { Routes } from '@angular/router';
import { authGuard } from './auth-guard';

export const routes: Routes = [
  {
    path: 'chat',
    canActivate: [authGuard],
    loadComponent: () =>
      import('./pages/chat/chat-component').then((com) => com.ChatComponent),
  },
  {
    path: 'login',
    loadComponent: () =>
      import('./pages/login/login-component').then((com) => com.LoginComponent),
  },
  {
    path: '',
    loadComponent: () =>
      import('./pages/login/login-component').then((com) => com.LoginComponent),
  },
];

With this, the route protection implementation is now complete and only authenticated users can view the dashboard.

How to Create and Setup the Users Table in Supabase using the SQL Editor

To create and setup the users table, use the schema below:

• id (uuid)

• full_name (text)

• avatar_url (text)

You can use the SQL Editor in Supabase. The SQL Editor is the third item on the menu panel in the Supabase dashboard. Here you are going to type in the query below in the SQL Editor input field:

CREATE TABLE public.users (
   id uuid not null references auth.users on delete cascade,
   full_name text NULL,
   avatar_url text NULL,
   primary key (id)
);

You can now click on the Run button on the bottom right. You should get a message that says: Success. No rows returned, as you can see in the image below:

Now let’s go ahead and enable row level security, as well as the Supabase function and trigger.

How to Configure Row Level Security Policies in Supabase with the SQL Editor

Row Level Security (RLS) in Supabase allows you to control access to individual rows in your database tables based on custom logic. It’s one of the core features for building secure, multi-user applications with Supabase.

RLS lets you define SQL policies that determine which users can SELECT, INSERT, UPDATE, or DELETE specific rows in a table.

To enable RLS in the users table, type the command below in your SQL Editor:

ALTER TABLE public.users ENABLE ROW LEVEL SECURITY;

For the purpose of this tutorial, you are going to create just two policies, which are:

1. The ability for users to access their own profile

2. The ability for users to update their own profile

The ability for users to access their own profile

To enable users access their own profile, head back to the SQL editor and create a new snippet with the following query:

CREATE POLICY "Permit Users to Access Their Profile"
  ON public.users
  FOR SELECT
  USING ( auth.uid() = id );

With this query, users will be able to access their own profile as long as the authenticated user’s ID matches the id of the column of the row.

The ability for users to update their own profile

To enable users update their own profile, head back to the SQL editor and create a new snippet with the following query:

CREATE POLICY "Permit Users to Update Their Profile"
  ON public.users
  FOR UPDATE
  USING ( auth.uid() = id );

With the above query, users will be able to update their own profile as long as the authenticated user’s ID matches the id of the column of the row.

How to Configure Supabase Functions in Supabase with the SQL Editor

Supabase Functions are serverless functions that can be deployed and run within your Supabase project using Supabase Edge Functions.

In this project, you will create a trigger function that automatically creates a new row in the users table whenever a new user is created in the auth.users table.

CREATE
OR REPLACE FUNCTION public.user_profile() RETURNS TRIGGER AS $$ BEGIN INSERT INTO public.users (id, full_name,avatar_url)
VALUES
  (
    NEW.id,
    NEW.raw_user_meta_data ->> 'full_name'::TEXT,
    NEW.raw_user_meta_data ->> 'avatar_url'::TEXT
  );
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

To summarize the above query:

• You start by defining or replacing a function named user_profile() that will be used as a trigger.

• Next, the trigger inserts a new row into the public.users table, and then extracts the full_name and avatar_url from the user's metadata as text.

• The inserted record is now returned when the trigger function is complete

• Finally, you use the SECURITY DEFINER keyword so that the function can run with the privileges of the user who created it.

How to Configure Supabase Trigger in Supabase with the SQL Editor

A trigger in Supabase is a PostgreSQL feature used to automatically run a function in response to events on a table (SELECT, INSERT, UPDATE, or DELETE). It’s mostly used with Row Level Security or syncing data across tables.

In this project, you will create a Supabase trigger that automatically runs a function after a new user is created in the auth.users table.

 CREATE TRIGGER
  create_user_trigger
  AFTER INSERT ON auth.users
  FOR EACH ROW
  EXECUTE PROCEDURE
    public.user_profile();

To summarize the above query:

• The first line creates a trigger named create_user_trigger.

• Next, the INSERT ON statement is activated when a user signs up and a new row is inserted into the auth.users table

• Then the trigger runs once for every new user added in a new row.

• Finally, the custom function public.user_profile() is called to perform some logic, typically inserting data into the users table.

With the above integration, you can now log into the dashboard with a new google account and view the users table. There you will see the data that contains the id, full_name, and avatar_url as you can see below:

How to Create and Setup the Chat Table in Supabase using the User Interface

To create the chat table, you will use the user interface in Supabase instead of the SQL Editor. To do this, you need to head to the Table Editor menu on the dashboard and click on the New Table button.

Once selected, a modal will popup which contains some input fields such as the table name, description, and columns. You can call the table name chat and omit the description for now since it’s optional. In the columns section, fill out the fields using the schema below:

• id (uuid)

• Created At (date)

• text (text)

• editable (boolean)

• sender (uuid)

You can see the configuration for this in the table below:

Next up, you need to add a foreign key relation for the users table. To do this, you scroll to the bottom of the modal and click on the Add foreign key relation button. This will prompt another modal on top of the current modal. Here you can take the following steps:

• Under the Select a table to reference to label, select the users table.

• Under the public.chat label, select the sender option.

• Under public.users label, select uuid.

• Under the Action if referenced row is updated label, select Cascade.

• Under the Action if referenced row is removed label, select Cascade as well.

If you’ve followed the above steps, you can now click on the save button, which successfully creates the chat table.

How to Create and Setup the Chat Table Policies in Supabase

The final step you need to perform for the chat table is to add a Row Level Security policy. You can do this by clicking the Add RLS policy button at the top of the chat table page.

A new page will appear. Then you can click on the Create policy button, which displays a modal.

The first policy you will create is the DELETE policy, which will have the configuration you can see in the image below:

From the above image, we made these four implementations:

• First, we entered the policy name as “Delete by User ID“.

• Next we selected the DELETE policy command clause.

• Then under the targeted roles, we selected authenticated in the drop down select, to allow only authenticated users to perform delete operations.

• Finally, under the USE OPTIONS ABOVE TO EDIT section, in line 7, we condition the query as (auth.uid() = sender) This allows only logged in users to delete their data.

You can now click on the Save policy button to complete the DELETE setup.

The second policy you will create is the INSERT policy, which will have the configuration you can see in the image below:

From the above image, four implementations were made:

• First, we entered the policy name as “Insert for Authenticated Users“.

• Next we selected the INSERT policy command clause.

• Then under the targeted roles, we selected authenticated in the drop down to allow only authenticated users perform insert operations.

• Finally, under the USE OPTIONS ABOVE TO EDIT section, in line 7, the query was conditioned as ((sender = auth.uid()) AND (created_at = now())). The first condition ensures that the sender field in the inserted row matches the currently logged-in user's ID (from the Supabase JWT), while the second condition ensures that the created_at field is exactly equal to the current timestamp at the time of insertion.

The third policy you will create is the SELECT policy, which will have the configuration you can see in the image below:

From the above image, we implemented four things:

• First, we entered the policy name as “Read Data for Authenticated Users“.

• Next we selected the SELECT policy command clause, pun intended 😊*.*

• Then under the targeted roles, we selected authenticated in the drop down to allow only authenticated users perform select operations.

• Finally, under the USE OPTIONS ABOVE TO EDIT section, in line 7, the query was conditioned as true. This allows all authenticated users to read all rows, or chats in our case.

With the above implementation, you’ve created all the policies needed for the chat application.

How to Integrate Functionality to Create a New Chat Message in the Angular Application

Now let’s add the code that lets users create a new chat message. First, start by creating a new Angular service using the command below:

ng g s services/chat-service

Within the chat-service.ts file, you can now configure the Supabase client, just as we did in the auth-service.ts file as seen below:

import { Injectable, signal } from '@angular/core';
import { SupabaseClient, createClient } from '@supabase/supabase-js';
import { environment } from '../../environments/environment.development';

@Injectable({
  providedIn: 'root',
})
export class ChatService {
  supabase!: SupabaseClient;

  constructor() {
    this.supabase = createClient(
      environment.supabaseUrl,
      environment.supabaseKey
    );
  }
}

Next, create the function that enables you to create a new chat message. The function called chatMessage() is below:

import { Injectable, signal } from '@angular/core';
import { SupabaseClient, createClient } from '@supabase/supabase-js';
import { environment } from '../../environments/environment.development';

@Injectable({
  providedIn: 'root',
})
export class ChatService {
  supabase!: SupabaseClient;

  constructor() {
    this.supabase = createClient(
      environment.supabaseUrl,
      environment.supabaseKey
    );
  }

  async chatMessage(text: string) {
    try {
      const { data, error } = await this.supabase.from('chat').insert({ text });

      if (error) {
        alert(error.message);
      }
    } catch (error) {
      alert(error);
    }
  }
}

The above chatMessage function sends a chat message by inserting it into the chat table in Supabase.

You can now call this service in the chat-component.ts file. Within the chat-component.ts, import and inject the chat-service.ts file.

To send the data to the Supabase database, you need to setup Reactive form. Reactive form in Angular enables you to get data from an input field, which can be passed as a payload and then inserted into the database.

To setup a Reactive form in Angular, follow these steps:

• Import FormBuilder, FormGroup, ReactiveFormsModule, and Validators from @angular/forms

• Insert the ReactiveFormsModule inside of the imports array.

• Inject the FormBuilder as a variable.

• Declare a property that will hold the Reactive Form group.

• Inject the FormBuilder into the ngOnInit lifecycle hook.

The code for the Reactive form setup is below:

import { Component, inject } from '@angular/core';
import { AuthService } from '../../services/auth-service';
import {
  FormBuilder,
  FormGroup,
  ReactiveFormsModule,
  Validators,
} from '@angular/forms';

@Component({
  selector: 'app-chat',
  standalone: true,
  imports: [ReactiveFormsModule],
  templateUrl: './chat-component.html',
  styleUrl: './chat-component.css',
})
export class ChatComponent {
  chatForm!: FormGroup;
  private fb = inject(FormBuilder);

  ngOnInit() {
    this.chatForm = this.fb.group({
      chat_message: ['', Validators.required],
    });
  }
}

To complete the Reactive form setup, bind the FormGroup into the HTML file. Also bind the disabled attribute, which disables the button when the form is invalid, as you can see below:

  <form [formGroup]="chatForm">
          <div class="flex-grow-0 py-3 px-4 border-top">
              <div class="input-group">
                <input formControlName="chat_message" type="text" class="form-control" placeholder="Type your message">
                <button [disabled]="!chatForm.valid" class="btn btn-primary">Send</button>
              </div>
           </div>
    </form>

With the Reactive form setup complete, you can now create the function that calls the service which allows you create a new chat message.

import { Component, inject } from '@angular/core';
import { AuthService } from '../../services/auth-service';
import {
  FormBuilder,
  FormGroup,
  ReactiveFormsModule,
  Validators,
} from '@angular/forms';
import { ChatService } from '../../services/chat-service';

@Component({
  selector: 'app-chat',
  standalone: true,
  imports: [ReactiveFormsModule],
  templateUrl: './chat-component.html',
  styleUrl: './chat-component.css',
})
export class ChatComponent {
  private chat_service = inject(ChatService);
  chatForm!: FormGroup;
  private fb = inject(FormBuilder);

  ngOnInit() {
    this.chatForm = this.fb.group({
      chat_message: ['', Validators.required],
    });
  }

  onSubmit() {
    const formValue = this.chatForm.value.chat_message;
    this.chat_service
      .chatMessage(formValue)
      .then((res) => {
        this.chatForm.reset();
      })
      .catch((err) => {
        alert(err.message);
      });
  }
}

The onSubmit() function in the above code basically does the following tasks:

• Gets the data from the Reactive form input field using the variable called formValue

• Calls the chatMessage() method from the ChatService, passing the data from the input field.

• If successful, it resets the form.

• If there's an error, it shows an alert with the error message.

In the chat-component.html file, use of the (ngSubmit) directive to bind the onSubmit() function to the form:

<form [formGroup]="chatForm" (ngSubmit)="onSubmit()">

You can now test to see if the data we send from the input field saves directly into the chat database table.

NOTE: make sure you delete all current users saved in the users table and authentication page on Supabase before trying this out for best results.

From the above image, you will click on the send button and send the Test data in the input field.

The data should now be successfully saved into the database and the INSERT operation should now be integrated into the Angular application.

How to Fetch Data in the Angular Application from Supabase

To fetch data from the chat table from Supabase, start by creating a service function in the chat-service.ts file, as seen below:

import { Injectable, signal } from '@angular/core';
import { SupabaseClient, createClient } from '@supabase/supabase-js';
import { environment } from '../../environments/environment.development';

@Injectable({
  providedIn: 'root',
})
export class ChatService {
  supabase!: SupabaseClient;

  constructor() {
    this.supabase = createClient(
      environment.supabaseUrl,
      environment.supabaseKey
    );
  }

  async chatMessage(text: string) {
    try {
      const { data, error } = await this.supabase.from('chat').insert({ text });
      if (error) {
        alert(error.message);
      }
    } catch (error) {
      alert(error);
    }
  }

    async listChat() {
    try {
      const { data, error } = await this.supabase
        .from('chat')
        .select('*,users(*)');

      if (error) {
        alert(error.message);
      }

      return data;
    } catch (error) {
      throw error;
    }
  }
}

To summarize the function above called listChat():

• We fetch the chat messages from the chat table using the from clause.

• Then we include the related user info by joining the users table with (select(', users()')).

• An alert message is shown if there's a Supabase error.

• Finally, the fetched data is returned, an error is thrown if something goes wrong.

Before you head to the chat-component.ts file to consume the listChat() service function, you need to create an interface which helps shape the structure of the array of objects returned from Supabase. This gives us type safety and consistency.

To set up the interface, create an interface folder within the app directory. Here you will create a file called chat-response.ts. Then create the structure below:

export interface Ichat {
  created_at: string;
  editable: boolean;
  id: string;
  sender: string;
  text: string;
  users: {
    avatar_url: string;
    id: string;
    full_name: string;
  };
}

Heading back to the chat-component.ts, import both the interface which was named Ichat as well as signal and effect from @angular/core:

import { Component, effect, inject, signal } from '@angular/core';
import { AuthService } from '../../services/auth-service';
import {
  FormBuilder,
  FormGroup,
  ReactiveFormsModule,
  Validators,
} from '@angular/forms';
import { ChatService } from '../../services/chat-service';
import { Ichat } from '../../interface/chat-response';

Next, create a variable called chats, which will hold the response from the Supabase client as a signal:

  chats = signal<Ichat[]>([]);

With this, you can now create the function that fetches the chat array of objects from the Supabase dashboard:

  onListChat() {
    this.chat_service
      .listChat()
      .then((res: Ichat[] | null) => {
        console.log(res);
        if (res !== null) {
          this.chats.set(res);
        } else {
          console.log('No messages Found');
        }
      })
      .catch((err) => {
        alert(err.message);
      });
  }

To summarize the function above, we started by:

• Calling the listChat() function from the ChatService to fetch the chat messages.

• If messages are returned, it updates the chats signal with the result, by using the set() method derived from signals.

• In the event where no messages are returned, it logs "No messages Found" to the console.

• If an error occurs, it shows an alert with the error message.

We then call the onListChat() function within the constructor using the effect() function, which helps handle asynchronous operations.

constructor() {
    effect(() => {
      this.onListChat();
    });
  }

When the application is saved, you can see the data in the console from the image below:

You can now display the chat data in the HTML file of the page by getting rid of the placeholder text.

To do this, you can use the @for control flow in Angular as seen below:

<main>
  <div class="container">
    <h3 class="mb-3">Supa Chat <button class="btn btn-secondary" style="float: right;">Log
        out</button>
    </h3>
    <div class="card">
      <div>

        <div class="col-12 col-lg-12 col-xl-12">
          @for (msg of this.chats(); track msg) {
          <div class="position-relative">
            <div class="chat-messages p-4">
              <div class="chat-message-left pb-4">
                <div class="me-5">
                  <img src={{msg?.users?.avatar_url}} class="rounded-circle mr-1" alt="image" width="40" height="40">
                  <div class="text-muted small text-nowrap mt-2">{{msg?.created_at | date: 'M/d/yy, h:mm a'}}</div>
                </div>
                <div class="flex-shrink-1 bg-light rounded py-2 px-3 ml-3">
                  <div class="font-weight-bold mb-1">{{msg?.users?.full_name}}</div>
                  {{msg?.text}}
                </div>
              </div>
            </div>
          </div>
          } @empty {
          <div>No chats available</div>
          }

          <form [formGroup]="chatForm" (ngSubmit)="onSubmit()">
            <div class="flex-grow-0 py-3 px-4 border-top">
              <div class="input-group">
                <input formControlName="chat_message" type="text" class="form-control" placeholder="Type your message">
                <button [disabled]="!chatForm.valid" class="btn btn-primary">Send</button>
              </div>
            </div>
          </form>
        </div>
      </div>
    </div>
  </div>
</main>

From the code above, right above the div with the position-relative class, we declared the @for (msg of this.chats(); track msg) control flow, which does the following:

• Loops through the array returned by this.chats() which is the signal variable that was declared in the template.

• Assigns each item in the array to the msg variable.

• Tracks each item by identity track msg for DOM updates.

Next, within the loop, you called the data in the appropriate HTML tag to display the image, the date the chat was created, the full name, and the chat message as well.

Finally, you created an @empty block which displays the message No chats available if there are no items in the array.

You should have the outcome below:

How to Delete Data in the Angular Application

When creating the delete functionality, first you need to create a service function in the chat-service.ts file as seen below:

  async deleteChat(id: string) {
    const data = await this.supabase.from('chat').delete().eq('id', id);
    return data;
  }

All the above function does is find the specific id provided from the parameter, and return the result of the delete operation.

Next, track the selected chat that was clicked from the array of listed chats and then pass the data down to your service.

To do this, first create a function within the service called selectedChats() which helps receive the data from the template:

 public savedChat = signal({});

 selectedChats(msg: Ichat) {
    this.savedChat.set(msg);
  }

Above, we created the variable called savedChat. It’s declared as a signal that helps receive the object of the chat that we want to delete using the set() method.

You can now head to the chat-component.ts file to create the function that passed the data down to the selectedChats() function.

You can see this function below:

 openDropDown(msg: Ichat) {
    console.log(msg);
    this.chat_service.selectedChats(msg);
  }

As you can see from the function above, once you bind it to the HTML element, it will make sure that you get the object of the specific chat that was clicked.

In our chat-component.html file, create a menu drop down that will help achieve this result as seen below:

<main>
  <div class="container">
    <h3 class="mb-3">Supa Chat <button class="btn btn-secondary" style="float: right;">Log
        out</button>
    </h3>
    <div class="card">
      <div>

        <div class="col-12 col-lg-12 col-xl-12">
          @for (msg of this.chats(); track msg) {
          <div class="position-relative">
            <div class="chat-messages p-4">
              <div class="chat-message-left pb-4">
                <div class="me-5">
                  <img src={{msg?.users?.avatar_url}} class="rounded-circle mr-1" alt="image" width="40" height="40">
                  <div class="text-muted small text-nowrap mt-2">{{msg?.created_at | date: 'M/d/yy, h:mm a'}}</div>
                </div>
                <div class="flex-shrink-1 bg-light rounded py-2 px-3 ml-3">
                  <div class="font-weight-bold mb-1">{{msg?.users?.full_name}}</div>
                  {{msg?.text}}
                </div>

                <!-- Delete Modal Button Menu-->
                <div class="dropdown">
                  <span (click)="openDropDown(msg)" class="mt-3 ms-5" type="button" id="dropdownMenuButton1"
                    data-bs-toggle="dropdown" aria-expanded="false">
                    ...
                  </span>
                  <ul class="dropdown-menu" aria-labelledby="dropdownMenuButton1">
                    <li>
                      <a class="dropdown-item" href="#" data-bs-toggle="modal" data-bs-target="#exampleModal">Delete</a>
                    </li>
                  </ul>
                </div>


              </div>
            </div>
          </div>
          } @empty {
          <div>No chats available</div>
          }

          <form [formGroup]="chatForm" (ngSubmit)="onSubmit()">
            <div class="flex-grow-0 py-3 px-4 border-top">
              <div class="input-group">
                <input formControlName="chat_message" type="text" class="form-control" placeholder="Type your message">
                <button [disabled]="!chatForm.valid" class="btn btn-primary">Send</button>
              </div>
            </div>
          </form>
        </div>
      </div>
    </div>
  </div>
</main>

From the above code, take note of the following: the comment with the text <!-- Delete Modal Button Menu--> is created within the @for control flow. This is essential because it allows the openDropDown(msg) to receive the right object as a parameter when the drop down menu is clicked. A quick look at the console will reveal this.

You can now create the delete modal component, which allows you to consume the delete service required for a chat to be deleted.

To create the delete component, use the command below:

ng g component layout/modal-component

The design for the delete component is a Bootstrap 5 modal that looks like this:

<!-- Modal -->
<div class="modal fade" id="exampleModal" tabindex="-1" aria-labelledby="exampleModalLabel" aria-hidden="true">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title" id="exampleModalLabel">Modal title</h5>
        <button type="button" class="btn-close" data-bs-dismiss="modal" aria-label="Close"></button>
      </div>
      <div class="modal-body">
        Are really sure you want to delete this message?
      </div>
      <div class="modal-footer">
        <button type="button" class="btn btn-secondary" data-bs-dismiss="modal">No</button>
        <button [attr.data-bs-dismiss]="!this.dismiss() === true ? 'modal' : null" (click)="deleteChat()" type="button"
          class="btn btn-primary">Yes</button>
      </div>
    </div>
  </div>
</div>

If you paste the above code directly in your code editor, you’re going to get a host of errors because we have not created the deleteChat() function as well as the dismiss() signal variable in the template file. Let’s go ahead and do that.

The first step in setting up the modal-componet.ts file component is to import the appropriate modules as seen below:

import { Component, effect, inject, signal } from '@angular/core';
import { ChatService } from '../../services/chat.service';
import { Router } from '@angular/router';

Next, inject the chatservice, Angular router, as well as the the dismiss variable which is a signal as seen below:

  private chat_service = inject(ChatService);
  private router = inject(Router);
  dismiss = signal(false);

With this you can now create the deleteChat() function as seen below:

deleteChat() {
    const id = (this.chat_service.savedChat() as { id: string }).id;

    console.log(id);

    this.chat_service
      .deleteChat(id)
      .then(() => {
        let currentUrl = this.router.url;

        this.dismiss.set(true);

        this.router
          .navigateByUrl('/', { skipLocationChange: true })
          .then(() => {
            this.router.navigate([currentUrl]);
          });
      })
      .catch((err) => {
        console.log(err);
        alert(err.message);
      });
  }

• The first thing we did under the deleteChat() method was to extract the id from the chat service.

• This id is then passed into the deleteChat() method from our service which helps delete the specific chat that was selected.

• Once the chat has been deleted, the current route gets reloaded to update the UI.

To activate the modal, you need to import the Modal Component in the chat-component.html file (last line of code below:

<main>
  <div class="container">
    <h3 class="mb-3">Supa Chat <button class="btn btn-secondary" style="float: right;">Log
        out</button>
    </h3>
    <div class="card">
      <div>

        <div class="col-12 col-lg-12 col-xl-12">
          @for (msg of this.chats(); track msg) {
          <div class="position-relative">
            <div class="chat-messages p-4">
              <div class="chat-message-left pb-4">
                <div class="me-5">
                  <img src={{msg?.users?.avatar_url}} class="rounded-circle mr-1" alt="image" width="40" height="40">
                  <div class="text-muted small text-nowrap mt-2">{{msg?.created_at | date: 'M/d/yy, h:mm a'}}</div>
                </div>
                <div class="flex-shrink-1 bg-light rounded py-2 px-3 ml-3">
                  <div class="font-weight-bold mb-1">{{msg?.users?.full_name}}</div>
                  {{msg?.text}}
                </div>

                <!-- Delete Modal Button Menu-->
                <div class="dropdown">
                  <span (click)="openDropDown(msg)" class="mt-3 ms-5" type="button" id="dropdownMenuButton1"
                    data-bs-toggle="dropdown" aria-expanded="false">
                    ...
                  </span>
                  <ul class="dropdown-menu" aria-labelledby="dropdownMenuButton1">
                    <li>
                      <a class="dropdown-item" href="#" data-bs-toggle="modal" data-bs-target="#exampleModal">Delete</a>
                    </li>
                  </ul>
                </div>


              </div>
            </div>
          </div>
          } @empty {
          <div>No chats available</div>
          }

          <form [formGroup]="chatForm" (ngSubmit)="onSubmit()">
            <div class="flex-grow-0 py-3 px-4 border-top">
              <div class="input-group">
                <input formControlName="chat_message" type="text" class="form-control" placeholder="Type your message">
                <button [disabled]="!chatForm.valid" class="btn btn-primary">Send</button>
              </div>
            </div>
          </form>
        </div>
      </div>
    </div>
  </div>
</main>

<!-- modal -->

<app-modal />

NOTE: Don’t forget to import the ModalComponent file in the chat-component.ts file to avoid having any errors.

You have now implemented the ability to Insert, read, and delete data. The final implementation is to integrate the logout functionality.

How to Implement Logout Functionality in the Angular Application

Earlier in the tutorial, within the auth-service.ts file, you created a function called signOut() as seen below:

 async signOut() {
    await this.supabase.auth.signOut();
  }

In the chat-component.ts file, you will import and inject the sigOut() method. To do this, follow these steps:

• Import and inject the Angular router.

• Import and inject the Authentication Service file

• Create the logOut() function that consumes the signOut() service:

async logOut() { 
this.auth .signOut() .then(() =>
 { this.router.navigate(['/login']); }) 
.catch((err) => {
 alert(err.message);
 });
 }

• Finally in the chat-component.html file, within the button tag at the top of the page, call the logout() function using the (click) event handler:

  <h3 class="mb-3">Supa Chat 
    <button (click)="logOut()" class="btn btn-secondary" style="float: right;">Log Out</button>
  </h3>

Once the Log Out button is clicked, the user gets navigated to the Login page and the user state gets reset in the browser.

Conclusion

In this tutorial, you learned how to build a real-time chat application using Angular and Supabase. We covered the following key concepts:

• How to create database tables in Supabase

• How to create triggers and functions in Supabase

• How to use signals to manage state in an Angular

• How to create authentication and authorization using Supabase and Google OAuth 2.0

• How to work with Reactive forms in Angular

and lots more.

You can access the full codebase by cloning the repository on GitHub.

If you found this article helpful, consider subscribing to my YouTube channel where I share hands-on tutorials on modern web development technologies like JavaScript, HTML, CSS, Angular, Supabase, Firebase, React, Third party API and AI tools, and many more. Cheers!

As projects grew in complexity and teams worked in parallel across different stacks, it became clear that monolithic approaches couldn’t keep up. I needed practical tools that allowed easy cross-app interaction, independent deployability, better team autonomy, framework-agnosticism, and more. Some solutions worked elegantly in theory but struggled in real-world conditions. Others made things messier and more painful than helpful.

After diving deep into different paradigms—from iframes to Web Components, single-spa, Module Federation, Piral, Luigi, and hybrid setups—I even distilled my proven experience into a full-fledged online course on Udemy.

And today, in this comprehensive hands-on tutorial, I want to share my expertise and tell you more about micro-frontend architecture—method by method—with code, tradeoffs, visuals, and real-world insights.

Table of Contents

• What are Micro Frontends For?

• Method #1: Iframes & Cross-Window Messaging

• Method #2: Web Components (Custom Elements + Shadow DOM)

• Method #3: Single-SPA — The Meta-Framework Approach

• Method #4: Module Federation - Sharing Code at Runtime

• Other Tools & Ecosystem Additions

• Final Thoughts

What are Micro Frontends For?

In traditional frontend development, we often build single, monolithic apps—one codebase, one repo, one deployment pipeline, one team. It works great for small to medium projects, sometimes even for larger ones.

But challenges arise when:

• Your frontend codebase expands beyond 50+ components.

• Multiple development teams need autonomy over different parts and tech stacks.

• Different sections require varying deployment frequencies (weekly or monthly).

• You need to integrate diverse frameworks, like combining React features with an Angular-based CMS.

This is where micro frontends step in.

Micro frontends extend the principles of microservices to the frontend world. Instead of one big frontend app, you build independent frontend modules, each owned by a team, using its own tech stack, deployed separately, and integrated at runtime.

Think of it like Lego blocks:

• Each block is similar to a self-contained micro frontend.

• They plug into a shared layout or shell.

• Each can evolve, update, or be replaced without affecting the others.

For example, imagine that you’re building a modern e-commerce site, and here’s what your business side expects from you:

Each team wants autonomy, and with micro frontends, each of these sections becomes a separate app, loaded dynamically into a shell at runtime.

Why It’s Getting Popular?

Here are a few things everyone considers:

1. Independent deployments – A little or no effort to coordinate every release.

2. Team autonomy – Teams choose their own stack and tools on the project.

3. Incremental upgrades – Migrate legacy apps piece by piece incrementally without the need to rewrite the whole app at once.

4. Technical agnosticism – Vue, React, Angular? Doesn’t matter. They can all work together seamlessly at the same time in a single app.

5. Better scalability – Parallelize work across teams to enable efficiency of delivery and scale at ease.

Now let’s discover how we can bring this idea to life in our projects.

Nowadays, there are different ways to achieve that, but not all solutions are equal. The implementation method you choose will drastically affect:

• Developer experience

• Bundle sizes and performance

• SEO and accessibility

• Runtime stability

• Interoperability across stacks

So let’s begin by exploring the oldest, but still surprisingly viable method.

Method #1: Iframes & Cross-Window Messaging

You may ask, “Aren’t iframes bad?” They’re often misunderstood. While yes, iframes can feel clunky and isolated, they’re also the most secure and decoupled way to host micro frontends—especially when you don’t trust the team on the other side.

What Is an IFRAME?

An iframe (inline frame) is an HTML element that allows you to embed another HTML page within your current webpage. The whole communication between apps is strictly based on events and delivered by means of the Post Message API.

If you need to send data to another app, you simply call the postMessage() method on that element. On the other side, to receive a message, you just have to subscribe to the message event. That’s it.

Real-World Example

Let’s see a simple example of two apps communicating with each other using iframes on two apps:

• The Main Web App

• A Search App.

Every iframe must be hosted somewhere to serve static content from it. It can be AWS Amplify, Digital Ocean, Heroku, GitHub Pages, or alike.

To help you out here, here’s an official GitHub guideline explaining how to host a website on their platform.

Let’s say you deployed a Search App on Github Pages and you were given this URL to host your app: https://example.github.io. Now let’s write some content for it.

Assuming that you want to post messages from the Search App to the Main Web App, and to subscribe to the incoming messages from it there. You can do it in this way:

console.log('Initializing Search App...');

// Subscribe to messages from outside the iframe (like Main Web App)
window.addEventListener('message', (event) => {
  if (event.data?.type === 'init') {
    console.log('Main Web App passed userId:', event.data.userId);
  }
});

// Simulate sending Search results back to Main Web App
window.parent.postMessage({
  type: 'searchResult',
  payload: ['Item A', 'Item B']
}, '*');

Here, you initialize the search app and set up two-way communication with a parent application (such as a main web app) using the Post Message API. You listen for incoming messages using the built-in message event. Once received, that message becomes available in the event.data object. Finally, you simulate sending data back to the parent by posting a searchResult message containing a list of items. This setup enables isolated iframe-based apps to communicate safely with the main shell application.

Then, in the DOM of the main web app, you need to include the iframe that will render the search app, specifying the URL to the hosted search app in this way:

<iframe
  id="search-mfe"
  src="https://example.github.io"
  style="width: 100%; height: 200px; border: none;"
></iframe>

Styles were added here to ensure that the iframe displays seamlessly within the layout for a cleaner UI integration.

And now you can pass some content from the main web app down to the search app and get some messages from it. You can accomplish it in the main web app’s JavaScript code in this way:

console.log('Initializing Main Web App...');

const iframe = document.getElementById('search-mfe');
iframe.onload = () => {
  // Send message to child iframe (inputs)
  iframe.contentWindow.postMessage({ type: 'init', userId: 42 }, '*');
};

window.addEventListener('message', (event) => {
  // Receive data from the Search App (outputs)
  if (event.data?.type === 'searchResult') {
    console.log('Received result from Search App: ', event.data.payload);
  }
});

As you see, when the iframe loads, the init event is sent to the search app (the type can be anything you want, just ensure it matches the one that another app expects from you). And then, in the message event handler as before, you can receive the incoming messages from the search app, and do something with them.

Here are a few pros and cons to consider, along with popular use cases:

✅ Pros:

• Strong sandboxing: No shared memory, no shared styles.

• Zero dependency clashes: One iframe is equivalent to one environment.

• Perfect for legacy: Easy to wrap old apps in an iframe.

• Practical for micro-apps in PHP, Java, Razor (ASP.NET)

❌ Cons:

• Slow rendering

• Difficult shared navigation

• Inconsistent/complicated styling

• Complex communication

• Must be hosted somewhere

👨🏻‍💻 Popular Use Cases

• Embedding legacy dashboards (for example, old AngularJS or Java apps)

• Secure cross-domain apps (for example, payments, 3rd party analytics)

• Highly untrusted integrations

• Embedded Ads

But if you want a more fluid UX, shared components, and a smoother dev experience, you’ll want something better. That brings us to Web Components.

Method #2: Web Components (Custom Elements + Shadow DOM)

“What if you could ship a self-contained natively understood widget that works in any framework — React, Vue, Angular, or plain HTML?”

That’s exactly what Web Components make possible. They’re natively built into the browser as an API, you don’t need a framework or extra dependency. They allow you to create reusable, scalable, encapsulated UI elements that work just like native HTML tags.

Moreover, you can easily use them as wrappers around any elements from other UI frameworks (React, Angular, Svelte, etc) and use your framework-based components as regular native DOM elements in any web application.

They are, in many ways, the ideal foundation for micro frontends.

A web component is made of:

• Custom Element - defines your own HTML tag (<user-profile>) and behavior

• Shadow DOM – provides scoped, encapsulated styles and DOM structure

• HTML Template – brings reusable HTML blocks/fragments

• Slots – acts as placeholder areas for host content (used in content projection)

In web components, you have to sync the data (input/output) via:

• Attributes (inputs):

  • In Javascript: element.setAttribute(), element.getAttribute(), and so on.

  • In HTML: <element attr1=”value1” attr2=”value2”></element>

• Properties (inputs) – element.someProp = value (only Javascript)

• Custom Events (outputs) - new CustomEvent('name', data)

First, let me show you a basic implementation of a web component, and then you’ll learn how to leverage it for micro-frontends.

Assuming that you’re building a reusable product-tile component that must:

• Accept one input parameter – “title”

• Send an output event "add-to-cart" with this “title” to the outside world, when the component is mounted to the DOM.

Here’s how this web component could look:

// product-tile.js
class ProductTile extends HTMLElement {
  // Specify which attributes (inputs) to observe for changes
  static get observedAttributes() { return ['title']; }

  constructor() {
      super(); // Call base HTMLElement constructor (obligatory)
      // Create a Shadow DOM for style and DOM encapsulation
      const shadow = this.attachShadow({ mode: 'open' });
      // Populate Shadow DOM with a DIV container where React will render the player
      shadow.innerHTML = `<div id="title"></div>`;
  }

  // Built-in Lifecycle Reaction.
  // Called when the custom element ProductTile is added to the DOM
  connectedCallback() {
      // When added to the DOM, read and render the title attribute
      const title = this.getAttribute('title') ?? 'Unnamed Product';
      this.updateTitle(title);

      // Dispatch a custom event with the current title
      const event = new CustomEvent('add-to-cart', {
          detail: { title },
          bubbles: true,
          composed: true,
      });

      this.dispatchEvent(event);
  }

  // Built-in Lifecycle Reaction.
  // Called whenever observed attributes change.
  // In our case it's "title" only
  attributeChangedCallback(name, oldValue, newValue) {
      if (name === 'title' && oldValue !== newValue) {
          this.updateTitle(newValue);
      }
  }

  // Internal method to safely update the title content
  updateTitle(title) {
      const titleElem = this.shadowRoot.querySelector('#title');
      titleElem.textContent = title;
  }
}

customElements.define('product-tile', ProductTile);

Now, let me explain what’s happening here:

• First, you create a custom element class that extends from HTMLElement or its children. This gives you access to web component lifecycle hooks and DOM integration capabilities.

• If you want to react to changes in input parameters (attributes), you have to define a static observedAttributes() getter that returns a list of attribute names to watch. In our case, we observe “title”.

• Then, in the constructor:

  • Call super() to properly inherit from HTMLElement.

  • Create a shadow DOM using attachShadow({ mode: 'open' }). This encapsulates your component’s internal DOM and styles. You can even use a closed mode here to add a higher level of isolation to the shadow DOM.

  • Then, populate the shadow DOM with minimal inner HTML—in this case, a <div> element that will later display the product title.

• When the component is added to the DOM, the built-in connectedCallback() lifecycle reaction runs:

  • It reads the current value of the "title" attribute.

  • Updates the UI with an initial value in the "title" attribute.

  • Then it dispatches a custom event named "add-to-cart", passing the "title" as detail down to it. The events are bubbles: true and composed: true, so that parent elements or host apps outside the shadow DOM can subscribe to it and catch it.

• When the title attribute changes at runtime, another built-in lifecycle reaction named attributeChangedCallback() runs automatically:

  • It checks the new value and updates the "title" display accordingly.

  • This enables reactive behavior in the component—similar to input bindings in UI frameworks.

• Finally, you register the component globally using customElements.define() method (it’s available in the global window object), giving it:

  • A tag name of <product-tile> that can be used anywhere in HTML.

  • A reference to the custom element you previously created to associate one with another.

Ultimately, here’s how you can use this component in your apps, which will work in vanilla JS, React, Angular, Svelte, Vue, whatever UI framework you choose:

<product-tile title="Coffee Mug"></product-tile>

And then you can listen to the "add-to-cart" event from inside ProductTile component like so:

const elem = document.querySelector('product-tile');
elem.addEventListener('add-to-cart', e => {
  console.log('Add to cart!', e.detail);
});

As you see, no ReactDOM.render, no NgModule, no extra glue. Everything is entirely native, pure JavaScript code that browsers understand.

And now, due to the Shadow DOM and other Web Components’ features, you can easily wrap and embed any web app written in a different framework into the Shadow Tree that will isolate your app entirely and won’t allow its layout or styles to leak out.

Alternatively, if you decide to publish it as a separate npm package (for example, @webcomp/product-tile), you can even dynamically import and mount the Web Component like so:

import('@webcomp/product-tile').then(() => {
  // Now <product-tile> is defined — you can create and use it
  const elem = document.createElement('product-tile');
  elem.setAttribute('title', 'Wireless Mouse');
  document.body.appendChild(elem);
});

Or load from CDN or any hosting provider:

<script type="module" src="https://example.github.io/product-tile.js"></script>

It’s simple, clean, and independent.

But you’re not here just for that, right? :) Now, let’s learn the real power of Web Components in a micro-frontends world!

Micro-Frontends with Web Components

Imagine that you’ve built a Video Player in React—or perhaps want to reuse one from another team. Now the question is: How can you make this React-based player usable in any other frontend application, regardless of its underlying framework, using Web Components?

Let’s figure it out!

Let’s say, this video player:

• Accepts src and controls as inputs

• Emits events: play and pause as outputs

• Can be used in any app via <magic-player> in this way:

    <magic-player
      src="https://cdn.example.com/video.mp4"
      controls="true"
    ></magic-player>
  

Now let’s get to implementation!

🔹 Step #1: Include your React player in the project

Here, you can play around with any React component of your choice, to be honest, or you can just use a simple React Video Player like the one below:

// ReactVideoPlayer.jsx

import React from 'react';

export function ReactVideoPlayer({ src, controls, onPlay, onPause }) {
  return (
      // HTML5 video element with full width and controls enabled
    <video
      width="100%"
      controls={controls}  {/* Enable / Disable controls */}
      onPlay={onPlay}      {/* Callback for play event */}
      onPause={onPause}    {/* Callback for pause event */}
    >
      <source src={src} type="video/mp4" />
      Your browser does not support the video tag.
    </video>
  );
}

🔹 Step #2: Create the Web Component Wrapper

Now, you need to create a Web Component wrapper around this React player app by mounting it into the shadow DOM of a custom element in this way:

// magic-player.element.js

// Define a new custom element class
class MagicPlayerElement extends HTMLElement {
  constructor() {
    super(); // Call base HTMLElement constructor (obligatory)

    // Create a Shadow DOM for style and DOM encapsulation
    const shadowRoot = this.attachShadow({ mode: 'open' });
    // Populate Shadow DOM with a DIV container where React will render the player
    shadowRoot.innerHTML = `
        <div id="react-video-player"></div>
    `;
  }
}

customElements.define('magic-player', MagicPlayerElement);

Then you need to add inputs and outputs like so:

// magic-player.element.js

// Define a new custom element class
class MagicPlayerElement extends HTMLElement {
  // Specify which attributes (inputs) to observe for changes
  static get observedAttributes() { return ['src', 'controls']; }

  constructor() {
    super(); // Call base HTMLElement constructor (obligatory)

    // Create a Shadow DOM for style and DOM encapsulation
    const shadowRoot = this.attachShadow({ mode: 'open' });
    // Populate Shadow DOM with a DIV container where React will render the player
    shadowRoot.innerHTML = `
        <div id="react-video-player"></div>
    `;
  }

  // Helper-like method to dispatch native-like events (our outputs)
  // In our case, it will be triggered for "onPlay" and "onPause" events
  dispatch(eventName, detail = {}) {
      const event = new CustomEvent(eventName, {
      detail,            // Pass custom data ("onPlay" or "onPause")
      bubbles: true,     // Allow event to bubble up
      composed: true     // Allow it to cross the Shadow DOM boundary
    });
    this.dispatchEvent(event);
  }
}

customElements.define('magic-player', MagicPlayerElement);

And lastly, add two built-in lifecycle reactions to render a React video player app when the page loads and every time the inputs change:

// magic-player.element.jsx

// Define a new custom element class
class MagicPlayerElement extends HTMLElement {
  // Specify which attributes (inputs) to observe for changes
  static get observedAttributes() { return ['src', 'controls']; }

  constructor() {
    super(); // Call base HTMLElement constructor (obligatory)

    // Create a Shadow DOM for style and DOM encapsulation
    const shadow = this.attachShadow({ mode: 'open' });
    // Populate Shadow DOM with a DIV container where React will render the player
    shadow.innerHTML = `
        <div id="react-video-player"></div>
    `;
  }

  // Helper-like method to dispatch native-like events (our outputs)
  // In our case, it will be triggered for "onPlay" and "onPause" events
  dispatch(eventName, detail = {}) {
      const event = new CustomEvent(eventName, {
      detail,            // Pass custom data ("onPlay" or "onPause")
      bubbles: true,     // Allow event to bubble up
      composed: true     // Allow it to cross the Shadow DOM boundary
    });
    this.dispatchEvent(event);
  }

  // Built-in Lifecycle Reaction.
  // Called when the custom element <magic-player> is added to the DOM
  connectedCallback() {
    this.render();
  }

  // Built-in Lifecycle Reaction.
  // Called whenever observed attributes change.
  // In our case it's "src" and "controls"
  attributeChangedCallback() {
    this.render();
  }

  // Render the React player inside the container
  render() {
    const src = this.getAttribute('src');
    const controls = this.getAttribute('controls') === 'true';
    const mount = this.shadowRoot.querySelector('#react-video-player');

    ReactDOM.createRoot(mount).render(
      <ReactVideoPlayer
        src={src}
        controls={controls}
        onPlay={() => this.dispatch('play')}
        onPause={() => this.dispatch('pause')}
      />
    );
  }
}

customElements.define('magic-player', MagicPlayerElement);

🔹 Step #3: Connect your React-Player to any UI framework:

Then, in the main web app (whatever UI framework you’re using there). We put our newly created React video player wrapper in any place in the DOM, passing down initial attributes (inputs) to it:

<!-- Use your new React-based player anywhere! -->
<magic-player
  src="https://cdn.example.com/movie.mp4"
  controls="true"
></magic-player>

And then you can easily subscribe to the custom events (outputs) from inside the React app:

// Listen to native-style events from the custom element
const magicPlayer = document.querySelector('magic-player');
magicPlayer.addEventListener('play', () => {
  console.log('Video has started playing!');
});

magicPlayer.addEventListener('pause', () => {
  console.log('Video has been paused.');
});

That’s it! Now, try to accomplish the same with a different UI framework!

✅ Pros

• Framework-agnostic: Works in React, Angular, Vue, Svelte, or even plain HTML — no rewrites needed

• Natively supported by browsers: No need for external libraries or frameworks — just HTML, JS, and CSS.

• No extra configuration or hosting needed as in iframes. But still, components can be published to npm/CDNs and reused across multiple apps.

• Intuitive & easy communication: Expose native DOM attributes as inputs and native custom events as outputs.

• SSR-friendly with hydration: It supports serialization, declarative shadow DOM, and can be server-rendered and hydrated, especially using modern tools.

• Supports Accessibility (ARIA attributes and roles).

❌ Cons

• Integration Difficulties: If you want to bridge two apps in different technical stacks, you need to properly manage their communication in a custom element wrapper and its shadow DOM.

• Limited Support for old Browsers: If you need compatibility with legacy browsers like Internet Explorer 10, Web Components need a polyfill. But here’s a popular repository with all polyfills for Web Components: https://github.com/webcomponents/polyfills

• Global State Isolation: There’s no built-in way to share state across components. You’ll need to implement your own global bus or event bridge using CustomEvents or alike.

👨🏻‍💻 Popular Use Cases

• Reusable Design systems & UI libraries

• Micro frontends inside framework apps

• Legacy integration to modern stack and vice versa

• Cross-team component delivery

• CDN-based plug-and-play UIs

The Web Components API has many more possibilities and power. So, if you want, you can go deeper and advance your knowledge by passing any available free course on freeCodeCamp or passing the one I’ve built myself around this technique on Udemy.

Now let’s move on!

Method #3: Single-SPA — The Meta-Framework Approach

“What if instead of embedding micro frontends as Web Components or iframes, we had a system that orchestrated multiple SPAs together in one layout?”

That’s what single-spa is all about. It’s not a rendering library, it’s a runtime JavaScript router and orchestrator for micro frontends.

Source: https://single-spa.js.org

What Is single-spa?

single-spa (Single Page Application) lets you build and run multiple independent SPAs (React, Vue, Angular, and so on) inside one webpage. Each SPA is responsible for part of the UI and is loaded dynamically depending on the current route.

In short, it’s a framework that:

• Loads your micro frontends when needed

• Mounts/unmounts them cleanly

• Coordinates routing and lifecycles

• Supports different frameworks in the same app.

Real-Life Example

Let’s say you have this route breakdown:

Each one is a fully independent SPA, and single-spa loads them as needed.

🔹 Step #1: single-spa installation

First, you need to install the single-spa as a dependency for your project:

# Create a new project (if it's not yet)
npm init

# Install Single SPA
npm install single-spa systemjs

Notice that we also installed the systemjs package. This package is responsible for the dynamic runtime module loading that makes Single-SPA work seamlessly. It uses SystemJS as a module loader to allow micro frontends to be:

1. Loaded at runtime

2. Independently deployed

3. Framework-agnostic

4. Lazy-loaded only when needed

Now you need to implement each micro-app. For instance, let’s see how the @shop/products app written in React could be managed.

🔹 Step #2: Project Structure

The project structure for each micro app can look like this:

shop/products/
├── src/
│   ├── root.component.jsx
│   └── index.single-spa.js
├── public/
│   └── index.html
├── package.json
└── webpack.config.js

🔹 Step #3: Root Micro App Component

The root.component.jsx file represents the root of the React app that will be mounted to the main DOM using single-spa. Here’s a simple example:

// src/root.component.jsx
import React from 'react';

export default function Root() {
  return (
    <div style={{ padding: '1rem', border: '1px solid #ccc' }}>
      <h2>🛍 Product Micro App</h2>
      <p>This is a micro frontend powered by React + Single-SPA!</p>
    </div>
  );
}

🔹 Step #4: Set Up Lifecycle Hooks

Also, each Micro App in single-spa requires an entry point with at least three core functions/lifecycle hooks. For that purpose, you will need a separate file, which you can name as index.single-spa.js and it will provide the implementation of those hooks, like:

• bootstrap() - Called when the micro app is launched by the main app (Shell) before mounting to the DOM

• mount() - Called when the app is attached to the host in the DOM

• unmount() - Called when the app is removed/detached from the DOM

And here’s an example of what they could look like:

// src/index.single-spa.js

import React from 'react';
import ReactDOM from 'react-dom/client';
import Root from './root.component.jsx';

// Hold the React root instance for reuse
let root = null;

// Called once when the micro frontend is first initialized
export function bootstrap() {
  return Promise.resolve();
}

// Called every time the route matches and the app should appear
export function mount(props) {
  return Promise.resolve().then(() => {
    const container = document.getElementById('product-container') || createContainer();
    root = ReactDOM.createRoot(container);
    root.render(<Root />);
  });
}

// Called when the route no longer matches (cleanup)
export function unmount() {
  return Promise.resolve().then(() => {
    if (root) {
      root.unmount();
    }
  });
}

// Create a container div if it doesn't exist
function createContainer() {
  const div = document.createElement('div');
  div.id = 'product-container';
  document.body.appendChild(div);
  return div;
}

As you see, you have to resolve a Promise in all lifecycle hooks and ensure the React app is mounted and unmounted properly based on the React best practices.

🔹 Step #5: Configuring Webpack for SystemJS

Also, each micro-app in single-spa needs a separate configuration. For that, you will include a webpack.config.js file, specifying how to build the app (output), where to host it (publicPath), and so on.

Since single-spa uses the SystemJS package, the libraryTarget will be system for all micro apps.

// webpack.config.js
module.exports = {
  externals: {
    react: 'React',
    'react-dom': 'ReactDOM',
  },
  output: {
    filename: 'products.js',
    libraryTarget: 'system', // SystemJS-compatible format
    publicPath: 'http://localhost:8500/', // Host location of this micro app
  },
};

This app will be hosted on the localhost:8500. For production, you will have to use any suitable hosting provider (like the ones described in the iframes section).

🔹 Step #6: Registering the Micro App in Root-Config

Next, it’s time to register a new micro-app in the Singla-SPA root config. Here’s how you can do it:

Create a root-config.js file in the root of the project and fill it with this content:

// root-config.js (host shell)
import { registerApplication, start } from 'single-spa';

registerApplication({
  name: '@shop/products',
  app: () => System.import('@shop/products'),
  activeWhen: ['/products'],
});

start(); // Initializes routing and micro app lifecycles

First, you have to register the application, and then you start it to enable routing and the micro app lifecycle. The registration for other micro apps will look the same.

Note: System.import() is part of SystemJS, used by default in single-spa for loading remote apps.

Also, single-spa comes with so-called "Parcels" – a lower-level construct in comparison to applications. They’re essentially self-contained pieces of UI that you can dynamically mount anywhere. Think of them like “mini microfrontends” or reusable widgets that don’t control routing:

// Example
mountParcel(SomeParcelComponent, { domElement: document.getElementById('micro-app') });

You’d use them when:

• You don’t want the parcel to own a route.

• You need to inject a micro frontend dynamically inside another one.

• You want encapsulated logic (like a widget) embedded within a larger app.

In all other cases, prefer the usage of a registerApplication(...) function.

🔹 Step #7: Adding Micro App to SystemJS Import Map

The last step is to register the micro app in SystemJS. For that, in your root index.html file, you need to add the following two scripts:

<!-- public/index.html -->

<!DOCTYPE html>
<html lang="en">
<head> <title>Micro Frontend Shell</title> </head>
<body>
  <nav>
    <a href="/products">Products</a> |
    <a href="/checkout">Checkout</a>
  </nav>

  <!-- Import maps handled by bundler or injected at runtime -->
  <script type="systemjs-importmap">
    {
      "imports": {
        "@shop/root-config": "http://localhost:9000/root-config.js",
        "@shop/products": "http://localhost:8500/products.js",
        // other micro apps
      }
    }
  </script>

  <!-- Start the root-config application -->
  <script>
    System.import('@shop/root-config');
  </script>
</body>
</html>