DEV Community: Yasin Demir

Notes I Kept While Moving a Project to Angular 21

Yasin Demir — Wed, 12 Aug 2026 21:27:36 +0000

Notes I Kept While Moving a Project to Angular 21

Last month I decided to move a side project to Angular 21. My intention was mundane — bump the version, fix whatever broke, move on. Two weeks later I was working in a framework that shared a name with the one I knew but felt like a different tool entirely. This isn't a changelog. It's the collection of "wait, that's different" moments I wrote down as I hit them.

What I noticed the day I ripped out Zone.js

When I first shipped provideZonelessChangeDetection() to production, I expected a small bump on a performance graph. What I got was something else: the end of a question I used to ask constantly while debugging — "why did this component just re-render?" With Zone.js in the picture, that question could turn into a small investigation. A setTimeout somewhere, a third-party library's event listener somewhere else, all of it triggering change detection, and you can't tell what triggered what just by staring at a template.

Without zones, a change is no longer a mystery event — it's traceable. A signal changed, everything depending on it updated, that's the whole story. At first this clarity felt almost uncomfortable, because it comes with a responsibility I wasn't used to: your state actually has to live in a signal. You can't assign to a component property and hope change detection sorts it out eventually. But that responsibility turned out to be a gift — the code now explains itself.

`resource()` didn't just replace RxJS, it killed a whole category of state bugs

On a project detail page I was fetching data based on a route parameter. The old way looked like: a subject, a switchMap, takeUntilDestroyed, a separate loading signal, a separate error signal, and the constant chore of keeping them all in sync by hand. It always felt like hand-rolling a tiny state machine.

With resource(), the same job became:

project = resource({
  params: () => ({ slug: this.slug() }),
  loader: ({ params }) => this.contentful.getProjectBySlug(params.slug),
});

project.value(), project.isLoading(), project.error() — all three are just there, synchronous, always consistent with each other. When the route changes, params reruns, a new fetch fires, and the previous in-flight request gets discarded. Every time I hand-wrote this before, I'd leave a bug somewhere — usually a race condition where a stale response arrived late and clobbered newer state. resource() gets this right by default, and I've simply stopped hunting for that bug.

This isn't RxJS being thrown out — it's still on the table anywhere real composition is needed. But for "just wire an HTTP call to component state," I don't reach for it anymore, and that difference mattered more than I expected.

Changing the control flow syntax wasn't cosmetic — the template started behaving like TypeScript

When I switched to @if / @for, I expected a cosmetic win — a shorter way to write what *ngIf used to do. The real difference showed up in the editor. Write @if (user(); as u) and the IDE actually knows the type of u — none of the occasional ambiguity that *ngIf + as could produce. The mandatory track in @for felt like busywork at first, until I remembered how many times in this codebase I'd tracked by index and then watched the DOM misbehave the moment a list got reordered. The compiler refusing to let me forget track quietly closed a category of bug I'd shipped more than once.

What the build tooling change actually felt like: the wait disappearing

After moving to the Vite/esbuild-based dev server, the thing I noticed most wasn't really a "feature" — it was the silence after hitting save. There used to be a small pause there, one I'd gotten so used to I stopped noticing it. Now that gap is gone, and once you consider that saving a file happens dozens of times a day, what disappeared wasn't just accumulated seconds — it was accumulated attention loss. The flow doesn't break.

SSR/hydration: no longer "hopefully it holds," now it just holds

This project already used server-side rendering, and hydration mismatches used to feel like a game of chance — a silent warning in the console, sometimes there, sometimes not, sometimes only in production. With Angular 21's hydration improvements, that uncertainty shrank considerably. The most concrete win: the code that skips server-rendering my WebGL background (the gl-bg component) and hands it off to the client needs far fewer special-case checks now, because the framework understands "this can't hydrate, skip it" better than my own workarounds did.

The overall feeling: the framework stands behind you now, not in front of you

Working with older Angular, I sometimes felt like I was writing code against the framework's assumptions — outsmarting the change detection cycle, preventing unnecessary re-renders, adding defensive code to make sure an RxJS subscription wasn't leaking. In Angular 21, most of that defensive layer is gone. Signals, zoneless, and resource() together don't just mean "less code" — they mean "less code to worry about." That sounds like a small difference until you've maintained a codebase for months and realized the real source of fatigue was never line count. It was that background worry.

If there are three things I'd genuinely tell you to try: use resource() in a real route-level data-fetching scenario (a toy todo list won't show you the difference), turn on zoneless in an existing project and leave one @HostListener-driven piece of state as a plain property instead of a signal, then watch what breaks (an instructive kind of pain), and misuse @for + track on purpose once, just to see firsthand when the DOM "remembers" and when it forgets. All three read as unremarkable in the docs. They don't read that way once you've actually done them.

Originally published on ysndmr.com.

Angular 21'e Taşınırken Defterime Düştüğüm Notlar

Yasin Demir — Wed, 12 Aug 2026 21:26:23 +0000

Angular 21'e taşınırken defterime düştüğüm notlar

Geçen ay bir yan projeyi Angular 21'e taşımaya karar verdiğimde niyetim sadece "sürüm numarasını güncelleyeyim" gibi bir şeydi. İki hafta sonra elimde farklı bir framework vardı — aynı isim, çok farklı bir his. Bu yazı bir changelog değil. Kod yazarken tuttuğum, "vay be bu değişti" dediğim anların derlemesi.

Zone.js'i kaldırdığım gün fark ettiğim şey

provideZonelessChangeDetection()'ı ilk kez production'a aldığımda beklediğim şey performans grafiğinde küçük bir iyileşmeydi. Olan şey bambaşkaydı: hata ayıklarken artık "neden bu component tekrar render oldu" sorusuna cevap veremediğim anlar bitti. Zone.js varken bu soru bazen bir dedektiflik işine dönüşürdü — bir yerde bir setTimeout, bir yerde bir üçüncü parti kütüphanenin event listener'ı, hepsi CD tetikliyor ve sen neyin neyi tetiklediğini template'e bakarak asla anlayamıyorsun.

Zoneless'ta değişiklik artık bir mistik olay değil, bir iz sürülebilir olay. Bir signal değişti, bağımlı olan her yer güncellendi, hepsi bu. İlk başta bu netlik biraz ürkütücü geldi çünkü alışkın olmadığım bir sorumluluk getiriyor: state'ini gerçekten signal'da tutman lazım, "component property'sine atayıp CD'nin bir şekilde hallet"meyi bekleyemezsin. Ama bu sorumluluk aslında bir hediye — kodun artık kendini anlatıyor.

`resource()` beni RxJS'ten değil, "ne zaman loading true olsun" sorusundan kurtardı

Bir proje detay sayfasında route parametresine göre veri çekiyordum. Eskiden bu iş şuna benzerdi: bir subject, bir switchMap, takeUntilDestroyed, ayrı bir loading signal'ı, ayrı bir error signal'ı, hepsini elle senkron tutma derdi. Küçük bir state machine'i elle yazmış gibi hissederdim.

resource() ile aynı işi şöyle kurdum:

project = resource({
  params: () => ({ slug: this.slug() }),
  loader: ({ params }) => this.contentful.getProjectBySlug(params.slug),
});

project.value(), project.isLoading(), project.error() — üçü de zaten orada, senkron, birbirleriyle tutarlı. Route değişince params fonksiyonu yeniden çalışıyor, yeni fetch tetikleniyor, eski isteğin sonucu iptal ediliyor. Bunu daha önce elle yazdığım her seferinde bir yerinde bug bırakırdım — genelde eski isteğin geç dönüp yeni state'in üstüne yazması şeklinde bir race condition. resource() bunu default olarak doğru yapıyor ve ben artık bu bug'ı aramıyorum.

RxJS'i attığım için değil, bu — RxJS hâlâ gerçek composition gerektiren yerlerde masada. Ama "sadece bir HTTP isteğini component state'ine bağlamak" için artık ona ihtiyacım yok, ve bu fark hissettiğimden daha büyük çıktı.

Control flow'u değiştirmek "sözdizimi güzelleşti" değil, "template artık TypeScript gibi davranıyor" demek

@if / @for'a geçtiğimde beklentim kozmetikti — *ngIf yerine daha kısa bir şey yazacaktım. Asıl fark editördeydi: @if (user(); as u) yazdığımda IDE artık u'nun tipini gerçekten biliyor, *ngIf + as kombinasyonunun bazen kafa karıştırdığı belirsizlikler yok. @for içindeki track zorunluluğu ilk başta bir angarya gibi geldi, sonra fark ettim ki bu proje boyunca yanlışlıkla index'e track ettiğim, sonra liste yeniden sıralanınca DOM'un tuhaf davrandığı kaç yer olduğunu unutmuşum. Derleyicinin "track'i unutma" demesi aslında geçmişte kendime defalarca açtığım bir bug kategorisini kapatmış.

Build tarafında hissedilen şey: bekleme süresinin kaybolması

Vite/esbuild tabanlı dev server'a geçtikten sonra en çok fark ettiğim şey aslında bir "özellik" bile değildi — save tuşuna bastıktan sonraki sessizlikti. Eskiden orada küçük bir bekleme vardı, o kadar alışmıştım ki fark etmiyordum bile. Şimdi o boşluk yok, ve bunun günde onlarca kez tekrarlanan bir eylem olduğunu düşününce, biriken zamandan çok, biriken dikkat kaybının önlendiğini fark ettim. Akış kırılmıyor.

SSR/hydration: artık "umarım tutar" değil "tutuyor"

Bu projede zaten server-side render kullanıyordum ve geçmişte hydration mismatch'leri benim için hep bir şans oyunuydu — console'da sessizce bir uyarı çıkar, bazen çıkmaz, production'da bazen görürsün bazen görmezsin. Angular 21'deki hydration iyileştirmeleriyle bu belirsizlik payı küçüldü. En somut fayda: WebGL arka planımı (gl-bg component'i) server'da hiç render etmeden client'a bırakan kod artık daha az özel-durum kontrolüne ihtiyaç duyuyor çünkü framework "bu hydrate edilemez, atla" durumunu benden daha iyi anlıyor.

Genel his: framework artık arkanda duruyor, önünde durmuyor

Eski Angular'la çalışırken bazen hissettiğim şey şuydu: framework'ün varsayımlarına karşı kod yazıyordum — CD döngüsünü kandırmak, gereksiz re-render'ı önlemek, RxJS subscription'ının sızmadığından emin olmak için ekstra defans yazmak. Angular 21'de bu defans katmanının çoğu kayboldu. Signal + zoneless + resource() üçlüsü bir araya geldiğinde ortaya çıkan şey "daha az kod" değil — "daha az kod hakkında endişelenmek". Fark küçük gibi görünüyor ama bir codebase'i aylarca sürdürdüğünde asıl yorgunluğun kaynağının satır sayısı değil, bu arka plan endişesi olduğunu anlıyorsun.

Denemenizi mutlaka önereceğim üç şey varsa: resource()'ı gerçek bir route-level veri çekme senaryosunda kullanın (basit bir todo listesinde farkı göremezsiniz), zoneless'ı açık bir projede @HostListener ile güncellenen bir state'i signal'a çevirmeden bırakıp neyin kırıldığını izleyin (öğretici bir acı), ve @for + track'i yanlış kullanıp DOM'un ne zaman "hatırladığını" ne zaman unuttuğunu bizzat görün. Üçü de dokümanda okuyunca sıradan görünüyor. Elde deneyince değil.

Originally published on ysndmr.com.

Signals Cleaned Up State in Angular. The DOM Was Still Stuck in 2018.

Yasin Demir — Thu, 30 Jul 2026 22:55:47 +0000

Angular Signals cleaned up state management. It didn't clean up the DOM.

Every time I needed to know whether an element was on screen, I wrote the same directive again. Set up an IntersectionObserver in ngOnInit, disconnect it in ngOnDestroy, call markForCheck() so change detection actually notices, and wrap the whole thing in an isPlatformBrowser check so the server doesn't blow up on a global that doesn't exist there.

That's a lot of ceremony to answer "is this thing visible yet."

The alternative was pulling in a third-party directive, which usually meant a dependency tree I didn't want and SSR behavior I had to verify myself.

So I wrote ngx-viewport-signals. Four primitives, no dependencies, and the observers clean themselves up.

The four primitives

import { ElementRef, inject } from '@angular/core';
import { inViewport, viewportRatio, elementSize, scrollProgress } from 'ngx-viewport-signals';

class HeroSection {
  private readonly el = inject(ElementRef);

  visible  = inViewport(this.el, { threshold: 0.3, once: true });
  ratio    = viewportRatio(this.el);
  size     = elementSize(this.el);
  progress = scrollProgress(this.el);
}

inViewport() is a boolean. Pass once: true for entrance animations and it disconnects the observer after the first hit, instead of leaving a live one running for the rest of the page's life.

viewportRatio() gives you the raw 0..1 intersection ratio when a boolean isn't enough.

elementSize() is a { width, height } signal backed by ResizeObserver.

scrollProgress() is 0..1 as the element travels through the viewport. Useful for progress bars and parallax.

All four accept an ElementRef, a raw Element, or an accessor function. That last one matters: it means a viewChild() signal query drops straight in, no AfterViewInit dance.

The part I actually care about: teardown

Three of the four primitives share one skeleton, and the whole lifecycle story is a single effect():

effect((onCleanup) => {
  const el = elementSignal();
  if (!el) return;

  const observer = createObserver();
  observer.observe(el);

  onCleanup(() => {
    observer.unobserve(el);
    observer.disconnect();
  });
});

onCleanup fires in both situations that matter: before the effect re-runs because the element changed, and when the injector is destroyed. One hook, both cases. No DestroyRef wiring, no ngOnDestroy, no leaked observer when a viewChild() swaps out from under you.

SSR

The guard sits at the top of the factory, not sprinkled through the code:

const value = signal(initial);
if (!isBrowserPlatform()) {
  return value.asReadonly();
}

On the server you get a static signal holding the default and nothing else runs. IntersectionObserver is never touched. Your components don't need platform checks of their own.

Why scrollProgress is different

The other three are one observer with a callback. scrollProgress isn't — you need a value on every frame, and IntersectionObserver only fires on threshold crossings.

So it runs a requestAnimationFrame loop, gated by an observer:

new IntersectionObserver(([entry]) => {
  active = entry.isIntersecting;
  if (active && rafId === null) {
    tick(entry.target);
  } else if (!active && rafId !== null) {
    cancelAnimationFrame(rafId);
    rafId = null;
  }
}, { threshold: 0, rootMargin: '0px' });

The rAF loop only spins while the element is actually intersecting. Scroll past it and the loop stops dead. Ten of these on a page cost you nothing when they're all off screen — which is most of the time.

It didn't fit the shared skeleton, so I left it bespoke rather than bending the abstraction to cover it.

Config is optional

providers: [
  provideViewportSignals({ defaultRootMargin: '0px', defaultThreshold: 0 })
]

Set a baseline rootMargin once if you want. Skip it entirely and everything still works — there's a default injection value, so nothing throws when the provider isn't there.

Try it

Demo: ysndmr.github.io/ngx-viewport-signals
GitHub: github.com/ysndmr/ngx-viewport-signals
Install: npm i ngx-viewport-signals

Angular 17 through 21, MIT, zero runtime dependencies.

If you're doing scroll-driven animation, lazy-loading heavy components, or anything that reacts to layout, give it a shot. I'm curious how you're handling viewport observation right now — the hand-rolled directive is still the most common answer I get, and I'd like to know if that's changing.

Originally published on ysndmr.com.

The Two-Level Computed Graph: How I Stopped Toggle Events From Re-Running Business Logic

Yasin Demir — Wed, 08 Jul 2026 23:14:18 +0000

When you build a mapping interface in Angular Signals, the naive approach puts everything in one computed:

readonly sections = computed(() => {
    const data = this.resource.value();
    const draft = this.draftSignal();
    const collapsed = this.collapsedSignal(); // 👈 mistake
    return data.map(section => resolve(section, draft, collapsed));
});

This looks clean. One signal, one truth. But the dependency graph doesn't care about your intentions. Every time the user toggles a section open or closed, collapsed changes, the computed re-runs, and resolve(), which does badge counting, mapping resolution, and fallback calculation across every row in every section, runs again in full.

On a feed with 50 columns and 200 values per column, that's a lot of work for a toggle.

The fix is a two-level graph:

// Level 1 — depends on data + draft only
private readonly resolvedSections = computed(() => {
    const data = this.resource.value();
    const draft = this.draftSignal();
    return data.map(section => resolve(section, draft));
    // isExpanded = false here, placeholder
});

// Level 2 — depends on Level 1 + collapse state only
readonly sections = computed(() => {
    const collapsed = this.collapsedSignal();
    return this.resolvedSections().map(section => ({
        ...section,
        isExpanded: section.available && !collapsed.has(section.name)
    }));
});

Now a toggle only invalidates Level 2. Badge counts, mapping resolution, validation: none of that runs. isValidToSave reads resolvedSections() directly, so it's also unaffected by toggles.

The broader principle: Angular's computed graph is only as good as your dependency boundaries. If a computed reads ten signals but only five of them are relevant to its output, the other five are noise, and that noise has a runtime cost. Designing the graph means deciding, explicitly, which signals belong together.

Glitch-free reactivity isn't a property you get for free. It's something you architect.

Originally published on ysndmr.com.

useEffect Is Not a Lifecycle Method

Yasin Demir — Wed, 08 Jul 2026 15:12:18 +0000

I spent longer than I should have mentally mapping useEffect onto componentDidMount and componentDidUpdate. That model works just enough to feel right. Then it breaks in ways that are genuinely hard to debug.

The actual model is simpler: useEffect synchronizes something outside React with your current state. That's it. Not "run when the component mounts." Synchronize an external thing.

The clearest version of this is a subscription. If your effect subscribes to something and your cleanup unsubscribes, React runs that cycle every time the dependency changes. Subscribe, unsubscribe, subscribe again. This feels wrong through the lifecycle lens. Through the synchronization lens it makes complete sense: whenever userId changes, I need to be subscribed to the right user's data.

Where this actually matters in practice: data fetching.

useEffect(() => {
  fetch(`/api/user/${userId}`)
    .then(r => r.json())
    .then(setUser);
}, [userId]);

This has a race condition. Two fetches fire, the slower one resolves second, you display stale data. The lifecycle model doesn't explain why. The synchronization model does: you started a new sync cycle, you never cancelled the old one.

useEffect(() => {
  let cancelled = false;
  fetch(`/api/user/${userId}`)
    .then(r => r.json())
    .then(data => {
      if (!cancelled) setUser(data);
    });
  return () => { cancelled = true; };
}, [userId]);

Cleanup doesn't mean "clean up when the component unmounts." It means "clean up before the next sync cycle starts."

Most of the time when useEffect feels weird or wrong, it's because you're thinking about when, not what. The question isn't "when does this run?" It's "what am I keeping in sync, and with what?"

Originally published on ysndmr.com.

rxResource Is Not a Command Bus

Yasin Demir — Wed, 08 Jul 2026 15:12:17 +0000

When Angular shipped rxResource, a lot of developers, myself included, immediately asked: can I use this for mutations too?

The answer is technically yes. Practically, no.

Here's what it looks like when you try:

private readonly saveTrigger = signal<Payload | undefined>(undefined);

private readonly saveResource = rxResource({
    params: () => this.saveTrigger(),
    stream: ({ params }) => this.api.save(params)
});

save() {
    this.saveTrigger.set(this.buildPayload());
}

Three things go wrong immediately.

First, params starts as undefined. rxResource still evaluates the stream, so on initial render, before the user has done anything, your save API gets called with undefined. You can guard against this, but you're already fighting the primitive.

Second, if the user saves twice with identical data, saveTrigger.set() produces a new object reference each time, so the signal technically changes, and the save fires. But if anything in your pipeline normalises the payload or Angular's scheduler batches the sets, you might skip the second trigger silently.

Third, error recovery is broken. After a failed save, saveTrigger still holds the last payload. The next save() call with the same data produces a new object reference, which re-triggers. That might be what you want. Or it might not. rxResource wasn't designed to give you control over this.

The correct tool for a one-shot mutation is a direct subscribe:

private readonly isSavingSignal = signal(false);

save(): void {
    const payload = this.buildPayload();
    this.isSavingSignal.set(true);
    this.api.save(payload).pipe(
        takeUntilDestroyed(this.destroyRef)
    ).subscribe({
        next: response => {
            this.handleSuccess(response);
            this.isSavingSignal.set(false);
        },
        error: () => {
            this.handleError();
            this.isSavingSignal.set(false);
        }
    });
}

Explicit, predictable, recoverable. isSavingSignal is a plain WritableSignal: readable anywhere, testable in isolation.

The rule I now apply: rxResource is for idempotent reads. If calling the operation twice with the same input would be a problem, it's a command, and commands don't belong in rxResource.

RxJS and Signals aren't competing. They're for different jobs. The skill is knowing which job you're solving before you pick the tool.

Originally published on ysndmr.com.

Why I Stopped Writing tap() Inside rxResource Streams

Yasin Demir — Wed, 08 Jul 2026 09:40:46 +0000

There's a pattern I see a lot in Angular codebases that adopted Signals early: a developer discovers rxResource, loves that it handles loading and error state automatically, and then immediately reaches for tap() to write a signal inside the stream.

private readonly resource = rxResource({
    params: () => this.paramsSignal(),
    stream: ({ params }) =>
        this.api.fetch(params).pipe(
            tap(data => this.sideSignal.set(data.meta)) // 💥
        )
});

This looks harmless. It runs in development without complaint in zone-based Angular. Then you enable zoneless, or Angular tightens its reactive graph enforcement, and you get NG0600: Writing to signals is not allowed in a reactive context.

The rxResource stream runs inside Angular's reactive scheduler. Signal writes there aren't just discouraged. They're illegal by design. The scheduler assumes computed signals and reactive contexts are read-only during evaluation. A write mid-computation breaks the glitch-free guarantee Angular's signal graph is built on.

The fix I landed on: make the stream return everything it needs to return, as a single typed value.

interface ResourceValue {
    readonly sections: Section[];
    readonly meta: Meta;
}

private readonly resource = rxResource<ResourceValue, Params>({
    stream: ({ params }) =>
        this.api.fetch(params).pipe(
            map(data => ({
                sections: transform(data),
                meta: data.meta
            }))
        )
});

No tap. No side signal. Everything the rest of the store needs lives in resource.value() and can be read via computed.

The lesson isn't "don't use tap". The lesson is that rxResource has a contract: it is a read primitive. Its stream is for fetching and transforming. If you're writing signals inside it, you're treating it as a command bus, and that's a different tool.

Originally published on ysndmr.com.

On building systems that survive team turnover

Yasin Demir — Tue, 07 Jul 2026 12:14:39 +0000

I have taken over codebases and had codebases taken from me. The experience in both directions has converged on one principle: a durable system communicates intent, not just implementation.

What durable looks like

Naming that explains purpose. Architecture that encodes constraints. Tests that document behavior, not implementation. The goal is a codebase where a newcomer can form a correct mental model in an afternoon.

The hardest part

Documentation rots. Comments lie. The only truthful documentation is the code itself. That's why naming and structure matter more than any README.

Originally published on ysndmr.com.

Why I stopped using design tokens as implementation details

Yasin Demir — Tue, 07 Jul 2026 12:14:38 +0000

Design tokens are not CSS variables. This distinction sounds semantic, but getting it wrong produces systems that serve neither designers nor developers.

The mistake

When teams generate tokens from Figma and map them 1:1 to CSS variables, they end up with --color-blue-500 everywhere. This is an implementation detail, not a token. A token is a decision: --color-accent. The implementation of that decision can change. The token should not.

The correct layer

Tokens belong at the semantic layer. They answer the question "what is this for?" not "what is this value?". --color-border-subtle is a token. --gray-200 is a primitive.

Originally published on ysndmr.com.

Stop Putting Everything in useState

Yasin Demir — Tue, 07 Jul 2026 11:00:29 +0000

There's a pattern I see constantly: every piece of UI state gets its own useState, the component re-renders on every interaction, someone adds useMemo to fix the performance, and the whole thing gets progressively harder to follow.

Most of that useState wasn't necessary.

useState is for values React needs to track in order to render correctly. Not every value in a component qualifies.

Three things that routinely end up in state when they shouldn't:

Derived values. If you have items in state and you're also storing filteredItems in state, you have two sources of truth that can diverge. filteredItems isn't state, it's a computation.

// what I see
const [items, setItems] = useState([]);
const [filteredItems, setFilteredItems] = useState([]);

// what it should be
const [items, setItems] = useState([]);
const filteredItems = useMemo(
  () => items.filter(item => item.active),
  [items]
);

Values you only read in event handlers. If a value never influences what gets rendered, it doesn't need to trigger a re-render. useRef holds it without the overhead. A closure variable sometimes works too.

Every form field. Controlled inputs are occasionally the right call. More often, you're adding a re-render on every keystroke for no benefit. Reading from FormData on submit, or using an uncontrolled input with a ref, covers most cases without the noise.

The check I use before reaching for useState: if this value changes and nothing in the rendered output needs to change, it's probably not state. If it can be computed from something that is state, it definitely isn't.

React re-renders fast, but not free. The easiest performance wins don't come from memoizing expensive renders. They come from not rendering when you don't need to.

Originally published on ysndmr.com.

Angular Signals: six months of production observations

Yasin Demir — Tue, 07 Jul 2026 10:37:34 +0000

Six months ago I started migrating the MKX Capital frontend from a BehaviorSubject-heavy architecture to Angular Signals. Here is what I learned.

Where Signals win

Computed state is where Signals are genuinely superior to RxJS. With computed(), derived state is lazy, memoized, and glitch-free. The mental model is simpler: a Signal is a value, not a stream.

Where they fall short

Time-based operations. Anything involving debounceTime, throttleTime, or complex multicasting still belongs in RxJS. The async pipe story for Signals is better with toSignal(), but the interop layer adds cognitive overhead.

The rule I settled on

Signals for synchronous reactive state. RxJS for async streams (HTTP, WebSockets, timers). The two cooperate well via toSignal() and toObservable().

Originally published on ysndmr.com.

State colocation is not a preference, it is an architecture

Yasin Demir — Tue, 07 Jul 2026 09:53:35 +0000

The first question I ask when reviewing a frontend architecture is: where does the state live relative to where it is used?

In most codebases I have reviewed, the answer is "in a global store, regardless of scope." This is the wrong default.

The rule

State should live as close to its consumers as possible. If only one component needs it, it is component state. If a subtree needs it, it is a context or service scoped to that subtree. Global state is for truly global concerns: authentication, locale, theme.

Originally published on ysndmr.com.

DEV Community: Yasin Demir

Notes I Kept While Moving a Project to Angular 21

Notes I Kept While Moving a Project to Angular 21

What I noticed the day I ripped out Zone.js

resource() didn't just replace RxJS, it killed a whole category of state bugs

Changing the control flow syntax wasn't cosmetic — the template started behaving like TypeScript

What the build tooling change actually felt like: the wait disappearing

SSR/hydration: no longer "hopefully it holds," now it just holds

The overall feeling: the framework stands behind you now, not in front of you

Angular 21'e Taşınırken Defterime Düştüğüm Notlar

Angular 21'e taşınırken defterime düştüğüm notlar

Zone.js'i kaldırdığım gün fark ettiğim şey

resource() beni RxJS'ten değil, "ne zaman loading true olsun" sorusundan kurtardı

Control flow'u değiştirmek "sözdizimi güzelleşti" değil, "template artık TypeScript gibi davranıyor" demek

Build tarafında hissedilen şey: bekleme süresinin kaybolması

SSR/hydration: artık "umarım tutar" değil "tutuyor"

Genel his: framework artık arkanda duruyor, önünde durmuyor

Signals Cleaned Up State in Angular. The DOM Was Still Stuck in 2018.

The four primitives

The part I actually care about: teardown

SSR

Why scrollProgress is different

Config is optional

Try it

The Two-Level Computed Graph: How I Stopped Toggle Events From Re-Running Business Logic

useEffect Is Not a Lifecycle Method

rxResource Is Not a Command Bus

Why I Stopped Writing tap() Inside rxResource Streams

On building systems that survive team turnover

What durable looks like

The hardest part

Why I stopped using design tokens as implementation details

The mistake

The correct layer

Stop Putting Everything in useState

Angular Signals: six months of production observations

Where Signals win

Where they fall short

The rule I settled on

State colocation is not a preference, it is an architecture

The rule

`resource()` didn't just replace RxJS, it killed a whole category of state bugs

`resource()` beni RxJS'ten değil, "ne zaman loading true olsun" sorusundan kurtardı