DEV Community: Aleks Onyshko

Beyond the Click: Engineering "Smart" Focus with Graph Theory

Aleks Onyshko — Thu, 22 Jan 2026 21:24:11 +0000

As I could have hoped, the title should have intrigued you. I can assure you, your curiosity will be rewarded. This article is about how I accidentally rediscovered and reapplied concepts from Smart TV and Game Console UX designs to our beloved web.

THE PROBLEM

It sounds simple. Here are the scenarios:

When I click on a TODO, the modal expands with the corresponding TODO data.
When I click outside (and importantly, not on the TODO), the modal should collapse.

Simple, right? Simple for us humans, because this is how we logically think. But let us try to solve this problem the "traditional" way.

Note: I will provide 'pseudo' code, as I think it illustrates the point better. Disregard Angular-specific syntax like @Component or @HostBinding.

Traditional Approach: The Modal Component

class ModalComponent {

  state = "collapsed"; // or "expanded"

  // We have to listen to the ENTIRE page, because we need 
  // to know when the user clicks the "void".
  onGlobalClick(clickEvent) {

    // 1. Geography Check: Did the user click ME?
    // If the click is inside the modal, obviously stay open.
    if (this.contains(clickEvent.target)) {
      return; 
    }

    // 2. The Trap: The "Outside" Paradox
    // The TODO item is technically "Outside".
    // If we just close now, clicking a Todo will instantly 
    // open AND close the modal in the same millisecond.

    // So, we start writing exceptions...

    // HACK: We have to manually check if the click target 
    // was one of the Todo items.
    if (clickEvent.target.classList.contains('todo-item')) {

        // It was a Todo! Don't close. Let the Todo handle the open logic.
        return;
    }

    // 3. Finally, if it wasn't me, and it wasn't a Todo...
    // It must be the background.
    this.collapse();
  }
}

Observations and Analysis

Pros

Speed: This solves our problem fast and now.
Simplicity: No overengineering, just procedural thinking.

Cons

Goodbye, reusability: We are strictly defining business logic inside the Modal component.
Goodbye, flexibility: If our rules changed in the future - for example, if we wanted Project items instead of TODOs - we would have to go into the Modal component and manually change the conditions.

Conclusion

Garbage. I don't know about you, but I would feel terrible doing something like this. It defies good software principles.

So, I wanted to implement these requirements considering best practices. It comes with a cost. The cost is engineering something that removes the direct dependency of the Modal on the TODO.

The Genius Kicks In

Not gonna lie, I am very proud of what I came up with. If you stick with me until the very end, I hope you will appreciate the elegance and the "revolution" of the solution I implemented.

First, I realized one important concept. When a user interacts with the page, only one part of the page is actually in their focus.

Focus Theory

Let's visualize a simple TODO app page and split it into Focus Zones.

As you can see, the page can actually be divided into a couple of focus zones. I immediately wanted to conceptualize them in the code. Here is how it looks:

export abstract class FocusArea {
  // Explained below, ignore this for now
  abstract focusEngine: FocusEngine;

  abstract id: string;
  abstract isActive: Signal<boolean>;

  abstract focus(): void;

  abstract initialize(...): void;

  abstract destroy(): void;
}

It is really simple. Importantly, we can focus() the zone, and we also have isActive — which tells us if the zone is active. Obvious, but essential.

Having them defined is a win, but we have to do something with them. What I want is to have two zones connected to each other, and for one zone to be able to trigger another zone. We are basically talking about two points connected to each other.

Graph Theory

The definition of this concept is as follows:

In mathematics and computer science, graph theory is the study of graphs, which are mathematical structures used to model pairwise relations between objects.

Hmmm...

relations between objects...

Sounds like exactly what we need.
So, the implementation plan became simple: represent the relations between zones as a graph. When I focus() a zone, I should be able to programmatically tell which zone is connected to the one I focused, and I can trigger whatever interaction I want.

Keep this simple concept in mind, as the following implementation might look a bit complex, but the inner core is exactly what I described above.

In order to conceptualize the graph, I need a separate entity.

Meet FocusEngine.

Pay attention, to the the data.
Before we write the logic, look closely at the graph property in the FocusEngine below:

TypeScript

abstract readonly graph: Map<FocusArea, Set<FocusArea>>;

I chose a Map where every Key is a FocusArea, and the Value is a Set of its neighbors. This isn't random. This is an Adjacency List.

Why? Because speed matters.

When I click a TODO item, I don't want to scan an array of 10,000 items to find connections. I want to perform a hash lookup — O(1) complexity - and get the exact list of neighbors instantly.

Key: TodoItem #42

Value: { ModalComponent }

Simple. Fast. Brutally effective.

Here is the abstract definition:


export interface FocusedGraphPart {
  originArea: FocusArea;
  connections: Set<FocusArea>;
}

export abstract class FocusEngine {
  // Added for clarity; it doesn't have to be exposed in the public contract
  abstract readonly focusedGraphPart: Signal<FocusedGraphPart | undefined>;
  abstract readonly graph: Map<FocusArea, Set<FocusArea>>;
  abstract readonly registry: Map<string, FocusArea>;
  abstract readonly pendingConnections: Map<string, Set<string>>;

  // A helper function to let us know if an Area is in focus
  abstract isActive(area: FocusArea): boolean;

  // Register an area as a node in the graph
  abstract register(areaId: string, area: FocusArea, connectedIds?: string[]): void;

  abstract unregister(areaId: string): void;

  // Link 2 parts of the graph between each other
  abstract link(area: FocusArea, areaB: FocusArea): void;

  abstract unlink(area: FocusArea, areaB: FocusArea): void;

  // Perform activation process if focusedArea has any connections
  abstract activate(focusedArea: FocusArea): void;
}

Having FocusArea and FocusEngine defined, we want a middleman that will allow our Components to become a FocusArea and add themselves to the graph.

Meet FocusAreaDirective:


@Directive()
export abstract class FocusAreaDirective implements FocusArea {
  public focusEngine = inject(FocusEngine);

  private destroyRef = inject(DestroyRef);

  public id!: string;
  public isActive: Signal<boolean> = computed(() => {
    return this.focusEngine.isActive(this);
  })

  // Important: notice connectedIds. This is how we define relations in the graph.
  public initialize({areaId, connectedIds}: FocusAreaConfig) {
    this.id = areaId;

    this.focusEngine.register(this.id, this, connectedIds);

    this.destroyRef.onDestroy(() => {
      this.destroy();
    })
  }

  public focus(): void {
    this.focusEngine.activate(this)
  }

  public destroy(): void {
    this.focusEngine.unregister(this.id);
  }

  @HostListener('click', ['$event'])
  public onClick(event: MouseEvent): void {
    event.stopPropagation();

    this.focus();
  }

  @HostBinding('class.is-active')
  get activeClass(): boolean {
    return this.isActive();
  }
}

So, if one of our Component's wants to become a FocusArea, it can simply do this:


export class TodoComponent extends FocusAreaDirective {
  public todo = input.required<Todo>()

  constructor() {
    super();

    effect(() => {
      this.initialize({
          areaId: `TODO_${this.todo().id}`, 
          connectedIds: ['TODO_CREATE_MODAL']
      })
    })
  }
}

That's it!!!!

The Engineering Challenges

Before I show you the final code, we need to address two massive problems I ran into.

The Secret headache: Graph Symmetry You will notice something peculiar in my link method. When Area A connects to Area B, I also force Area B to connect to Area A.

this.graph.get(areaA).add(areaB);
this.graph.get(areaB).add(areaA); // The Mirror

You ask, "why do we need the mirror connections? The Modal doesn't care about the Todo!"

Actually, it does. It's about Cleanup.

Imagine the user navigates away and the Modal is destroyed. If the connection was only one-way (Todo -> Modal), the Todo would still be holding a reference to a dead Modal.

By enforcing Symmetry, when the Modal dies, it can look at its own list of friends and say, "Hey Todo, I'm leaving. Delete my number." It makes cleanup instantaneous without requiring a full graph scan.

The "Chicken or Egg" Problem Now, if you are an experienced frontend developer, you are probably logically asking:

"But Alex! You can't just link things! What if the Todo loads before the Modal? The Modal doesn't exist yet!"

You are absolutely right. In the chaotic world of modern frameworks (Angular, React, Vue), we have zero guarantees about render order.

Scenario: TodoItem initializes. It says: "Connect me to TODO_MODAL!"

Reality: The ModalComponent hasn't rendered yet. It's undefined.

Result: The code crashes. Game over.

I spent three days banging my head against the wall on this(almost literally). The solution? The Waiting Room.

I introduced pendingConnections. It’s a simple "Post-it Note" system.

Todo tries to connect to Modal.

Engine sees Modal is missing.

Engine says: "Chill. I'll leave a note." It adds Todo ID to the pendingConnections list for the Modal.

Time passes...

Modal finally renders and registers itself.

Engine checks the notes: "Oh, Todo was waiting for you!" and instantly links them.

Now, it doesn't matter what loads first, second, or last. The graph effectively "heals" itself as components arrive.

The Implementation Details

Having the whole picture defined, let me show you the implementation of the brain behind all this fun(fuuun, of course).

FocusEngine Implementation:

export class FocusEngineService implements FocusEngine {
  public readonly graph = new Map<FocusArea, Set<FocusArea>>();
  public readonly registry = new Map<string, FocusArea>();
  public readonly pendingConnections = new Map<string, Set<string>>;

  public focusedGraphPart = signal<FocusedGraphPart | undefined>(undefined);

  public register(areaId: string, area: FocusArea, connectedIds?: string[]): void {
    this.registry.set(areaId, area);

    const registeredArea = this.registry.get(areaId)!;

    if (connectedIds) {
      connectedIds.forEach((connectionId: string) => {
        const connectedArea = this.registry.get(connectionId);

        if (connectedArea) {
          this.link(registeredArea, connectedArea);
        } else {
          this.pendingConnections.set(
              connectionId, 
              (this.pendingConnections.get(connectionId) ?? new Set<string>()).add(areaId)
          );
        }
      })
    }

    if (this.pendingConnections.has(areaId)) {
      this.resolvePendingConnectionsOfArea(areaId);
    }
  }

  // We create a mirror connection to support future cleanup (Symmetry)
  public link(areaA: FocusArea, areaB: FocusArea): void {
    this.graph.set(areaA, (this.graph.get(areaA) ?? new Set<FocusArea>()).add(areaB))
    this.graph.set(areaB, (this.graph.get(areaB) ?? new Set<FocusArea>()).add(areaA))
  }

  public unlink(areaA: FocusArea, areaB: FocusArea): void {
    const areaAConnections = this.graph.get(areaA);
    const areaBConnections = this.graph.get(areaB);

    if (areaAConnections) {
      areaAConnections.delete(areaB);
    }

    if (areaBConnections) {
      areaBConnections.delete(areaA);
    }
  }

  public unregister(areaId: string) {
    const area = this.registry.get(areaId);

    if (area) {
      const areaConnections = this.graph.get(area);

      if (areaConnections) {
        [...areaConnections].forEach((connection) => {
          this.unlink(area, connection);
        })
      }

      this.registry.delete(areaId);
      this.graph.delete(area);
    }
  }

  public activate(focusedArea: FocusArea): void {
    const registryFocusedArea = this.registry.get(focusedArea.id);

    if (registryFocusedArea) {
      this.focusedGraphPart.set({
        originArea: focusedArea,
        connections: this.graph.get(registryFocusedArea) ?? new Set()
      });
    }
  }

  public isActive(area: FocusArea): boolean {
    const focusedGraphPart = this.focusedGraphPart();

    return focusedGraphPart ? focusedGraphPart.originArea === area || focusedGraphPart.connections.has(area) : false
  }

  private resolvePendingConnectionsOfArea(areaId: string): void {
    const pendingConnections = this.pendingConnections.get(areaId)!;

    pendingConnections.forEach((dependentId: string) => {
      const connectedArea = this.registry.get(dependentId);

      if (connectedArea) {
        this.link(this.registry.get(areaId)!, connectedArea);
      }
    })

    this.pendingConnections.delete(areaId);

  }
}

This is kind of it. We solved our problem.

Now the code in the modal component looks amazingly simple.

In the modal component, we can simply do:


  this.initialize({areaId: 'TODO_CREATE_MODAL', connectedIds: []});

  // Treat this as a reaction to the TODO click.
  // The modal becomes active and listens to the `cardHeight` variable so it can adjust its height.
  effect(() => {
      this.cardHeight = this.isActive() ? `${config.maximumSize}px` : `${config.minimumSize}px`;
    });

In the TODO component, we can do this:


  this.initialize({areaId: `TODO_${this.todo().id}`, connectedIds: ['TODO_CREATE_MODAL']})

The full code can be found in this repo: Live Todo Repo

Feel free to clone it and observe everything in action. I am too tired to add more details, but I believe that those who are interested will have enough curiosity to investigate. I don't want to serve everything on a silver platter, fellow developers!

Also, as a cherry on top, when I also registered the whole backgound of the app as separate node with **no connections.
When I click on the background, another part of the graph just simply activates, so modal and todo becomes inactive.

No need for modal to even know about this. That was the entire point.

Closing Thoughts

Being curious about why I had to go through literal hell to build this, I asked my fellow Gemini: "Bro, why did no one come up with this idea before me?"

What I found left me in shock.

This WAS done before. Not in the Web universe, but in the universe of Smart TVs and Game Consoles.

Thinking about this in retrospect, it becomes pretty obvious. I am a real enjoyer of video games, and console developers had to solve this problem because the user doesn't have a mouse. They only have arrow keys to click. So user interaction literally looks like this: Area 1 -> (arrowRight) -> Area 2 -> Area 3, etc. Console devs needed a map of possible interactions for every point on the screen.

And now, thanks to this experiment, this pattern has migrated to the Web.

All the best,

Yours, Alex.

Reactive library in ~60 lines of code

Aleks Onyshko — Thu, 13 Feb 2025 09:36:03 +0000

This article is heavily inspired by great article of Ryan Carniato

https://dev.to/ryansolid/building-a-reactive-library-from-scratch-1i0p
Minko Gechev's implementation of this library https://github.com/mgechev/revolt/blob/main/lib/signal.ts

Feel free to check them out! My motivation for writing this article is to make these concepts even more understandable

@ryansolid and @mgechev are very intelligent and I had to spend a considerable amount of time to fully understand the solution. It is just ~60 lines of code and at first glance seems quite straightforward but when trying to comprehend what is really going on it appears very complex (subjectively for me).

This article will be about breaking down the solution listed in 2 articles above, so please check them out first.

Implementation starts

First, we have to define what we want. We will have two main entities Signal and Effect . Signal should store and return current value of a Signal. It should also trigger an Effect , if Effect used a Signal and Signal new value was set.

Let's try to represent this in the code.

type ReadableSignal<T> = () => T; // yes, indeed, signal is just a function that return value

Then we can have a Signal which value we can change

interface WritableSignal<T> extends ReadableSignal<T> {
  set(value: T): void;
}

Let's then create an actual code that will produce us these objects.

function signal<T>(value: T): WritableSignal<T> {
  const read = () => {
    return value;
  }

  // we use the fact that functions in js are just objects
  read.set = (nextValue: T) => {
      value = nextValue;
  };

  return read;
}

Now can even can see how these Signal are working!

const count = signal(0);
console.log(count()); // 0

count.set(1);
console.log(count()); // now it is 2

But by their own, Signal are not very useful. They are just now containers of value and with ability to change this value.
True power of Signal is felt, when someone can listen to changes in this Signal. They are event emitters after all.

Effect

So now just quick recap of what we want.

const count = signal(0);

effect(() => {
    console.log(count()); // executes initially
})

count.set(1); // effect is triggered and we will see 1 in the console

First we will need something that represents and Effect

type Effect = () => void; // yes, effects are just functions that returns nothing

And now we have to create effect function;

function effect(fn: Effect): void {
  const execute = () => {
    fn();
  }

  execute();
}

This is not very useful yet, but this is a start.

How to let Signal and Effect know about each other?

We will need something like this.

//                 +---------------------+
//                 | Global Context [E]  |
//                 +---------------------+
//                       /          \
//                      /            \
//                     v              v
// +-----------------------+ <=====> +-------------------------------------------+
// |       Signal S        |         |         Effect E                          |
// |     value: X          |         |       execute()                           |
// | subscriptions: { E }  |         | dependencies: {S.subscriptions reference} |
// +-----------------------+         +-------------------------------------------+
//

Let me try implement it in a code, so it will be a little bit more clear.

So the idea is that in GlobalContext we will have access to currenty executed Effect. Let's start be defining a type.

interface RunningEffect {
    execute: () => void; // a callback in the effect that should be invoked
    dependencies: Set<Set<RunningEffect>> // you can think of this as refs to signals 
}

Let's create a context

const context: Running[] = [];

Then we have to push this RunningEffect whenever an effect callback is executed(just a reminder it is executed every time, a Signal used inside of that Effect has reveived a new value).

It will look like this

function effect(fn: Effect): void {
    const execute = () => {
        context.push(running); // adding effect to context

        try {
            fn();
        } finally {
            context.pop(); // after completion of effect remove it from stack
        }
    }

    const running: Running = {
        execute,
        dependencies: new Set<Set<Running>>() // treat this Set<Signal> for simplicity
    }

    execute();
}

Now we have to finish the puzzle in Signal

function signal<T>(value: T): WritableSignal<T> {
    // Set of Effects that listens to this signals
    const subscriptions: Set<Running> = new Set();

    const read = () => {
        const running = context[context.length - 1]; 
        // get currently executed effect. Keep in mind, 
        // that js is one-threaded,
        // so basically we have a guarantee 
        //that if we have an Effect in the context,
    // then this signal is being read from that Effect

    // if we have a running effect right now
        if(running) {
            // add effect to subscriptions of signal
            subscriptions.add(running); 

            // add a reference of subscriptions 
            //to the currently running effect
            running.dependencies.add(subscriptions);
        }

        return value;
    }

    read.set = (nextValue: T) => {
        value = nextValue;

        // triggering an Effect is signal value is changed
        for(let sub of [...subscriptions]) {
            sub.execute();
        }
    };

    return read;
}

Now we have the whole picture

type ReadableSignal<T> = () => T;
interface WritableSignal<T> extends ReadableSignal<T> {
    set(value: T): void; 
}

type Effect = () => void;

interface Running {
    execute: () => void; // a callback in the effect that should be invoked
    dependencies: Set<Set<Running>> // Set of Effects that correspond to particular Signal
}

const context: Running[] = []; // context of running effects

function signal<T>(value: T): WritableSignal<T> {
    // Set of Effects that listens to this signals
    const subscriptions: Set<Running> = new Set();

    const read = () => {
        const running = context[context.length - 1]; 

    // if we have a running effect right now
        if(running) {
            // add effect to subscriptions of signal
            subscriptions.add(running); 

            // add a reference of subscriptions 
            //to the currently running effect
            running.dependencies.add(subscriptions);
        }

        return value;
    }

    read.set = (nextValue: T) => {
        value = nextValue;

        // triggering an Effect is signal value is changed
        for(let sub of [...subscriptions]) {
            sub.execute();
        }
    };

    return read;
}

function effect(fn: Effect): void {
    const execute = () => {
        context.push(running); // adding effect to context

        try {
            fn();
        } finally {
            context.pop(); // after completion of effect remove it from stack
        }
    }

    const running: Running = {
        execute,
        dependencies: new Set<Set<Running>>()
    }

    execute();
}

This implementation is great!! But it is far too soon to clebrate. We have a problem.

Imagine we have this scenario. It is an Effect that reads Signals conditionally.

const count = signal(0);
const count2 = signal(666);

const condition = signal(true);

effect(() => {
    if(condition()) {
        console.log(count());
    } else {
        console.log(count2());
    }
})

// initial log of effect - 0, as condition() is true and count() is being read

condition.set(false);

// logs 666 as condition() is false

count.set(1);

// logs 666 again!!!!

We expect Effec to not trigger itself as count() should not be accessed.

We have to introduce some cleanup, so every time effect is executed, it's dependencies should be rebuild.

function cleanup(running: Running): void {
    for(const dep of running.dependencies) {
       // we delete Effect ref from every Signal, 
       // running.dependencies === Signal.subscriptions
        dep.delete(running);
    }

    running.dependencies.clear(); // we clear the effect from all dependencies
}

Now we have to add it to the Effect lifecycle.

function effect(fn: Effect): void {
    const execute = () => {
        cleanup(running); // cleans up before every execution
        context.push(running);

        try {
            fn();
        } finally {
            context.pop();
        }
    }

    const running: Running = {
        execute,
        dependencies: new Set<Set<Running>>()
    }

    execute();
}

That's it!! With this adaptions our problem is solved!

const count = signal(0);
const count2 = signal(666);

const condition = signal(true);

effect(() => {
    if(condition()) {
        console.log(count());
    } else {
        console.log(count2());
    }
})

// initial log of effect - 0, as condition() is true and count() is being read

condition.set(false);
// logs 666 as condition() is false

count.set(1);
// nothing is being logged!!!

Here is the full code with the diagram

type ReadableSignal<T> = () => T;
interface WritableSignal<T> extends ReadableSignal<T> {
    set(value: T): void;
}

type Effect = () => void;

interface Running {
    execute: () => void;
    dependencies: Set<Set<Running>>
}

const context: Running[] = [];

function signal<T>(value: T): WritableSignal<T> {
    const subscriptions: Set<Running> = new Set();

    const read = () => {
        const running = context[context.length - 1];

        if(running) {
            subscriptions.add(running);
            running.dependencies.add(subscriptions);
        }

        return value;
    }

    read.set = (nextValue: T) => {
        value = nextValue;

        for(let sub of [...subscriptions]) {
            sub.execute();
        }
    };

    return read;
}

function cleanup(running: Running): void {
    for(const dep of running.dependencies) {
        dep.delete(running);
    }

    running.dependencies.clear();
}

function effect(fn: Effect): void {
    const execute = () => {
        cleanup(running);
        context.push(running);

        try {
            fn();
        } finally {
            context.pop();
        }
    }

    const running: Running = {
        execute,
        dependencies: new Set<Set<Running>>()
    }

    execute();
}

//                 +---------------------+
//                 | Global Context [E]  |
//                 +---------------------+
//                       /          \
//                      /            \
//                     v             v
// +-----------------------+ <=====> +-------------------------------------------+
// |       Signal S        |         |         Effect E                          |
// |     value: X          |         |       execute()                           |
// | subscriptions: { E }  |         | dependencies: {S.subscriptions reference} |
// +-----------------------+         +-------------------------------------------+
//

Wish you happy coding. If anything is unclear please don't hesitate to comment.

Building a Generic Virtual Scroll Table in Angular: A Scalable Approach

Aleks Onyshko — Wed, 05 Feb 2025 16:14:34 +0000

Introduction

Handling large lists efficiently is a common challenge in web applications. Standard tables can cause performance issues when rendering thousands of rows. Virtual scrolling solves this by rendering only the visible portion of the list, significantly improving performance.

But what if we need to display different types of data using the same virtual scroll logic? Without a generic approach, we'd end up copy-pasting table implementations, leading to redundant code.

This article introduces a Generic Virtual Scroll Table in Angular, which supports different data structures while maintaining a clean and reusable architecture.

The Problem: Avoiding Code Duplication

Imagine a scenario where different modules in an application require tables for displaying:

Users
Orders
Products
Custom Fields

Each table shares the same core functionality:

Fetching paginated data
Virtual scrolling
Item selection
Handling empty states

A common mistake is to create separate table components for each entity, leading to repeated logic and high maintenance costs. If a bug is found in one table, we have to fix it in multiple places.

To solve this, we need a generic solution—one component that can handle any type of list item.

The Solution: A Generic Virtual Scroll Table

We achieve this by implementing a base component that can display any type of data while keeping business logic separate in a dedicated service.

Step 1: Define a Generic Interface for Table Items

Every item displayed in our table must have a unique identifier. We define a generic interface:

export interface VirtualScrollTableItem {
  id: number;
}

This ensures that all items used in the table follow a consistent structure.

Step 2: Create the Generic Table Component

The core of our solution is the VirtualScrollTableComponent, which acts as a template component for any virtual scroll table.

IMPORTANT: @ContentChild('itemTemplate', { static: true }) public itemTemplateRef: any; - makes sure we can have any content we want as an item for the row

@Component({
  selector: 'virtual-scroll-table',
  templateUrl: './virtual-scroll-table.component.html',
  styleUrls: ['./virtual-scroll-table.component.less'],
  changeDetection: ChangeDetectionStrategy.OnPush,
  encapsulation: ViewEncapsulation.None
})
export class VirtualScrollTableComponent<T extends VirtualScrollTableItem> implements OnInit {
  @HostBinding('class.virtual-scroll-table') public hostCls = true;

  // allows as to have any generic item displayed here
  @ContentChild('itemTemplate', { static: true }) public itemTemplateRef: any;

  public readonly items$: Observable<T[]>;
  public readonly isEmpty$: Observable<boolean>;
  public readonly loading$: Observable<boolean>;
  public readonly selectedItems$: BehaviorSubject<Record<number, T>>;

  @ViewChild(CdkVirtualScrollViewport) public viewport: CdkVirtualScrollViewport;

  // here we rely on the service being provided in viewProviders
  // of parent component
  constructor(@SkipSelf() @Host() private virtualScrollTableService: VirtualScrollTableService<T>) {
    this.items$ = this.virtualScrollTableService.items$;
    this.isEmpty$ = this.virtualScrollTableService.isEmpty$;
    this.loading$ = this.virtualScrollTableService.loading$;
    this.selectedItems$ = this.virtualScrollTableService.selectedItems$;
  }

  public ngOnInit(): void {
    this.virtualScrollTableService.loadItems();
  }

  public onRequestNextPage(): void {
    this.virtualScrollTableService.onRequestNextPage(this.viewport);
  }

  public selectionChanged(selected: boolean, item: T): void {
    this.virtualScrollTableService.selectionChanged(selected, item);
  }
}

This component is completely independent of data type, making it reusable for any kind of list.

Template looks like this, as generic as possible

<ng-container *ngIf="(isEmpty$ | async) === false; else emptyPage">
  <div class="virtual-scroll-table_row--sticky" *ngIf="(items$ | async).length > 0">
    <div class="virtual-scroll-table_row--sticky_item" *ngFor="let item of stickyRowConfig">{{ item | translate }}</div>
  </div>

  <cdk-virtual-scroll-viewport
    [itemSize]="itemSize"
    [minBufferPx]="60"
    [maxBufferPx]="120"
    (scrolledIndexChange)="onRequestNextPage()">
    <div class="virtual-scroll-table_row" *cdkVirtualFor="let item of items$ | async; index as i; trackBy: trackByFn">
      <mat-checkbox
        #checkbox
        class="virtual-scroll-table_row_checkbox"
        *ngIf="selectionEnabled" 
        [checked]="!!(selectedItems$ | async)?.[item.id]" 
        (click)="selectionChanged(checkbox.checked, item)">
      </mat-checkbox>

      <div class="virtual-scroll-table_row_content">
        <ng-container [ngTemplateOutlet]="itemTemplateRef" [ngTemplateOutletContext]="{ $implicit: item, index: i }"></ng-container>
      </div>
    </div>

    <loading-mask *ngIf="(loading$ | async) && (items$ | async).length > 0" class="virtual-scroll-table_row-loader"></loading-mask>
  </cdk-virtual-scroll-viewport>
</ng-container>

<loading-mask
  *ngIf="(loading$ | async) && (items$ | async).length === 0"
  class="virtual-scroll-table_fullscreen-loader">
</loading-mask>

<ng-template #emptyPage>
  <empty-page [config]="emptyPageConfig"></empty-page>
</ng-template>

Step 3: Define a Base Service for Managing Data

Instead of handling data inside the component, we delegate the logic to a service that follows a common interface.

export abstract class VirtualScrollTableService<T extends VirtualScrollTableItem> {
  public readonly items$: Observable<T[]>;
  public readonly isEmpty$: Observable<boolean>;
  public readonly loading$: Observable<boolean>;
  public readonly selectedItems$ = new BehaviorSubject<Record<number, T>>({});

  public abstract loadItems(): void;
  public abstract onRequestNextPage(viewport: CdkVirtualScrollViewport): void;
  public abstract selectionChanged?(selected: boolean, item: T): void;
  public abstract clearSelection?(): void;
}

This forces all virtual table services to follow the same contract while allowing flexibility for different data sources.

Step 4: Implement a Domain-Specific Service

We start be creating wrapper component

@Component({
  selector: 'custom-fields-virtual-scroll-table',
  imports: [CommonModule, VirtualScrollTableComponent, CustomFieldsTableRowComponent],
  templateUrl: './custom-fields-virtual-scroll-table.component.html',
  styleUrls: ['./custom-fields-virtual-scroll-table.component.less'],
  changeDetection: ChangeDetectionStrategy.OnPush,
  encapsulation: ViewEncapsulation.None,
  viewProviders: [
    {
      provide: VirtualScrollTableService,
      useFactory: (customFieldStore: CustomFieldsStore, store: Store<any>) =>
        new CustomFieldsVirtualScrollTableService(customFieldStore, store),
      deps: [CustomFieldsStore, Store<any>]
    }
  ]
})
export class CustomFieldsVirtualScrollTableComponent{ }

As you can see it is empty, which is very good, as it means that we did a good job of extracting common logic

Then,, if we want a table for custom fields, we create a dedicated service:

@Injectable()
export class CustomFieldsVirtualScrollTableService
  extends ReactiveService
  implements VirtualScrollTableService<CustomField> {

  public readonly items$: Observable<CustomField[]>;
  public readonly isEmpty$: Observable<boolean>;
  public readonly loading$: Observable<boolean>;
  public readonly selectedItems$ = new BehaviorSubject<Record<number, CustomField>>({});

  constructor(public customFieldsStore: CustomFieldsStore, private store: Store<any>) {
    super();

    this.items$ = combineLatest([
      this.store.select(selectCustomFieldEntities),
      this.customFieldsStore.customFieldIds$
    ]).pipe(map(([customFields, customFieldIds]) => customFieldIds.map(id => customFields[id])));

    this.isEmpty$ = this.customFieldsStore.hasCustomFields$.pipe(map(hasFields => !hasFields));
    this.loading$ = this.customFieldsStore.loading$;
  }

  public loadItems(): void {
    this.customFieldsStore.loadCustomFields$();
  }

  public onRequestNextPage(viewport: CdkVirtualScrollViewport): void {
    this.customFieldsStore.loadNextBatch$();
  }
}

Final piece

<virtual-scroll-table>
  <ng-template #itemTemplate let-customField let-id="index">
    <custom-fields-table-row
        [customField]="customField">
    </custom-fields-table-row>
  </ng-template>
</virtual-scroll-table>

Conclusion

Using a Generic Virtual Scroll Table in Angular eliminates repetitive code and provides a scalable, maintainable, and efficient way to handle large lists. By separating UI concerns from data logic, this approach ensures long-term maintainability and flexibility.

If you're building tables in Angular, don’t fall into the copy-paste trap—invest in a reusable architecture today!

Lifecycle Hooks in Angular Redefined

Aleks Onyshko — Sat, 18 Jan 2025 20:27:44 +0000

Introduction

Angular developers have long relied on lifecycle hooks to manage component behavior and interactions with the DOM. However, the introduction of signal-based APIs represents a significant shift in how developers can write reactive and declarative code. This article explores how to transition from traditional lifecycle hooks to modern signal-based APIs, demonstrating how these new tools simplify code, enhance reactivity, and reduce boilerplate.

ngOnInit

Why we used ngOnInit?

The ngOnInit lifecycle hook was essential in traditional Angular development for basically 2 things:

Working with @Input Properties: Ensuring @Input values are initialized and available for use after the component is created.
Performing Network Requests: Fetching data once all inputs are available to ensure the component has the necessary information to render.

Old Way:

@Component({ ... })
class UserComponent implements OnInit {
  @Input() name: string;
  @Input() lastName: string;
  @Input() userId: string;

  fullName: string;
  userData: string;

  constructor(private httpClient: HttpClient) {}

  ngOnInit(): void {
    // getting access to inputs here
    this.fullName = `${this.name} ${this.lastName}`;
    this.httpClient
      .get(`https://api.example.com/user/${this.userId}`)
      .subscribe((data: any) => {
        this.userData = data.name;
      });
  }
}

New way:

@Component(...)
class UserComponent {
  // signal based inputs!!!
  name = input.required<string>();
  lastName = input.required<string>();
  userId = input.required<string>();

  // no need for ngOnInit anymore
  fullName = computed(() => `${this.name()} ${this.lastName()}`);

  // signal based way yo do network request
  userData = resource({
    request: () => ({ id: this.userId() }),
    loader: (request) => 
      this.httpClient
        .get(`https://api.example.com/user/${request.id}`)
  });
}

Key Benefits of Signals:

Immediate Access to Inputs: No need to wait for lifecycle hooks; inputs are available as signals from the start.
Reactive State Management: computed and resource ensure the UI is always in sync with the latest state.
Simpler Code: Removes the boilerplate associated with lifecycle hooks and manual subscriptions.

ngOnChanges

Why we used ngOnChanges?
The ngOnChanges lifecycle hook allowed developers to listen for changes in @Input properties and respond to them appropriately.

Old way:

@Component(...)
class UserComponent implements OnChanges {
  @Input() name: string;
  @Input() lastName: string;

  fullName: string;

  ngOnChanges(changes: SimpleChanges): void {
    if (changes.name || changes.lastName) {
      this.fullName = `${this.name} ${this.lastName}`;
      console.log('Input changes detected:', this.fullName);
    }
  }
}

New way:

@Component(...)
class UserComponent {
  name = input.required<string>();
  lastName = input.required<string>();

  fullName = computed(() => `${this.name()} ${this.lastName()}`);
}

Pretty easy right? For me, subjectively and probably objectively this is much more understandable.

ngOnDestroy

Why we used ngOnDestroy:

The ngOnDestroy lifecycle hook was traditionally used for cleanup tasks, such as unsubscribing from observables, clearing intervals, or detaching event listeners.

Old way:

@Component(...)
export class CleanupComponent implements OnDestroy {
  private intervalId: any;

  constructor() {
    this.intervalId = setInterval(() => {
      console.log('Interval running');
    }, 1000);
  }

  ngOnDestroy(): void {
    clearInterval(this.intervalId);
    console.log('Interval cleared');
  }
}

New way

@Component(...)
export class CleanupComponent {
  constructor() {
    const intervalId = setInterval(() => {
      console.log('Interval running');
    }, 1000);

    inject(DestroyRef).onDestroy(() => {
      clearInterval(intervalId);
    });
  }
}

The "After" Hooks

Why we used After Hooks:

Angular's "After" hooks were used to interact with the DOM or its projected content once Angular completed rendering. These hooks include:
ngAfterContentInit: Triggered once after Angular projects external content into the component's view.
ngAfterContentChecked: Invoked after every check of the projected content.
ngAfterViewInit: Runs once after Angular initializes the component's view and its children.
ngAfterViewChecked: Called after every check of the component's view and its children.

Old Way

@Component({ template: '<canvas #myCanvas></canvas>' })
export class FooComponent implements 
  AfterViewInit, AfterViewChecked 
{
  @ViewChild('myCanvas') myCanvas: ElementRef<HTMLCanvasElement>;

  ngAfterViewInit() {
    initCharts(this.myCanvas.nativeElement);
    console.log('Charts initialized');
  }

  ngAfterViewChecked() {
    console.log('View checked');
  }
}

New way

@Component({ template: '<canvas #myCanvas></canvas>' })
export class FooComponent {
  myCanvas = viewChild('myCanvas');

  constructor() {
    // runs once after the app rendered 
    afterNextRender(() => {
      initCharts(this.myCanvas());
      console.log('Charts initialized');
    });

    afterRender(() => {
      // runs every time app renders something 
      console.log('View updated');
    });
  }
}

ngDoCheck

Personally I used it very-very rarely in my practise.

Just use effect(), should be completely enough.

Summary

By transitioning to signal-based APIs, Angular developers can:

Eliminate the need for lifecycle hooks like ngOnInit, ngOnChanges, ngOnDestroy, and others.
Write more declarative, reactive, and maintainable code.
Simplify resource management, dependency tracking, and UI updates.
This evolution represents a significant step forward in Angular development, making applications cleaner, more performant, and easier to debug.

Wish you happy coding with this knowledge and hope you learn something new today!

Framework agnostic Avatar component

Aleks Onyshko — Wed, 27 Nov 2024 12:00:45 +0000

Hello! Today I would like to discuss my journey of creating an Avatar component and its evolution by applying best OOP practises.

In this article, we'll explore:

Basic avatar implementation
Evolution to clean architecture
Why certain patterns were chosen
Common pitfalls and solutions
Real-world considerations

Let's start.

Introduction

So, imagine you have a task, create an Avatar component that represents some user in the system. It will look like this UI wise.

Nothing really complicated right?
As an experienced developer, you might right away start to asses what data would you need for that component.

You would need probably some object that will hold username(tooltip purposes), backgroundImageUrl, size(how big you avatar would be).

So, let's create this object and define it in our system by something like this

export class AvatarConfiguration {
  public backgroundColor: string = '#666666';
  public backgroundImageUrl: string | null = null;
  public size: number | AVATAR_SIZE = AVATAR_SIZE.m;
  public fontSize: number | TEXT_SIZE = TEXT_SIZE.m;
  public cssClass: string = '';
  public email: string = '';
  public username: string = '';
  public placeholder: string = '';
  public id: string = '';
}

And then we might as well define and AvatarComponent as well that gets this info via @Input().

@Component({
  selector: 'app-avatar',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
   <div class="avatar avatar--size-{{ config.size }}">
     @if(!!config.backgroundImageUrl) {
       <span class="avatar_image"
        [style.background-image]="
         'url('+ config.backgroundImageUrl + ')'
       "></span>
  } @else {
    <span 
     class="avatar_placeholder
     avatar_placeholder--{{ config.size | avatarSizeModifiers }}">
      {{  config.placeholder }}
    </span>
  }
</div>

  `
})
export class AvatarComponent {
  @Input({ required: true }) config!: AvatarConfiguration;
}

And final piece of the puzzle, as we need somehow to build this configuration and we don't want to create that configuration in a lot of places, we might as well implement very handy pattern called Builder

export class AvatarConfigurationBuilder {
  public config: AvatarConfiguration;

  constructor() {
    this.config = this.createConfig();
  }

  public withUsername(username: string) {
    this.config.username = username;
    return this;
  }

  public withPlaceholder(username: string) {
    this.config.placeholder = this.createPlaceholder(username);
    return this;
  }

  public withBackgroundImageUrl(imageUrl: string) {
    this.config.backgroundImageUrl = imageUrl;
    return this;
  }

  public withSize(size: number | AVATAR_SIZE) {
    this.config.size = +size;
    return this;
  }

  public build(): AvatarConfiguration {
    return this.config;
  }

  public createConfig(): AvatarConfiguration {
    return new AvatarConfiguration() as T;
  }

  ...other methods
}

As you can see we can already create some configurations, we made this builder to be responsible for creation of that AvatarConfiguration and we are free to go!

In the code we already can use that builder to create our beloved AvatarConfiguration, we can just use

new AvatarConfigurationBuilder()
.withPlaceholder('placeholder')
.withBackgroundImageUrl('some url)
.build()

and it will return us what we need.

Conclusions

There are no problems if our implementation stays still. But as we know, usually times throws new challenges(also known as features).

What I particularly faced was upload functionality.
And here where I have faced a lot of problems and challenges.

Journey begins

First you might think, what is the big problem, you can add corresponding functionality to the avatar.component and easy peasy.
Not so fast.

export class AvatarComponent {
  constructor(private storage: Storage) {} // 😱 Direct Firebase dependency

  async uploadNewImage() {
    const input = 
     document.createElement('input'); // 😱 Direct DOM manipulation
    input.type = 'file';
    input.onchange = async (e) => {
      const file = (e.target as HTMLInputElement).files![0];
      // 😱 Direct Firebase upload
      const storageRef = ref(this.storage, file.name);
      const uploadTask = uploadBytesResumable(storageRef, file);
      // ... upload logic
    };
    input.click();
    ...rest of the logic
  }
}

This is a working solution and if you satisfied with it, it is totally fine. Most people do like this, implement something right away, so it works and then stop. I completely understand that someone might have short deadlines or other reasons, but what is important that result still stays the same. *Awfully complicated tries to maintain this code.
*

So logical question how to make this code maintainable?

First I would start by creating an abstract representation of our beloved Avatar.

export abstract class Avatar {
  public configuration!: AvatarConfiguration;

  protected constructor(config: AvatarConfiguration) {
    this.configuration = config;
  }
}

Simple enough. As you could have already seen, AvatarConfiguration is just a simple class that holds a bunch of values for Avatar, and it is very suitable as a part of Avatar and NOT its representation.

Then next logical step would be define an Avatar with upload capabilities.

// following Interface Segregation principle!
interface WithUpload {
  fileUploadImplementation: FileUpload;
  fileExtractorImplementation: FileExtractor;
  uploadFn: () => Promise<string>;
}

export abstract class AvatarWithFileUpload extends Avatar implements WithUpload {
  public uploadFn: () => Promise<string>;

  protected constructor(
    config: AvatarConfiguration,
    // abstraction over file upload functionality
    public fileUploadImplementation: FileUpload,
    // abstraction over file extract functionality
    public fileExtractorImplementation: FileExtractor
  ) {
    super(config);

    this.uploadFn = () =>
      firstValueFrom(
        this.fileExtractorImplementation.getFiles(true).pipe(
          switchMap(files => {
            return this.fileUploadImplementation
              .uploadFileToStorage(files[0]).pipe(
                map(downloadUrl => {
                this.configuration.backgroundImageUrl = downloadUrl!;

                return downloadUrl!;
              })
            );
          }),
          take(1)
        )
      );
  }
}

So as you can see uploadFn() which represent an ability of Avatar
to change it's background image and in meanwhile relying on only abstractions.

Let me show you how FileUpload and FileExtractor are built.

MORE ABSTRACTIONS!!!

I know it's already sounds like over complication but bear with me!

FileExtractor

export abstract class FileExtractor {
  public abstract getFiles(single?: boolean, supportedFileTypes?: string[]): Observable<File[]>;
}

As you can see it is a simple contract that simply states - "You give me some options, I give you stream with files". That's how we can abstract from any specifics of OS and browser, as long as they can guarantee consistency with interfaces(Observable, File).

FileUpload

export abstract class FileUpload {
  public abstract uploadFileToStorage(file: File): Observable<string | null>;
}

The same goes here, we can possibly upload to any storage in the world.

Now final piece of abstraction cake is to define something that will give Avatars I want, basic one and the ONE with upload functionality.

export abstract class AvatarFactory {
  abstract createAvatar
    (user: User, params?: Partial<AvatarConfiguration>): Avatar;
  abstract createAvatarWithUpload
   (user: User, params?: Partial<AvatarConfiguration>): AvatarWithFileUpload;
}

The power of this cannot be underestimated. This code will be working in any framework where typescript is used and easily converted into library.

You might be already questioning where is Angular in all of this.
Now let me show how this code can work with Angular.

Dive back to Angular

So in my real case scenario, it was an angular app for music school called Touche. So my Avatar now has some context and can building its own representation in Touche angular app.

Parade of implementations, or where the fun begins:

(I put all abstractions and implementations in one file for simplicity, they can be easily separated and that's great!)

Avatar

export abstract class Avatar {
  public configuration!: AvatarConfiguration;

  protected constructor(config: AvatarConfiguration) {
    this.configuration = config;
  }
}

// real implementation of avatar in Touche project
export class ToucheAvatar extends Avatar {
  constructor(config: AvatarConfiguration) {
    super(config);
  }
}

Avatar with upload capabilities!

export class ToucheAvatarWithFileUpload extends AvatarWithFileUpload {
  constructor(
    config: AvatarConfiguration,
    fileUploadImplementation: FileUpload,
    fileExtractorImplementation: FileExtractor
  ) {
    super(config, fileUploadImplementation, fileExtractorImplementation);
  }
}

as a reminder, abstract counterpart =>
export abstract class AvatarWithFileUpload extends Avatar implements WithUpload {
  public uploadFn: () => Promise<string>;

  protected constructor(
    config: AvatarConfiguration,
    public fileUploadImplementation: FileUpload,
    public fileExtractorImplementation: FileExtractor
  ) {
    super(config);

    this.uploadFn = () =>
      ...default upload code
    );
  }
}

AvatarsFactory

Main place where all everything is combined

// will come in handy later!!!
@Injectable()
export class ToucheAvatarFactory implements AvatarFactory {
  constructor(
    private avatarConfigurationBuilderFactory: AvatarConfigurationBuilderFactory,
    private fileUpload: FileUpload,
    private fileExtractor: FileExtractor
  ) {
    super();
  }

  // basic avatar
  public createAvatar(user: User, params?: Partial<AvatarConfiguration>): Avatar {
    return new ToucheAvatar(this.getDefaultAvatarConfiguration(user, params));
  }
  // upload avatar
  public createAvatarWithUpload(user: User, params?: Partial<AvatarConfiguration>): AvatarWithFileUpload {
    return new ToucheAvatarWithFileUpload(
      this.getDefaultAvatarConfiguration(user, params),
      this.fileUpload,
      this.fileExtractor
    );
  }

  private getDefaultAvatarConfiguration(user: User, params?: Partial<AvatarConfiguration>): AvatarConfiguration {
    return this.avatarConfigurationBuilderFactory
      .getBuilder()
      .withId(user.uid)
      .withUsername(user!.displayName ?? user!.email ?? '')
      .withPlaceholder(user!.displayName ?? user!.email ?? '')
      .withSize(params?.size ?? AVATAR_SIZE.s)
      .withBackgroundImageUrl(user!.backgroundImageUrl)
      .build();
  }
}

// as a reminder of abstraction counterpart 
export abstract class AvatarFactory {
  abstract createAvatar(user: User, params?: Partial<AvatarConfiguration>): Avatar;
  abstract createAvatarWithUpload(user: User, params?: Partial<AvatarConfiguration>): AvatarWithFileUpload;
}

Final setup

We want to finally use all these concrete implementations in UI!
That's the place where Angular DI system comes into play.

const ABSTRACTIONS: Provider[] = [
  {
    provide: FileExtractor,
    useClass: ToucheFileExtractor
  },
  {
    provide: FileUpload,
    useClass: ToucheFileUpload
  },
  {
    provide: AvatarFactory,
    useClass: ToucheAvatarFactory
  },
];

export const applicationConfig: ApplicationConfig = {
  providers: [ABSTRACTIONS]
}

and register them in the providers of new ApplicationConfig property of bootstrapApplication function(standalone architecture) or in appModule.

And now, we can use this factory to get avatars in any @Injectable() service, using abstract class as a reference to concrete implementation!

@Injectable({providedIn: 'root')
export class SomeService
  constructor(
    private avatarFactory: AvatarFactory// Abstraction here!!!
  )
}

So now, by properly setting up abstractions in Angular DI, we are only relying on abstractions and not implementations!

Tell me what you think in the comments!