DEV Community: Yasin Demir

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.

What ref() and reactive() Are Actually For

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

Vue 3 gives you two ways to make something reactive: ref() and reactive(). The docs explain the difference clearly enough. What they don't tell you is which one to reach for by default.

The short answer: ref(), almost always. reactive() for specific situations where you know what you're trading away.

Here's the problem with reactive(). It loses reactivity when you destructure it or reassign the root object, which catches people off guard more than it should.

const state = reactive({ count: 0, name: '' });

state.count++;       // works, Vue tracks this
const { count } = state;
count++;             // doesn't work, Vue has no idea

ref() sidesteps this because the reactive pointer lives on the .value property. You can pass a ref anywhere, destructure the container, and the ref itself stays tracked.

The case where reactive() actually earns its place: a form object where all the values are always read and written together, passed as-is to a composable, and you're never going to replace the whole reference. Some people find dropping the .value noise worth that constraint. I get it. But in composables especially, ref() is much easier to work with because you can return individual refs that stay reactive when the caller destructures them.

export function useCounter() {
  const count = ref(0);
  const increment = () => count.value++;
  return { count, increment };
}

const { count, increment } = useCounter(); // both still reactive

You can't do that cleanly with reactive(): destructuring breaks the connection.

For most of the time I was figuring out the ref/reactive split, I was making it more complicated than it needed to be. Default to ref(). Reach for reactive() when you have a specific reason. That's the whole decision.

Originally published on ysndmr.com.

Watchers Are Usually the Wrong Answer

Yasin Demir — Tue, 07 Jul 2026 09:39:46 +0000

When I started with Vue's Composition API I used watch() constantly. State changes, something needs to happen. That's what watchers are for. Right?

Most of the time, no.

Watchers are for side effects: persisting to localStorage, calling an API when something changes, syncing with a library that Vue doesn't control. They're not for computing derived values, and they're not for keeping reactive state in sync with other reactive state.

The most common misuse:

const firstName = ref('')
const lastName = ref('')
const fullName = ref('')

watch([firstName, lastName], ([first, last]) => {
  fullName.value = `${first} ${last}`
})

This is a computed property written the hard way. It runs asynchronously by default, it's harder to read, and it can produce frames where fullName is stale before the watcher fires.

const firstName = ref('')
const lastName = ref('')
const fullName = computed(() => `${firstName.value} ${lastName.value}`)

Always in sync. No timing edge cases. One line.

The other pattern that causes problems: chaining watchers. Watch A to update B, watch B to update C. I've done this. Every time I've eventually produced a cycle or a timing issue that was annoying to debug. If values derive from each other, computed handles it.

Where watch() actually belongs: real side effects. userId changes and you need to fetch new data, that's a watcher. The route changes and you need to update a third-party map instance, watcher. You need to debounce an API call on search input, watcher with a cleanup function.

The question I ask before adding a watch: is this a side effect, or is this a value that depends on other values? If it's the second thing, it's a computed. I've removed a lot of watchers by asking that.

Originally published on ysndmr.com.

Why I Built ngx-local-vault: Signals, Encryption, and TTL for Angular Storage

Yasin Demir — Tue, 07 Jul 2026 08:42:14 +0000

Every app needs to persist something in the browser: user preferences, a sidebar toggle, a short-lived session token. localStorage and sessionStorage are the default tools for that.

But using the raw Web Storage API in Angular still feels like 2015. You end up writing the same boilerplate every time.

Most storage wrappers give you a getter and a setter and call it done. Reactivity, encryption, expiration: you're on your own for all three.

So I built ngx-local-vault: persistence, encryption, and TTL, wired into a native Angular WritableSignal.

What's Actually Wrong with Browser Storage

If you've built anything non-trivial in Angular, at least one of these has bitten you:

No reactivity. localStorage.setItem() doesn't trigger change detection. You end up writing your own events, or an RxJS Subject, just so a component notices the value changed.
Plain text. JWTs and profile data sitting in localStorage in plain text are one DevTools tab (or one XSS script) away from being read.
No expiry. localStorage just sits there forever. Want a token to die after 15 minutes? Store a timestamp yourself, check it on load, delete it yourself.
SSR headaches. Touch window.localStorage during server-side rendering and you get ReferenceError: window is not defined. Wrapping every access in isPlatformBrowser gets old fast.

ngx-local-vault

It's a small library, under 2KB gzipped with no dependencies beyond Angular itself, that treats browser storage as something a component can just read reactively.

Instead of separate read and write calls, there's a watchSignal() method that hands you back a real Angular Signal. Read it, .set() it, .update() it: encryption and TTL happen underneath without you thinking about them.

1. Setup

Add it to app.config.ts. Works with Angular 17 through 20.

import { ApplicationConfig } from '@angular/core';
import { provideVault } from 'ngx-local-vault';

export const appConfig: ApplicationConfig = {
  providers: [
    provideVault({
      prefix: 'app_',
      encryptionKey: 'your-secure-key',
      driver: 'local'
    })
  ]
};

2. Using it

Inject VaultService and watch a key:

import { inject, Component } from '@angular/core';
import { VaultService } from 'ngx-local-vault';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  standalone: true
})
export class AppComponent {
  private vault = inject(VaultService);

  theme = this.vault.watchSignal<'light' | 'dark'>('theme', 'light');

  session = this.vault.watchSignal<string | null>('session-token', null, {
    expiresIn: '15m'
  });

  toggleTheme() {
    this.theme.update(current => current === 'light' ? 'dark' : 'light');
  }

  login(token: string) {
    this.session.set(token);
  }
}

What it does differently

Real signals. watchSignal() returns an actual WritableSignal<T>, not some wrapper you have to learn.
Encrypted at rest. Open the Application tab in DevTools and you won't find raw JSON or a bare token sitting there.
TTL that actually deletes itself. Pass expiresIn: '15m' and the entry disappears in-tab when the clock runs out. No reload needed. It takes plain strings: 500ms, 30s, 15m, 2h, 1d.
SSR-safe. Guarded by PLATFORM_ID, so on the server it's just a no-op. No hydration mismatches.
Actually zero dependencies. Only @angular/core and @angular/common as peers. Even tslib gets stripped at build time.

Try It

Live demo: ysndmr.github.io/ngx-local-vault
NPM: npmjs.com/package/ngx-local-vault
GitHub: github.com/ysndmr/ngx-local-vault
My site: ysndmr.com
Original post: dev.to

If you're not on Angular, there are React and Vue versions too. Links are in the GitHub README.

Wrap Up

Signals changed how Angular handles state. I think storage should have followed the same shift a while ago.

How are you handling browser storage in your Angular apps right now? Open an issue or drop a star on GitHub if this is useful to you.

Originally published on ysndmr.com.