I spent most of last Tuesday staring at a massive, sprawling JavaScript file. It handled everything—fetching user data, updating the DOM, managing local state. And it was breaking constantly. We’re running Node.js 22.1.0 and targeting modern browsers, but our codebase felt like it was stuck in 2015.

Well, the solution wasn’t just renaming .js to .ts and fixing the red squiggles in VS Code 1.88. That just gives you strictly-typed spaghetti. To actually fix the architecture, I had to lean hard into TypeScript’s Object-Oriented Programming features.

Look, I know “OOP” makes some functional programming purists break out in hives. But when you’re dealing with async API calls and messy DOM state, classes with strict access modifiers are exactly what you need.

The Vanilla JS Mess

Here’s what our legacy code looked like. It’s standard JavaScript. It works, but it’s incredibly fragile.

class UserDashboard {
    constructor(containerId) {
        this.container = document.getElementById(containerId);
        this.apiEndpoint = 'https://api.example.com/users';
        this.users = []; // Anyone can mutate this
    }

    async fetchUsers() {
        const res = await fetch(this.apiEndpoint);
        this.users = await res.json();
        this.render();
    }

    render() {
        // Fragile DOM manipulation
        this.container.innerHTML = this.users.map(u => <div>${u.name}</div>).join('');
    }
}

Anyone can do dashboard.apiEndpoint = 'lol' from another file and break the whole app. The DOM container might be null, but JS doesn’t care until runtime. The API response is a complete mystery box.

Locking it down with TypeScript OOP

First things first. We need a base class for API fetching. I want the endpoint locked down, and I want internal fetching methods hidden from the outside world. This is where readonly and protected come in.

class ApiClient<T> {
    // Readonly: Can't be changed after the constructor fires
    readonly baseUrl: string;

    constructor(url: string) {
        this.baseUrl = url;
    }

    // Protected: Only accessible here and in child classes
    // We don't want random components calling this directly
    protected async fetchData(path: string): Promise<T> {
        try {
            const response = await fetch(${this.baseUrl}${path});
            if (!response.ok) throw new Error(HTTP error! status: ${response.status});
            return await response.json();
        } catch (error) {
            console.error("Fetch failed:", error);
            throw error;
        }
    }
}

A quick gotcha about readonly arrays

Side note on readonly. I’ve been burned by this three times now. If you declare an array like readonly items: User[], you are only protecting the variable reassignment. Another developer can still do dashboard.items.push(newUser) and mutate your state.

And if you want true immutability in TS, you need readonly items: readonly User[]. It looks redundant, but that second readonly actually freezes the array methods like push and pop. The docs don’t make this obvious, but it will save you hours of debugging race conditions.

Inheritance and the DOM

Now we use extends to build our specific dashboard. We inherit the API logic and add our DOM manipulation on top.

interface User {
    readonly id: number; // Perfect for DB records that shouldn't change
    name: string;
    role: string;
}

class AdminDashboard extends ApiClient<User[]> {
    private container: HTMLElement;

    constructor(url: string, containerId: string) {
        super(url); // Must call the parent constructor first

        const el = document.getElementById(containerId);
        if (!el) {
            throw new Error(Container ${containerId} missing from DOM);
        }
        this.container = el;
    }

    // This is the only public method. 
    async loadAdmins(): Promise<void> {
        // Using the protected method inherited from ApiClient
        const users = await this.fetchData('/admins');
        this.renderDOM(users);
    }

    private renderDOM(users: User[]): void {
        this.container.innerHTML = ''; // Clear existing

        users.forEach(user => {
            const div = document.createElement('div');
            div.className = 'admin-card';
            // Safe access: TS knows 'id' and 'name' exist
            div.textContent = #${user.id}: ${user.name} (${user.role});
            this.container.appendChild(div);
        });
    }
}

We rolled this architecture out across our main reporting module last month. By strictly typing our API boundaries and locking down state with these modifiers, we cut our runtime TypeErrors in production by 82% over three weeks.

You don’t have to go full Java-enterprise with abstract factories and singletons to get value out of this. Just use basic inheritance to share your async logic, protect your internal methods, and freeze your IDs. It makes a massive difference when the codebase scales.

This approach also aligns well with the principles of TypeScript tests that actually catch bugs. By encapsulating our API calls and DOM manipulation, we can more easily write isolated unit tests that validate the behavior of each class.

And speaking of testing, make sure you’re also taking advantage of TypeScript’s type assertion features. They’ll help you catch bugs at compile-time instead of runtime.

TypeScript’s official documentation on classes and inheritance provides a comprehensive guide on using these OOP features effectively. Additionally, the TypeScript roadmap offers insights into the language’s future development and upcoming features that can further improve your TypeScript-based projects.