DEV Community: Yasin Demir

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 — which is 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.

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.

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, 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.