Forem: Kedar Kulkarni

Stop Burning Money: How Smarter Angular Code Slashes Your Server Bills

Kedar Kulkarni — Tue, 27 Jan 2026 16:08:46 +0000

Most developers think "server costs" are a backend problem. But the truth is, your Frontend is the remote control for your cloud invoice. If your frontend is "dumb," it forces your server to work overtime.

For companies scaling to millions of users, "lazy" frontend habits can result in server bills that are 5x to 10x higher than they need to be. Here is how optimizing your Angular app can save you thousands of dollars, explained in plain English.

1. Stop Paying for "Waiters" (Static Hosting)

Imagine hiring a waiter to stand by a table 24/7, even when no one is there. That’s what it's like when you serve Angular through a Node.js or Java server.

The Fix: Build your app as "Static Files" (ng build) and host them on S3 + CloudFront, Vercel, or Netlify.
Why it saves money: A virtual server (like EC2) costs roughly ₹2,500/mo just to stay "on." Static hosting costs about ₹50/mo because you only pay for storage and actual traffic.
Pro Tip: If you don't need SEO-heavy pages, avoid SSR (Server Side Rendering). Every SSR request burns server CPU/RAM; Static files burn nothing.

2. The "Ask Once" Rule (API Caching)

If you need a list of users for five different parts of a page, don't ask the server five times.

The Fix: Use the RxJS shareReplay(1) operator in your services.
Why it saves money: Every API hit burns backend compute. Multicasting your data can reduce your backend requests by 60–80%, allowing you to serve more users without upgrading your server.

3. Don't Be a "Stuttering" Search (Debouncing)

If a user types "iPhone" in a search bar, a bad app sends 6 separate requests to your database (i, iP, iPh...).

The Fix: Use debounceTime(400). Wait for the user to stop typing before hitting the API.
Why it saves money: It reduces Database load by up to 90%. This keeps you on a "Basic" database plan instead of forced upgrades to "Enterprise" IOPS tiers.

4. Smart Loading (Lazy Loading & @defer)

Why load the "Admin Dashboard" code for a customer who just wants to see their landing page?

The Fix: Use loadChildren for routes and the new @defer blocks for template-level lazy loading.
Why it saves money: Cloud providers charge for "Egress" (data sent out). Smaller bundles = lower bandwidth fees.

5. The "Offline Store" Strategy (PWA)

In a standard app, every refresh re-downloads the same logos, fonts, and core files.

The Fix: Run ng add @angular/pwa.
Why it saves money: Service Workers store your app shell on the user's device. For a large app, this saves 40–60% on bandwidth because the user's device "hosts" the heavy UI files locally.

6. "Micro-Surgery" for Large Apps (Micro-Frontends)

In giant enterprise apps, a 1-line change often requires re-building and re-deploying a 20MB application.

The Fix: Use Module Federation to break the app into independent Micro-Frontends (MFE).
Why it saves money: You only run CI/CD builds for the specific module that changed. This slashes your "Build Minute" costs on platforms like GitHub Actions or CircleCI.

7. Signals: The "Energy Efficient" Lightbulb

Standard Angular checks your entire app tree for changes every time you click. Signals only update the exact spot that changed.

The Fix: Migrate from traditional variables to Angular Signals.
Why it saves money: Lower CPU usage. In professional VDI or "Cloud Desktop" environments, this reduces the infrastructure footprint needed to host users.

💰 The Financial Impact: At a Glance

User Base	"Dumb" Angular Bill	"Smart" Angular Bill	Savings
Small (1k users)	₹5,000 / mo	₹200 / mo	96%
Medium (50k users)	₹50,000 / mo	₹8,000 / mo	84%
Enterprise (1M+)	₹5,00,000+ / mo	₹1,00,000 / mo	₹4 Lakhs/mo

The Bottom Line

A "cheap" server bill starts with high-quality code. By making your Angular app smarter, you stop treating your backend like a 24/7 punching bag.

What’s your favorite way to save on cloud costs? Let's discuss in the comments! 👇

Complete Guide to ADA Compliance in Angular Applications

Kedar Kulkarni — Sat, 12 Jul 2025 04:07:39 +0000

In today’s digital-first world, accessibility is no longer optional—it’s essential. Whether you're building a sleek startup UI or a government web app, your Angular project must cater to everyone, including people with disabilities. This blog is your one-stop guide to achieving ADA compliance in Angular—from strategy to implementation.

🚀 Why Accessibility Matters in Angular

The Americans with Disabilities Act (ADA) mandates digital accessibility as part of equal access. Accessibility ensures that users with visual, auditory, cognitive, or motor impairments can effectively use your application.

Angular, as a dynamic Single Page Application (SPA) framework, adds complexity—rendering content client-side, which can break assistive technologies like screen readers.

If you're developing with Angular, this guide will help you:

Understand what ADA compliance means
Identify accessibility issues in Angular SPAs
Fix common UI problems using real-world practices
Test and maintain accessible code at scale

📚 Understanding ADA, WCAG, and Angular

🌐 What is ADA Compliance?

The ADA prohibits discrimination against individuals with disabilities in public spaces—this now includes web applications. This is enforced through adherence to WCAG (Web Content Accessibility Guidelines), which defines standards like:

Perceivable: Content must be available to the senses
Operable: Users can interact with it using keyboards and assistive tech
Understandable: Content and UI are easy to follow
Robust: Compatible with future tools and tech

🧠 How Angular Fits Into Accessibility

Angular’s SPA behavior means content changes without full page reloads. While great for performance, this can trip up screen readers and keyboard users.

Key Angular challenges:

Missing focus management during route changes
Improper or missing ARIA roles
Custom components with no keyboard support
Dynamic updates that are not announced

Fortunately, Angular has tools like Angular CDK’s a11y package and Angular Material, which include built-in accessibility support.

🕵️‍♂️ Identifying Accessibility Issues in Angular Apps

Here’s how to evaluate your app’s accessibility status:

🔧 Automated Tools

axe-core (browser extension / CLI)
Google Lighthouse (built into Chrome DevTools)
WAVE Tool (web-based or extension)
Pa11y (perfect for CI/CD)

👀 Manual Testing

Use screen readers (VoiceOver, NVDA, JAWS)
Navigate with only a keyboard (Tab, Enter, Arrow keys)
Use high-contrast mode
Zoom in to 200% and verify layout

🔥 Common Angular Accessibility Pitfalls

1. Focus Management Failures

After route transitions, users using screen readers may get lost. Fix it using a service:

@Injectable()
export class FocusManager {
  focusMainHeading() {
    const h1 = document.querySelector('h1');
    if (h1) (h1 as HTMLElement).focus();
  }
}

Call this after navigation.

2. Dynamic Content Not Announced

Use aria-live regions to inform screen readers:

<div aria-live="polite" aria-atomic="true" class="sr-only">
  {{ statusMessage }}
</div>

3. Custom Components Missing Labels

✅ Use aria-label or aria-labelledby:

<input type="text" aria-label="Search query" />

<label id="name-label">Name</label>
<input type="text" aria-labelledby="name-label" />

4. Missing Keyboard Support

Ensure buttons, toggles, and modals can be accessed via Tab and activated via Enter/Space:

@HostListener('keydown', ['$event'])
onKeyDown(event: KeyboardEvent) {
  if (event.key === 'Enter' || event.key === ' ') {
    this.onClick();
    event.preventDefault();
  }
}

5. Color Contrast Issues

WCAG requires a contrast ratio of:

4.5:1 for normal text
3:1 for large text

Use WebAIM contrast checker to validate your theme.

🧰 Tools & Libraries for Angular Accessibility

✅ Angular CDK a11y: Focus trapping, live announcers, overlays
🎨 Angular Material: Accessible components (but still test them!)
🛠️ Codelyzer + TSLint: Add accessibility rules
🧪 axe-core Angular Integration: Run a11y tests programmatically

🧪 Real Angular Accessibility Failures (Case Studies)

🔎 Case 1: E-Commerce Filter Inaccessibility

Problem: Custom checkboxes with no ARIA roles

Fix: Added semantic markup + live region updates

🔎 Case 2: Government Services Portal

Problem: Incomplete forms using keyboard, missing skip links
Fix: Added semantic HTML + skip navigation + ARIA
📄 Result: Passed WCAG 2.1 AA audit

🔎 Case 3: Online Learning Platform Lawsuit

Problem: No captions, no labels, no keyboard escape
Fix: Full remediation with CI-integrated a11y tests
✅ Result: Legal risk mitigated + better UX

🧑‍💻 Accessibility Best Practices in Angular

💡 Design Phase

Create personas that include users with disabilities
Use accessible color palettes from the start
Test wireframes with keyboard and screen reader users

🛠️ Development Phase

✅ Semantic HTML First

Use <button>, <nav>, <header>, <form> instead of divs.

✅ ARIA Attributes

Use only when HTML can’t express behavior. Example:

<button
  [attr.aria-label]="isOpen ? 'Collapse menu' : 'Expand menu'"
  [attr.aria-expanded]="isOpen"
  (click)="toggleMenu()"
>
  Menu
</button>

✅ Keyboard Navigation

All interactive components should:

Be focusable (tabindex="0")
Respond to Enter or Space
Maintain logical tab order

🧪 Testing & Maintenance

Run axe-core or pa11y after each deploy
Include test:a11y in your package.json:

{
  "scripts": {
    "test:a11y": "ng test && pa11y http://localhost:4200",
    "lint:a11y": "ng lint --fix"
  }
}

Train your dev team to use screen readers
Document accessibility rules in your internal UI guidelines

🏁 Conclusion

ADA compliance in Angular is not just about checking boxes—it’s about building web apps that welcome everyone.

With Angular’s tools, WCAG guidance, and proactive testing, you can ship products that are usable, ethical, and inclusive.

🌎 Accessibility is a journey, not a one-time fix. Start today, improve continuously.

📚 Additional Resources

I’ve developed a custom ADA-compliant Angular documentation site - https://ada-compliance.vercel.app/, feel free to explore it.

⚙️ ARIA for Developers – Roles, States, and Accessible Components in React

Kedar Kulkarni — Sat, 12 Jul 2025 04:05:08 +0000

In the first two parts of this series, we covered the fundamentals of accessibility and how to fix common issues like missing labels, bad contrast, and incorrect heading structure. Now, let’s dive deeper into ARIA (Accessible Rich Internet Applications) and how to use it with React to build dynamic and accessible web interfaces.

🔎 What Is ARIA?

WAI-ARIA is a W3C specification designed to enhance the accessibility of custom web components and dynamic content. When native HTML elements fall short—like custom dropdowns, modals, sliders, or toggles—ARIA roles and attributes bridge the gap by communicating additional semantics to assistive technologies.

⚠️ Before You Use ARIA…

🧠 “If you can use a native HTML element with the built-in behavior you need—use that instead of ARIA.”

Native elements like <button>, <input>, <nav>, and <form> already have accessibility features. Only use ARIA if there's no semantic HTML alternative.

🔧 ARIA Core Concepts

Feature	Description
Role	Defines what the element is (e.g., `button`, `dialog`)
State	Describes current conditions (e.g., `aria-expanded="true"`)
Property	Provides extra context (e.g., `aria-labelledby="title"`)

Let’s see how to apply these in a real-world project using React.

🧪 React + ARIA: Practical Examples

1️⃣ Toggle Button (Accessible Switch)

Here’s how to create a keyboard-operable toggle switch using ARIA.

import { useState } from "react"

function ToggleButton() {
  const [isOn, setIsOn] = useState(false)

  return (
    <div
      role="switch"
      aria-checked={isOn}
      tabIndex={0}
      onClick={() => setIsOn(!isOn)}
      onKeyDown={(e) => {
        if (e.key === "Enter" || e.key === " ") {
          e.preventDefault()
          setIsOn(!isOn)
        }
      }}
      style={{
        display: 'inline-block',
        padding: '10px 20px',
        background: isOn ? '#4caf50' : '#ccc',
        borderRadius: '20px',
        cursor: 'pointer',
        userSelect: 'none'
      }}
    >
      {isOn ? "ON" : "OFF"}
    </div>
  )
}

🧠 ARIA Highlights:

role="switch" tells screen readers it’s a toggle.
aria-checked indicates current state.
tabIndex={0} makes the element focusable.
Arrow keys or spacebar trigger the toggle.

2️⃣ Custom Dropdown with Keyboard Support

import { useState, useRef, useEffect } from "react"

const options = ["Apple", "Banana", "Cherry"]

function Dropdown() {
  const [isOpen, setIsOpen] = useState(false)
  const [selected, setSelected] = useState(null)
  const [highlightedIndex, setHighlightedIndex] = useState(0)
  const dropdownRef = useRef(null)

  useEffect(() => {
    if (isOpen && dropdownRef.current) dropdownRef.current.focus()
  }, [isOpen])

  const handleKeyDown = (e) => {
    if (!isOpen && (e.key === "Enter" || e.key === " ")) {
      e.preventDefault()
      setIsOpen(true)
      return
    }

    if (isOpen) {
      switch (e.key) {
        case "ArrowDown":
          e.preventDefault()
          setHighlightedIndex((i) => (i + 1) % options.length)
          break
        case "ArrowUp":
          e.preventDefault()
          setHighlightedIndex((i) => (i - 1 + options.length) % options.length)
          break
        case "Enter":
          e.preventDefault()
          setSelected(options[highlightedIndex])
          setIsOpen(false)
          break
        case "Escape":
          setIsOpen(false)
          break
      }
    }
  }

  return (
    <div>
      <div
        role="button"
        aria-haspopup="listbox"
        aria-expanded={isOpen}
        aria-controls="dropdown-list"
        tabIndex={0}
        onClick={() => setIsOpen((o) => !o)}
        onKeyDown={handleKeyDown}
        style={{
          padding: "10px",
          background: "#eee",
          border: "1px solid #ccc",
          width: "200px",
          cursor: "pointer",
        }}
      >
        {selected || "Select an option"}
      </div>

      {isOpen && (
        <ul
          id="dropdown-list"
          role="listbox"
          ref={dropdownRef}
          tabIndex={-1}
          style={{
            listStyle: "none",
            margin: 0,
            padding: 0,
            border: "1px solid #ccc",
            background: "white",
          }}
        >
          {options.map((opt, i) => (
            <li
              key={opt}
              role="option"
              aria-selected={highlightedIndex === i}
              onClick={() => {
                setSelected(opt)
                setIsOpen(false)
              }}
              style={{
                padding: "10px",
                background: highlightedIndex === i ? "#007bff" : "white",
                color: highlightedIndex === i ? "white" : "black",
              }}
            >
              {opt}
            </li>
          ))}
        </ul>
      )}
    </div>
  )
}

ARIA Usage:

role="button": Declares the trigger element
aria-expanded: Shows whether dropdown is open
aria-haspopup="listbox": Identifies a related popup
role="listbox" & role="option": Define the dropdown structure

3️⃣ Accessible Labeling: `aria-label` & `aria-labelledby`

Sometimes visible labels aren’t possible. ARIA attributes help provide accessible names.

`aria-label` (Custom label directly on the element):

<input type="text" aria-label="First name" />

`aria-labelledby` (Reference another element's `id`):

<span id="label1">Username</span>
<input type="text" aria-labelledby="label1" />

🔒 ARIA Do’s and Don’ts

✅ Do This	❌ Don’t Do This
Use semantic HTML if available	Replace native elements with divs + ARIA
Make ARIA widgets keyboard-accessible	Ignore focus/keyboard behavior
Test with screen readers & WAVE	Assume ARIA works out-of-the-box
Use `aria-hidden="true"` sparingly	Apply it to interactive or focusable elements

🧠 Key ARIA Roles You Should Know

Role	Use Case
`button`	Interactive element
`dialog`	Modal popup
`tab`, `tabpanel`	Tab interfaces
`listbox` / `option`	Dropdowns or selections
`alert`	Announce important changes

🧩 Full list: ARIA Roles Overview – MDN

📋 Summary: Building Accessible Components with ARIA

Topic	Key Point
Use ARIA selectively	Prefer native elements when possible
Labeling matters	Use `aria-label` or `aria-labelledby` to name elements
Manage state	Use `aria-expanded`, `aria-checked`, etc. to reflect status
Support keyboards	Always provide `tabIndex` and `onKeyDown` handlers
Validate early	Test with WAVE, NVDA, VoiceOver

🛠️ Fixing Common Accessibility Issues – Alt Text, Contrast, Headings & Forms

Kedar Kulkarni — Sat, 12 Jul 2025 04:03:30 +0000

In Part 1, we explored the basics of accessibility and how to create a solid semantic HTML foundation. Now, let’s move forward by identifying and fixing the most common accessibility problems that appear on real-world websites.

These small fixes can drastically improve usability and compliance with WCAG Level A and AA standards.

🖼️ 1. Missing or Inaccurate Alt Text for Images

Images must include meaningful alternative text (alt) to describe their purpose to screen readers and assistive tools.

❌ Common Problems

Missing alt attribute
Decorative images without alt=""
Redundant alt text (e.g., same as caption or nearby text)

✅ Best Practices

Describe the function of the image, not the appearance.
If an image is purely decorative, use alt="" to hide it from screen readers.
Don't duplicate nearby content.

🧪 Example

<!-- Bad: missing alt -->
<img src="search-icon.png">

<!-- Good: functional alt -->
<img src="search-icon.png" alt="Search">

<!-- Decorative image -->
<img src="divider.png" alt="">

🛠️ Tool Tip: Use WAVE to detect missing or redundant alt text.

🎨 2. Poor Color Contrast

Low contrast between text and background colors makes content unreadable for users with visual impairments or color blindness.

❌ Common Issue

Text blends into the background due to insufficient contrast.

✅ Fix It

Ensure a contrast ratio of at least 4.5:1 for normal text, and 3:1 for large text.

🔧 Example

/* Too light */
color: #cccccc;
background: #ffffff;

/* Better */
color: #333333;
background: #ffffff;

Use the WAVE contrast checker or WebAIM contrast tool to validate.

🧩 3. Improper Heading Structure

Headings help screen reader users understand the page structure and quickly navigate between sections.

❌ Common Mistakes

Skipping heading levels (e.g., <h1> → <h3>)
Using headings for styling only
Missing <h1> altogether

✅ Best Practices

Use only one <h1> per page, usually as the page title.
Maintain a logical hierarchy: <h1> → <h2> → <h3>, and so on.
Don’t skip levels.

🧪 Example

<!-- Correct order -->
<h1>Page Title</h1>
  <h2>Section 1</h2>
    <h3>Sub-section</h3>

<!-- Skipped order (bad) -->
<h1>Page Title</h1>
  <h3>Sub-section</h3> <!-- Skipped h2 -->

🧠 Use the WAVE tool to view the heading outline visually and fix skipped levels.

📝 4. Form Inputs Without Labels

Unlabeled form controls are unusable with screen readers and keyboard navigation. Screen readers rely on label associations to describe the purpose of each input field.

❌ Issues

No <label> element
Only placeholder used (not accessible)
Labels are not correctly associated

✅ Fix It

There are two valid ways to associate labels:

Using for and id
Wrapping input inside the <label>

🧪 Examples

<!-- Good with for/id -->
<label for="email">Email:</label>
<input id="email" type="email" name="email">

<!-- Good with wrapping -->
<label>
  Email:
  <input type="email" name="email">
</label>

<!-- Using ARIA -->
<input type="email" aria-label="Enter your email">

❗ Don’t rely only on placeholder — it disappears after input and is not read consistently by assistive tools.

🔍 5. Keyboard Navigation Failures

Many users rely on keyboards (not mice) to interact with websites. All interactive elements must be reachable via the Tab key and should show a visible focus state.

✅ Keyboard Navigation Checklist:

Can you tab to links, buttons, form fields, and controls?
Does each element show a visual outline when focused?
Can you tab out of all interactive elements? (No “keyboard traps”)

🧪 Test it:

Open your site
Hit Tab repeatedly
Observe what gets focus and in what order

🛠️ Use tabindex="0" on custom elements to include them in the natural tab flow.

🧾 Summary Checklist

✅ Fix	Description
Alt Text	Add meaningful `alt` for functional images, `alt=""` for decorative
Contrast	Maintain minimum contrast ratio (4.5:1 for normal text)
Headings	Use semantic headings in correct order; don’t skip levels
Labels	Associate each input with a visible or accessible label
Keyboard	Make sure all functionality works via keyboard only

🔄 Coming Up: Building Accessible Widgets with ARIA in React (Blog 3)

Next, we’ll explore ARIA roles, states, and properties to build accessible custom components like dropdowns, modals, and toggle buttons — especially in React apps.

✨ A Beginner's Guide to Web Accessibility – WCAG, Easy Checks & Semantic HTML

Kedar Kulkarni — Sat, 12 Jul 2025 04:02:03 +0000

Creating inclusive digital experiences means building websites that work for everyone, including individuals with physical, sensory, or cognitive impairments. Web accessibility isn’t just an option—it’s a foundational principle of good design. This post marks the beginning of a three-part series designed to help developers build accessible websites from the ground up.

🌐 What Is Web Accessibility?

Web accessibility ensures that digital products can be understood, navigated, and interacted with by users who have diverse abilities. This includes people who:

Are blind or have low vision
Are deaf or hard of hearing
Use assistive technologies (e.g., screen readers, keyboard-only navigation)
Experience cognitive or neurological conditions

By making our websites more accessible, we also improve usability for all users—not just those with disabilities.

📘 WCAG Compliance Levels Explained

The Web Content Accessibility Guidelines (WCAG) provide a structured approach to making web content accessible. These standards define three levels of conformance:

Level	Description	Who Benefits
A	Basic accessibility	Covers essential needs of users with disabilities
AA	Recommended for most organizations	Addresses the majority of common barriers
AAA	Highest standard (difficult to meet)	Supports a wide range of impairments

🧪 Examples:

AAA: w3.org, bbc.com, mit.edu
AA: google.com, microsoft.com, apple.com, india.gov.in

🛠️ Setting Up a Simple Accessible HTML Page

Let’s begin with a basic project that meets Level A requirements.

Step 1: Create a folder for your project

mkdir myweb
cd myweb

Step 2: Build a semantic `index.html` file

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Getting Started with Accessibility</title>
</head>
<body>
  <header>
    <h1>Welcome to Our Accessible Site</h1>
    <nav>
      <a href="#home">Home</a>
    </nav>
  </header>
  <main>
    <section>
      <h2>What is Accessibility?</h2>
    </section>
    <section>
      <h2>Why It Matters</h2>
    </section>
  </main>
  <footer>
    <a href="#contact">Contact Us</a>
  </footer>
</body>
</html>

Step 3: View it using Live Server in VS Code

🔍 Quick Accessibility Audit: Easy Checks

W3C offers a set of informal checks called Easy Checks to help anyone quickly evaluate a page’s accessibility—even without expert knowledge.

✅ What It Covers:

Titles: Ensure each page has a clear and specific <title>.
Image Descriptions: Use meaningful alt attributes for all images.
Headings: Use heading tags in a logical order, without skipping levels.
Text Contrast: Ensure sufficient color contrast between text and background.
Keyboard Navigation: All functions should be usable via the keyboard.
Forms: Every form input must be associated with a visible or hidden <label>.

🔧 Tools for Manual Accessibility Checks

📌 WAVE by WebAIM

WAVE is a browser-based accessibility evaluator that flags issues like missing alt text, low contrast, and improper heading order.

🧪 Browser Developer Tools

Use the Inspector to verify alt attributes on images.
Test keyboard tab navigation to ensure elements receive focus.

🧠 Why Semantic HTML Is Crucial

Semantic HTML elements give structure and meaning to your content. They’re recognized by browsers, assistive technologies, and search engines alike.

Tag	Purpose
`<header>`	Identifies the page’s header section
`<nav>`	Wraps navigation links
`<main>`	Denotes primary page content
`<section>`	Groups related content
`<footer>`	Marks the page’s footer
`<label>`	Connects text to form inputs
`<button>`	Preferred over `div` for clicks

🔴 Avoid using <div> or <span> for layout unless no semantic alternative exists.

🎯 Final Thoughts

Accessibility benefits everyone, not just those with disabilities.
Starting with semantic HTML and proper structure makes a huge difference.
Use tools like WAVE and Easy Checks for quick wins.
Aim for at least WCAG Level A; strive for AA as your standard.

🚀 Coming Up: Common Accessibility Mistakes and How to Fix Them (Blog 2)

In the next part of the series, we’ll dive into the most frequent issues developers face—like poor contrast, unlabeled form fields, and heading structure problems—and how to resolve them with real code examples.

Simplifying Pagination in Angular with a Reusable Base Component

Kedar Kulkarni — Mon, 14 Apr 2025 20:39:53 +0000

Our objective is to abstract the repetitive aspects of pagination—such as tracking the current page, page size, total items, and loading state—into a base component. This base component will provide a standardized way to handle pagination, which can be extended by other components to implement their specific data-fetching logic.

Creating the BasePaginationComponent
Let's define a generic BasePaginationComponent class that handles the core pagination functionality:

import { finalize } from 'rxjs/operators';
import { Observable } from 'rxjs';

export abstract class BasePaginationComponent<T> {
  data: T[] = [];
  currentPage = 1;
  pageSize = 10;
  totalItems = 0;
  isLoading = false;

  // Abstract method to fetch data; must be implemented by subclasses
  protected abstract fetchData(page: number, size: number): Observable<{ items: T[]; total: number }>;

  // Method to load data for a specific page
  loadPage(page: number): void {
    this.isLoading = true;
    this.fetchData(page, this.pageSize)
      .pipe(finalize(() => (this.isLoading = false)))
      .subscribe(response => {
        this.data = response.items;
        this.totalItems = response.total;
        this.currentPage = page;
      });
  }

  // Method to handle page change events (e.g., from a paginator component)
  onPageChange(page: number): void {
    this.loadPage(page);
  }
}

In this base component:

data: Holds the current page's data items.
currentPage: Tracks the current page number.
pageSize: Defines the number of items per page.
totalItems: Stores the total number of items across all pages.
isLoading: Indicates whether a data fetch operation is in progress.
fetchData: An abstract method that must be implemented by subclasses to fetch data for a given page and page size.
loadPage: Handles the logic for loading data for a specific page.
onPageChange: A helper method to be called when the page changes, which in turn calls loadPage.

Implementing the PaginationControlsComponent

import { Component, Input, Output, EventEmitter, OnChanges, SimpleChanges } from '@angular/core';

@Component({
  selector: 'app-pagination-controls',
  templateUrl: './pagination-controls.component.html'
})
export class PaginationControlsComponent implements OnChanges {
  @Input() currentPage: number = 1;
  @Input() totalItems: number = 0;
  @Input() pageSize: number = 10;
  @Output() pageChange: EventEmitter<number> = new EventEmitter<number>();

  totalPages: number = 0;
  pages: number[] = [];

  ngOnChanges(changes: SimpleChanges): void {
    this.totalPages = Math.ceil(this.totalItems / this.pageSize);
    this.pages = Array.from({ length: this.totalPages }, (_, i) => i + 1);
  }

  changePage(page: number): void {
    if (page >= 1 && page <= this.totalPages && page !== this.currentPage) {
      this.pageChange.emit(page);
    }
  }
}

Extending the Base Component
Now, let's create a component that extends BasePaginationComponent to display a list of users:

import { Component, OnInit } from '@angular/core';
import { Observable } from 'rxjs';
import { BasePaginationComponent } from './base-pagination.component';
import { UserService } from './user.service';
import { User } from './user.model';

@Component({
  selector: 'app-user-list',
  templateUrl: './user-list.component.html'
})
export class UserListComponent extends BasePaginationComponent<User> implements OnInit {
  constructor(private userService: UserService) {
    super();
  }

  ngOnInit(): void {
    this.loadPage(this.currentPage);
  }

  protected fetchData(page: number, size: number): Observable<{ items: User[]; total: number }> {
    return this.userService.getUsers(page, size);
  }
}

In this example:

UserListComponent extends BasePaginationComponent, specifying User as the data type.
The fetchData method is implemented to fetch users from the UserService.
The template displays the list of users and includes a custom app-pagination-controls component to handle pagination UI.

Handling Edge Cases in Your Pagination System

While the basic implementation works well, a production-ready pagination system should address these common edge cases:

Large datasets: Display a limited range of pages (first, last, and a few around current) with ellipses instead of showing all page numbers
Navigation boundaries: Disable Previous/Next buttons at first/last pages, and hide pagination entirely for single-page results
Empty results: Provide user feedback when no items exist instead of showing empty pagination controls
Page size changes: Reset to first page when page size changes to ensure consistent user experience
URL integration: Consider syncing pagination state with URL parameters for bookmarking and sharing specific pages
Responsive design: Adapt controls for smaller screens with simplified mobile-friendly navigation
Accessibility: Implement keyboard navigation and proper ARIA labels for inclusive user experience
Error handling: Gracefully manage network failures during server-side pagination operations

Cleaning Up Angular Form Submissions: A Reusable Approach

Kedar Kulkarni — Mon, 14 Apr 2025 20:04:16 +0000

Working with forms in Angular often involves repeating the same steps:

Collecting form data
Making an API call
Managing loading states
Handling success and error responses
Disabling the submit button during processing

If you find yourself duplicating this logic across multiple components, consider a more efficient approach.

Typically, a form submission in Angular might look like this:

onSubmit() {
  this.isSubmitting = true;
  const payload = this.form.value;

  this.api.saveUser(payload).pipe(
    finalize(() => this.isSubmitting = false)
  ).subscribe({
    next: res => console.log('Success', res),
    error: err => console.error('Error', err)
  });
}

While functional, this pattern can become repetitive and more challenging to maintain as your application grows.

Introducing a Reusable Base Component
To streamline this process, we can create a base component that encapsulates the common submission logic:

// base-submit.component.ts
export abstract class BaseSubmitComponent<T = any> {
  isSubmitting = false;

  // Method to create the payload
  abstract createPayload(): T;

  // Method to handle successful submission
  abstract onSubmitSuccess(response: any): void;

  protected submit(apiFn: (payload: T) => Observable<any>) {
    this.isSubmitting = true;
    const payload = this.createPayload();

    apiFn(payload).pipe(
      finalize(() => this.isSubmitting = false)
    ).subscribe({
      next: res => this.onSubmitSuccess(res),
      error: err => this.handleError(err)
    });
  }

  protected handleError(err: any) {
    console.error('Submit error:', err);
    // Implement your error handling logic here
  }
}

With this base component, individual form components can focus on their specific logic:

export class UserFormComponent extends BaseSubmitComponent<UserPayload> {
  form = this.fb.group({
    name: [''],
    email: ['']
  });

  constructor(private fb: FormBuilder, private api: ApiService) {
    super();
  }

  createPayload(): UserPayload {
    return this.form.value;
  }

  onSubmitSuccess(response: any) {
    console.log('User saved successfully:', response);
    // Additional success handling
  }

  onSubmit() {
    this.submit(payload => this.api.saveUser(payload));
  }
}

Advantages of This Approach

Consistency: Ensures uniform handling of submissions across components.
Maintainability: Centralizes common logic, making updates easier.
Clarity: Keeps individual components focused on their unique responsibilities.
Extensibility: Allows for easy addition of features like validation checks or pre-submission hooks.

Enhancements to Consider

Shared UI Components: Create reusable components for buttons or form fields that integrate with the submission state.
Centralized Error Handling: Implement a global service for displaying error messages or notifications.
Form Validation: Incorporate validation logic to prevent invalid submissions.

Edge Cases to Handle

When implementing this form submission pattern, consider these important scenarios:

Custom Error Handling: Allow components to implement their error handling via an onSubmitError method.
Pre-submission Validation: Add validation checks before API calls to prevent invalid submissions.
Cancellable Requests: Implement a way to cancel ongoing submissions if users navigate away.
Form Reset Logic: Add standardized methods to reset forms after successful submissions.
Submission Throttling: Prevent duplicate submissions from rapid clicking.

Forem: Kedar Kulkarni

Stop Burning Money: How Smarter Angular Code Slashes Your Server Bills

1. Stop Paying for "Waiters" (Static Hosting)

2. The "Ask Once" Rule (API Caching)

3. Don't Be a "Stuttering" Search (Debouncing)

4. Smart Loading (Lazy Loading & @defer)

5. The "Offline Store" Strategy (PWA)

6. "Micro-Surgery" for Large Apps (Micro-Frontends)

7. Signals: The "Energy Efficient" Lightbulb

💰 The Financial Impact: At a Glance

The Bottom Line

Complete Guide to ADA Compliance in Angular Applications

🚀 Why Accessibility Matters in Angular

📚 Understanding ADA, WCAG, and Angular

🌐 What is ADA Compliance?

🧠 How Angular Fits Into Accessibility

🕵️‍♂️ Identifying Accessibility Issues in Angular Apps

🔧 Automated Tools

👀 Manual Testing

🔥 Common Angular Accessibility Pitfalls

1. Focus Management Failures

2. Dynamic Content Not Announced

3. Custom Components Missing Labels

4. Missing Keyboard Support

5. Color Contrast Issues

🧰 Tools & Libraries for Angular Accessibility

🧪 Real Angular Accessibility Failures (Case Studies)

🔎 Case 1: E-Commerce Filter Inaccessibility

Fix: Added semantic markup + live region updates

🔎 Case 2: Government Services Portal

🔎 Case 3: Online Learning Platform Lawsuit

🧑‍💻 Accessibility Best Practices in Angular

💡 Design Phase

🛠️ Development Phase

✅ Semantic HTML First

✅ ARIA Attributes

✅ Keyboard Navigation

🧪 Testing & Maintenance

🏁 Conclusion

📚 Additional Resources

⚙️ ARIA for Developers – Roles, States, and Accessible Components in React

🔎 What Is ARIA?

⚠️ Before You Use ARIA…

🔧 ARIA Core Concepts

🧪 React + ARIA: Practical Examples

1️⃣ Toggle Button (Accessible Switch)

🧠 ARIA Highlights:

2️⃣ Custom Dropdown with Keyboard Support

ARIA Usage:

3️⃣ Accessible Labeling: aria-label & aria-labelledby

aria-label (Custom label directly on the element):

aria-labelledby (Reference another element's id):

🔒 ARIA Do’s and Don’ts

🧠 Key ARIA Roles You Should Know

📋 Summary: Building Accessible Components with ARIA

🛠️ Fixing Common Accessibility Issues – Alt Text, Contrast, Headings & Forms

🖼️ 1. Missing or Inaccurate Alt Text for Images

❌ Common Problems

✅ Best Practices

🧪 Example

🎨 2. Poor Color Contrast

❌ Common Issue

✅ Fix It

🔧 Example

🧩 3. Improper Heading Structure

❌ Common Mistakes

✅ Best Practices

🧪 Example

📝 4. Form Inputs Without Labels

❌ Issues

✅ Fix It

🧪 Examples

🔍 5. Keyboard Navigation Failures

✅ Keyboard Navigation Checklist:

🧾 Summary Checklist

🔄 Coming Up: Building Accessible Widgets with ARIA in React (Blog 3)

✨ A Beginner's Guide to Web Accessibility – WCAG, Easy Checks & Semantic HTML

🌐 What Is Web Accessibility?

📘 WCAG Compliance Levels Explained

🛠️ Setting Up a Simple Accessible HTML Page

3️⃣ Accessible Labeling: `aria-label` & `aria-labelledby`

`aria-label` (Custom label directly on the element):

`aria-labelledby` (Reference another element's `id`):

Step 2: Build a semantic `index.html` file