DEV Community: Duško Perić

Abstract Classes in TypeScript: Enforcing an Architectural Imperative

Duško Perić — Thu, 13 Nov 2025 17:16:09 +0000

When developing robust and scalable software applications, introducing abstract classes in TypeScript is often a key architectural decision. An abstract class is the right solution when we want to define a shared foundation for a group of related objects, providing common, already implemented state and behavior (the DRY principle). In other words, an abstract class defines what its subclasses share, and what they are required to implement in order to be concrete and functional.

Design Balance: Implemented Methods and Abstract Requirements

The strength of an abstract class lies in its ability to balance shared implementation with required customization.
This division is expressed through two components that coexist within an abstract structure:

Shared Behavior (Concrete Methods and Properties)
This part of the abstract class includes all methods and properties that are fully functional and implemented. Subclasses automatically inherit this implementation without needing to rewrite it.
Abstract Imperative (Required Methods)
These are methods that define a signature but lack an implementation. By declaring a method as abstract, we are not offering an option, we are enforcing that every subclass must provide its own implementation.

abstract class ApiClient<T> {
  // Shared behavior
  async getAll(): Promise<T[]> {
    const res = await fetch(this.getEndpoint());
    return res.json();
  }

  // Required behavior: each subclass MUST return its own endpoint
  protected abstract getEndpoint(): string;
}

interface User { id: number; name: string; }
interface Product { id: number; title: string; }

// Concrete class for users
class UserClient extends ApiClient<User> {
  protected getEndpoint(): string {
    return "/api/users";
  }
}

// Concrete class for products
class ProductClient extends ApiClient<Product> {
  protected getEndpoint(): string {
    return "/api/products";
  }
}

// Usage
const users = new UserClient();
users.getAll()

const products = new ProductClient();
products.getAll()

Design Control and Discipline

The greatest contribution of an abstract class is its ability to enforce structural discipline and protect the codebase from inconsistencies. Abstract classes ensure that:

Key functionality is never forgotten: Declaring an essential method as abstract guarantees that no subclass can be created without providing a concrete implementation of that method.
Consistent Behavior (Polymorphism): Different subclasses can provide different implementations, but from the outside they can all be treated uniformly through the shared abstract type.

Abstraction serves as the first line of defense in complex systems, ensuring that the core structure and identity of an object aren’t bypassed or ignored.

Using abstract classes is a way to ensure a clear architectural structure: shared logic is centralized, and essential behavior cannot be omitted. The result is more organized, readable, and stable code.

The Boundary Between “Clever” and “Clean” Code

Duško Perić — Sun, 19 Oct 2025 17:45:15 +0000

Writing code is a constant balance between efficiency, clarity, and maintainability. Sometimes, developers create solutions that are technically elegant and compact, but their readability and long-term sustainability may be compromised.

In such cases, the question arises: when does code become too “clever,” and when is it truly “clean” and maintainable? Understanding this boundary is crucial for writing professional and sustainable software.

Clever Code: A Demonstration of Skill and Knowledge

“Clever” code showcases a deep understanding of the language and programming concepts. It often employs advanced constructs and complex expressions to condense multiple operations into a compact form.

It is concise, efficient, and can initially appear elegant, as it allows complex logic to be expressed in a minimal number of lines.

const processedItems: string[] = items
  .filter(item => item.active && item.value > 0)
  .map(item => `${item.name} (${item.category ?? 'uncategorized'}) - ${item.value}`)
  .sort((a, b) => a.localeCompare(b));

However, while such code demonstrates a high level of expertise, its readability and maintainability often suffer. Future readers and even the original author after some time may struggle to quickly understand what is happening, making debugging, refactoring, and team collaboration more difficult.

Clean Code: A Demonstration of Maturity and Thoughtfulness

“Clean” code prioritizes clarity and maintainability over the impressiveness of expressions. Its focus is on making logic obvious and easy to understand.

function formatItem(item: Item): string {
  return `${item.name} (${item.category ?? 'uncategorized'}) - ${item.value}`;
}

function sortItems(items: string[]): string[] {
  return items.sort((a, b) => a.localeCompare(b));
}

function processItems(items: Item[]): string[] {
  const activeItems = items.filter(item => item.active && item.value > 0);
  const formattedItems = activeItems.map(formatItem);
  return sortItems(formattedItems);
}

Instead of compressing everything into a single line or using advanced tricks, clean code breaks problems into smaller, self-contained parts with descriptive names and clear responsibilities. Each component or function clearly communicates its intent, enabling readers to quickly grasp how the system works.

This approach facilitates maintenance, testing, and teamwork. Clean code may not always be the shortest or most striking, but its value lies in long-term stability and ease of comprehension.

The Boundary Between Clever and Clean Code

There is no strict line separating clever from clean code. Clever code can be understandable and elegant when the underlying idea is clearly expressed, while clean code can become overly verbose if it avoids conciseness and the “showing-off” of skill.

function processItems(items: Item[]): string[] {
  const activeItems = items.filter(item => item.active && item.value > 0);

  const formattedItems = activeItems.map(item =>
    `${item.name} (${item.category ?? 'uncategorized'}) - ${item.value}`
  );

  return formattedItems.sort((a, b) => a.localeCompare(b));
}

Maturity in coding comes when a developer knows when to use more complex expressions and when to break down logic. The priority is no longer to impress other developers but to enable them to quickly understand and work with the code.

The true skill lies in balance: concise enough to be elegant, yet clear enough to avoid confusion. The boundary is found when form and function work together. Code that is beautiful and efficient, yet completely readable.

A Simple Way to Grasp Dependency Injection

Duško Perić — Tue, 07 Oct 2025 08:47:26 +0000

Dependency Injection is one of those concepts that developers use every day, yet often struggle to explain clearly.
The good news is: it’s not as abstract as it sounds. If we translate it into a real-world example everything suddenly makes sense.

Without Dependency Injection

Imagine you’re a sandwich seller.
A customer comes to buy a sandwich, but before you can sell it, you have to make it yourself: slice the bread, add cheese, tomatoes, lettuce...

In code, that looks something like this:

class Sandwich {
  constructor(private type: string) {}

  make(): string {
    return `Sandwich (${this.type}) is made.`;
  }
}

class Seller {
  private sandwich: Sandwich;

  constructor() {
    this.sandwich = new Sandwich("ham");
  }

  sell(): void {
    console.log(this.sandwich.make());
    console.log("Seller is selling the sandwich.");
  }
}

Here, the seller creates the sandwich before selling it.
That means if we want to sell a veggie sandwich instead of ham, we need to go inside the Seller class and change the code.
The seller and the sandwich are tightly coupled, not great if our menu starts expanding.

With Dependency Injection

Now imagine a smarter setup: someone else is in charge of making sandwiches.
The seller simply receives a ready-made sandwich and focuses on what he does best: selling.

class Sandwich {
  constructor(private type: string) {}

  make(): string {
    return `Sandwich (${this.type}) is made.`;
  }
}

class Seller {
  constructor(private sandwich: Sandwich) {}

  sell(): void {
    console.log(this.sandwich.make());
    console.log("Seller is selling the sandwich.");
  }
}

const sandwich = new Sandwich("veggie");
const seller = new Seller(sandwich);
seller.sell();

Now the seller doesn’t care how the sandwich was made, he just needs it to exist.
This is exactly what Dependency Injection means:

Instead of a class creating its own dependencies, it receives them from the outside.

DI in Angular

Angular takes this idea even further.
When you declare a service and inject it into a component, Angular’s DI system takes care of providing the right instance automatically.

For example:

@Injectable({ providedIn: 'root' })
export class SandwichService {
  make() {
    return 'Ham sandwich is made.';
  }
}

@Component({
  selector: 'app-seller',
  template: `
    <button (click)="sell()">Sell Sandwich</button>
    <p>{{ message }}</p>
  `
})
export class SellerComponent {
  private sandwichService = inject(SandwichService)
  message = '';

  sell() {
    this.message = this.sandwichService.make() + ' Seller is selling it.';
  }
}

The SellerComponent doesn’t create the SandwichService, Angular does.
It just declares that it depends on it, and Angular’s injector takes care of the rest.

Dependency Injection sounds fancy, but it’s really just about delegating responsibility.
Your classes shouldn’t build the things they depend on, they should just use them.

Once you get that, you’ll see DI everywhere, not as some magical Angular mechanism, but as a simple design pattern that makes your code cleaner, more flexible, and easier to test.

So next time someone asks you what Dependency Injection is, just tell them:

It’s like being a sandwich seller who doesn’t have to make the sandwich, someone else prepares it, you just sell it.

NgRx Signal Store Event API: A Modern Take on Event-Driven Architecture

Duško Perić — Wed, 24 Sep 2025 14:04:27 +0000

If you've ever worked with NgRx Signal Store, you know it's a powerful tool for managing state in Angular applications in a totally new way. But what if you could take it a step further? Imagine an event-driven system where the flow of state is completely decoupled, giving you incredible flexibility with minimal boilerplate.

Well, that's exactly what the NgRx SignalStore Events feature brings to the table. Now, your code can operate on a principle of "something happened, so I'm telling everyone who's interested."

Imagine you're playing a game and your hero just took down a tough enemy. A bunch of stuff happens all at once, right? Your hero gets XP, maybe some gold drops, and a status message pops up on the screen. Traditionally, getting all these things to happen smoothly could be a tangled mess of interconnected functions and state updates. It's like trying to untangle a hundred fishing lines at once.

The new Event API is the clean solution to this problem. Instead of your hero component directly telling the XP store to update, the hero just shouts, "Enemy Slain!". Everyone else, the XP tracker, the gold counter, the UI message service listens for that shout and reacts. It's a much cleaner, more scalable way to build things.

How It Works

Let's dive into a real-world scenario from our game. We need to handle a single event: an enemy is defeated. This simple action triggers a chain reaction across our game's state.
First, let's define the state we'll be managing with our HeroStore. We'll track the hero's core stats.

// hero.store.ts
export interface HeroState {
  level: number;
  xp: number;
  gold: number;
}

export const initialState: HeroState = {
  level: 1,
  xp: 0,
  gold: 0,
};

Next, we define the events. The most important part of this is that the events carry the necessary data. In our case, when an enemy is defeated, we need to know the XP and gold they were carrying. A separate event for a level-up is what keeps our logic clean.

// hero.events.ts
import { type } from '@ngrx/signals';
import { eventGroup } from '@ngrx/signals/events';

export const heroPanelEvents= eventGroup({
  source: 'Hero Panel',
  events: {
    enemyDefeated: type<{ xpValue: number; goldDrop: number }>(),
  },
});

export const heroApiEvents = eventGroup({
  source: 'Hero API',
  events: {
    levelUp: type<{ newLevel: number }>(),
  },
});

Now for the HeroStore itself. Here, we combine two key pieces: the reducer and the effects.

The reducer's job is to update the state based on the event's payload.
The effects handle the "side effects", any complex logic, calculations, or API calls that don't directly change the state.

// hero.store.ts
import { signalStore, withState } from '@ngrx/signals';
import { withReducer, on } from '@ngrx/signals/events';
import { heroPanelEvents, heroApiEvents } from './hero.events';
import { withHeroEffects } from './withHeroEffects';

export interface HeroState {
  level: number;
  xp: number;
  gold: number;
}

export const initialState: HeroState = {
  level: 1,
  xp: 0,
  gold: 0,
};

export const HeroStore = signalStore(
  withState<HeroState>(initialState),
  withHeroEffects(),
  withReducer(
    on(heroPanelEvents.enemyDefeated, ({ payload }) => ({ gold, xp }) => ({
      xp: xp + payload.xpValue,
      gold: gold + payload.goldDrop,
    })),
    on(heroApiEvents.levelUp, ({ payload }) => ({
      level: payload.newLevel,
    }))
  )
);

// withHeroEffects.ts
import { inject } from '@angular/core';
import { signalStoreFeature, type } from '@ngrx/signals';
import { withEffects } from '@ngrx/signals/events';
import { Events } from '@ngrx/signals/events';
import { map, switchMap } from 'rxjs';
import { heroPanelEvents, heroApiEvents } from './hero.events';
import { HeroState } from './hero.store';
import { HeroService } from './hero.service';

export function withHeroEffects() {
  return signalStoreFeature(
    type<{ state: HeroState }>(),
    withEffects(
      (
        store, 
        events = inject(Events), 
        heroService = inject(HeroService)
      ) => ({
      levelUpEffect: events.on(heroPanelEvents.enemyDefeated).pipe(
        switchMap(() =>
          heroService.checkLevel(store.xp()).pipe(
            map((newLevel: number) => {
              if (newLevel > store.level()) {
                return heroApiEvents.levelUp({ newLevel });
              }
              return null;
            })
          )
        )
      )
    }))
  );
}

The withEffects feature is where our logic for leveling up lives.
Here, the effect listens for the enemyDefeated event. When that event occurs, it calls heroService.checkLevel with the hero's current XP. The backend returns the hero's new level, if any. If the returned newLevel is higher than the current level, the effect emits heroApiEvents.levelUp. The signalStore automatically dispatches this event, which is then handled by the reducer to update the state.

This is a beautiful example of how effects and reducers work together. The effect handles the "what-if" logic, and the reducer handles the final state update.

Putting It All Together

So you've set up your store, defined your events, and even created an effect. Now, what do you do in your component? This is where everything clicks.

Thanks to the injectDispatch and signalStore APIs, your component code becomes incredibly clean. You just tell the app what happened, and the rest is handled by the system.

// hero.component.ts
import { Component, inject } from '@angular/core';
import { HeroStore } from './hero.store';
import { heroPanelEvents } from './hero.events';
import { injectDispatch } from '@ngrx/signals/events';

@Component({
  selector: 'app-hero-panel',
  template: `
    <h2>Hero Stats</h2>
    <p>Level: {{ store.level() }}</p>
    <p>XP: {{ store.xp() }}</p>
    <p>Gold: {{ store.gold() }}</p>
    <button (click)="onEnemyDefeated()">Defeat Enemy</button>
  `,
  providers: [HeroStore],
})
export default class HeroPanelComponent {
  private readonly store = inject(HeroStore);
  private readonly dispatch = injectDispatch(heroPanelEvents);

  onEnemyDefeated() {
    // We're just telling the app an enemy was defeated, providing the XP and gold.
    // The store and effect will handle the rest!
    this.dispatch.enemyDefeated({ xpValue: 200, goldDrop: 50 });
  }
}

Notice how clean this is. The component doesn't need to know how to update the XP, gold, or level; it just dispatches an event. It says, "Hey, an enemy was defeated with 200 XP and 50 gold." The HeroStore then listens, and the HeroPanelComponent automatically updates its display because it's reading the state from a signal (store.xp(), store.level(), etc.).

This approach gives you the power to create a robust and well-structured application, just like a well-designed game. The next time you're building something complex, think about how events could make your life easier.

Custom Store Features in NgRx Signal Store

Duško Perić — Mon, 08 Sep 2025 08:10:02 +0000

You’ve probably faced this situation before – you’re adding a new feature to your app, and you realize you need the same logic you already wrote somewhere else. Copy-pasting feels quick, but it soon leads to duplicated code and harder maintenance. In state management, the way to avoid this problem is with custom store features. They allow you to define shared functionality once and then apply it seamlessly to multiple stores.

To see how this works in practice, imagine building an Angular app to track players and teams in a competitive game.

You’ll need:

Player store – stores player’s name and role (mid, jungle, top, support, adc).
Team store – stores the team name and number of wins.
Shared feature – both players and teams have a rank (bronze, silver, gold…).

Instead of duplicating the rank logic in both stores, we can pull it out into a custom feature and just reuse it.

Create the shared feature

// with-rank.feature.ts
import { signalStoreFeature, withState, withComputed } from '@ngrx/signals';
import { computed, Signal } from '@angular/core';

export type Rank = 'bronze' | 'silver' | 'gold';

export interface RankState {
  rank: Rank;
}

// reusable feature
export function withRank() {
  return signalStoreFeature(
    withState<RankState>({ rank: 'bronze' }),
    withComputed(({ rank }) => ({
      isGold: computed(() => rank() === 'gold'),
    }))
  );
}

// helper functions to patch state easily
export function setGold(): RankState {
  return { rank: 'gold' };
}

export function setSilver(): RankState {
  return { rank: 'silver' };
}

export function setBronze(): RankState {
  return { rank: 'bronze' };
}

Here’s what we got:

rank state
Helpers like setGold, setSilver and setBronze to update state.
A computed property isGold we can use in templates.

Player store

// player.store.ts
import { signalStore, withState, withMethods, patchState } from '@ngrx/signals';
import { withRank, setGold } from './with-rank.feature';

type Role = 'mid' | 'jungle' | 'top' | 'adc' | 'support';

export interface PlayerState {
  name: string;
  role: Role;
}

export const PlayerStore = signalStore(
  withState<PlayerState>({ name: 'Faker', role: 'mid' }),
  withRank(),
  withMethods((store) => ({
    promoteToGold() {
      patchState(store, setGold());
    }
  }))
);

Our player now has:

name,
role,
and thanks to withRank → also a rank.

Team store

// team.store.ts
import { signalStore, withState, withMethods, patchState } from '@ngrx/signals';
import { withRank, setGold } from './with-rank.feature';

export interface TeamState {
  teamName: string;
  wins: number;
}

export const TeamStore = signalStore(
  withState<TeamState>({ teamName: 'T1', wins: 0 }),
  withRank(),
  withMethods((store) => ({
    promoteTeamToGold() {
      patchState(store, setGold());
    }
  }))
);

The team has:

teamName,
wins,
and again, a rank.

Using the PlayerStore in a component

// player-card.component.ts
import { Component, inject } from '@angular/core';
import { PlayerStore } from './player.store';

@Component({
  selector: 'app-player-card',
  template: `
    <div class="card">
      <h2>{{ playerStore.name() }} — {{ playerStore.role() }}</h2>

      <p>Rank: <strong>{{ playerStore.rank() }}</strong></p>

      @if (playerStore.isGold()) {
        <p>🏅 This player is Gold!</p>
      }

      <button (click)="playerStore.promoteToGold()">Promote to Gold</button>
    </div>
  `,
})
export class PlayerCardComponent {
  playerStore = inject(PlayerStore);
}

Using the TeamStore in a component

// team-card.component.ts
import { Component, inject } from '@angular/core';
import { TeamStore } from './team.store';

@Component({
  selector: 'app-team-card',
  template: `
    <div class="card">
      <h2>{{ teamStore.teamName() }}</h2>

      <p>Wins: {{ teamStore.wins() }}</p>
      <p>Rank: <strong>{{ teamStore.rank() }}</strong></p>

      @if (teamStore.isGold()) {
        <p>🏆 This team is Gold!</p>
      }

      <button (click)="teamStore.promoteTeamToGold()">Promote Team to Gold</button>
    </div>
  `,
})
export class TeamCardComponent {
  teamStore = inject(TeamStore);
}

Here, we inject our PlayerStore or TeamStore, display the relevant info, and allow a one-click promotion to gold (if only ranking up in games was this easy 😂).

What did we gain?

By extracting rank into a custom feature, we avoided duplicating logic across multiple stores. Both players and teams share the same feature, and we can extend it in the future if needed.

Think of custom store features like power-ups in a game, you create them once and then use them wherever you need that extra boost.

✅ Cleaner code
✅ Reusable state & methods
✅ Less duplication

And the best part: your stores stay lean and focused on their specific responsibilities.

Leveling Up State Management with withLinkedState in NgRx v20

Duško Perić — Sat, 23 Aug 2025 11:13:38 +0000

NgRx v20 just dropped, and with it comes a shiny new feature: withLinkedState.

Think of it like a buff for your SignalStore – it lets you create reactive, dependent state that automatically updates when its source changes. Less boilerplate, more focus on the fun stuff.

Imagine you’re building a little League of Legends dashboard. You’ve got a list of champions in your store, and you always want to keep track of the first champion in the list.

Without withLinkedState, you’d probably write some extra logic in your component. With it, you can keep everything in the store:

const ChampionStore = signalStore(
  withState({ champions: ['Nautilus', 'Blitzcrank', 'Leona'] }),
  withLinkedState(({ champions }) => ({
    currentChampion: () => champions()[0],
  })),
  withMethods((store) => ({
    setChampions(champions: string[]): void {
      patchState(store, { champions });
    },
    setCurrentChampion(champion: string): void {
      patchState(store, { currentChampion: champion });
    },
  }))
);

That’s it, currentChampion is just there, reactive and ready.
If the champions array changes, your “selected” champion updates instantly. Swap the list, and your new champion is auto-picked like magic. But if you want to take control, you can use patchState to lock in your pick.

Ok, but what if you don’t just want the first champion, but want to stick to your main even if the champion list changes?

That’s where linkedSignal comes in.

type Champion = { id: number; name: string };

const ChampionStore = signalStore(
  withState({ champions: [] as Champion[] }),
  withLinkedState(({ champions }) => ({
    currentChampion: linkedSignal<Champion, Champion>({
      source: champions,
      computation: (newList, previous) => {
        // Keep your old main if still in the new list
        const currentChamp = newList.find((c) => c.id === previous?.value.id);
        // Otherwise, default to the first champ
        return currentChamp ?? newList[0];
      },
    }),
  }))
);

So if you’re a Nautilus main (anchor’s down! ⚓) and the list updates, your store will keep you locked on him unless he’s removed. If he’s gone, you’ll default to the first champ in line.

withLinkedState feels like unlocking a new rune: less effort, more power, and smoother gameplay when it comes to managing state. It’s a neat addition that makes your store logic more intuitive and future-proof.