Most frontend performance work isn’t about making everything load faster. It’s about making sure the browser spends its first few seconds on what the user actually needs first.

Images, fonts, third-party scripts, iframes, JavaScript and animations can all compete for network bandwidth and CPU time. Some are critical. Many aren’t.

A useful performance strategy is therefore:

Load, execute and render the things users need first. Defer everything else until it becomes relevant.

This playbook covers a practical approach to images, LCP, third-party code, JavaScript, layout stability and accessibility.

1. Start With Measurement, Not Optimizations

Before changing code, first understand what is actually slowing the page down.

Useful tools include:

• Lighthouse for lab-based performance checks
• Chrome DevTools Network panel and waterfall
• Performance panel for long tasks and main-thread activity
• JavaScript Coverage to identify code that is loaded but unused
• Core Web Vitals, particularly LCP, CLS and INP
• Real-user monitoring (RUM) for production data

Using AI to Analyze Performance Data

Performance reports can contain a large amount of information: network requests, JavaScript execution, long tasks, LCP breakdowns, unused code, third-party resources and layout shifts. Manually going through every signal can make it difficult to distinguish the important problems from the noise.

AI tools can be useful as an additional analysis layer.

A practical workflow is to provide an AI tool with performance artifacts such as Lighthouse reports, Chrome DevTools traces, network waterfalls, performance profiles or exported Web Vitals data. The AI can then help summarize the findings, identify patterns, connect related issues and highlight areas that deserve deeper investigation.

For example, instead of simply looking at a Lighthouse warning such as “Reduce unused JavaScript,” an AI-assisted analysis can help connect that finding with the application structure:

Lighthouse
   ↓
Unused JavaScript
   ↓
Which bundle?
   ↓
Which component imported it?
   ↓
Is that component needed on initial load?
   ↓
Can it be dynamically imported?

The same approach can be used to cross-reference multiple signals. For example, an LCP regression combined with the network waterfall may reveal that a third-party script, font or non-critical image is competing with the LCP resource.

AI should not replace the underlying measurements or browser tooling. Its most useful role is to reduce the analysis effort and surface potential gaps faster. The proposed diagnosis should still be verified against the actual trace, network behavior and production data before making an optimization.

A useful mental model is:

Use browser tools to collect evidence; use AI to help interpret the evidence; use engineering judgment to decide what to change.

A useful investigation loop is:

Measure
  ↓
Analyze the evidence
  ↓
Form a hypothesis
  ↓
Make one targeted change
  ↓
Measure again
  ↓
Keep or revert

The goal isn’t to optimize based on a single Lighthouse recommendation. It’s to connect multiple pieces of evidence, form a hypothesis, validate the change, and then decide whether the improvement is worth keeping.

Use Engineering Judgment

Not every performance recommendation is worth implementing. An optimization may improve one metric while adding complexity, increasing maintenance cost or regression risk, or negatively affecting the user experience elsewhere.

Performance work should therefore be treated as a trade-off exercise. Consider the impact, implementation effort, complexity, and risk before making a change. Some improvements may be worth shipping immediately, while others may have too little benefit to justify the cost.

It is also important to validate the result after the change. If an optimization does not produce the expected improvement — or introduces unexpected side effects — revert the change rather than optimizing for the sake of optimization.

The goal is not to implement every recommendation from Lighthouse, DevTools, or an AI analysis. The goal is to make high-value, low-risk improvements that meaningfully improve the user experience.

The more useful question is:

What is competing with the user’s first meaningful experience?

For example, a page may download a large amount of JavaScript, but if that JavaScript belongs to a lightbox the user hasn’t opened, it shouldn’t necessarily be part of the initial loading cost.

2. The Mental Model: The Browser Has Limited Attention

A useful way to think about frontend performance is to imagine that the browser has a limited amount of bandwidth and CPU available during the first few seconds.

First viewport
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
         LCP        Interaction       Layout
          │              │              │
       Images           JS           Dimensions
       Fonts          Widgets        Skeletons

Every unnecessary resource can compete with something more important.

This leads to a simple principle:

Don’t just ask whether something is fast. Ask whether it needs to happen now.

That principle can guide most frontend performance decisions.

3. Images: Prioritize Only What Matters

Images are often one of the easiest places to find unnecessary work.

What to check

• Lighthouse’s “Properly size images” audit
• Offscreen image loading
• Network waterfall
• Image dimensions and variants
• Which element is actually reported as LCP
• How carousel and slider images are mounted

A useful way to categorize images is:

1. The LCP image — important immediately
2. Other visible images — potentially important, but not necessarily critical
3. Offscreen images — wait until they’re needed

The important part isn’t simply “lazy load images.”

It’s deciding which image deserves priority.

3.1 Identify the Actual LCP Image

A common mistake is treating multiple images as equally important.

For example, a hero image and the first image of every card may all be marked as high priority.

That can cause multiple large images to compete for bandwidth even though only one ultimately becomes the LCP element.

Instead:

Identify the actual LCP resource and prioritize that resource rather than everything that happens to appear near the top of the page.

3.2 Understand loading vs fetchPriority

These mechanisms solve different problems. They influence resource loading, but they control different things.

"loading" controls timing.

It tells the browser whether a resource needs to be loaded as part of the initial page experience or whether its loading can be deferred until it is needed.

loading="lazy"
Allows the browser to defer loading until the resource is needed. Use it for offscreen or below-the-fold images.

loading="eager"
Tells the browser not to intentionally defer loading. Use it for important images that are immediately visible, such as the hero/LCP image.

"fetchPriority" controls importance.

It tells the browser how important a resource is relative to other resources that are competing for network or browser resources.

fetchPriority="high"
Signals that a resource is particularly important compared with other requests. Typically useful for the LCP image.

fetchPriority="low"
Signals that a resource is less important and can take a lower priority. Useful for non-critical images that might otherwise compete with more important resources.

For example:

<Image
  src={hero}
  priority
  fetchPriority="high"
  sizes="100vw"
/>

The exact implementation depends on the framework and image component, but the principle is the same.

Avoid high priority everywhere

Making every first-screen image high priority simply recreates the original problem.

If everything is important, nothing is meaningfully prioritized.

fetchPriority is a hint, not a guarantee, and it doesn't replace lazy loading.

3.3 Serve the Right Image

Another common problem is downloading an image that is much larger than the viewport requires.

For example, a mobile device may download a desktop-sized image even though only a fraction of its pixels are displayed.

Use responsive image techniques such as srcset, sizes, or framework-level image optimization to select an appropriate resource.

The general principle:

Don’t optimize only the loading behavior. Optimize the payload itself.

A perfectly prioritized 1.5 MB image is still a 1.5 MB image.

3.4 Don’t Eagerly Load Every Carousel Slide

A carousel may contain five or ten images, while the user initially sees only one.

For list-card carousels:

• The first image doesn’t automatically become a “hero”.
• Additional slides can be loaded on demand.
• Avoid mounting every slide up front when users are unlikely to view them.

For a lightbox or full-screen gallery, the trade-off is different.

Users may immediately jump to another image, so aggressively delaying every slide can make interaction feel slow.

The important distinction is:

Performance optimization depends on the interaction model.

A list-card carousel and a full-screen gallery should not necessarily use the same loading strategy.

3.5 Don’t Tie Loading to the Active Slide

A subtle issue can occur when lazy/eager behavior is tied directly to the currently active slide.

When the user swipes, the image may be remounted or treated as a new resource.

That can result in flashes and, in some cases, additional downloads.

Instead:

Tie loading decisions to the initial rendering strategy, not simply to which slide happens to be active.

3.6 Don’t Animate What Users Can’t See

Animated loading placeholders can consume CPU even when the associated content isn’t visible.

A better approach is:

• Use a static placeholder by default.
• Start animation only when the content is close to the viewport.
• Don’t animate hidden slides.
• Respect prefers-reduced-motion.

Not every loading state needs to consume CPU.

4. LCP: Clear the Runway

LCP is a race.

The browser has to download resources, process them, execute JavaScript and eventually paint the element that becomes the LCP candidate.

Anything unnecessary competing during that period can make the finish line harder to reach.

Look at everything loading around the time of the LCP element:

• Fonts
• Third-party scripts
• Iframes
• Additional images
• JavaScript execution

The key question is:

Does this resource need to happen before the user sees the primary content?

If the answer is no, look for a way to defer it.

4.1 Fonts

Preloading a font tells the browser:

“This resource is important. Start downloading it immediately.”

That’s useful when the font is genuinely critical.

It’s less useful when that same bandwidth could be used by the LCP resource.

Consider:

• Keeping preload for the primary UI font where it is genuinely needed.
• Removing unnecessary preload from secondary or decorative fonts.
• Using font-display: swap where appropriate.

The general rule:

Preload is not a performance badge. Preload means “this resource is important enough to compete for early bandwidth.”

Use it deliberately.

5. Third-Party Code: Defer Without Breaking the Experience

Third-party widgets are particularly interesting because their JavaScript is often outside your direct control.

Chat widgets, analytics libraries, maps and support tools are common examples.

A chat widget might initially follow this pattern:

Page starts
    ↓
Chat SDK starts loading
    ↓
Parse + execute third-party JS
    ↓
LCP competes with chat

Instead, defer non-critical third-party code:

Page starts
    ↓
Critical page content
    ↓
window.load
    ↓
Browser idle time
    ↓
Chat SDK

A client-only dynamic import combined with window.load and idle scheduling can be used for this pattern.

Conceptually:

window.addEventListener("load", () => {
  requestIdleCallback(loadChat, {
    timeout: 5000,
  });
});

The exact timeout is application-specific.

The important principle is:

Defer third-party work opportunistically, but don’t defer it indefinitely.

There is also an important UX constraint.

Waiting until the user clicks the chat launcher before loading anything may make the launcher unavailable.

A hybrid strategy can work better:

Normal path
Page → load → idle → Chat

User clicks early
Page → click → Chat immediately

This pattern is useful for functionality that should eventually be available but isn’t part of the critical rendering path.

6. Iframes: Don’t Let a Separate Document Block the Page

An iframe isn’t just another element.

It represents another document with its own resources and execution.

Maps, videos and embedded third-party experiences can therefore become surprisingly expensive.

A common approach is:

Page navigation
      ↓
Critical content renders
      ↓
Page load / idle
      ↓
Observe placeholder
      ↓
User approaches content
      ↓
Set iframe src

The iframe should also have a sized placeholder so that loading it doesn’t introduce layout shift.

There should also be an explicit escape hatch:

If the user asks for the content, load it immediately.

This creates a useful general pattern:

Defer by default, bypass the delay when the user expresses intent.

7. JavaScript: If It’s Not Open, Don’t Ship It

JavaScript has multiple costs:

Download
   ↓
Parse
   ↓
Compile
   ↓
Execute
   ↓
Hydrate / Render

Reducing initial JavaScript can therefore reduce more than network transfer. It can also reduce parsing, execution and main-thread work.

A useful rule is:

If the user hasn’t requested a piece of UI, don’t make the browser pay for it during initial rendering.

7.1 Overlays and Heavy Interactive UI

Lightboxes, drawers and detail panels are good candidates for dynamic imports.

Instead of loading them with the initial page:

Initial page
    ↓
Small loading shell
    ↓
User opens gallery
    ↓
Dynamic import
    ↓
Gallery mounts

The first interaction pays the loading cost, but subsequent opens are cheap because the chunk is cached.

The broader principle:

Move cost from initial page load to the interaction that actually needs the feature.

7.2 Don’t Build Skeletons With Heavy Components

Some loading states can accidentally require much of the same component machinery as the final UI.

For simple layouts, CSS is often enough.

.skeleton {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

The principle:

A loading state shouldn’t require a large UI component just to draw boxes.

7.3 Below-the-Fold Sections

Below-the-fold content doesn’t always need to be part of the initial JavaScript cost.

Consider:

• Splitting expensive variants into separate chunks.
• Dynamically importing sliders and other heavy interactive components.
• Keeping important first-fold and SEO content available synchronously.

7.4 Don’t Animate During Hydration

Decorative animations are another form of work.

If an animation doesn’t communicate something important to the user, there’s often little reason to run it during initial hydration.

For example, a wishlist animation makes sense after the user clicks “Add to wishlist.”

It doesn’t need to run every time the page hydrates.

Prefer interaction-driven animation over startup animation.

8. CLS: Reserve Space Before Content Arrives

Performance isn’t only about speed.

A page that appears quickly but jumps around while loading is still a poor experience.

Common sources of CLS include:

• Layout changes after hydration
• Images without predictable dimensions
• Iframes appearing without reserved space
• Loading states that don’t match the final layout
• Asynchronous content being inserted into existing layouts

8.1 Make the Server and Client Agree

Responsive rendering can introduce a subtle problem.

For example:

Server HTML
Desktop layout
      ↓
Hydration
      ↓
Client detects mobile
      ↓
Remount / layout change

This can create layout shifts and unnecessary rendering work.

Where appropriate, use server-side device hints or other stable inputs so that the server HTML and first client render make consistent layout decisions.

The broader lesson:

Avoid rendering one layout and immediately replacing it with another after hydration.

8.2 A Loader Is Not the Layout

A skeleton can technically reserve space while still producing a poor experience if its geometry doesn’t match the final content.

For example:

Skeleton
┌──────────────┐
│              │
└──────────────┘

Actual card
┌─────────────────────┐
│                     │
│                     │
└─────────────────────┘

Both occupy space, but the transition can still cause visual movement.

Prefer:

• aspect-ratio boxes
• Grid structures matching the final layout
• Placeholder dimensions matching real content

The goal isn’t simply:

“Reserve some space.”

It’s:

**Reserve the right space.

8.3 Iframes Need a Box Before They Need a src

For maps and similar content, render a sized placeholder first.

┌────────────────────────┐
│                        │
│       Placeholder      │
│                        │
└────────────────────────┘
           ↓
        iframe loads
           ↓
┌────────────────────────┐
│                        │
│       Actual content   │
│                        │
└────────────────────────┘

The iframe can then fade in without changing the surrounding layout.

9. Common Approaches That Don’t Work Well

Performance optimization often involves trying an approach that sounds reasonable and discovering that it creates a different problem.

Some common examples:

The goal isn’t to find a clever optimization.

It’s to find the simplest strategy that improves the user experience without creating a new problem somewhere else.

10. Performance Without Accessibility Regressions

Performance optimizations shouldn’t come at the cost of usability or accessibility.

Common checks include:

• Add accessible labels to icon-only buttons.
• Remove redundant aria-labels where visible text already describes the control.
• Use role="presentation" for purely structural elements where appropriate.
• Use role="status" for loading states where users need to be informed of asynchronous changes.
• Use inert when content should remain mounted but temporarily unavailable for interaction.
• Respect prefers-reduced-motion for animated loading states.

The goal is simple:

Make the browser do less work without making the experience less understandable.

11. Measure the Result

Performance work is difficult to evaluate without measurement.

Always compare the state before and after meaningful changes.

For example:

If exact numbers cannot be shared, relative improvements are still useful.

For example:

LCP improved by approximately [X]%, while the initial JavaScript payload decreased by approximately [Y]%.

The important part is connecting an engineering change to a measurable outcome.

12. A Practical Frontend Performance Checklist

These aren’t universal rules. They’re useful defaults to start with and then validate through measurement.

Images

• Identify the actual LCP image.
• Give the LCP resource preferential treatment.
• Don’t make every above-the-fold image high priority.
• Serve an appropriately sized image for the viewport.
• Lazy-load genuinely offscreen images.
• Don’t mount every carousel slide unnecessarily.

Third-party code

• Keep third-party scripts out of the critical rendering path where possible.
• Prefer load → idle → interaction over loading everything immediately.
• Give user intent an escape hatch: if the user asks for something, load it immediately.

JavaScript

• Dynamically import expensive UI that users don’t need immediately.
• Don’t mount overlays, drawers or galleries before they’re needed.
• Keep loading states lightweight.
• Avoid unnecessary work during hydration.
• Prefer interaction-driven animation.

Layout

• Reserve space before asynchronous content arrives.
• Make skeleton geometry match the final UI.
• Keep server and client rendering decisions aligned.
• Avoid remounting content unnecessarily.

Measurement

• Measure before optimizing.
• Identify the actual bottleneck instead of optimizing by assumption.
• Change one meaningful thing at a time.
• Validate the result again.
• Use both lab measurements and real-user data when possible.

Conclusion

The biggest frontend performance improvements often come from one simple question:

Does this need to happen now?

The hero image probably does. The fifth carousel image probably doesn’t.

The product content does. The unopened lightbox doesn’t.

The user’s requested map does. The third-party widget probably doesn’t need to compete with LCP.

The goal isn’t to make every resource load as quickly as possible.

It’s to make the right resources load, execute and render at the right time.

Don’t try to make everything happen faster. Make the right things happen first.

Frontend Performance Optimization: A Practical Guide to Faster Web Pages was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

We introduced Figma MCP with Cursor into our workflow to generate frontend code directly from Figma design nodes. While the setup worked functionally, the generated UI code was inconsistent — particularly around CSS variable usage.

The root cause wasn’t the AI tooling.

It was inconsistent design token and CSS variable naming.

To get started with Figma MCP, follow the official Figma MCP Server guide provided by Figma.

The Core Issue: Token Drift

Over time, our system evolved like this:

In Figma

color.primary.500
color.brand.main
color.blue.600

In Frontend CSS

--color-primary
--brand-blue
--blue-600

Many of these variables represented the same raw color value but were exposed through different semantic token names across design and frontend. Humans could reason about this ambiguity; Figma MCP could not.

When Figma MCP attempted to generate code from a design node, inconsistent or overlapping token references prevented deterministic name resolution, resulting in unpredictable CSS variable output or fallback to raw values.

Why This Breaks Figma MCP

• Figma MCP relies on explicit design token references, not inferred intent or value matching.
• It resolves CSS variables through name-based mapping between design tokens and frontend variables.
• When multiple semantic tokens reference the same value, MCP cannot deterministically choose one.
• Misalignment between token names and CSS variables breaks reliable mapping.

In such cases, MCP emits inconsistent variables or falls back to raw values — an issue that must be fixed at the design system level, not through prompts.

The Fix: Make Tokens Deterministic

Step 1: Separate Raw Tokens From Semantic Tokens

We restructured our tokens to follow a strict hierarchy.

Raw tokens (single source of truth):

color.raw.blue.600 = #2563EB

Semantic tokens (reference raw tokens):

color.action.primary = {color.raw.blue.600}
color.link.default   = {color.raw.blue.600}

Rules we enforced:

• One raw value per token
• Semantic tokens must reference raw tokens
• No duplicate semantics for the same intent

This eliminated ambiguity at the design layer.

Step 2: Align Frontend CSS Variables With Tokens

Next, frontend variables were aligned one-to-one with Figma tokens.

:root {
  --color-raw-blue-600: #2563eb;

  --color-action-primary: var(--color-raw-blue-600);
  --color-link-default: var(--color-raw-blue-600);
}

Key principles:

• CSS variable names mirror Figma token names — Figma design tokens are the source of truth
• No frontend-only aliases
• Semantic intent is preserved in naming

We used a Figma plugin — Token Sniff to extract tokens directly into CSS to avoid manual drift.

Step 3: Use Figma MCP After Alignment

Once design tokens and frontend CSS variables are fully aligned, you can start using Figma MCP with Cursor for code generation.

• MCP could reliably identify the correct token
• Cursor generated predictable variable usage
• No more random or legacy CSS variable names

The AI output became stable because the system became deterministic.

What This Enables

• Deterministic CSS variable resolution during Figma MCP–based UI code generation.
• Consistent AI-generated UI output across components and files.
• Lower post-generation cleanup cost due to predictable token usage.
• Stronger contract between design and frontend via shared token naming.
• Scalable AI-assisted workflows without relying on prompt heuristics.

Key Takeaways

• Figma MCP resolves variables by token name, not by value or intent.
• Design token ambiguity directly results in unstable AI output.
• Frontend CSS variables must align one-to-one with design tokens.
• Token structure is system infrastructure, not a styling concern.
• Reliable AI code generation depends more on system design than prompts.

Conclusion

Figma MCP and Cursor didn’t require better prompts. They required a cleaner design system.

By enforcing strict token hierarchies and aligning frontend variables with Figma design tokens, we turned AI-generated UI code from “sometimes useful” into something we can reliably trust in production.

The BroadcastChannel API in JavaScript makes it easy to sync data and state across multiple browser tabs or windows in real time.

When building modern web applications, it’s common for users to open multiple tabs of the same app. Think of scenarios like a shopping cart, logging out, or changing themes — the changes in one tab should instantly reflect in all other open tabs.

While developers often use localStorage with the storage event to handle this, there’s a much cleaner, modern approach: the BroadcastChannel API.

In this post, we’ll explore what the BroadcastChannel API is, how it works, when to use it, and how to implement it in a React/Next.js app.

What is the BroadcastChannel API?

The BroadcastChannel API is a simple browser API that enables communication between different browsing contexts — that means tabs, windows, iframes, or even workers — as long as they share the same origin (protocol, host, and port).

In other words, it lets you broadcast messages across multiple tabs of the same app without relying on hacks like localStorage or server-side websockets.

How it works

You create a channel with a unique name:

const channel = new BroadcastChannel("my-app");

Any tab can send a message:

channel.postMessage({ type: "LOGOUT" });

Other tabs listening to the same channel receive the message:

channel.onmessage = (event) => {
  console.log(event.data); // { type: "LOGOUT" }
};

That’s it — no polling, no storage tricks, just direct communication between tabs.

Why use BroadcastChannel API?

Here are a few real-world use cases:

1. Authentication Sync
   If a user logs out in one tab, all other open tabs should log out instantly.
2. Shopping Cart Updates
   Add an item to the cart in one tab, and other tabs show the updated cart without refreshing.
3. Theme or Settings Sync
   Toggle dark mode in one tab and see the change across all tabs.
4. Collaborative Dashboards
   Keep multiple open dashboards in sync with real-time data changes.

Implementing BroadcastChannel in Next.js

Let’s walk through a small example in Next.js to demonstrate syncing logout across tabs.

Step 1: Create a broadcast utility

// utils/broadcast.ts
export const initBroadcast = (name: string) => {
  const channel = new BroadcastChannel(name);
  return channel;
};

Step 2: Setup listener in _app.tsx

// pages/_app.tsx
import { useEffect } from "react";
import { initBroadcast } from "@/utils/broadcast";

function MyApp({ Component, pageProps }) {
  useEffect(() => {
    const bc = initBroadcast("my-app");

    bc.onmessage = (event) => {
      if (event.data.type === "LOGOUT") {
        // Example: redirect to login
        window.location.href = "/login";
      }
    };

    return () => bc.close();
  }, []);

  return <Component {...pageProps} />;
}

export default MyApp;

Step 3: Trigger an action from any tab

// components/LogoutButton.tsx
import React from "react";

export default function LogoutButton() {
  const handleLogout = () => {
    const bc = new BroadcastChannel("my-app");

    bc.postMessage({ type: "LOGOUT" });
    bc.close();
  };

  return <button onClick={handleLogout}>Logout</button>;
}

Now, when you click Logout in one tab, every open tab of your app will receive the LOGOUT message and redirect to the login page.

Things to Know

• Browser Support: The BroadcastChannel API is supported in all modern browsers (Chrome, Firefox, Safari, Edge). Internet Explorer is not supported.
• Same Origin: Tabs must share the same origin (protocol + host + port).
• Performance: It’s lightweight and faster than localStorage events since it doesn’t write to disk.

If you need to support older browsers, you can provide a fallback using localStorage and the storage event.

Final Thoughts

The BroadcastChannel API is a powerful yet underused tool for creating seamless multi-tab experiences in web applications. Whether it’s syncing authentication state, updating shopping carts, or reflecting settings across tabs, BroadcastChannel provides a cleaner and more efficient solution than traditional hacks.

Whether you’re building with Next.js, React, or even plain JavaScript projects, the BroadcastChannel API can help deliver a smoother and more consistent experience across all open tabs.

Whether you’re enhancing current features, working with legacy files, refactoring spaghetti code, or simply trying to improve code quality, AI can act as a powerful assistant — but only if you know how to guide it well.

AI-powered code editors are reshaping the way developers write, refactor, and understand code. While many demos highlight how AI can spin up entire projects from scratch, this post takes a more practical, real-life perspective: how to use AI effectively within an existing codebase.

This isn’t an in-depth tutorial or theoretical guide. Instead, it’s a collection of quick, actionable tips based on my real-world usage of Cursor IDE over the past few months. If you’re just getting started with AI coding tools, these learnings will help you get more value out of the experience and integrate AI smoothly into your development workflow.

1. Building New Components (The Smart Way)

When working in a mature or large codebase, adding new components is part of everyday life. AI can significantly reduce the time required — if you give it the right instructions.

A. Break down the requirement into small, manageable tasks

Don’t dump the entire feature description in one go. Instead, isolate smaller responsibilities like layout, state management, logic, and API integration.

For example:

• First prompt: “Create the base JSX layout for a product grid with dummy data.”
• Follow-up: “Add filtering logic based on selected categories.”
• Then: “Integrate this with the fetchProducts API and handle loading/error states.”

Why this helps: When you chunk things down, AI understands context better and delivers results that are easier to validate. You also avoid bloated or irrelevant output.

B. Use clear, precise prompts with well-defined expectations

AI performs best when you give it all the context upfront: component name, expected props, how it should behave, and how it should look.

Example prompt:

“Create a React component named ProductGrid that takes in a list of products and available categories as props. Render a grid of products and display a dropdown filter to filter by category."

C. Iterate with follow-up prompts

Once AI returns something useful, keep building on it:

• “Add skeleton loading and an error message.”
• “Make the layout responsive on mobile screens.”
• “Add accessibility attributes for screen readers.”
• “Convert this to TypeScript with proper types.”

Think of the AI like a junior developer: give it small tasks, review its output, and guide it to the finish line.

2. Working with Existing Code

Let’s face it — most developers spend far more time maintaining and updating existing code than writing fresh features. AI can be your best friend in this space if you scope it correctly.

A. Adding new logic or functions

If the new logic is independent, you can prompt AI directly.

Example prompt:

“Write a helper function that takes a price number and returns a formatted currency string. It should return a fallback message for invalid input.”

B. Modifying existing methods

This is where things get tricky. Broad prompts can confuse the model and lead to unintended changes.

Poor prompt:

“Update handleSubmit to include validations.”

Better prompt:

“Within handleSubmit, add a condition to validate that the email ends with ‘.org’. If not, set an error message and prevent form submission.”

By narrowing the focus, you reduce the chances of AI altering unrelated logic.

C. Refactor large files one step at a time

Instead of feeding AI an entire file:

• Highlight a single function or block
• Prompt: “Refactor this function to improve readability and add inline comments.”
• Follow-up: “Split this into two smaller pure functions.”
• Follow-up: “Move the API call into a separate utility module.”

Why this works:

• Reduces confusion for AI and you
• Easier to track and test changes
• Keeps your code stable while improving it incrementally

3. Enhancing & Refactoring Code

Some of the most immediate value from AI comes from helping you polish existing code — making it cleaner, faster, and easier to understand.

A. Optimize for performance or readability

• “Refactor to use early returns to avoid deep nesting.”
• “Extract the date formatting logic into a utility.”
• “Rewrite this callback using async/await.”

B. Improve code documentation

• “Add inline comments to explain the logic in this useEffect.”
• “Generate a short summary for this file that I can include in the README.”

C. Improve naming conventions

• “Suggest more descriptive names for these variables and functions based on their purpose.”

4. Chat With AI Like a Design Partner

AI isn’t just a code writer. It’s an idea generator, rubber duck, and architectural sounding board — if you treat it that way.

A. Use it to brainstorm solutions

“Should I debounce search input using useEffect, a custom hook, or lodash.debounce?”

AI will often give you a helpful breakdown:

• Pros and cons of each approach
• When to use useCallback or useMemo
• Code snippets and common pitfalls

B. Explore architecture and trade-offs

“Should I use Redux or Context API for global state in a mid-sized React app?” “Should I do client-side filtering or call the API on each filter change?”

C. Break down work like a product manager

“I need to build a multi-step form. What are the logical steps to implement it in React?”

D. Explore better ways to improve old code

“Is there a cleaner pattern for handling async form submission with loading states?”

You’re not just solving problems — you’re learning, improving, and designing smarter.

Prompting Cheatsheet

Here’s a quick reference guide to help you prompt more effectively:

Generate new code:
Include structure, input/output expectations, and purpose.

Refactor/optimize:
Be specific: “Make this more readable”, “Remove unnecessary nesting”, “Extract side effects.”

Understand code:
Ask: “What does this hook do?”, “Explain this function step by step.”

Improve naming:
“Suggest more expressive identifiers for these variables.”

Explore design:
“What’s a more modern or testable way to approach this?”

🚫 Bad Prompt:

“Do this for me.”

✅ Good Prompt:

“Write a custom React hook that handles fetch requests with loading and error states.”

Want to sharpen your prompting skills? Try this free prompt engineering course which helped me articulate prompts.

Summary

Using AI in your code editor isn’t about replacing developers — it’s about amplifying your productivity. With clear communication, tight scope, and thoughtful iteration, you can:

• Ship features faster
• Improve readability and maintainability
• Onboard new teammates more efficiently
• Learn and grow through real-time collaboration

Treat AI like a trusted pair programmer — one that helps you brainstorm, write, review, and refactor code. Once you develop that habit, it becomes a seamless part of your development flow.

The future of coding isn’t solo — it’s collaborative, and AI is right there with you on the journey.

Introduction

Using Husky to run ESLint on staged files before committing ensures code quality and consistency. Husky enables Git hooks, letting us run scripts before commits. Combined with lint-staged, only staged files get linted, optimizing performance and reducing unnecessary computations.

This guide walks through setting up Husky to automatically lint staged files using ESLint, preventing errors from entering the repository and ensuring cleaner commits.

What is Husky?

Before diving into the setup, let’s first explore Husky and its capabilities. Husky is a Git hook tool that automates tasks before commits and pushes, ensuring code quality and consistency. Apart from running ESLint on staged files, it can:

• Run Tests Before Commit — Prevents broken code by executing unit or integration tests.
• Enforce Code Formatting — Runs Prettier or other formatters to maintain style consistency.
• Prevent Bad Commits — Blocks commits with linting errors, security vulnerabilities, or missing dependencies.
• Automate Dependency Checks — Ensures packages are installed before committing or pushing.
• Enforce Commit Message Standards — Uses commitlint to maintain a structured commit history.

Step 1: Install Dependencies

To begin, install Husky and lint-staged as development dependencies:

npm install --save-dev husky
npm install --save-dev lint-staged

These tools enforce linting rules at pre-commit, ensuring only formatted, error-free code gets committed, thus reducing the number of build-time failures.

Step 2: Enable Husky in the Project

Initialize Husky by running the following command:

npx husky install

This creates the .husky/ directory, which will store all Git hooks configured for the repository.

Step 3: Configure Husky Pre-Commit Hook

If you have already executed npx husky install, a pre-commit hook might already exist in the .husky/ directory, containing npm test as its default content. To modify it for linting staged files, replace its content with the following:

File: .husky/pre-commit

npm run lint-staged

This command ensures that lint-staged runs whenever you attempt to commit changes.

To make sure the pre-commit script runs correctly, grant execution permissions:

chmod ug+x .husky/*

Step 4: Set Up Lint-Staged

4.1 Configuring package.json

Understanding the prepare Script

The prepare script in package.json ensures that Husky is correctly installed and configured, but it also includes a conditional check:

{
   ...
   "prepare": "node -e \"if (process.env.NODE_ENV !== 'production'){process.exit(1)} \" || husky install | chmod ug+x .husky/*"
}

Breakdown:

1. Check Environment: The node -e command runs an inline Node.js script to check if NODE_ENV is set to production. If it's not, the script exits with a failure status (1).
2. Install Husky: The || operator ensures that if the previous command fails, husky install runs, setting up Git hooks.
3. Ensure Execution Permissions: The | chmod ug+x .husky/* command ensures that Husky scripts are executable.

This setup prevents Husky from running in production environments while maintaining proper permissions for pre-commit hooks.

Inside your package.json, define a script for running lint-staged:

File: package.json

{
    "scripts": {
        "lint-staged": "lint-staged",
        "prepare": "node -e \"if (process.env.NODE_ENV !== 'production'){process.exit(1)} \" || husky install | chmod ug+x .husky/*"
    }
}

This ensures that Husky is correctly installed and configured.

4.2 Configuring .lintstagedrc.json

Define which files should be linted using a lint-staged configuration file:

File: .lintstagedrc.json

{
   "*.{js,tsx,ts}": ["eslint --ignore-path .gitignore --fix", "eslint --ignore-path .gitignore"]
}

This configuration ensures that JavaScript and TypeScript files are automatically formatted and checked before being committed.

Alternatively, if you’re working with Next.js, you can use a .lintstagedrc.js configuration for lint-staged.

Configuring .lintstagedrc.js

If you’re not using the Next.js, you can skip this configuration.

File: .lintstagedrc.js

// Ref: https://nextjs.org/docs/pages/api-reference/config/eslint#running-lint-on-staged-files

const path = require('path');

const buildEslintCommand = (filenames) =>
  `next lint --fix --file ${filenames.map((f) => path.relative(process.cwd(), f)).join(' --file ')}`;

module.exports = {
  '*.{js,jsx,ts,tsx}': [buildEslintCommand],
};

This setup allows Next.js projects to run next lint only on staged files, optimizing performance.

Step 5: Testing the Setup

To verify everything works correctly, follow these steps:

1. Stage a file for commit:

To produce ESLint error, you can import any component (from your repo) in a file and keep it unused.

git add yourfile.js

2. Attempt to commit:

git commit -m "Test Husky linting"

3. Check if ESLint runs on staged files:

• If linting errors exist, the commit will be blocked until the issues are fixed.
• If no errors exist, the commit will proceed.

Step 6: Troubleshooting

If you run into issues, try the following troubleshooting steps:

• Ensure Husky is installed:

npx husky install

• Check if the .husky/pre-commit script has execution permissions:

ls -l .husky/

• Manually run lint-staged to debug errors:

npx lint-staged

• If you are using Next.js, confirm that the correct ESLint configuration is being picked up.

Conclusion

Setting up Husky with ESLint and lint-staged helps enforce code quality by catching linting errors before they reach the repository. This ensures that only properly formatted, error-free code gets committed, improving overall project maintainability and developer productivity.

By integrating this workflow into your project, you can prevent build-time errors and maintain a consistent coding standard across your team.

Further Reading

• Husky Documentation
• ESLint Configuration Guide
• Next.js ESLint Setup

Happy coding! 🚀

In the previous post — Stripe Payment Integration — Key Concepts & Payment Flow | Part 1, we covered the key concepts and payment flow of Stripe’s PaymentElement. Now, we’ll walk through the implementation details of an already built integration, breaking down the core steps involved in handling payments.

Introduction

This guide will explain how the client and server interact, how PaymentIntents are created and confirmed, and how transactions are processed securely. By the end, you’ll have a clear understanding of how this integration works and how you can adapt it to your own application.

We will be referring these two apps to learn about the stripe integration.

• Frontend App
• Backend App

Stripe Implementation Breakdown

In this section, we will look into each of the integration steps we had explored with the help of flow diagram in prvious post.

Step 1: Customer Initiates Payment:

Upon running the development server on the provided branch, you will see the following web app. Clicking the “Buy Now” button initiate the payment intent and redirects the user to a payment page where they can proceed with the payment.

Step 2: Client Sends Order Details to Server:

On the client-side, clicking the “Buy Now” button will post the Product ID to our server-side API endpoint /create-payment-intent.

Next: This end point generates a client_secret on server and returns the PaymentIntentId to client.

Here, PaymentIntentId is an ID generated on server to map an order (client_secret) which is initiated to make a payment.

const handleSubmit = async (event) => {
    event.preventDefault()

    try {
      // Create a payment intent on the server
      const data = await fetch(
        `${import.meta.env.VITE_API_ENDPOINT}/create-payment-intent`,
        {
          method: "POST",
          headers: { "Content-Type": "application/json" },
          body: JSON.stringify({ item: { id: product.id } }),
        }
      ).then((res) => res.json())

      if (data?.intentId) {
        navigate(`/order/payment/${data?.intentId}`)
        return
      }

      if (error) {
        console.error("Payment failed:", error)
        alert("Payment failed. Please try again.")
      } else if (paymentIntent.status === "succeeded") {
        console.log("Payment succeeded:", paymentIntent)
        alert("Payment successful! Thank you for your purchase.")
      }
    } catch (error) {
      console.error("Error during payment:", error)
      alert("Something went wrong. Please try again.")
    }
  }

Step 3: Server Creates PaymentIntent:

On the server side, the /create-payment-intent endpoint follows three main steps, which are explained in detail after the code snippet below.

app.post("/create-payment-intent", async (req, res) => {
  const { item } = req.body
  
  // Step 3.1: Fetch product details from id
  const productData = await db.getProductDetails(item?.id)

  // Check if the product data is found
  if (!productData) {
    res.status(500).send({
      paymentIntent: "Data not found",
    })
    return
  }

  // Step 3.2: Create a PaymentIntent with the order amount and currency
  const paymentIntent = await stripeAPI.paymentIntents.create({
    amount: productData?.amount * 100,
    currency: productData?.currency?.toLowerCase(),
    // In the latest version of the API, specifying the `automatic_payment_methods` parameter is optional because Stripe enables its functionality by default.
    automatic_payment_methods: {
      enabled: true,
    },
  })

  // Step 3.3: Generate Intent Id and store it along with client_secret
  const intentId = await db.addBookingIntent(paymentIntent.client_secret)

  res.send({
    intentId,
  })
})

Step 3.1: First, The server fetches product details from the database based on the received Product ID.

It’s recommended to use database-stored price-sensitive information instead of relying on client-side inputs, as these can be susceptible to tampering.

Step 3.2: Create the paymentIntent using Stripe API `paymentIntents.create()` with the Order details fetched in previous step. On success, this API returns the `client_secret`.

Step 3.3: We will store this `client_secret` in database, mapped to a UUID. This UUID acts as an intent ID, allowing us to retrieve the `client_secret` in subsequent steps.

const addBookingIntent = async (clientSecret) => {
  // Alternatively you can call db.write() explicitely later
  // to write to db.json
  const intentId = uuidv4()

  db.data.bookingIntents.push({ id: intentId, clientSecret })
  await db.write()

  return intentId
}

Step 4: Client Displays Payment Form:

After receiving the Payment Intent ID from the previous step, the user is redirected to the payment page at /order/payment/${data?.intentId}.

On the payment page, the client makes a request to the server via the /get-payment-intent API endpoint to retrieve the client_secret using the Payment Intent ID.

Once the client_secret is received, the Elements provider from the react-stripe-js module is initialized. The PaymentElement component is then rendered, displaying the payment form for the user.

// src/pages/order/payment.jsx
// Render block of <PaymentPage ... />

const [clientSecret, setClientSecret] = useState()

useEffect(() => {
  if (clientSecret) return

  // Get the client_secret as soon as the page loads
  fetch(`${import.meta.env.VITE_API_ENDPOINT}/get-payment-intent`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ intentId: params.intentId }),
  })
    .then((res) => res.json())
    .then((data) => setClientSecret(data.clientSecret))
}, [])

...

{!clientSecret ? "Loading" : ""}
{clientSecret && (
    <Elements stripe={stripePromise} options={options}>
      <PaymentForm intentId={params.intentId} />
    </Elements>
)}

...

// src/pages/order/payment.jsx
// Render block of `<PaymentForm ... />` component

return (
    <>
      <h1>Payment details</h1>
      <form onSubmit={handleSubmit}>
        <PaymentElement />

        <button
          disabled={!stripe}
          style={{
            marginTop: "18px",
          }}
        >
          Submit
        </button>
      </form>
      {error}
    </>
  )

Step 5: Customer Finalises Payment:

At this stage, the customer enters their card details or selects a wallet payment option. The client then confirms the PaymentIntent using stripe.confirmPayment(). To securely transmit the payment information collected through the Payment Element to the Stripe API, the Elements instance must be accessed, as it is required to work with the stripe.confirmPayment method.

// `<PaymentForm ... />` component - src/pages/order/payment.jsx
const handleSubmit = async (event) => {
    // We don't want to let default form submission happen here,
    // which would refresh the page.
    event.preventDefault()

    if (!stripe || !elements) {
      // Stripe.js hasn't yet loaded.
      // Make sure to disable form submission until Stripe.js has loaded.
      return
    }

    const result = await stripe.confirmPayment({
      //`Elements` instance that was used to create the Payment Element
      elements,
      confirmParams: {
        return_url: `${import.meta.env.VITE_BASE_URL}/order/status/${intentId}`,
      },
    })

    if (result.error) {
      // Show error to your customer (for example, payment details incomplete)
      setError(result.error.message)
      console.log(result.error.message)
    } else {
      setError("")
      // Your customer will be redirected to your `return_url`. For some payment
      // methods like iDEAL, your customer will be redirected to an intermediate
      // site first to authorize the payment, then redirected to the `return_url`.
    }
  }

  return (
    <>
      <h1>Payment details</h1>
      <form onSubmit={handleSubmit}>
        ...
      </form>
      {error}
    </>
  )

Step 6: Stripe Processes Payment:

Once the customer submits their payment details, Stripe takes over the process. Stripe first verifies the provided payment information and checks if authentication is required.

If Strong Customer Authentication (SCA) is needed (such as 3D Secure for European transactions), Stripe prompts the customer to complete the authentication process. After successful authentication (if required), Stripe attempts to charge the customer’s payment method.

Depending on the result, the payment can either be successful, require further action, or fail due to insufficient funds, incorrect details, or other reasons.

Step 7: Server Verifies Payment Status:

After Stripe processes the payment, it sends a webhook event (payment_intent.succeeded, payment_intent.payment_failed, or payment_intent.requires_action) to the backend server. The server listens for these webhook notifications to confirm the final payment status.

• If the webhook event is payment_intent.succeeded, the server marks the order as paid and updates the database.
• If the event is payment_intent.requires_action, the server notifies the frontend that additional authentication (e.g., 3D Secure) is needed.
• If the event is payment_intent.payment_failed, the server logs the error and provides details on why the payment was unsuccessful.

Note: We haven’t implemented the webhook in our integration. Here, we have sample code from the stripe guide on setting up the webhook.

// This example uses Express to receive webhooks
const express = require('express');
const app = express();

// Match the raw body to content type application/json
// If you are using Express v4 - v4.16 you need to use body-parser, not express, to retrieve the request body
app.post('/webhook', express.json({type: 'application/json'}), (request, response) => {
  const event = request.body;

  // Handle the event
  switch (event.type) {
    case 'payment_intent.succeeded':
      const paymentIntent = event.data.object;
      // Then define and call a method to handle the successful payment intent.
      // handlePaymentIntentSucceeded(paymentIntent);
      break;
    case 'payment_method.attached':
      const paymentMethod = event.data.object;
      // Then define and call a method to handle the successful attachment of a PaymentMethod.
      // handlePaymentMethodAttached(paymentMethod);
      break;
    // ... handle other event types
    default:
      console.log(`Unhandled event type ${event.type}`);
  }

  // Return a response to acknowledge receipt of the event
  response.json({received: true});
});

app.listen(4242, () => console.log('Running on port 4242'));

Step 8: Client Updates Customer:

Once the server processes the webhook event, it sends the final payment status back to the client (frontend). The frontend updates the UI accordingly:

• If the payment was successful, the customer sees a confirmation message and may be redirected to a success page.
• If additional action is required (e.g., authentication), the frontend prompts the customer to complete it.
• If the payment fails, the UI displays an error message with options to retry or use a different payment method.

Verify the transaction on Dashboard

Here’s the transaction list from the Stripe Dashboard, showcasing two different payment methods — one processed using the PayNow Wallet and the other using a Card.

Conclusion

In this post, we broke down the implementation of Stripe PaymentElement by walking through the key integration steps on both the client and server sides. We explored how PaymentIntents are created and managed, how to securely handle payment details, and how Stripe dynamically offers supported payment methods to users.

By understanding this integration, you now have a solid foundation for implementing a seamless and secure payment flow in your own application. Whether you’re handling card payments, wallets, or local payment methods, Stripe’s PaymentElement provides a flexible and user-friendly solution to optimize your checkout experience.

If you’re looking to extend this setup, consider exploring subscription billing, advanced fraud prevention, or post-payment actions to further enhance your Stripe integration. 🚀

Stripe provides a powerful and flexible payment processing system, but choosing the right integration approach can sometimes feel overwhelming. In this post, we’ll break down the key concepts of Stripe’s payment system, walk through the payment flow diagram, and explain the process of setting up a Stripe account and enabling wallet payments to improve the checkout experience.

Stripe payment processing system is a vast topic which provides every possible solution related to payments. It won’t be possible to cover everything in these two blog posts. So we are limiting our scope to some foundation concepts and an integration guide with a common use-case.

Introduction

In this post, we’ll explore how to identify right payment method for your need with brief overview of the available payment integration options, followed by an in-depth look at the Stripe payment flow for PaymentElement and integration steps with short description.

By the end of this guide, you’ll have a overall understanding of how Stripe’s PaymentElement works and be ready to move on to the implementation phase. In next post, we’ll look into the implementation steps based on flow diagram discussed in this post.

Choosing the Right Stripe Payment Integration

Stripe provides a range of payment integration options designed to meet different business needs, which can sometimes make choosing the right approach feel overwhelming. The first step in the integration process is to define the currencies and countries you want to support.

Once that’s decided, Stripe’s documentation offers detailed tables to help you identify the available payment methods for each region. Based on your requirement, If you’re looking to integrate PaymentElement for a seamless checkout experience, this guide will walk you through everything you need to know.

Payment Integration Options

Let’s look at each payment methods and its use cases.

Payment Links

If you’re looking for a simple way to accept payments without building a separate website or application, Stripe Payment Links can be a great option.

They allow you to create a shareable link that customers can use to make payments or subscribe to services. You can distribute these links across multiple channels, including social media, emails, or directly on your website, making it a flexible and hassle-free payment solution.

Checkout

Checkout provides a low-code payment integration with a customizable payment form. You can embed it directly on your website, redirect users to a Stripe-hosted payment page, or create a tailored checkout experience using Stripe Elements. It supports both one-time payments and subscriptions while offering over 40 local payment methods.

Billing (Subscription)

Billing simplifies subscription management and invoicing. It automates recurring payments, enables custom pricing plans, and manages billing cycles, including trials and renewals — making it ideal for businesses offering subscription-based services.

Invoicing

Invoicing allows you to quickly create and send professional invoices without writing any code. You can generate invoices directly from the Stripe Dashboard or use the Invoicing API to automate payment collection and reconciliation.

Payment Element

The Payment Element is a web-based UI component that supports over 40 payment methods, handles input validation, and manages errors seamlessly. It can be used on its own or combined with other elements in your web app’s frontend for a smooth checkout experience.

Since we will be implementing the custom flow, we will be using the Payment Intents API. It is essential for handling dynamic payment flows. It tracks the entire payment lifecycle — from creation to checkout — and ensures compliance with authentication requirements, such as Strong Customer Authentication (SCA), when necessary.

Key concepts

1. PaymentIntent
   A PaymentIntent represents a single transaction attempt, managing the entire payment lifecycle. It supports authentication, handles required actions, and ensures compliance with Strong Customer Authentication (SCA).
2. PaymentElement
   The PaymentElement is a prebuilt UI component that allows users to enter payment details securely. It supports over 40+ payment methods, dynamically adjusting based on the customer’s location and selected currency.
3. Client Secret
   The client_secret is a unique key generated when creating a PaymentIntent. It is passed securely to the frontend to confirm and finalize the payment using stripe.confirmPayment().
4. Webhook Events
   Stripe sends webhook events to notify the server about important payment updates, such as success, failure, or disputes. This allows the backend to react accordingly, such as updating order status or triggering email notifications.
5. Wallet Payments
   Apple Pay, Google Pay, and Link are digital wallets that allow users to pay with saved cards for a frictionless checkout experience. Enabling these methods can significantly improve conversion rates, especially on mobile devices.
6. Dynamic Payment Method Display
   Stripe automatically shows or hides payment methods based on the user’s location, currency, and device. This ensures that customers only see payment options that are relevant and supported for their region.
7. 3D Secure Authentication (SCA)
   Some transactions require Strong Customer Authentication (SCA) under regulations like PSD2 in Europe. Stripe automatically handles 3D Secure (3DS) authentication by prompting users to verify their identity through OTP or biometric verification.
8. Test and Live Modes
   Stripe provides two environments: 1) Test mode allows developers to simulate transactions using test cards without real charges. 2) Live mode processes actual payments with real customer data.
9. Refunds and Disputes
   Merchants can issue full or partial refunds directly from the Stripe Dashboard or API. If a customer disputes a charge, Stripe provides tools to submit evidence and manage chargebacks effectively.
10. Customer Object
    The Customer Object helps businesses store user details, including saved payment methods, billing information, and past transactions. This is useful for recurring payments and personalized user experiences.
11. Fraud Prevention (Radar)
    Stripe Radar is a built-in fraud detection system that automatically analyzes transactions, detecting fraudulent patterns and reducing chargeback risks.
12. Payment Statuses
    Stripe categorizes payment statuses into:

• Succeeded: Payment was processed successfully.
• Requires Action: Additional authentication (like 3D Secure) is needed.
• Failed: Payment was declined or unsuccessful.

Some of the concepts are not used in our blog posts. However, we still have covered those in this list.

How Custom Payment works?

Now, we have overall idea about the key concepts and payment methods, let’s see how custom payment works with Stripe.

The diagram illustrates the flow of a payment using Stripe’s PaymentIntent API, involving four key participants: Customer, Client, Server, and Stripe.

Here’s a concise explanation of each step in the client-server interaction for creating a PaymentIntent before collecting payment details:

1. Customer Initiates Payment: The customer selects a product and navigates to the payment page.

2. Client Sends Order Details to Server: The client sends product details (e.g., product ID, quantity) to the server via an API request.

3. Server Creates PaymentIntent: The server creates a PaymentIntent using Stripe’s API and returns the `client_secret` to the client.

Payment Intents API is essential for handling dynamic payment flows. It tracks the entire payment lifecycle — from creation to checkout — and ensures compliance with authentication requirements, such as Strong Customer Authentication (SCA), when necessary.

4. Client Displays Payment Form: The client uses Stripe’s PaymentElement to display a form for entering payment details.

5. Customer Finalises Payment: The customer submits payment details, and the client confirms the PaymentIntent using `stripe.confirmPayment()`.

6. Stripe Processes Payment: Stripe processes the payment, handles authentication, and attempts to charge the customer.

7. Server Verifies Payment Status: The server receives a webhook from Stripe with the payment status (e.g., success or failure).

8. Client Updates Customer: The client notifies the customer of the payment status, such as success or retry options.

Setting up Stripe Account and Payment Methods

Create an Account on Stripe

You can first start with creating an account on Stripe. It will ask for Business and back related information. However, all the information is not required in case you are running the Test Mode.

Enable Payment methods

To configure payment methods, visit the Payment Methods section in the Stripe Dashboard. Here, you’ll find a list of available payment options — some, like cards and commonly used methods, are enabled by default.

Even if multiple payment methods are enabled, Stripe intelligently determines the available options based on the customer’s currency, location, and any applicable restrictions. This dynamic offering helps improve conversion rates. For example, Apple Pay won’t appear for customers in India, while GrabPay is only available in Singapore and Malaysia.

Conclusion

In this post, we explored the key concepts of Stripe’s payment system, walked through the payment flow diagram, and covered the steps to create a Stripe account and enable wallet payments for a seamless checkout experience. Understanding these fundamentals is crucial before diving into the actual implementation.

In the next post — Understanding Stripe Payment Integration — A Breakdown of the Implementation | Part 2, we’ll take this knowledge and walk through the step-by-step integration of Stripe’s PaymentElement. Using the flow diagram discussed here, we’ll set up both the client-side and server-side to securely handle payments and complete transactions.

Getting started with web app development can often feel overwhelming, especially when tackling the challenge of setting up a solid project structure. This guide aims to simplify the process by helping you create a foundational setup for web applications, enabling you to build with ease and minimal effort.

What We’ll Cover

1. Prerequisites
2. Front-end Setup
3. Back-end Setup
4. Integrating Front-end with Back-end

1. Prerequisites

In this guide, we’ll build a web app named “starter-online-store” using the following tech stack:

• Build tool: Vite — A fast and modern build tool that helps you quickly set up and develop web projects.
• Front-end: ReactJS — A popular JavaScript library for building user interfaces, especially for single-page applications.
• Back-end: ExpressJS — A minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

2. Front-end Setup

In this section, we will set up the front-end of our web app by creating a React application using Vite. This will provide us with a fast and efficient development environment to build our user interface.

Step 1: Create a React Project with Vite

Ensure you have Node.js (v18+ or v20+) installed. Then, use the following command to scaffold a React project with Vite:

npm create vite@latest starter-online-store -- --template react

Follow the prompts during installation. After the setup, run these commands to initialize the project:

cd stripe-client-app
npm install
npm run dev

Upon successful setup, your terminal will display a local development URL (e.g., localhost:5173). Visit this URL to view your project.

Step 2: Install Additional Dependencies

To enhance your React app, install the following modules:

2.1. Error Handling

Install the react-error-boundary library for handling errors:

npm install react-error-boundary

Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed.

Wrap your <App /> component with the <ErrorBoundary> component in src/main.jsx:

...
createRoot(document.getElementById("root")).render(
  <StrictMode>
    <ErrorBoundary>
      <App />
    </ErrorBoundary>
  </StrictMode>
)

2.2. Routing

Install react-router-dom for handling routing in your app:

npm install react-router-dom

This library enables you to match URLs to components and navigate between pages.

Step 3: Add a Sample Product to the Home Page

3.1. Create a Page Component

Add a pages folder in the src directory and create a file named home.jsx.

Add the following content in home.jsx which we created in last step.

const Home = () => {
  const handleSubmit = async (event) => {
    event.preventDefault()

    console.log("Handle Buy Now click")
  }

  return (
      <div className="product-container">
        <h2>Wireless Headphones</h2>
        <img
          src="wireless-headphone.webp"  // Place this file in {YOUR_PROJECT}/public/ folder
          alt="Light house"
          className="product-image"
        />
        <p>
          High-quality wireless headphones with noise cancellation and 20-hour
          battery life.
        </p>
        <div className="product-price-cta">
          <p style={{ fontSize: "24px" }}>$19.99</p>

          <button onClick={handleSubmit}>Buy Now</button>
        </div>
      </div>
  )
}

export { Home }

3.2. Update Your App.jsx File

Replace the content of src/App.jsx with:

import { Route, Routes } from "react-router-dom"
import { Home } from "./pages/home"

import "./App.css"

const routes = [
  {
    path: "/",
    element: <Home />,
  },
]

function App() {
  return (
    <Routes>
      {routes.map(({ path, element }, index) => (
        <Route path={path} element={element} key={index} />
      ))}
    </Routes>
  )
}

export default App

You can directly use this GitHub project to get started!

Back-end Setup

Our backend will use Express.js, a minimalist web framework for Node.js. It provides a robust set of features for building web and mobile applications efficiently.

Step 1: Initialize the Node.js Project and Install Dependencies

1. Navigate to your project folder in the terminal.

2. Initialize the project by running the following command:

npm init

Follow the prompts to configure your package.json file.

3. Install the Express.js framework:

npm install express --save

Step 2: Configure ES Module Support

To use modern ES Modules instead of the older CommonJS syntax, you need to update the package.json file by adding "type": "module". This change allows you to use the latest JavaScript module features, which are more efficient and easier to manage.

Additionally, you should add "start-server": "node index.js" under the "scripts" section. This script provides a convenient way to start your server with a simple command, making it easier to run and manage your application.

{
  "name": "online-store-server",
  ...
  "type": "module",
  ...
  "scripts": {
    "start-server": "node index.js"
  }
}

Step 3: Create the Server

1. At the root level of your project folder, create a new file named index.js.
2. Add the following code to set up a basic Express server:

import express from "express";

const app = express();

app.get("/", (req, res) => {
  res.send("Hello World!");
});

app.listen(4242, () => {
  console.log(`Example app listening on port 4242`);
});

Step 4: Install Additional Dependencies

We’ll also install two essential modules for future use. Open terminal and install following two modules.

1. cors: Middleware for enabling Cross-Origin Resource Sharing.

npm install cors

2. dotenv: Utility to load environment variables from a .env file into process.env.

npm install dotenv

Step 5: Update the Server File

Now, let’s update the server.js file to include the newly installed modules. Here’s the revised content:

import express from "express";
import "dotenv/config";
import cors from "cors";

const app = express();

// Enable CORS
app.use(cors());

// Define a sample route
app.get("/", (req, res) => {
  res.send("Hello World!");
});

// Start the server
app.listen(4242, () => {
  console.log(`Server is running on http://localhost:4242`);
});

Step 6: Start the Server

Run the following command to start your server:

npm run start-server

You should see the server running successfully. Open your browser and visit localhost:4242. You should see the “ Hello World!” message displayed.

Integrating Front-End with Back-End: Fetching Product Details

Now that we have our front-end and back-end set up, let’s take the next step: connecting the two. We will create an API endpoint on the server to return product details and fetch this data from the front-end to display it dynamically.

Step 1: Create an API Endpoint on the Server

1. Open the index.js file in your back-end project.
2. Add a new route that returns product details. Update the file as follows:

 import express from "express";
 import "dotenv/config";
 import cors from "cors";

 const app = express();

 // Enable CORS
 app.use(cors());

 // Product data
 const products = [
   {
     id: 1,
     name: "Wireless Headphones",
     description: "High-quality wireless headphones with noise cancellation and 20-hour battery life.",
     price: 99.99,
     image: "/wireless-headphone.webp", // Place this image in the public folder of your FE project
   },
 ];

 // API endpoint to fetch product details
 app.get("/api/products", (req, res) => {
   res.json(products);
 });

 // Sample route
 app.get("/", (req, res) => {
   res.send("Hello World!");
 });

 // Start the server
 app.listen(4242, () => {
   console.log(`Server is running on http://localhost:4242`);
 });

This endpoint (/api/products) will return a JSON response containing the product data.

Step 2: Update the Front-End to Consume the API

1. Open the src/pages/home.jsx file in your front-end project.
2. Replace the hardcoded product data with an API call to fetch the product details. Update the file as follows:

 import { useEffect, useState } from "react";

 const Home = () => {
   const [product, setProduct] = useState(null);

   useEffect(() => {
     const fetchProduct = async () => {
       try {
         const response = await fetch("http://localhost:4242/api/products");
         const data = await response.json();
         setProduct(data[0]); // Assuming one product for simplicity
       } catch (error) {
         console.error("Error fetching product data:", error);
       }
     };

     fetchProduct();
   }, []);

   const handleSubmit = (event) => {
     event.preventDefault();
     console.log("Handle Buy Now click");
   };

   return (
     <div className="product-container">
       {product ? (
         <>
           <h2>{product.name}</h2>
           <img
             src={product.image}
             alt={product.name}
             className="product-image"
           />
           <p>{product.description}</p>
           <div className="product-price-cta">
             <p style={{ fontSize: "24px" }}>${product.price}</p>
             <button onClick={handleSubmit}>Buy Now</button>
           </div>
         </>
       ) : (
         <p>Loading product details...</p>
       )}
     </div>
   );
 };

 export { Home };

Step 3: Test the Integration

1. Re-start your back-end server:
Press ^ C on Mac / Ctrl + C on Windows, then run following command:

npm run start-server

2. Open your browser and navigate to http://localhost:5173. You should see the product details dynamically fetched from the back-end and displayed on the front-end.

By following this integration, you’ve connected your front-end with your back-end, enabling your application to fetch and display dynamic content. This approach can be extended to handle more complex data flows and API integrations in the future.

Conclusion

In this article, we’ve built a solid foundation for developing a full-stack web application by setting up the front-end and back-end from scratch. We started with a modern front-end stack using React and Vite, ensuring a fast and efficient development experience. On the back-end, we leveraged Express.js to create a lightweight and scalable server, integrating essential modules like cors and dotenv to handle cross-origin requests and environment configurations seamlessly.

Originally published at https://web-lab.hashnode.dev on January 16, 2025.