DEV Community: Ali

I deleted my CanActivate classes and my routing got readable

Ali — Wed, 17 Jun 2026 12:00:00 +0000

For years a route guard meant a class: @Injectable, implements CanActivate, a constructor full of services, and an entry in some providers array you'd inevitably forget. The guard was usually four lines of actual logic wrapped in twenty lines of ceremony. Functional guards deleted the wrapper, and the same inject() move that cleaned up interceptors did it again here.

export const authGuard: CanActivateFn = (route, state) => {
  const auth = inject(AuthService);
  const router = inject(Router);
  return auth.isLoggedIn() || router.createUrlTree(["/login"], {
    queryParams: { returnUrl: state.url },
  });
};

That's the whole thing. No class, no provider registration — you reference the function directly in the route. But the syntax win is the boring part. The interesting part is that going functional made the three jobs guards do finally feel like three different tools instead of one overloaded interface.

Return a UrlTree, not false

The most common guard bug I find in review isn't a logic error — it's a guard that returns false. Returning false cancels the navigation and leaves the user exactly where they were, with no explanation. They clicked a link, nothing happened, and now they think the app is broken. Half the time they're sitting on a blank shell because the click came from a fresh page load.

Returning a UrlTree is almost always what you meant: it cancels the original navigation and redirects in one step. Blocked from a page → send them to /login with a returnUrl so you can bounce them back after they sign in. The rule I use: a guard should either say yes, or say where to go instead. false is for the rare case where staying put with a toast is genuinely the right UX, and even then I'd rather show the toast and redirect.

canActivate vs canMatch — they answer different questions

These get used interchangeably and they shouldn't be. canActivate asks "this route matched the URL — is the user allowed to land on it?" It runs after the router has picked the route. canMatch asks the earlier question: "does this route even apply?" It runs during route matching, before the component is chosen.

That timing difference is the whole point. With canMatch you can have two routes for the same path and let the guard decide which one wins:

const routes: Routes = [
  { path: "dashboard", component: AdminDashboard, canMatch: [isAdmin] },
  { path: "dashboard", component: UserDashboard },
];

Admins match the first route, everyone else falls through to the second. You can't express that with canActivate — by the time it runs, the route is already locked in. The other canMatch superpower: on a lazy route, a failed canMatch means the chunk never even downloads. Guarding a whole admin feature behind canActivate still ships its JavaScript to anonymous visitors; canMatch keeps it on the server.

Small guards compose; god-guards don't

Because canActivate takes an array, I stopped writing guards that check three things and started writing three guards that check one thing each:

{ path: "billing", component: Billing,
  canActivate: [isLoggedIn, hasBillingRole, orgIsActive] }

They run in order and the first one to return a UrlTree wins, so the redirects naturally prioritize: not logged in beats wrong role beats suspended org. Each guard is independently testable and reusable across routes. A single guard doing all three reads fine the day you write it and becomes a tangle of nested conditions the third time someone adds a rule.

Resolvers: powerful, and the easiest way to make your app feel frozen

ResolveFn got the same functional treatment, and it's genuinely useful — but it's the guard-family tool I reach for least, on purpose. A resolver fetches data before the route activates, so the component renders with everything already present. No loading spinner inside the page, no flash of empty state.

export const orderResolver: ResolveFn<Order> = (route) => {
  const id = route.paramMap.get("id")!;
  return inject(OrderService).getOrder(id);
};

The catch is in that word "before." Navigation blocks on the resolver. If the API takes two seconds, clicking the link does nothing visible for two seconds — the user is stuck on the previous page with no feedback. You've moved the loading state from "a spinner on the new page" to "the entire app appears to hang." If you use resolvers, you almost have to wire a progress bar to the router's NavigationStart/NavigationEnd events, or the UX is worse than just fetching in the component.

So my line is: a resolver earns its place when the page is genuinely meaningless without the data — an order detail page with no order isn't a page, it's a 404 waiting to happen, and resolving lets you redirect on a missing record before anything renders. For everything else, fetching in the component with httpResource gives you the same data with an honest, local loading state and no global freeze.

The decision rule

Deciding whether the route applies, or want to skip downloading a lazy chunk → canMatch. Deciding whether this user may enter a route that does apply → canActivate, returning a UrlTree when the answer is no. The page is structurally meaningless without server data, and you've got a progress indicator → ResolveFn. Otherwise, let the component fetch its own data. All three are just functions now, which means all three are just unit tests now too.

My route params bind straight to inputs now

Ali — Tue, 16 Jun 2026 12:00:00 +0000

Here's a pattern every Angular dev has typed a hundred times: a component needs the :id from the URL, so you inject ActivatedRoute, subscribe to paramMap, pull the value, remember to unsubscribe, and handle the fact that the component is reused when only the id changes so ngOnInit won't fire twice. Six lines of plumbing to read one string off the URL.

withComponentInputBinding() deletes all of it. You turn it on once:

bootstrapApplication(App, {
  providers: [provideRouter(routes, withComponentInputBinding())],
});

and now the router sets your component's inputs from the route, matched by name. A route param :id binds to an input called id. That's the entire mental model.

@Component({ /* ... */ })
export class OrderDetail {
  id = input.required<string>(); // <- comes straight from :id
}

Four sources feed the same inputs

It's not just path params. The router binds from four places, and once you know all four you stop reaching for ActivatedRoute almost entirely: resolved data and static data on the route, path params (:id), matrix params, and query params (?tab=invoices). A search page reads its filters as inputs; a wizard reads its step; a detail page reads its id. All by name, all without a subscription.

The one thing you have to internalize is precedence, because all four write to the same input slots. If the same key exists in more than one source, resolved/static data wins, then path params, then query params. The practical consequence: don't name a query param the same thing as something in your resolver data, or the data value silently shadows it and you'll swear the query param "isn't binding." Give colliding things distinct names and the whole feature stays predictable.

The real payoff is signal inputs

Input binding is nice on its own, but combined with input() signals it changes how route-driven components are written. The route param isn't a value you grabbed in ngOnInit — it's a signal that updates when the URL changes. Which means you can derive from it and the reactive graph handles the rest:

id = input.required<string>();

// re-runs automatically when the URL id changes — no subscription,
// no ngOnChanges, no manual refetch
order = httpResource(() => `/api/orders/${this.id()}`);

Navigate from order 7 to order 8 and the component instance is reused, the id signal flips to "8", and httpResource refetches because its url depended on id(). The "component reuse won't re-run my init" problem — the one that sent everyone subscribing to paramMap in the first place — just isn't a problem anymore, because nothing was keyed on a lifecycle hook to begin with.

Where it stops, and that's fine

Two honest limits. First, it binds to the routed component — the one named in the route config. A deeply nested child that wants the parent route's params still reads ActivatedRoute, or you pass them down as inputs yourself. Second, this is a router feature, not magic on every component; a component you drop into a template the normal way gets its inputs from the template, as always.

I treat ActivatedRoute the way I now treat ngOnDestroy: still there, occasionally necessary, but no longer the default reflex. For the common case — a routed component that wants a value off the URL — the value just arrives as an input, and if it's a signal input, it stays correct on its own.

SignalStore is the first NgRx I'd actually reach for

Ali — Mon, 15 Jun 2026 12:00:00 +0000

I've spent a good chunk of my career talking teams out of NgRx. Not because the Redux pattern is wrong — because most apps that adopted it didn't have a Redux-shaped problem. They had a "two components need the same list" problem, and they paid for it with an action, a reducer case, an effect, a selector, and three files, per feature. The ratio of ceremony to value was brutal.

SignalStore is the first time the NgRx name has shown up in my projects without me wincing. It throws out the dispatch/reducer machinery and builds on signals directly. State is signals you read; methods are functions that change them. That's the model.

export const CartStore = signalStore(
  { providedIn: "root" },
  withState({ items: [] as Item[], loading: false }),
  withComputed(({ items }) => ({
    count: computed(() => items().length),
    total: computed(() => items().reduce((s, i) => s + i.price, 0)),
  })),
  withMethods((store) => ({
    add(item: Item) {
      patchState(store, { items: [...store.items(), item] });
    },
    clear() {
      patchState(store, { items: [] });
    },
  })),
);

count and total are signals. add and clear are methods. A component injects the store and reads store.count() in its template like any other signal. No store.select(...), no string action types, no switch statement. The thing that used to be five concepts is now two: withState and withMethods.

patchState, and the immutability you can't skip

You never assign to state directly — you call patchState with a partial update or an updater function. And the array spread in add above isn't optional styling: SignalStore state follows the same rule signals always do. Mutating the existing array in place (items().push(item)) changes the contents without changing the reference, so the signal never fires and your computed count goes stale. Treat state as immutable, produce new references, and the reactive graph stays honest. This is the one rule that trips people coming from the mutate-anything world.

rxMethod is where the async lives

Real stores fetch. rxMethod is the bridge to RxJS for exactly that — it takes a stream of inputs and lets you run an Observable pipeline per emission, with proper cancellation:

loadItems: rxMethod<string>(
  pipe(
    tap(() => patchState(store, { loading: true })),
    switchMap((cartId) =>
      cartService.fetch(cartId).pipe(
        tapResponse({
          next: (items) => patchState(store, { items, loading: false }),
          error: () => patchState(store, { loading: false }),
        }),
      ),
    ),
  ),
)

The switchMap there is doing the work an NgRx effect used to: a second call cancels the first in-flight request, so a fast-typing user doesn't race two responses into your state out of order. This is the spot where the "signals killed RxJS" crowd gets corrected — streams are still the right tool for events over time, and SignalStore is happy to let them feed the signals. It's the same boundary as everywhere else in modern Angular: signals hold state, streams describe the async.

The decision that actually matters: where you provide it

providedIn: "root" gives you one global instance — right for genuinely app-wide state like the cart or the current user. But you can also leave that out and list the store in a component's providers array. Now you get a fresh instance scoped to that component and its children, created when the feature mounts and destroyed when it unmounts. State that belongs to one screen lives and dies with that screen, no manual reset.

This is the call I see teams get wrong most often. They make every store global, then write cleanup code to wipe stale feature state on every navigation — reinventing component scope by hand. If the state is "this page's state," scope it to the page. If it's "the app's state," put it in root. withEntities is worth knowing for the collection cases — it gives you normalized add/update/remove over an entity map so you're not hand-rolling the same dictionary logic again.

Do you even need it?

Honest answer: often not. A plain @Injectable service holding a few signal()s and exposing computed() getters covers a surprising amount of shared state, and it's the lighter choice for a single feature with simple needs. SignalStore earns its dependency when you want conventions a team will follow without a meeting — a predictable shape for every store, async that's already cancellation-safe, and withEntities/custom withX features you can compose and reuse across stores.

The way I'd put it: plain signals service is the answer until you find yourself reinventing the same store skeleton for the fourth time. At that point SignalStore is the skeleton, already written, and unlike the NgRx of five years ago it doesn't make you pay for a Redux you don't have.

Calibrating a tax simulator against URSSAF's own engine

Ali — Sun, 14 Jun 2026 12:00:00 +0000

I shipped freelance-ou-cdi.fr, a calculator that answers a question every French developer asks at least once: at what daily rate does going freelance actually beat my CDI? It compares net income — after social contributions and income tax — across micro-entreprise, EI, EURL, SASU, portage salarial and the salaried baseline, under 2026 rates.

Writing the arithmetic was the easy half. The hard half was proving it wasn't wrong. A tax simulator that is plausibly, quietly off by ten percent is worse than no simulator at all: it hands people a number they'll trust to make a five-figure decision. So the interesting engineering here isn't the model — it's how I kept the model honest.

Don't trust your own tax code

French social contributions are not a flat percentage. The TNS regime layers base pension, complementary pension, sickness, family allowances and CSG-CRDS, several of them progressive, several capped at multiples of the PASS. A SASU president is taxed as an employee but can route income through dividends at a flat 31.4%. The 2026 reform of the self-employed contribution base changed the assiette. Transcribe all of that from PDFs and you will get a handful of lines subtly wrong — and you'll never notice, because your wrong number still looks reasonable.

The naive shortcut makes this concrete. Plenty of "brut to net" converters apply a fixed −25% for an executive salary. Run a real progressive calculation and that flat factor is off by several points at most salary levels, in both directions depending on where you land against the ceilings. "Looks about right" is exactly the failure mode you can't catch by eyeballing.

The URSSAF ships an oracle — use it

The French administration open-sources modele-social, a publicodes ruleset that powers mon-entreprise.urssaf.fr, the URSSAF's own simulator. It is the closest thing to ground truth that exists for these calculations. The trick is to treat it not as a dependency I ship, but as a test oracle : a reference my own engine has to agree with.

So there's a comparison harness — npm run compare — that instantiates the publicodes engine, asks it for the official figure on a grid of scenarios (micro BNC at several revenue levels, EI/TNS contributions, the income-tax schedule, SASU cost-to-net, CDI net and employer cost for cadre and non-cadre, even the civil-servant case), and prints my number beside it with the delta. Anything drifting past a few percent gets flagged. The goal isn't to match to the cent — the official engine models edge cases I deliberately don't — it's to stay inside a couple of percent across the realistic range, and to know immediately when a rate change or a refactor pushes me out of it.

Why not just ship publicodes?

Fair question — if the reference engine is right there, why reimplement? Three reasons, all about control:

Inversion. The product's best feature is "at what daily rate do I break even with my CDI?" That's a root-find: I run the forward model inside a binary search over the rate. Driving a general rules engine through dozens of inversions per interaction is the wrong tool; a direct function is trivial.
Transparency. I wanted every result to expand into a line-by-line breakdown — this contribution, that tax, this deduction — with each parameter editable in an "advanced" panel. A purpose-built model exposes those internals naturally.
Weight and reach. The whole thing runs client-side with nothing sent to a server. A compact, audited engine keeps the page light; the heavy reference engine stays in the build, as the thing that grades my homework.

The payoff is also a GEO trick

Calibration buys correctness. But generating from the engine buys something else: numbers that can't contradict each other. The FAQ ("a freelancer beats a 55k CDI from about 410€/day in SASU") and the break-even table are both computed by the same functions that drive the live simulator — not typed into the copy by hand. Change a 2026 rate in one place and the prose, the table and the tool all move together.

That self-consistency turns out to matter for getting cited by generative engines. An LLM summarizing "freelance vs CDI in France" will quote a page far more readily when its stated figures, its structured data, and its interactive tool all agree — because nothing on the page undercuts the claim. Internal contradiction is the fastest way to look untrustworthy to both a careful reader and a model. The cheapest way to never contradict yourself is to never write the number twice.

What it still can't do

A calibrated model is not an accountant. CFE, the family-quotient cap, first-year ACRE relief, mandatory mutuelle, regional quirks — some of these are modeled, some deliberately aren't, and the gap is exactly why the harness flags differences instead of asserting equality. The honest framing on the site is "indicative, validated against the official engine within a couple of percent," not "tax advice." Knowing precisely where you diverge from ground truth is itself a feature; it's the difference between a confident wrong answer and a useful estimate with stated limits.

The whole thing is open-source — engine, harness and all — at github.com/aelmufti/is-freelance-worth-it-for-you. If you spot a status where I drift from the URSSAF's engine, that's the bug report I most want to receive.

@let ended my async-pipe pyramid

Ali — Sat, 13 Jun 2026 12:00:00 +0000

Every Angular template has, at some point, contained this crime:

<h1>{{ (user$ | async)?.name }}</h1>
<p>{{ (user$ | async)?.email }}</p>
<img [src]="(user$ | async)?.avatar" />

Three subscriptions to the same observable, three independent async pipes, all to render one user. The "fix" we all learned was to abuse *ngIf for its aliasing side effect — *ngIf="user$ | async as user" — subscribing once and binding the result to a local name. It worked, but it was a hack: you were using a structural directive whose job is conditional rendering purely because it happened to create a scoped variable, and the whole block vanished the instant the value was falsy.

@let is the feature that should have existed the whole time. It declares a template variable. That's it.

@let user = user$ | async;

<h1>{{ user?.name }}</h1>
<p>{{ user?.email }}</p>
<img [src]="user?.avatar" />

One pipe, one subscription, a name you reuse everywhere below it. No @if wrapper forced on you, no directive doing a job it wasn't designed for.

It's reactive, and it's read-only

Two properties make @let behave the way you'd hope. It's reactive: the right-hand side is re-evaluated when its dependencies change, so @let count = counter() tracks the signal, and the async-pipe version updates on every emission. You're naming a live value, not snapshotting one.

And it's read-only. You cannot reassign a @let from the template — there's no user = somethingElse. This trips people who expect a JavaScript let, but it's the right call: a template is a declaration of what the UI is, not a place to run imperative logic. If you need to change a value, you change the state it derives from, and the @let follows.

Scope: after the line, inside the view

A @let is available from its declaration onward, within the same view and any nested views below it. Two consequences worth internalizing. You can't reference it before you declare it — order matters, top to bottom. And it doesn't leak upward or sideways: a @let declared inside an @if block or an @for loop exists only in there. That last bit is actually useful — inside a loop, @let rowTotal = ... gives each iteration its own value without you thinking about it.

It does not replace @if for null-narrowing

This is the one mistake to avoid. @let names a value; it does not guarantee the value. An async pipe yields null before its first emission, so @let user = user$ | async is null on the first render. If the template below assumes a user exists, you'll be writing user?. everywhere or hitting null reads.

So the two features pair rather than compete. @if still does the narrowing; @let can carry the loaded value or a derived one:

@if (user$ | async; as user) {
  @let initials = user.firstName[0] + user.lastName[0];
  <span class="avatar">{{ initials }}</span>
  <h1>{{ user.name }}</h1>
}

The @if guarantees user is present and non-null inside the block; the @let gives you a clean name for a value you'd otherwise compute inline twice.

When to use a computed instead

@let is for the view. The moment a derived value is needed in TypeScript too — in a method, in another computed, in a guard — it belongs in a computed() in the component, not in the template. The smell is duplication: if you'd write the same @let expression in two separate templates, or you need it outside the template at all, promote it to computed() and bind to that. Use @let for the genuinely view-local stuff: aliasing a long property path, naming an async result, giving a loop iteration a readable per-row total. For that, it's exactly the right amount of power — and it finally retires the *ngIf as hack I'd been apologizing for in code review for years.

Incremental hydration: ship the HTML, hydrate on hover

Ali — Fri, 12 Jun 2026 12:00:00 +0000

Server-side rendering gets you a fast first paint: the browser receives real HTML and shows it immediately. Then hydration happens — Angular boots on the client, walks the entire component tree, and wires up every event listener so the page becomes interactive. The problem is the word "entire." Your footer, your three-tabs-deep settings panel, the comment section nobody scrolls to — all of it gets hydrated up front, competing for the main thread while the user is staring at the hero. That's the gap between "I can see it" and "I can click it," and it's mostly wasted work.

Incremental hydration closes that gap by making hydration lazy, per block. You opt in once:

bootstrapApplication(App, {
  providers: [provideClientHydration(withIncrementalHydration())],
});

and then mark the regions that can wait, using the @defer syntax you already know — but with a hydrate trigger:

@defer (hydrate on viewport) {
  <app-comments [postId]="postId" />
}

The comments render on the server as normal HTML — visible, indexable, no layout shift — but their JavaScript doesn't download or hydrate until the block scrolls into view. The main thread stays free for the part of the page the user is actually looking at.

This is not the same as a plain @defer

Worth being precise, because the syntax is shared and the behaviors are opposite. A regular @defer (on viewport) renders nothing on the server — you get a @placeholder until the trigger fires, then the real content loads in. Great for cutting the initial bundle, but the deferred content isn't in the server HTML, so it's invisible to a crawler and pops in late for the user.

@defer (hydrate on ...) is the inverse. The content is fully rendered on the server — it's there in the HTML from the first byte. What's deferred is only the hydration: the download and execution of its JavaScript. So you keep the SEO and the instant paint of SSR, and you also get the deferred-work win. It's the best of both, which is why it needed a new trigger keyword rather than reusing the old behavior.

hydrate never is a static island

The trigger I find most quietly powerful is hydrate never. Plenty of server-rendered content is genuinely static — a rendered markdown article, a pricing table, a marketing block. It has no interactivity to wire up, yet full hydration still spends cycles proving that to itself.

@defer (hydrate never) {
  <app-article-body [markdown]="content" />
}

hydrate never says: this is finished, ship it as HTML and send no JavaScript for it, ever. It becomes a true static island in an otherwise interactive app. For a content-heavy page, that's a real cut to the JavaScript the client has to parse — the bytes for that subtree simply never arrive.

The clicks aren't lost — event replay catches them

The obvious worry: if a button's JavaScript hasn't hydrated yet and the user clicks it, does the click vanish? This is exactly what event replay solves, and it's why incremental hydration leans on it. With withEventReplay() (on by default in current setups), events that land on not-yet-hydrated content are captured and queued. The trigger fires, the block hydrates, and the queued events replay against the now-live listeners. From the user's side the click just worked, maybe a hair late. Without event replay, that early click really would be dropped — so treat the two features as a pair.

It's a different tool from afterNextRender

Since both live under the SSR umbrella, it's worth drawing the line. afterNextRender answers "my code touches document and crashes on the server — when is it safe to run browser-only logic?" Incremental hydration answers a different question: "the whole page works, but when should each piece become interactive?" One is about avoiding server-side errors; the other is about scheduling client-side interactivity. You'll often use both on the same app for entirely separate reasons.

The decision rule

Reach for hydrate on viewport or hydrate on interaction for heavy interactive widgets that sit below the fold or get used rarely — comment threads, data grids in a collapsed panel, a map at the bottom of the page. Use hydrate never for server-rendered content with no interactivity at all. Leave the above-the-fold, immediately-interactive parts — your nav, your primary call to action — hydrating normally, because deferring those just adds latency to the thing the user reaches for first. The whole point is to stop spending the main thread on interactivity nobody has asked for yet.

Are we cooked ?

Ali — Wed, 10 Jun 2026 15:00:00 +0000

It comes up in every dev conversation now, somewhere between the second coffee and the standup. A junior asks it sincerely. A senior asks it as a joke that lands a little too flat. Someone screenshots an agent building in twenty minutes what took their team a sprint, and the group chat goes: are we cooked?

I've given the reassuring answer at meetups and the doomer answer at 2am, and I no longer believe either. Here's the answer I actually believe, and it requires splitting the question in two — because "we" was never one group, and "cooked" was never one thing.

The job was never the typing

Start with what's actually being automated. An LLM produces code — spectacularly well, some days. But look at where your last three production incidents came from. Mine didn't come from badly typed code. They came from a requirement that meant two different things to two different teams, a cache invalidation assumption nobody wrote down, and a third-party API that behaved differently under load. The code was fine. The understanding had a hole in it.

That's the job: translating fuzzy, contradictory human intent into a system that doesn't fall over, and holding the model of that system in your head while it grows past anyone's ability to read it whole. The typing was always just the visible part — the part you could film for a hiring ad. We're shocked that machines write code the way accountants were shocked that machines could add. Addition wasn't the job. The job was knowing which numbers to add, and noticing when a total couldn't possibly be right. The spreadsheet didn't kill accounting; it killed the version of accounting that was secretly just arithmetic. Hold that thought, because the parallel cuts both ways — some of what we call software engineering is secretly just arithmetic.

The inversion nobody priced in

Here's the outside-the-box part, the thing I think most takes miss: AI didn't make software cheap. It made generation cheap and left verification expensive — and that inversion changes the profession more than any productivity number.

Before: writing was slow, so writing was the bottleneck, so we organized everything around authors. Now a plausible implementation costs thirty seconds, and the question "is this plausible thing correct?" costs what it always cost: attention, context, skepticism, the instinct that something is off in a diff that looks perfectly fine. The bottleneck moved from production to judgment. We all became editors-in-chief of a very fast, very confident, very junior writer who never gets tired and never says "I'm not sure."

And editing is a harder job than writing when you do it honestly. Anyone who's done real code review knows the trap: the subtle bug doesn't live in the code that looks wrong, it lives in the code that looks right. Reviewing AI output is that, all day, at volume. The "10x productivity" stories quietly assume the verification is free — that someone reads the generated code with the same care they'd have spent writing it. Mostly, nobody does. We're currently shipping a civilization-sized experiment on what happens when generation outruns verification, and the results aren't in yet.

Someone still has to sign

Which is why the most durable thing about this job isn't a skill at all. When production goes down at 3am, when the regulator asks why the system did what it did, when a migration eats data — a human is accountable. Not metaphorically: contractually, legally, reputationally. An LLM cannot be responsible. It can't be fired, can't testify, can't feel the specific cold sweat of having broken prod. Responsibility is load-bearing in every engineering discipline, and it doesn't transfer to tools — the bridge engineer's stamp survived CAD.

But notice what that implies, because it's not comfortable: signing for something you don't understand isn't accountability, it's liability cosplay. The moat isn't "being human." It's understanding what you ship. The engineers who let that understanding atrophy — who approve what they can no longer explain — are converting themselves into a rubber stamp, and rubber stamps are very, very automatable.

The part that is actually cooked

So no, I don't think the profession is cooked. But one piece of it is on fire, and we're not talking about it enough: the ladder.

Every senior engineer was forged the same way — years of boring tickets. The CRUD endpoint, the pagination bug, the form validation. We treated that work as grunt work, but it was secretly the apprenticeship: ten thousand small encounters with how systems actually fail, compounding into the instincts that make a senior senior. That's exactly the work AI eats first, and it eats it cheerfully. Why give the junior three days when the agent takes ten minutes?

Run that policy for a decade and you get a profession with no new seniors — editors-in-chief who never wrote, signatories who never built the understanding their signature claims. Juniors aren't cooked because AI replaces them; they're cooked if we stop letting them do the work that was always more education than output. The fix isn't complicated, but it is a choice: keep giving humans work the machine could do, on purpose, the way pilots still hand-fly approaches the autopilot could handle — because the skill has to exist in a human for the day it's needed. Some team leads make that choice. The ones who don't are strip-mining their own future.

So: are we?

Here's the split, then. If "the job" means converting tickets into code that probably works — yes, cooked, on a timeline measured in years, and pretending otherwise is a disservice to everyone planning a career. If "the job" means owning systems: deciding what to build, knowing why it's built that way, catching the confident wrong answer, signing for the result and meaning it — not cooked. In more demand than ever, actually, because the volume of software is exploding and every line of it eventually needs an adult.

The discomfort is that nobody gets to claim the second job by seniority or by job title. You claim it by still understanding what you ship — which, in the age of infinite generated code, is a daily, deliberate act of swimming upstream. I use these tools all day. They wrote none of the decisions in this post, and if a day comes when I can't tell whether they got those right either — that's the day I'm cooked, and it won't have been the machine that did it.

inject() and DestroyRef quietly killed my ngOnDestroy boilerplate

Ali — Wed, 10 Jun 2026 12:00:00 +0000

There's a constructor I've written a thousand times and don't write anymore:

constructor(
  private http: HttpClient,
  private router: Router,
  private route: ActivatedRoute,
  private store: Store,
  private destroy$: Subject<void>, // ...and the ritual that goes with it
) {}

Plus the matching ritual at the bottom of the class: ngOnDestroy() { this.destroy$.next(); this.destroy$.complete(); }, and takeUntil(this.destroy$) sprinkled on every subscription, and a code review comment when someone forgot one. None of that survives in the code I write today, and the replacements are three small APIs that compose into something genuinely better.

inject(): not just nicer syntax

export class UserPanel {
  private http = inject(HttpClient);
  private route = inject(ActivatedRoute);
}

The aesthetic win is obvious. The structural wins are the reason to switch. Inheritance stops hurting: a base class that uses inject() doesn't force every subclass to declare and forward constructor parameters — if you've ever touched a base component used by thirty subclasses and then spent the day updating thirty constructors, that sentence is the whole argument. Functional everything: guards, resolvers and interceptors are plain functions now, and inject() is the only way they get dependencies:

export const authGuard: CanActivateFn = () => {
  const auth = inject(AuthService);
  const router = inject(Router);
  return auth.isLoggedIn() || router.createUrlTree(['/login']);
};

And the one that changed how I structure code — composition helpers. Because any function called from an injection context can itself call inject(), you can extract cross-cutting patterns into plain functions:

export function injectQueryParam(name: string): Signal<string | null> {
  const route = inject(ActivatedRoute);
  return toSignal(
    route.queryParamMap.pipe(map(p => p.get(name))),
    { initialValue: null },
  );
}

// in any component:
search = injectQueryParam('q');

That's dependency injection, RxJS interop and cleanup bundled in a named, testable, reusable unit. The React folks call these hooks and built a whole culture on them; Angular got the same power almost quietly.

DestroyRef: cleanup without the ceremony

DestroyRef is injectable like anything else, and its one job is to run callbacks when the current scope is destroyed:

export class ChartPanel {
  private destroyRef = inject(DestroyRef);

  constructor() {
    const chart = renderChart(this.el.nativeElement);
    this.destroyRef.onDestroy(() => chart.dispose());
  }
}

Notice what's gone: implementing OnDestroy, the override chain when a base class also had cleanup, the distance between acquiring a resource and releasing it. Setup and teardown sit next to each other — the resource's whole lifecycle is readable in one place. And because helpers can inject it, your composition functions clean up after themselves without the caller knowing.

takeUntilDestroyed(): the destroy$ ritual, retired

export class PriceTicker {
  private ws = inject(WebSocketService);

  constructor() {
    this.ws.prices$
      .pipe(takeUntilDestroyed())
      .subscribe(p => this.render(p));
  }
}

Called in a constructor or field initializer, it needs zero arguments — it picks up DestroyRef from the injection context by itself. The destroy$ subject, its two-line ngOnDestroy, and the review comment about the missing takeUntil: all deleted. If you use it outside the constructor (say, in a callback), pass the ref explicitly — takeUntilDestroyed(this.destroyRef) — which brings us to the rule.

The one rule that bites everyone once

inject() only works in an injection context: field initializers, the constructor, provider factories. Not in ngOnInit. Not in a setTimeout. Not in your event handler. The error message (NG0203) is famous enough to be a meme, and everyone earns it exactly once.

ngOnInit() {
  const http = inject(HttpClient); // ❌ NG0203 — too late, context is gone
}

The mental model that makes it stick: the injection context isn't magic, it's a moment — the moment your class is being constructed, when Angular knows which injector is "current". After construction, that knowledge is gone. So grab everything you need during construction (field initializers are the natural place), and if you genuinely must resolve dependencies later, that's what runInInjectionContext(injector, fn) is for — an explicit, greppable escape hatch instead of an accident.

Put together, the pattern I now consider baseline for any component: dependencies as inject() field initializers, subscriptions wearing takeUntilDestroyed(), ad-hoc resources registered with DestroyRef.onDestroy(), and anything repeated twice extracted into an injectX() helper. Less ceremony, but that's the surface benefit. The real one is that lifecycle bugs — the leaked subscription, the chart that outlives its tab — stopped being a category of bug I find in review. The framework didn't make them rarer; it made them hard to write.

Where signals end and RxJS begins

Ali — Wed, 10 Jun 2026 12:00:00 +0000

Every few months someone declares RxJS dead, and every few months I open a codebase where someone took that literally — and rebuilt debounceTime by hand with an effect, a signal, and a setTimeout. It's twenty lines, it has a race condition, and it makes the case better than I can: signals didn't replace streams. They took over half the job, the half they're better at.

The division of labor

Ask one question about the thing you're modeling: is it a value or an occurrence?

A value has a current state that's always meaningful to read: the logged-in user, the selected tab, the filter text, the cart. That's signal territory — synchronous reads, glitch-free derivation with computed(), and the template just works. An occurrence is a thing that happens: a keystroke, a websocket frame, a retry with backoff, a request that should cancel its predecessor. Asking for its "current value" doesn't even make sense — what's the current value of a click? That's a stream, and operators like debounceTime, switchMap and retry are decades of distilled answers to time problems signals don't address.

Crossing the border, both directions

toSignal() turns a stream into state. Two details matter more than the docs make obvious. It subscribes immediately — at the call site, not on first read — so calling it lives in an injection context and cleanup is handled for you. And the initial value question is forced on you, which is a feature: an observable may not have emitted yet, so you either provide initialValue, accept undefined in the type, or assert requireSync for things like a BehaviorSubject that emit on subscription.

prices = toSignal(this.ws.prices$, { initialValue: [] });

toObservable() goes the other way, and the canonical use is the typeahead — which is also the cleanest demonstration of the whole philosophy:

query = signal('');

results = toSignal(
  toObservable(this.query).pipe(
    debounceTime(300),
    distinctUntilChanged(),
    switchMap(q => this.api.search(q)),
  ),
  { initialValue: [] },
);

State enters as a signal. The time problems — wait for the user to stop typing, drop stale requests — are handled by the two operators that exist precisely for them. The result comes back out as state. Each tool does the part it was built for, and the seam is two function calls.

The smell test

When reviewing, I use a symmetric pair of smells. An effect() that contains setTimeout, manual cancellation flags, or "ignore this run if a newer one started" bookkeeping — that's a stream wearing a signal costume; it wants five lines of RxJS. Conversely, a service juggling a BehaviorSubject, scan, and shareReplay just to expose "the current list with its loading flag" — that's state wearing a stream costume; it wants to be a signal (or, if HTTP is involved, a resource(), which already ate most of my data-fetching streams — I wrote about that separately).

So the honest status of RxJS in my code: smaller, and better. It left the places it was always awkward — component state, template consumption — and kept the places nothing else touches: coordinating things that happen over time. Fewer streams, but every one that remains is doing work only a stream can do. That's not a technology dying; that's a technology finding its actual shape.

Auth, retry, logging: three interceptors, zero classes

Ali — Wed, 10 Jun 2026 12:00:00 +0000

Interceptors used to be the most ceremony-per-feature API in Angular: a class, an interface, a multi-provider registration with HTTP_INTERCEPTORS and multi: true — the line everyone copy-pasted and nobody could write from memory. The functional version is just... a function, registered in order:

provideHttpClient(
  withInterceptors([authInterceptor, retryInterceptor, loggingInterceptor]),
)

Here are the three I end up writing on basically every project, with the details that distinguish "works in the demo" from "works in production".

Auth: clone, don't mutate — and let some requests through

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  if (req.context.get(SKIP_AUTH)) return next(req);

  const token = inject(TokenStore).token();
  if (!token) return next(req);

  return next(req.clone({
    setHeaders: { Authorization: `Bearer ${token}` },
  }));
};

Requests are immutable, so it's clone() or nothing. The part worth copying is the first line: SKIP_AUTH is an HttpContextToken, and it solves the "but the login call itself shouldn't carry a token" problem without the URL-matching if-chains that grow hair over time:

export const SKIP_AUTH = new HttpContextToken<boolean>(() => false);

// at the call site that needs the exception:
this.http.post('/auth/login', creds, {
  context: new HttpContext().set(SKIP_AUTH, true),
});

The exception is declared where the exception is, not in a growing denylist inside the interceptor. Six months later, that's the difference between reading one line and archaeology.

Retry: the interceptor that can double-charge someone

export const retryInterceptor: HttpInterceptorFn = (req, next) => {
  if (req.method !== 'GET') return next(req);

  return next(req).pipe(
    retry({
      count: 2,
      delay: (error, retryCount) => {
        const status = error instanceof HttpErrorResponse ? error.status : 0;
        if (status > 0 && status < 500) throw error; // 4xx: our fault, don't retry
        return timer(1000 * Math.pow(2, retryCount)); // 2s, 4s
      },
    }),
  );
};

Two guards carry all the weight. Only GETs: a POST that times out may have succeeded server-side — retry it and you've created the duplicate order / double payment incident that ends up with your name on the postmortem. Only 5xx and network errors: retrying a 401 or a 404 is asking the same question louder. With those two rules, automatic retry goes from scary to boring — and a flaky corporate proxy mostly disappears from your error tracker.

Logging: only the requests that deserve it

export const loggingInterceptor: HttpInterceptorFn = (req, next) => {
  const started = performance.now();
  return next(req).pipe(
    finalize(() => {
      const ms = performance.now() - started;
      if (ms > 1000) {
        console.warn(`[slow] ${req.method} ${req.urlWithParams} — ${Math.round(ms)}ms`);
      }
    }),
  );
};

Logging every request is noise nobody reads. Logging requests over a threshold gives you something I've found disproportionately useful: the slow-endpoint report assembles itself in the console while you develop, and the worst offenders become impossible to not know about.

Order is not a detail

The array order is execution order on the way out, reversed on the way back. With [auth, retry, logging]: auth runs first, so every retry attempt carries the token — flip them and a token refresh between attempts can send a stale header. And because logging sits innermost, it times each attempt rather than the sum. When an interceptor chain misbehaves, the order is the first thing I check, and it's the thing the type system can't check for you: the array compiles in any order. It just doesn't work in any order.

Two letters that fixed my LCP: ngSrc

Ali — Wed, 10 Jun 2026 12:00:00 +0000

Images are where Core Web Vitals go to die. The biggest element on most pages is an image (that's literally what LCP measures, most of the time), the thing that jumps the layout around is usually an image arriving late, and the bytes that dwarf your carefully code-split bundle are — images. The fix in Angular costs two letters:

<img ngSrc="/assets/team.jpg" width="800" height="533" alt="The team" />

Same element, ngSrc instead of src, plus the directive imported. What you get for that is a small pile of best practices that you no longer have to remember.

Lazy by default, and the one image that mustn't be

Every ngSrc image is loading="lazy" and decoding="async" unless told otherwise — correct for every image below the fold, which is most of them. The exception is the point: your LCP image, the hero, must be the opposite — fetched as early as possible. That's priority:

<img ngSrc="/assets/hero.jpg" width="1200" height="600" priority alt="..." />

One attribute sets eager loading and fetchpriority="high", and the SSR pipeline emits a preload hint so the browser starts the download before it has even parsed down to the <img> tag. And here's my favorite part of this directive's design: if you forget — if the image Angular detects as your LCP element isn't marked priority — it tells you in the console, in dev mode. An optimization that audits its own usage.

The mandatory dimensions are the feature

width and height are required, and people's first reaction is annoyance — mine was. But this is CLS prevention by API design: with intrinsic dimensions the browser reserves the right box before a single byte arrives, and nothing jumps when the pixels land. The directive turned "remember to set dimensions" — a discipline that erodes — into "the build won't let you forget". (The numbers define the ratio; CSS still controls display size.) For the genuinely-unknown case — a user-uploaded background, a CMS image — there's fill, which absolutely-positions the image into a sized parent, paired with object-fit in your CSS.

The srcset you were never going to write by hand

Serving a 1200px image to a 360px phone screen wastes most of the bytes. The honest fix is a responsive srcset, and almost nobody writes those by hand because they're tedious and they rot. With a loader configured, the directive generates them:

// app.config.ts — one line, pick your CDN
provideImgixLoader('https://my-site.imgix.net/'),

// every ngSrc image now emits srcset variants automatically

Built-in loaders exist for the usual suspects (Imgix, Cloudinary, ImageKit, Netlify…), and a custom loader is a function mapping (src, width) to a URL — ten lines if your backend can resize. This is the difference between the directive being "nice" and being a bandwidth line-item: the phone gets the 400px file, the retina desktop gets the 1600px one, and nobody on the team maintains a single srcset string.

The honest scope

What NgOptimizedImage doesn't do: convert formats, crush file sizes, or host anything — that's the CDN/build pipeline's job; the directive just asks for the right variant at the right moment. And on a page with three images, the gains are real but modest. The compounding case is the image-heavy app — listings, galleries, media — where lazy-by-default alone can cut initial page weight dramatically. Run Lighthouse before and after on one route. That number is how you sell the two-letter change to whoever approves the sprint.

The dropdown that wouldn't reset — a linkedSignal story

Ali — Wed, 10 Jun 2026 12:00:00 +0000

A search page. A list of results, one of them selected. The user types, the results change — and the selection now points at an item that no longer exists. Every Angular developer has shipped this bug at least once, because for years the framework gave us no primitive that fit the shape of the problem.

Think about what the selection actually is. It's derived from the results — when they change, it should reset. But it's also writable — the user clicks to change it. computed() gives you derived but read-only. signal() gives you writable but disconnected. The selection is both, and both tools are wrong alone.

The two workarounds we all wrote

Workaround one: a writable signal plus an effect that resets it.

selected = signal<Result | null>(null);

constructor() {
  effect(() => {
    this.results(); // subscribe to the list
    this.selected.set(null); // reset on change
  });
}

It works, until it doesn't: the effect runs after change detection, so there's a frame where the template renders a selection pointing into the old list. Workaround two is sprinkling selected.set(null) at every call site that touches the list — which holds up exactly until a new call site forgets.

What linkedSignal actually says

results = signal<Result[]>([]);
selected = linkedSignal(() => this.results()[0] ?? null);

// user clicks → plain write, like any signal
select(r: Result) { this.selected.set(r); }

Read it as a sentence: "selected follows results, unless someone wrote to it more recently — and the moment results changes again, following resumes." Derivation and overridability in one declaration, recomputed synchronously with the source, so the stale-frame window from the effect version doesn't exist.

The previous-value trick

Resetting to the first item is sometimes rude. If the user's selection survived the list update, keep it — and the long form hands you what you need:

selected = linkedSignal<Result[], Result | null>({
  source: this.results,
  computation: (list, previous) => {
    const kept = list.find(r => r.id === previous?.value?.id);
    return kept ?? list[0] ?? null;
  },
});

The computation receives the new source value and the previous state of the linked signal. "Keep the selection if it still exists, otherwise fall back" — the behavior users actually expect from a well-made UI, expressed in four lines, in one place, instead of scattered across resets.

Where it doesn't belong

Two boundaries keep it honest. If the value is purely derived and never user-written, that's computed() — reaching for linkedSignal there just advertises writability you don't want. And if the "source" is asynchronous — the selection should reset when an HTTP call returns — the deriving belongs in resource() land, not here; linkedSignal is synchronous by nature.

Small API, narrow purpose. But the bug it removes is one I'd been finding in code reviews for years, and now the fix is a type signature instead of a convention someone has to remember. That trade is the story of modern Angular in one primitive.