DEV Community: Srikar Phani Kumar Marti

Why Input Latency Symptoms Can Mislead Developers: A Deep Dive Into the Real Causes

Srikar Phani Kumar Marti — Mon, 26 Oct 2026 13:02:03 +0000

You’re clicking a button or typing in a form, and the UI feels sluggish. Maybe the button highlight or input response lags behind your finger or mouse by a noticeable fraction of a second. You open your profiler, see some long frames, and assume the culprit is obvious: your JavaScript is blocking the main thread. But wait, digging deeper, the cause isn’t always what it seems.

I ran into this exact confusion debugging a web app where users complained about input lag. Profiling showed long tasks, but the input event timestamps didn’t line up with when UI updates actually happened. The symptoms pointed fingers at JavaScript execution, but it turned out the real bottleneck was a mix of event handling delays, rendering pipeline quirks, and misunderstood profiling signals.

Let’s walk through how browsers handle input events, rendering, and JavaScript work together , and why input latency symptoms can mislead you.

The Familiar Symptom: Input Feels Sluggish

Imagine this: you press a key or tap a button. The app should respond immediately , highlight the button, update text, whatever. Instead, something feels off:

The UI update happens noticeably after your input.
Sometimes the delay is consistent; other times, it’s jittery.
Profiling shows long JavaScript tasks around input, but it’s unclear if that’s cause or effect.

You might think the fix is straightforward: optimize your JS handlers or throttle expensive logic. But what if the event isn’t even reaching your code on time? Or the rendering pipeline itself is introducing delays?

Input Events Aren’t Instant: The Browser Event Pipeline

Browsers don’t just fire an event the moment your finger touches the screen. Input events travel through multiple phases:

Raw Input Processing: The OS and browser receive hardware signals , touch, mouse, keyboard.
Event Coalescing: For pointer and touch events, browsers may batch or coalesce multiple events into one to avoid flooding your app.
Event Dispatch: The browser fires DOM events on appropriate targets.
Event Handling: Your JavaScript listeners run.

This pipeline can add subtle delays:

On mobile, touch events can be delayed by about 300ms historically to detect double taps (though this is largely fixed with pointer events).
Coalescing means you might get fewer events but some representing multiple physical inputs, causing perceived latency.
If the main thread is busy, event callbacks queue up and run late.

So even before your handler runs, the event might already be delayed.

Rendering Pipeline Adds Another Layer of Delay

After your JavaScript updates state or DOM, the browser proceeds through rendering steps:

Style Recalculation: Determine affected CSS styles.
Layout: Compute positions and sizes.
Paint: Draw pixels.
Composite: Combine layers for final display.

These steps happen asynchronously after your JS task finishes. If your JS blocks the main thread for too long, rendering waits. But even if JS is quick, heavy style/layout/paint jobs can delay frame updates.

Profiling Can Lie: Understanding Timeline Marks

When you look at DevTools performance traces, several marks confuse newcomers:

Event Timing: Shows when an event fired and how long its handler took.
Frames: Show when the browser painted new content.
Long Tasks: Blocks that keep the main thread busy.

It’s tempting to blame the longest task overlapping the input event, but remember:

Your event handler may run late due to earlier tasks.
Rendering work triggered by your handler runs after JS finishes.
Input latency includes both event delay and render delay.

For example, a long style recalculation after your handler ends can cause the visible UI update to lag even if JS was fast.

JavaScript Execution Isn’t the Whole Story

In one recent bug, I found a React app where input felt delayed. Profiling showed 50ms event handlers and 100ms layout recalculations after. Initially, I thought throttling or debouncing input handlers would help.

But the real gain came from splitting heavy CSS selectors to speed layout and adding will-change to trigger compositing layers. The rendering work was the actual bottleneck, not JS.

What You Can Do to Pinpoint the Real Bottleneck

Start with the profiler timeline:

Check when the input event fired vs. when the handler ran. If there’s a gap, the main thread was busy.
Look at style/layout/paint work after the handler. Long layout means your DOM or CSS is expensive.
Use Event Timing API (event.timeStamp and performance.now()) to measure event latency from user input.

Try isolating:

Run with minimal JavaScript handlers to see if input latency persists.
Simplify CSS and DOM to measure layout cost.
Use Chrome’s Rendering panel to visualize paint and composite layers.

Common Pitfalls That Mislead Developers

Blaming expensive JS exclusively: Sometimes JS is fast, but layout or paint is slow.
Ignoring event coalescing or pointer event quirks: These can cause input events to batch, delaying your handler.
Misreading profiler timelines: Overlapping long tasks don’t always cause visible lag.
Neglecting browser optimizations and heuristics: Browsers may delay rendering or event firing to optimize battery or CPU usage.

Wrapping Up

Input latency feels simple until you peek under the hood. It’s a dance between hardware input, event processing, JavaScript execution, and rendering steps. Each layer can add delay, and symptoms that look like JS slowness may really be rendering or event dispatch subtleties.

Next time input feels slow, don’t just blame your handlers. Look closely at event timing, rendering workload, and how the browser pipeline orchestrates everything. With that understanding, you’ll find the real bottlenecks faster and fix input lag for good.

Helpful learning resources

MDN Web Docs
web.dev performance guidance
React documentation Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Why Signal Forms Matter in Angular: The Subtle Traps and How to Avoid Them

Srikar Phani Kumar Marti — Thu, 22 Oct 2026 10:46:41 +0000

You’ve been there: your Angular component’s UI stubbornly refuses to update even though you’re sure you changed the signal’s value. No errors, no crashes, just silence.

I had this happen recently while refactoring a component’s state to use Angular Signals. I was updating a signal that held an object, but the UI didn’t react. After some head-scratching, I realized the problem wasn’t Angular’s reactivity itself but the form of the signal, how the signal stored and exposed its value.

Signals Aren’t Just Boxes: They Have Forms

At first glance, a signal is just a container for a value you can get or set. But under the hood, Angular Signals can hold primitives, objects, arrays, or even computed values. How this data is shaped and updated determines if Angular’s change detection triggers.

To put it simply, the form of a signal is about what kind of value it emits and how you update it.

A primitive signal holds a string, number, boolean, etc.
An object signal holds a reference to an object.
A computed signal derives its value from other signals.

Why Signal Form Tripped Me Up: The Object Reference Gotcha

Here’s a minimal reproduction of what I ran into:

const user = signal({ name: 'Alice', age: 30 });

// Later...
user().age = 31; // Mutating the nested property
// user.set(user()); // Not called

I changed user().age, expecting Angular to detect that the user signal changed and update the UI. But it didn’t. Why?

Angular’s Signals track changes using reference equality. When you mutate a nested property inside the object but don’t assign a new object to the signal, Angular has no way to know anything changed.

So just mutating the object’s property is invisible to Angular's tracking.

How to Fix This: Always Update the Signal with a New Reference

To trigger updates, you have to replace the signal’s value with a new object:

user.set({ ...user(), age: 31 });

This creates a new object, and Angular sees the reference changed, so it triggers updates.

What About Computed Signals?

Computed signals derive their value from other signals and update automatically when dependencies change.

Example:

const count = signal(0);
const double = computed(() => count() * 2);

Here, double recomputes whenever count changes. But if count holds an object and you mutate it without changing the reference, double won’t update either.

So the same reference rule applies.

Signal Forms in Templates: Why Reading Matters

Another subtlety: how you read a signal impacts dependency tracking.

In your template, you typically call the signal as a function: {{ user().name }}. This registers a dependency on user. But if you read nested properties outside Angular’s reactive context or in plain functions, the dependency won’t be tracked.

For example, if you extract const name = user().name in a non-reactive function, Angular won’t know to update when user changes.

So always read signals inside reactive contexts (templates, computed signals, effect functions).

Practical Tips to Avoid Signal Form Bugs

Treat signals holding objects as immutable. Always replace the whole object rather than mutating it in place.
Use computed signals to derive values instead of manually reading and mutating nested properties.
Avoid side effects or mutations inside signals’ values. If you need to update deeply nested state, consider immutable updates or helper libraries.
Read signals only inside reactive contexts. Don’t cache nested properties in non-reactive code.

When to Use Different Signal Forms

Use primitive signals for simple values like counters, booleans, strings.
Use object signals for state objects but update immutably.
Use computed signals to derive data you don’t want to manage manually.

For example, managing a form input state:

const formState = signal({ firstName: '', lastName: '' });

function updateFirstName(value: string) {
  formState.set({ ...formState(), firstName: value });
}

What Happens if You Don’t Follow Signal Forms?

You’ll face frustrating UI bugs where the view never updates or updates inconsistently. Debugging these can be tricky because Angular won’t warn you about mutations inside signal values.

Sometimes you might see stale data in your components or computed signals not re-evaluating.

Wrapping Up

Angular Signals are powerful, but their reactivity depends heavily on how you shape and update their values. Treat signals as immutable containers and update them by replacing values, not mutating them. Keep your reads inside reactive contexts.

Once you get this, your Angular apps will feel more predictable, and those silent update bugs will become a thing of the past.

If you’ve struggled with signals not updating, check the form of your signal values first. The fix might be simpler than you think.

Helpful learning resources

MDN Web Docs
React documentation
OpenAI developer resources Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

CSS Logical Properties: How Browsers Translate Them to Physical Styles

Srikar Phani Kumar Marti — Wed, 21 Oct 2026 10:52:22 +0000

You’ve probably hit this subtle bug before: you write some CSS using logical properties like margin-inline-start, expecting your layout to just work regardless of text direction. But then you flip your app to RTL or switch writing modes, and suddenly things don’t line up as you expected. Margins that should shift to the left stay put, or worse, shift in the wrong direction.

I ran into this during a recent localization sprint. Our UI had mixed LTR and RTL content, and rather than duplicating styles or using awkward hacks, I leaned on CSS logical properties. They’re supposed to abstract away physical directions like left/right and top/bottom. But debugging why my margins weren’t behaving as I imagined forced me to dig under the hood , how exactly do browsers turn these logical properties into physical ones?

Logical vs Physical CSS Properties: The Basic Idea

Traditional CSS uses physical directions:

margin-left: 10px;
padding-top: 5px;

These are fixed to the box’s edges, regardless of the document’s writing mode (LTR or RTL) or layout direction (horizontal or vertical).

Logical properties, introduced in CSS Logical Properties and Values Module, let you specify styles based on the writing mode and flow:

margin-inline-start applies margin at the start of the inline flow
padding-block-end applies padding at the end of the block flow

So in a left-to-right language, margin-inline-start equals margin-left. In right-to-left, it maps to margin-right. This makes your CSS more adaptable without duplication.

But here’s the kicker: browsers do this mapping internally, translating your logical properties to physical ones at layout time. Understanding that translation explains many layout quirks.

How Browsers Translate Logical Properties

When the browser’s CSS engine parses a rule like:

.my-box {
  margin-inline-start: 16px;
}

it doesn’t leave it as margin-inline-start. Instead, it figures out the physical edge corresponding to "inline start" for the element’s writing mode and direction.

For example, suppose your document is LTR horizontal:

inline direction goes left to right
inline start is left

The browser will apply the margin as margin-left: 16px internally. But if the same element is in RTL horizontal:

inline direction is right to left
inline start is right

Now the browser applies margin-right: 16px.

This mapping happens during style computation, after resolving the element’s writing-mode and direction but before layout.

What about vertical writing modes?

When the writing mode is vertical (like Japanese or Mongolian vertical text), "inline" and "block" directions swap:

Inline flows top to bottom or bottom to top
Block flows left to right or right to left

So margin-inline-start could map to margin-top or margin-bottom depending on writing-mode and direction. This can be surprisingly confusing if you only think in LTR horizontal terms.

Behind the Scenes: The Browser’s Style Computation Pipeline

In the browser’s rendering engine (think Blink, Gecko, or WebKit), style computation is a multi-step process:

Parsing CSS , The engine parses your CSS, creating a style tree where each node has declarations like margin-inline-start.
Resolving Computed Styles , The engine resolves computed values for each property. For logical properties, it uses the element’s computed writing-mode and direction to map logical properties to physical ones.
Applying Physical Styles , The engine applies these physical styles to layout boxes, which then participate in the box model and flow layout calculations.

This means that from the layout engine’s perspective, it never really sees margin-inline-start; it only sees margin-left or margin-top, etc., depending on context.

Why This Matters for Debugging Layout Issues

Unexpected Margins on RTL or Vertical Text

If your app flips to RTL but some margins don’t move as expected, check if you’re mixing logical and physical properties. Physical properties like margin-left don’t adapt, so your layout breaks.

Overriding Logical Properties with Physical Ones

Sometimes, authors override logical properties with physical ones elsewhere in CSS. Because physical properties have the same specificity and cascade rules, the last one wins. This can cause logical properties to be silently ignored.

DevTools Show Physical Properties

Inspecting elements in browser DevTools often shows the physical properties after translation, not the logical ones you wrote. This can confuse you into thinking your CSS isn’t applied.

Practical Tips When Using Logical Properties

Always use logical properties consistently in your CSS for layout margins, paddings, borders, and positioning.
Be mindful of writing mode. If your app supports vertical writing modes, test your layouts carefully. Logical properties behave differently there.
Check DevTools carefully. Don’t expect to see margin-inline-start in computed styles. Look for the mapped physical properties.
Use computed styles and layout debugging tools. Some browsers let you visualize box model edges and directions, which can help understand how logical properties translate.
Avoid mixing physical and logical properties for the same edge. This reduces cascade confusion.

A Real Debugging Example

I had a sidebar that used:

.sidebar {
  padding-inline-start: 20px;
  border-inline-end: 1px solid #ccc;
}

It looked perfect in LTR, but in RTL, the padding stayed on the left, and the border appeared on the left instead of the right. Turns out, somewhere else in the stylesheet, there was a physical property:

.sidebar {
  padding-left: 10px;
}

Because padding-left came after in the cascade, it silently overrode the logical padding on the physical left edge.

Removing the physical property and relying solely on logical properties fixed the problem.

Wrap-up

CSS logical properties are a powerful way to write adaptable, locale-friendly styles. But they’re not magic. Browsers internally translate them to physical properties based on the element’s writing mode and direction, and understanding that helps you debug those sticky layout issues in multilingual or vertical writing layouts.

Next time your margin-inline-start feels stubborn, remember: it’s actually a margin-left or margin-right in disguise, chosen based on your document’s flow.

Happy styling!

Helpful learning resources

MDN Web Docs
web.dev performance guidance
OpenAI developer resources Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

The Real Cost of CSS Variables: Runtime Resolution and Performance Implications

Srikar Phani Kumar Marti — Tue, 20 Oct 2026 11:55:30 +0000

You’ve probably felt it before: you write a neat CSS variable to keep your colors or spacing consistent, only to notice your page feels sluggish during some interactions. Maybe animations stutter, or style recalculations take longer than expected. It’s tempting to assume CSS variables are just a handy, cost-free abstraction, but under the hood they have real runtime costs that can sneak up on you.

I hit this wall while optimizing a complex web app where CSS variables were used extensively , not just for theming but also for layout tweaks. At first, I thought the slowdowns were unrelated, maybe a heavy JS bundle or too many DOM nodes. But profiling told a different story: style recalculations spiked and correlated tightly with changes to CSS variables.

Let’s walk through what actually happens inside browsers when you use CSS custom properties, why their runtime resolution matters, and how to balance convenience with performance in production apps.

Why CSS variables aren’t just static values

Unlike regular CSS properties with fixed values like color: red, CSS custom properties (variables) are dynamic. They’re defined like this:

:root {
  --main-color: #3498db;
}
.button {
  color: var(--main-color);
}

At first glance, this looks simple: define once, reuse many times. But here’s the twist: browsers don’t replace var(--main-color) with #3498db at parse time. Instead, the actual value gets resolved during style computation at runtime.

Why? Because CSS variables can cascade, inherit, and be overridden anywhere in the DOM tree. For example:

.section1 {
  --main-color: #e74c3c;
}

If a .button is inside .section1, its var(--main-color) resolves to red, not blue. That means the browser has to look up the DOM tree to find the closest variable definition each time it computes styles.

What happens when the browser resolves CSS variables

The browser’s style engine maintains a cascade and inheritance graph. When it encounters a var() reference, it:

Checks the element’s inline styles and stylesheets for a matching --variable declaration.
If not found, climbs up the DOM tree to parent elements, looking for a value.
Uses the first defined value it finds.
If none is found, applies fallback if provided, or invalidates the property.

This lookup isn’t free. It happens every time styles are recalculated, which can be frequent during layout shifts, animations, or DOM changes.

Why style recalculations get expensive with many variables

Imagine you have hundreds of elements using variables like var(--spacing), var(--color), or var(--font-size). When a variable value changes on a parent (say via a theme switch or a CSS class toggle), the browser must:

Invalidate styles of all elements affected by that variable.
Re-resolve the variable value for each element, performing the DOM climb repeatedly.
Update the computed style map and potentially trigger layout or paint updates.

This can cause a cascade of work that quickly adds up, especially if variables are used in properties that impact layout (like margins, widths) or paint (like colors).

I found this by profiling in Chrome DevTools’ Performance tab. Style recalculation times ballooned when toggling a theme color variable that was referenced deep in the DOM tree.

Variables in animations: a double-edged sword

CSS variables shine for theming and responsive design, but mixing them into animations can cause trouble.

If your animation changes a CSS variable value on a root or container element, every dependent property on all children potentially needs re-resolving every frame. For example:

@keyframes pulseColor {
  0% { --main-color: #3498db; }
  50% { --main-color: #e74c3c; }
  100% { --main-color: #3498db; }
}

Applying this animation to a top-level container means the browser must recompute styles for all descendants referencing --main-color on every animation frame. That can kill frame rates.

If you instead animate properties directly (like background-color), the browser can often optimize and GPU-accelerate the paint without full style recomputations.

Which CSS properties amplify the cost?

Not all properties are equal. When a CSS variable is used in a property that affects layout or paint, style recalcs can trigger more expensive downstream work.

For example, variables used in:

width, height, margin, padding → can cause layout recalculations
color, background-color → cause paint invalidations
transform, opacity → usually handled by compositor, less costly

Using variables in properties that trigger layout recalcs can multiply the performance cost because layout affects positioning and size, cascading through the render tree.

How I balanced CSS variables with performance

After pinpointing CSS variable resolution as a bottleneck, I took several practical steps:

1. Limit variable scope

Avoid setting variables on very high-level elements like :root if you don’t need to. Instead, scope them to smaller subtrees where they’re used. This reduces how many elements get invalidated when a variable changes.

2. Cache computed values in CSS or JS

For values that rarely change but are performance critical, consider replacing variables with static values or compute and inject styles via JS if dynamic recalculation is too costly.

3. Avoid animating variables for large subtrees

Reserve CSS variable animations for small, isolated parts of the DOM. For global animations, animate properties directly when possible.

4. Use DevTools to profile style recalcs

Modern browser DevTools can help you see exactly how long style recalculations take and what triggers them. This helps catch expensive variable usage early.

When CSS variables still win

Despite the cost, CSS variables provide unmatched flexibility, especially for theming, design tokens, and building components that adapt to context. They’re a powerful tool , but like all tools, you need to wield them with care.

Knowing what’s going on under the hood helps you decide when variables make sense and when static styles or JavaScript-driven updates might be better.

Next time your app feels sluggish after a style change, consider that it might be your variables quietly doing a lot of work behind the scenes.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

How CSS Containment Affects Layout and Paint Performance in Large Apps

Srikar Phani Kumar Marti — Mon, 19 Oct 2026 10:46:11 +0000

Ever been frustrated by a slow, janky UI in your large app, and wondered if there’s some CSS magic to speed things up? You might have stumbled upon the CSS contain property and thought, "Great, I’ll just slap this on some big container, and the browser will do less work, right?"

I fell into that trap myself. I added contain: layout paint; to a few big sections and felt an initial rush, my app felt snappier. But then, weird bugs started showing up. Some parts didn’t repaint right, elements overflowed unexpectedly, and animations broke. What gives?

Let’s get under the hood and see exactly what CSS containment does, why it matters for layout and paint performance, and how to avoid those frustrating surprises.

What is CSS Containment, Really?

The contain property tells the browser to isolate a DOM subtree from the rest of the page in certain ways. Think of it as declaring a "boundary" for browser work:

layout containment (contain: layout): The browser can treat the element and its descendants as independent for layout calculations. Changes inside won’t force the browser to re-layout everything outside.
paint containment (contain: paint): The browser knows the element's rendering is self-contained and won't paint outside its bounds. This can improve paint performance.
size containment (contain: size): The element’s size is independent; the browser doesn’t check children to compute size.

You can combine these: contain: layout paint; or contain: strict; (which includes layout, paint, size, style, and more).

Why Does This Help Performance?

Browsers spend a lot of time recalculating layout and repainting when something changes, like DOM updates, style changes, or animations. Normally, these changes can ripple through the entire page, causing a cascade of work.

When you set containment, you tell the browser: "Hey, this subtree won’t affect anything outside." That means:

Layout changes inside don’t cause re-layout outside.
Paint work can be clipped and cached more aggressively.
The browser can optimize invalidation regions.

In large apps with complex component trees, this isolation can dramatically reduce the work browsers do per frame, keeping your UI smooth.

A Real-World Debugging Tale

I added contain: layout paint; to a sidebar component in a React app. The sidebar is a big, complex tree that updates frequently.

At first, everything was smoother. Typing in inputs inside the sidebar didn’t freeze the main content. Great!

But then, some dropdown menus inside the sidebar started rendering outside their bounds, overflowing or getting clipped. Animations inside the sidebar also sometimes jumped or flickered.

What happened?

Turns out, contain: paint creates a new stacking context and clipping boundary. If your dropdowns use position: fixed or rely on overflow visible outside the container, containment clips them off. The browser assumes the subtree can't paint outside itself.

Breaking Down the Tradeoffs

Here’s what you gain and lose when you use contain:

Gain: Faster layout and paint because the browser scopes work.
Lose: Elements inside can’t affect outside layout or paint. This breaks things like:
- Overflow visible elements (tooltips, dropdowns)
- CSS filters and blend modes spilling outside
- Some CSS inheritance behaviors

How Browsers Implement Containment

Under the hood, containment lets browsers do incremental work:

They calculate layout for the contained subtree independently.
They create separate layers and stacking contexts for paint.
They limit invalidation regions to those layers.

This isolation reduces the cost of style recalculation, layout, and paint, especially when you have lots of DOM nodes.

When to Use `contain` in Production Apps

Start with these guidelines:

Use on large container elements with complex subtrees that update often.
Avoid on elements with children that rely on overflow visible or fixed positioning that escapes their bounds.
Test carefully in browsers you support. Containment behavior can vary slightly.
Combine with layout debugging tools (like Chrome’s Paint Flashing) to see how containment affects repainting.

Debugging Unexpected Behavior

If you see clipped dropdowns, tooltips, or animations flickering:

Check if contain is set on any ancestor.
Try removing paint containment first; layout alone is less restrictive.
Inspect stacking contexts (element.style.contain) and overflow properties.
Consider moving popups outside contained containers using portals or separate DOM nodes.

Example: Containment and Dropdowns

.sidebar {
  contain: layout paint;
  overflow: hidden;
  position: relative;
}

.dropdown {
  position: absolute;
  top: 100%;
  left: 0;
  /* But if .sidebar has paint containment, the dropdown might be clipped! */
}

If .sidebar uses contain: paint, the dropdown can’t paint outside .sidebar's bounding box, causing visual clipping.

Workaround: Render dropdowns at a higher DOM level (e.g., React portals) so they escape the containment boundary.

A Quick Checklist Before Adding `contain`

Does the container have children that overflow outside or use fixed positioning?
Will descendants use CSS filters, shadows, or blend modes that extend beyond boundaries?
Are you okay with the contained subtree being isolated from the rest of the page’s style and layout?

If the answer is no to any, containment might cause subtle bugs.

Final Thoughts

CSS containment is a powerful tool to improve performance by letting browsers scope layout and paint work. But it’s not a silver bullet. Knowing what it does under the hood helps you make informed tradeoffs and avoid bugs that can feel like ghost problems.

Next time your large app stutters or repaints too much, try containment, but keep an eye on those sneaky clipping and stacking bugs. And remember, sometimes the best fix is a well-placed React portal or layering tweak.

Give it a try, and you’ll start seeing your app from the browser’s eyes, focused, isolated, and faster.

Helpful learning resources

MDN Web Docs
web.dev performance guidance
React documentation Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

What’s New and Different in Angular NgRX Store Version 22

Srikar Phani Kumar Marti — Fri, 16 Oct 2026 11:35:32 +0000

You know that feeling when you upgrade a familiar library , and suddenly your app behaves slightly differently? No errors, no big crashes, just subtle changes that make you scratch your head?

That’s exactly what happened when I upgraded an Angular app from NgRX 13 to NgRX 22 recently. I rely on NgRX store for state management and effects, but version 22 introduced some tweaks that changed how selectors behave, typing improves, and runtime performance shifts.

Here’s a walkthrough of the key changes I encountered, what’s really going on under the hood, and how you can spot and adapt to these differences.

The NgRX store you thought you knew

If you’ve used NgRX store before, you know it’s basically Redux for Angular, with selectors, actions, reducers, and effects to manage state in a reactive way.

The core concepts stayed the same in v22, but the implementation details and typings improved. Still, some subtle differences sneaked in that can trip you up.

For example, the way selectors memoize results and how they handle parameterized selectors got some internal revisions. Also, there’s better TypeScript inference for feature selectors now.

What caught me off guard: Selector memoization changes

In previous versions, selector memoization was straightforward: a selector caches its last input and output, and skips recalculations if inputs are strictly equal.

With NgRX 22, the selector memoization logic was refined to improve performance and avoid stale data. It now better tracks dependencies internally and avoids unnecessary recalculations in some edge cases.

Sounds great until you hit this weird bug where a selector that depended on a nested object stopped updating when the nested object’s properties changed but the reference didn’t.

Here’s a quick example:

const selectFeature = createFeatureSelector<MyFeatureState>('feature');
const selectNestedValue = createSelector(
  selectFeature,
  feature => feature.nested.value
);

If your reducer mutated nested in place (which you shouldn’t do, but sometimes happens), the selector might not re-run because the top-level feature object reference didn’t change.

NgRX 22 memoizes more aggressively and relies on inputs’ references for change detection more strictly. This pushed me to audit reducers and ensure immutable updates everywhere.

Better typing for feature selectors

One of the biggest quality-of-life improvements in NgRX 22 is how TypeScript infers types for feature selectors.

Previously, you had to manually specify state interfaces frequently, or deal with loose typings that made autocomplete and error detection weaker.

Now, createFeatureSelector fully infers the feature slice type if you pass a generic argument, and downstream selectors get tighter typings automatically. This made refactoring safer and helped catch bugs early in my IDE.

Here’s how I updated selectors:

interface MyFeatureState {
  items: Item[];
  loading: boolean;
}

const selectFeature = createFeatureSelector<MyFeatureState>('myFeature');
const selectItems = createSelector(
  selectFeature,
  state => state.items
);

With version 22, the state argument in the selector callback is correctly typed as MyFeatureState, so no more casting or guessing.

Breaking changes to note: StoreModule.forRoot and forFeature

The NgRX team cleaned up the StoreModule APIs slightly. While the old syntax still works, it now warns if you mix incompatible configurations.

If your app registers feature states dynamically or with lazy-loaded modules, make sure your forFeature calls match the expected typings and that you pass reducers directly or as a map object.

They also recommend using the new provideState() and provideStore() APIs introduced alongside v22 for better tree-shaking and standalone API support in Angular 16+. Migrating to these new providers can improve bundle sizes but needs some code changes.

Effects improvements and subtle runtime behavior changes

NgRX Effects also got some polish. The main change I noticed was around error handling and completion behavior:

Effects don’t complete by default anymore, which means they keep listening indefinitely unless explicitly completed.
The new createEffect options let you specify if an effect should dispatch actions or not more clearly.

This helped me catch some subtle bugs where effects stopped firing after certain errors or completions in older versions.

Why these changes matter: A real debugging story

I spent a frustrating afternoon debugging an issue where a selector stopped updating after a certain action dispatched. The UI stayed stale.

Turns out, the reducer was mutating nested state properties instead of returning new objects. NgRX 22’s stricter memoization ignored the change because the feature slice’s root reference didn’t change.

Fixing the reducer to return new objects fixed the selector updates immediately:

// Bad (mutating nested state)
state.nested.value = newValue;
return state;

// Good (immutable update)
return {
  ...state,
  nested: {
    ...state.nested,
    value: newValue
  }
};

This reinforced the immutable update pattern more strictly than before.

Wrapping up the NgRX 22 upgrade

Upgrading to NgRX 22 was mostly smooth, but it nudged me to pay closer attention to immutability and typing.

Selector memoization is more aggressive and reference-based.
Typings for feature selectors got much better.
StoreModule APIs have new providers and recommended usage for Angular standalone.
Effects behavior around completion and dispatch is clearer now.

If you’re upgrading, audit your reducers for immutable patterns, update your selectors to use new typings, and consider switching to the new provider APIs.

NgRX store is still the solid choice for Angular state management, but version 22 reminds you to keep your state immutable and your typings tight.

If you’ve run into other quirks or hidden gems in NgRX 22, I’d love to hear about them!

Helpful learning resources

MDN Web Docs
web.dev performance guidance
React documentation Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Understanding Paint Containment and Composite Layers for Smooth Animations

Srikar Phani Kumar Marti — Thu, 15 Oct 2026 14:08:40 +0000

You’re building a slick UI with smooth animations. You add a subtle transform here, a fade there. But then, boom , your animations stutter. Frames drop, interactions feel sluggish, and your user experience tanks.

You tweak your CSS, add will-change: transform, and suddenly things get smoother. But why? What actually happens under the hood when you add that mysterious CSS property? Or when you add contain: paint? How do those tiny CSS hints help the browser decide to offload rendering work to the GPU?

Let me share what I learned digging into paint containment and compositing layers , the quiet heroes behind buttery smooth animations and frustrating jank.

The moment you realize something’s wrong

I was working on a dashboard with complex nested components and animations. Some animations were jittery, especially when scrolling or interacting with other UI parts.

Opening Chrome DevTools, I checked the Performance tab and noticed a lot of layout and paint work every frame. The GPU wasn’t getting a break.

I suspected compositing layers weren’t being created smartly. If each animated element had its own layer, the browser could push rasterization to the GPU, freeing up the CPU and enabling smooth 60fps animations.

But how does the browser decide what gets its own compositing layer?

What is a compositing layer anyway?

Imagine the browser’s rendering pipeline like an assembly line:

Style: The browser figures out what styles apply to each element.
Layout: Positions and sizes are computed.
Paint: Elements are drawn into bitmaps.
Composite: These bitmaps (layers) are combined to produce the final image.

Most elements are painted into a shared bitmap. But some elements get their own bitmap , a compositing layer. This bitmap can be handed off to the GPU to be transformed or animated independently without repainting the entire page.

When a layer is created, animations like transforms or opacity changes on that layer become super cheap , the GPU just moves or blends that bitmap.

Paint containment: telling the browser to isolate painting

You can hint to the browser when an element should get its own compositing layer by using CSS containment. The contain property lets you declare what aspects of rendering are confined to a subtree.

contain: paint means “hey browser, this element and its subtree won’t affect anything outside their bounding box when painting.”

Why does this matter? Because if the browser knows an element is paint-contained, it can safely create a compositing layer for it. Changes inside won’t force repaints outside.

Consider this example:

.card {
  contain: paint;
  will-change: transform;
}

Here, .card is paint-contained and hints it will be transformed. The browser can create a separate layer for .card and push its rendering work to the GPU.

How paint containment creates layers under the hood

Under the hood, the browser’s rendering engine tracks containment properties during the paint phase.

When it hits an element with contain: paint, it creates a new paint layer.
This layer is a bitmap snapshot of that subtree.
Because it’s isolated, the browser knows repainting this layer won’t affect siblings or ancestors.
The compositor can now handle that layer independently.

This is a big win for animations.

If you animate a transform on that element, the browser only needs to update the layer’s position on screen , no repaint or re-layout.

Without containment, the browser might have to repaint a large part of the page every frame.

The GPU angle: why compositing layers matter

Compositing layers are the boundary between CPU-bound painting and GPU-accelerated compositing.

Your browser’s GPU can move, scale, rotate, or fade whole layers very efficiently.

But creating too many layers is also bad , each layer consumes GPU memory and overhead.

The browser tries to balance:

Too few layers: More repaint work on CPU, animations jank.
Too many layers: GPU memory pressure, possible thrashing.

You can influence this balance with contain, will-change, and other CSS properties.

Debugging paint containment and layers in DevTools

If you suspect your animations are slow due to missing layers, here’s how to check:

Layers panel in Chrome DevTools:
- Open DevTools > More Tools > Layers.
- You’ll see a visual map of compositing layers.
- Animated elements should have their own layers.
Rendering tab > Paint flashing:
- Enable "Paint flashing" to see what parts of the page repaint during interactions.
- If large areas repaint during a transform animation, you lack proper containment.
Performance tab:
- Record a profile while animating.
- Look for "Recalculate Style" and "Paint" tasks.
- Excessive painting per frame hints at missing layers.

Practical tips to avoid jank

Use contain: paint or contain: layout paint on animated elements or their parents when possible.
Add will-change: transform (or whatever property you animate) to hint the browser early.
Avoid animating properties that force layout or paint (like width, height, top).
Keep your layer tree manageable: don’t paint-contain everything blindly.
Test on real devices with DevTools profiling.

Real-world gotchas

Not all browsers support all containment types equally.
Overusing will-change can backfire and cause memory bloat.
Complex shadow DOM or web components might not behave as expected without explicit containment.
Sometimes, a parent’s overflow or opacity settings affect layer creation unexpectedly.

Why understanding this matters

When you grasp how paint containment and compositing layers work, you can:

Write CSS that helps the browser optimize rendering.
Debug tricky animation jank by spotting missing layers.
Balance GPU memory usage and CPU load.
Build smoother, more responsive UIs.

Next time your animation stutters, pause and inspect your layers. Your GPU will thank you.

Helpful learning resources

MDN Web Docs
web.dev performance guidance
OpenAI developer resources Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

How Angular Signals Really Work: Behind the Scenes of Reactivity

Srikar Phani Kumar Marti — Tue, 13 Oct 2026 10:49:13 +0000

You’ve been there: you update some Angular state, expecting your UI to refresh instantly. But the component stays stubbornly frozen, no errors or warnings , just silence. Maybe you’re using Angular Signals, and they promised to simplify reactivity, but your updates don’t always reflect where you expect.

That exact thing happened to me recently. At first, I thought it was a bug in my code. After some digging, I realized the mystery was how Angular Signals track dependencies and trigger updates behind the scenes. It’s not magic, but it’s subtle.

Let me walk you through what I figured out about Angular Signals , how they manage state reactively, how they track which parts of your app depend on them, and how they kick off Angular’s change detection when needed.

The moment a signal feels like magic , or doesn’t

Signals in Angular look like reactive variables. You declare a signal with signal(initialValue) and read or write its .value. When the value changes, anything depending on it should update.

Sounds simple, right? But here’s the catch: those "anything depending on it" are tracked, not guessed.

Imagine this component snippet:

const count = signal(0);

@Component({ ... })
class CounterComponent {
  count = count;
  double = computed(() => this.count.value * 2);
}

If your template uses {{ double() }}, Angular automatically knows to update when count changes, because double depends on it. But what if you just read count.value directly in some plain function, outside Angular's reactive context? The signal won’t know to notify anyone.

I ran into this when I had a signal update inside an event handler that wasn’t wrapped properly in Angular’s reactive context. No UI update happened , the component didn’t re-render because Angular’s change detection wasn’t triggered.

Signals are reactive primitives with dependency tracking

Under the hood, a signal is not just a value holder. It keeps track of who reads its value during a reactive computation.

Here’s how it works:

When you call a computed signal or Angular evaluates a component’s template, Angular creates a "tracking context."
As the computation runs, every signal’s .value getter checks if there’s a current tracking context.
If there is, the signal records that the computation depends on it.
When the signal’s value changes, it looks up all the computations (or subscribers) that depend on it and notifies them.

This means Angular knows precisely which parts of your UI rely on which signals, so it only updates what actually needs to change.

How Angular signals tie into change detection

Signals themselves don’t update the UI directly. They notify their subscribers, which could be:

Computed signals that recalculate derived values
Angular’s change detection mechanism to re-render components

When a signal updates, it queues Angular's change detection for the associated component. This happens asynchronously, usually scheduled via NgZone or microtasks.

That’s why sometimes you see updates batched together , Angular waits for the current synchronous work to finish before running change detection.

If you update a signal outside Angular’s zone, or in some async callback without zone awareness, Angular won’t know to check your component again. That was the root cause of my silent update bug.

Debugging signals: What to look for

Here are some concrete things I learned to check when your Angular Signals don’t seem to update the UI:

Are you reading the signal inside a reactive context?

Reading signal.value in a plain function without Angular's tracking won’t register a dependency.

Is the signal update happening inside Angular’s zone?

If you update a signal inside a callback from a non-Angular source (like setTimeout or a third-party library), Angular might miss it. Use NgZone.run() or zone.runOutsideAngular() carefully.

Are you using computed signals correctly?

Computed signals cache their results and only recompute when dependencies change. If your computed signal references something outside signals, it won’t update.

Are you mixing signals with other reactive tools?

Angular Signals work best when you stick to their reactive model. Mixing RxJS or other state management patterns requires bridging carefully.

A simple example to illustrate

Here’s a minimal example I played with:

const count = signal(0);
const doubled = computed(() => count.value * 2);

@Component({
  selector: 'my-counter',
  template: `
    <p>Count: {{ count() }}</p>
    <p>Doubled: {{ doubled() }}</p>
    <button (click)="increment()">Increment</button>
  `,
})
export class MyCounter {
  count = count;
  doubled = doubled;

  increment() {
    this.count.set(this.count() + 1);
  }
}

This works perfectly because:

The template calls count() and doubled(), so Angular tracks those dependencies.
Clicking the button calls increment(), which updates the signal.
The signal change triggers Angular’s change detection to re-render the template.

But if you read count.value outside Angular’s reactive system (say in a console log or a raw callback), Angular won’t know to update anything.

Why this matters for your app

Signals are powerful because they give you fine-grained control over reactivity without heavy machinery. But that power comes with responsibility:

You must be mindful of where you access signals
Understand how Angular tracks dependencies
Ensure updates happen inside Angular’s zone

Once you get it, signals can simplify your state management and reduce unnecessary renders.

But if you treat them like plain variables, you’ll end up chasing bugs where your UI silently refuses to update.

Wrapping up

Angular Signals are more than just reactive variables, they’re reactive primitives with smart dependency tracking and integration with Angular’s change detection. The secret to getting them right? Understanding where and how Angular tracks signal usage and triggers updates.

Next time your UI feels stuck after a signal update, check if you’re in the right reactive context and Angular’s zone. That little insight saved me hours of debugging.

Signals aren’t magic, but once you understand how they work under the hood, you’ll find them a practical and elegant way to manage state in Angular.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Angular Standalone Components: How They Change Compilation and Dependency Injection

Srikar Phani Kumar Marti — Mon, 12 Oct 2026 11:21:10 +0000

Ever had that nagging feeling when your Angular module files start piling up, and the boilerplate for NgModules feels like a mountain you just want to avoid climbing? I ran into this recently trying to simplify a mid-sized Angular app. Then Angular’s standalone components landed and suddenly, things started to look cleaner, and stranger under the hood.

Standalone components let you skip NgModules entirely for many cases. That sounds like a purely syntactic win, but it actually shakes up how Angular’s compiler processes components and how dependency injection (DI) scopes get wired together. I dug into what actually changes, and what it means when debugging weird DI errors or compilation issues in large apps.

The familiar setup: NgModules as the backbone

For years, Angular developers have leaned on NgModules to group components, directives, and pipes, and crucially, to configure DI scopes and compilation context. When you build or add a component, you register it inside a module’s declarations. Services get provided either at the root or inside modules via providers arrays.

The compiler gathers metadata from all these modules to generate factories and link DI providers. It’s a big coordination job. This centralized NgModule system shaped how Angular apps are structured, how lazy loading works, and how scopes of injectors nest.

But there’s a cost: boilerplate explodes, and sometimes it’s hard to untangle which module provides what, especially in large apps with many feature modules.

Enter standalone components: no module needed

Standalone components flip this pattern. You declare a component with standalone: true in its decorator:

@Component({
  selector: 'app-widget',
  templateUrl: './widget.html',
  standalone: true,
  imports: [CommonModule, FormsModule] // just like NgModule imports
})
export class WidgetComponent {}

No NgModule to declare it in. You import needed Angular directives or other components directly via the imports array on the component itself.

While this feels like a breath of fresh air, it also means Angular’s compiler has to handle components differently.

Compilation shifts: from NgModule metadata to component-level context

With NgModules, the compiler collects all declarations and imports at module level, generating a giant compilation graph. Standalone components move this graph closer to the component, bundling its dependencies and metadata tightly.

This means:

The compiler generates factories for standalone components that include their own import graphs.
Tree-shaking gets friendlier, no need to pull in an entire NgModule just because a component depends on one directive inside it.
The compilation is more incremental and localized.

I noticed this when rebuilding a standalone-heavy app and watching the Angular build logs. The compiler reported different metadata files emitted, and fewer global module summaries. Debugging compilation errors required me to look at component import arrays rather than hunting for the culprit module.

Dependency Injection scopes: the subtle but important changes

NgModules have been the usual DI scope boundaries. When you provide a service in a module, all components declared inside share that injector.

With standalone components, DI scopes become more flexible, and a bit trickier:

Standalone components create their own injector scope if they provide services.
When a standalone component imports other standalone components, Angular merges their injectors appropriately.
You can still provide services at the root level or in component providers, but the absence of modules means the injector hierarchy follows the component tree more directly.

For example, if WidgetComponent provides a service in its providers array, that service instance is scoped to that component subtree. If you nest that widget inside another standalone component, each instance can have its own injector.

This can catch you off guard if you expect module-wide singleton services but accidentally scope them too narrowly.

Practical debugging implications

I ran into a couple of tricky debugging moments:

Unexpected multiple instances of a service: Without modules to unify providers, if you provide a service in multiple standalone components, Angular treats them as separate injectors. Your service state can fragment unexpectedly.
Missing dependencies at runtime: The compiler verifies imports on standalone components carefully. Forgetting to import a directive or pipe that was previously imported transitively via a module leads to runtime template errors.
Lazy loading changes: Lazy-loaded routes can now point directly to standalone components, which changes how injector hierarchies form. Debugging injector trees requires inspecting component injector parents rather than module injectors.

What this means for large apps

For big Angular apps, standalone components can simplify the dependency graph by removing module layers. But you need to be intentional about:

Explicit imports on components: You no longer rely on deep NgModule import chains. Every component must declare what it needs.
Service provider placement: Decide carefully where you provide services. If you want a singleton, provide at root or in a core standalone component that wraps the app.
Injector awareness: When debugging DI errors, think component injector tree, not module injector tree.
Compilation boundaries: Build tooling and compilers now work more incrementally. This can speed up builds but also surface errors earlier.

Wrapping up: standalone means rethink, not just remove modules

Standalone components in Angular are more than just a shortcut to skip NgModules. They shift compilation from a module-centric graph to a component-centric one and change how dependency injection scopes operate.

If you try them, prepare to:

Explicitly import every dependency in your component
Rethink service provider scopes
Learn new debugging mental models focusing on component injector hierarchies

But in return, you get lighter components, more granular compilation, and a flexible DI model that aligns more closely with your UI structure.

If your Angular app ever felt weighed down by modules, standalone components might just be the fresh start you need. Just remember, under the hood, Angular is doing quite a bit more work to keep your app running smoothly.

Helpful learning resources

MDN Web Docs
OpenAI developer resources Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Decoding the CSS Cascade: How Browsers Resolve Conflicting Declarations

Srikar Phani Kumar Marti — Fri, 09 Oct 2026 11:53:29 +0000

Ever added a CSS rule, sure it should apply, but the browser stubbornly sticks to the old style? You tweak selectors, add !important, but still something else wins that you didn’t expect. I’ve been there more times than I care to count.

CSS feels simple at first: write a selector, set a property, watch the change. But once your stylesheets grow, frameworks pile on layers, and browsers juggle conflicting declarations, things get messy. The secret sauce behind it all is the CSS cascade , the rules browsers use to decide which style actually applies when multiple declarations fight.

I recently dug into how the cascade really works and it changed how I debug CSS issues. Along the way, I noticed how SCSS-generated CSS and its nesting can subtly affect cascade outcomes. Here’s what I learned, with examples you can try yourself.

When CSS surprises you

Imagine this:

.button {
  color: blue;
}

.highlight {
  color: red;
}

And your HTML:

<button class="button highlight">Click me</button>

You expect the button text to be red because .highlight is last and looks more specific, right? But it stays blue. What’s going on?

Turns out, .button and .highlight have the same specificity (both one class), but the cascade also considers origin and source order. The .button rule might come from a stylesheet loaded later, or even from a user agent stylesheet or browser extension.

With SCSS, you might write nested selectors that compile to different source orders than you expect, which can change which rule wins.

Let’s break down what’s actually happening.

The cascade’s main players

The cascade resolves conflicts between multiple CSS declarations targeting the same element and property. It prioritizes declarations based on four factors:

Origin , Where the CSS comes from (user agent, user, author, inline).
Importance , Whether a declaration is marked !important.
Specificity , How precisely a selector targets an element.
Source order , Which declaration appears last in the CSS when everything else ties.

We’ll walk through each with examples , including how SCSS can affect source order.

1. Origin: Browser vs you

CSS rules come from different origins:

User agent stylesheets , The browser’s default styles (like gray buttons).
User stylesheets , Styles a user applies to override websites (rare for devs).
Author stylesheets , Your CSS files.
Inline styles , Styles written directly on elements via the style attribute.

The cascade ranks origins roughly like this:

User !important > Author !important > Author normal > User normal > User agent

Inline styles have very high specificity and usually win unless overridden by !important from author or user styles.

Example:

<button class="btn" style="color: green">Save</button>

.btn {
  color: red !important;
}

Here, the .btn rule is an author !important style, which beats inline styles without !important. So the text will be red, not green.

2. Importance: The `!important` trump card

Adding !important bumps a declaration above normal ones, even with lower specificity.

.button {
  color: blue !important;
}
.highlight {
  color: red;
}

Now .button wins because of !important, even though .highlight comes later.

Be careful: overusing !important turns your CSS into a debugging nightmare. Use it sparingly.

3. Specificity: Counting your selector’s weight

Specificity measures how precisely a selector targets an element. It’s roughly:

Inline styles: 1,0,0,0
IDs: 0,1,0,0 per ID
Classes, attributes, pseudo-classes: 0,0,1,0 each
Element names and pseudo-elements: 0,0,0,1 each

Example:

#nav a.active {
  color: blue;
}

.nav a {
  color: red;
}

#nav a.active is more specific because it has an ID selector, so it wins.

How SCSS nesting can affect specificity and source order

SCSS lets you nest selectors, which compiles to multiple selectors in CSS. For example:

.button {
  color: blue;
  &.highlight {
    color: red;
  }
}

Compiles to:

.button {
  color: blue;
}

.button.highlight {
  color: red;
}

Here, .button.highlight is more specific than .button alone, so it wins.

But if you write:

.highlight {
  color: red;
}

.button {
  color: blue;
}

The compiled CSS source order has .highlight first, .button later , so .button wins if specificity ties.

SCSS source order depends on how you organize your files and nesting, which affects cascade.

4. Source order: Last rule wins

When origin, importance, and specificity tie, the declaration that appears last in the CSS wins.

For example:

.button {
  color: blue;
}

.button {
  color: red;
}

The button text will be red because the second rule comes later.

With SCSS, remember that nesting and imports can reorder rules unexpectedly.

Why specificity can be tricky

Sometimes inline styles override CSS rules with !important. That’s because inline styles have very high specificity, but !important can trump inline styles if the !important comes from the author or user origin.

Also, attribute selectors and pseudo-classes add to specificity, so adding [type="button"] or :hover can change which rule wins.

Debugging cascade issues: Tools and tricks

When a style won’t apply:

Use your browser’s devtools Computed Styles pane to see which rules apply and which get overridden.
Look for specificity and origin badges.
Check for !important flags , they usually explain why a rule is winning.
Review source order in your CSS files and how SCSS compiles your styles.
Inline styles and JavaScript-injected styles often cause surprises.

Real-world example: Unexpected background color

I once had a card component whose background wouldn’t change despite multiple CSS attempts:

.card {
  background-color: white;
}

.highlighted {
  background-color: yellow !important;
}

Applied like this:

<div class="card highlighted">...</div>

But the background stayed white. Devtools showed an inline style:

<div class="card highlighted" style="background-color: white;">...</div>

Inline styles have higher specificity than author styles. The !important on .highlighted didn’t override the inline style because the inline style wasn’t marked !important.

The fix? Remove the inline style or add !important via JavaScript if needed. Better yet, avoid inline styles for such properties.

What about inheritance?

Some CSS properties inherit by default (like color and font-family). Others don’t (like margin and border). The cascade applies after inheritance, so if you see unexpected styles, inheritance might be involved. But inheritance only fills in when no declaration exists , it doesn’t override declarations.

Wrapping up the cascade puzzle

The cascade isn’t just "last rule wins." It’s a layered system balancing where styles come from, how important they are, how specific selectors are, and where they appear in your CSS.

Understanding these layers helps you debug tricky styling issues faster and write more predictable CSS. When that style refuses to apply, don’t just add !important; pause, check origins, specificity, and source order , including how your SCSS compiles , and your fix will land smoother.

Next time your CSS fights back, remember the cascade’s secret hierarchy and use it wisely.

Helpful learning resources

MDN Web Docs
OpenAI developer resources Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

How Angular Signals Work Under the Hood: Reactive Primitives and Change Detection

Srikar Phani Kumar Marti — Wed, 07 Oct 2026 11:00:47 +0000

Ever had a component in Angular that stubbornly refuses to update when you think it should? You tweak some state, and the UI looks frozen , no error, no warning, just silence. Then, after some trial and error, you realize the problem isn’t your code but how Angular’s new Signals system tracks dependencies and triggers change detection.

I hit this wall recently while migrating a complex form to use Angular Signals. At first glance, signals seemed like magic , reactive primitives that promised simpler state management and automatic updates. But the behavior wasn’t always intuitive, especially when combined with Angular’s existing change detection mechanism.

Here’s what I learned about how Angular Signals work under the hood, how they track dependencies, how they trigger change detection, and some debugging strategies to tame reactive state bugs in production.

Angular Signals: More than just reactive variables

Signals in Angular are reactive containers that hold a value and notify subscribers when that value changes. Unlike simple BehaviorSubjects or EventEmitters, signals automatically track which computations depend on them, so updates propagate precisely where needed.

But how does Angular know which component or template should update when a signal changes? The answer lies in dependency tracking combined with Angular’s change detection.

Dependency tracking: Catching who uses what

When you read a signal's value inside a reactive computation or template, Angular records that this computation depends on the signal. This happens through a global tracking context:

When Angular evaluates a reactive function (like a computed signal or a component context during change detection), it sets a current "tracking frame."
When you access a signal’s value inside that frame, the signal registers itself as a dependency.
Later, when the signal’s value changes, Angular knows exactly which computations or components need to be re-run or marked dirty.

For example:

const count = signal(0);
const doubled = computed(() => count() * 2);

Here, doubled tracks count as a dependency. When count updates, Angular will re-run the doubled computation.

Signals and Angular change detection: The handshake

Angular traditionally uses zones and dirty checking to detect changes. Signals add a layer of precision by marking affected components as dirty immediately when a signal changes.

Here’s the flow:

A signal’s setter updates its value.
The signal notifies all subscribed computations and Angular components that depend on it.
Angular marks those components as dirty.
At the next change detection cycle, only the dirty components re-render.

This reduces unnecessary re-renders and improves performance.

But it also means if you update a signal outside Angular’s zone or without proper subscription, Angular might not know to check for updates.

Where bugs creep in: Missing subscriptions and outside zone updates

A frequent gotcha I faced was updating signals in contexts Angular doesn’t track, such as:

Event handlers not wrapped in Angular’s zone.
Observables or promises updating signals asynchronously.
Signals used inside third-party libraries or outside Angular’s component context.

In these cases, Angular’s change detection can miss the signal update, leaving the UI stale.

For instance:

import { runOutsideAngular } from '@angular/core';

runOutsideAngular(() => {
  setTimeout(() => {
    count.set(count() + 1); // Angular may not detect this change
  }, 1000);
});

Without wrapping this in NgZone.run(), Angular won’t know to run change detection after count updates.

Debugging reactive state bugs: What to watch for

Check where you update signals: Are updates happening inside Angular’s zone? If not, wrap them in NgZone.run() to ensure change detection triggers.
Verify signal subscriptions: Components automatically subscribe to signals accessed in templates or computations. But if you read signals imperatively without access during change detection, Angular won’t track dependencies.
Use effect() for side effects: When you need to run code in response to signal changes, use effect(). It automatically tracks dependencies and runs when signals change.

Example:

effect(() => {
  console.log('Count changed:', count());
});

Inspect the dependency graph: Angular provides debugging tools that show signal dependencies and which computations are dirty. Use these to spot unexpected missing links.

Signals and templates: How Angular wires it all up

When you use signals in templates, Angular calls the signal to get its current value during change detection. This access causes Angular to register the component as a subscriber to the signal.

So, if you write:

<div>{{ count() }}</div>

Angular knows this component depends on count. When count updates, Angular marks this component dirty, triggering a re-render.

Computed signals: Laziness and caching

Computed signals are lazy. They only re-run their function when accessed and when one of their dependencies has changed.

That means if you have a computed signal that isn’t read by anything, it won’t run. This can trip you up if you expect side effects inside computed signals , those should go inside effect() instead.

One more thing: Batch updates

Angular batches synchronous signal updates to avoid redundant change detection runs. If you update multiple signals synchronously, Angular runs change detection once after all updates complete.

This is why sometimes your UI updates only after all state changes finish, which is a good thing for performance but can confuse debugging if you expect immediate UI changes after each setter.

Wrapping up

Angular Signals bring a fresh reactive model to Angular apps, but their magic depends on how Angular tracks dependencies and integrates with change detection. If you find your UI not updating, check if your signals are updated inside Angular’s zone and if components properly subscribe to those signals.

Remember:

Accessing signals during component rendering registers dependencies.
Signal updates mark components dirty to trigger change detection.
Updates outside Angular’s zone need manual zone re-entry.
Use effect() for side effects, not computed signals.

Getting these right will save you from mysterious stale UI bugs and make your Angular apps feel snappy and reliable.

If you’re diving into Angular Signals, keep an eye on these mechanisms under the hood , they’re the secret sauce behind smooth reactivity.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

Design Systems and Accessibility: Mechanisms to Enforce Consistent Focus Management

Srikar Phani Kumar Marti — Mon, 05 Oct 2026 11:01:19 +0000

Ever been puzzled when tabbing through a complex UI built from a design system, only to have the focus jump in unexpected ways or disappear entirely? Maybe a modal’s close button isn’t reachable by keyboard, or focus lands on something visually hidden. It’s a tiny annoyance for some, but a showstopper for keyboard users and screen reader folks.

I’ve faced this exact headache while working on a large React design system. The components promised accessibility out of the box, but subtle app-level overrides or custom wrappers sometimes broke the focus flow. Tracking down where the focus management logic lived, and why it wasn’t working, led me down a rabbit hole of internal mechanisms that design systems use to enforce consistent, accessible focus.

Let me share what I learned about how design systems coordinate focus, how they integrate with ARIA, and how you can debug when your app’s overrides clash with those defaults.

Focus management is more than tabindex

Setting tabindex is the classic way to control keyboard focus order. But design systems go way beyond sprinkling tabindex attributes.

For example, take a dropdown component. When you open it, focus should move into the dropdown’s first interactive item. When you close it, focus needs to return to the button that triggered it. And keyboard navigation inside the dropdown needs to cycle logically.

Design systems bake these rules into their components using JavaScript focus management. They listen for keyboard events, programmatically call .focus() on appropriate elements, and maintain internal state about what should be focused next.

This means a lot of logic lives inside the system’s components, not just in markup.

How design systems enforce consistent focus

1. Centralized focus utilities

Many systems include shared focus utilities: helper functions or hooks that set focus, trap focus within dialogs, or restore focus after navigation. These utilities handle quirks across browsers and assistive tech.

For example, a "focus trap" utility listens for tab key presses and ensures focus cycles only within a modal’s interactive elements, preventing keyboard users from tabbing to elements behind the modal.

2. Focus context and state

Some systems create a focus context that tracks the current focus target and allows nested components to coordinate. For example, a tab panel component and its tabs share focus state so that activating a tab moves focus correctly and updates the panel.

3. ARIA integration

ARIA attributes are part of the story but not the whole story. Design systems use ARIA roles like role="dialog", aria-modal="true", and aria-labelledby to help screen readers understand component purpose and relationships.

But focus management is still done with JavaScript. For instance, an accessible modal will set aria-hidden="true" on background content and shift focus to the modal container when opened.

4. Keyboard event handling

Design systems intercept keyboard events like Tab, Shift+Tab, Escape, and arrow keys to customize focus movement and component behavior.

For example, arrow keys might move focus between menu items, Escape closes a modal and returns focus, and Tab cycles focus inside a focus trap.

When your app overrides break focus management

I ran into bugs when app-level styles or wrappers overrode the design system’s components. Here are common pitfalls:

Custom wrappers missing focus forwarding: If you wrap a focusable component but don’t forward refs properly, programmatic .focus() calls inside the system fail silently.
CSS hiding focus indicators: Overriding focus styles with outline: none or other rules can make focus invisible.
Conflicting event handlers: Adding keyboard handlers that prevent default behavior or stop propagation can break the system’s internal focus logic.
Dynamic rendering mismatches: Rendering components conditionally without coordinating focus restoration leads to lost focus or unexpected jumps.

Debugging focus issues in design systems

Use browser devtools’ accessibility inspectors

Browsers like Chrome and Firefox have accessibility panes showing the accessibility tree and focusable elements. Use these to verify which elements are focusable and whether ARIA attributes are set correctly.

Manual focus inspection

Try tabbing through your app step by step. Note where focus lands, where it disappears, or where it loops unexpectedly.

Use document.activeElement in the console to see the current focused element at any point.

Check event listeners

Inspect the event listeners on elements to see if keyboard events are handled or blocked.

Verify ref forwarding

If your components use React, ensure ref forwarding is correctly set up so the design system can call .focus() on the right DOM node.

Test with screen readers

Keyboard focus and visual focus indicators are only part of accessibility. Test with screen readers like NVDA or VoiceOver to make sure focus changes align with announcements.

Example: Focus trap in a modal

Here’s a simplified example of how a focus trap works inside a modal component:

function Modal({isOpen, onClose, children}) {
  const modalRef = useRef(null);

  useEffect(() => {
    if (!isOpen) return;

    const focusableElements = modalRef.current.querySelectorAll(
      'a[href], button, input, textarea, select, [tabindex]:not([tabindex="-1"])'
    );
    const firstElement = focusableElements[0];
    const lastElement = focusableElements[focusableElements.length - 1];

    function handleKeyDown(e) {
      if (e.key === 'Tab') {
        if (e.shiftKey) {
          if (document.activeElement === firstElement) {
            e.preventDefault();
            lastElement.focus();
          }
        } else {
          if (document.activeElement === lastElement) {
            e.preventDefault();
            firstElement.focus();
          }
        }
      }

      if (e.key === 'Escape') {
        onClose();
      }
    }

    modalRef.current.addEventListener('keydown', handleKeyDown);
    firstElement.focus();

    return () => {
      modalRef.current.removeEventListener('keydown', handleKeyDown);
    };
  }, [isOpen, onClose]);

  if (!isOpen) return null;

  return (
    <div role="dialog" aria-modal="true" ref={modalRef}>
      {children}
    </div>
  );
}

This snippet traps focus inside the modal while it’s open and closes on Escape. Design systems build on this idea but handle edge cases and browser quirks.

Wrapping up

Focus management inside design systems is a mix of ARIA, JavaScript, event handling, and CSS working together. It’s not enough to add tabindex and call it done.

If you build or maintain a design system, consider:

Providing standardized focus utilities
Documenting expected focus behavior for each component
Testing with keyboard and screen readers
Encouraging app teams to respect focus management and avoid harmful overrides

If you’re integrating a design system and hit focus bugs, dig into the event handling, ref forwarding, and CSS focus styles. Use browser devtools and assistive tech to observe what’s happening.

These mechanisms might feel like plumbing, but getting focus right makes your UI genuinely usable for everyone.

Helpful learning resources

W3C WAI accessibility guidance
W3Schools accessibility tutorials
MDN Web Docs Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

DEV Community: Srikar Phani Kumar Marti

Why Input Latency Symptoms Can Mislead Developers: A Deep Dive Into the Real Causes

The Familiar Symptom: Input Feels Sluggish

Input Events Aren’t Instant: The Browser Event Pipeline

Rendering Pipeline Adds Another Layer of Delay

Profiling Can Lie: Understanding Timeline Marks

JavaScript Execution Isn’t the Whole Story

What You Can Do to Pinpoint the Real Bottleneck

Common Pitfalls That Mislead Developers

Wrapping Up

Helpful learning resources

Why Signal Forms Matter in Angular: The Subtle Traps and How to Avoid Them

Signals Aren’t Just Boxes: They Have Forms

Why Signal Form Tripped Me Up: The Object Reference Gotcha

How to Fix This: Always Update the Signal with a New Reference

What About Computed Signals?

Signal Forms in Templates: Why Reading Matters

Practical Tips to Avoid Signal Form Bugs

When to Use Different Signal Forms

What Happens if You Don’t Follow Signal Forms?

Wrapping Up

Helpful learning resources

CSS Logical Properties: How Browsers Translate Them to Physical Styles

Logical vs Physical CSS Properties: The Basic Idea

How Browsers Translate Logical Properties

What about vertical writing modes?

Behind the Scenes: The Browser’s Style Computation Pipeline

Why This Matters for Debugging Layout Issues

Practical Tips When Using Logical Properties

A Real Debugging Example

Wrap-up

Helpful learning resources

The Real Cost of CSS Variables: Runtime Resolution and Performance Implications

Why CSS variables aren’t just static values

What happens when the browser resolves CSS variables

Why style recalculations get expensive with many variables

Variables in animations: a double-edged sword

Which CSS properties amplify the cost?

How I balanced CSS variables with performance

1. Limit variable scope

2. Cache computed values in CSS or JS

3. Avoid animating variables for large subtrees

4. Use DevTools to profile style recalcs

When CSS variables still win

Helpful learning resources

How CSS Containment Affects Layout and Paint Performance in Large Apps

What is CSS Containment, Really?

Why Does This Help Performance?

A Real-World Debugging Tale

Breaking Down the Tradeoffs

How Browsers Implement Containment

When to Use contain in Production Apps

Debugging Unexpected Behavior

Example: Containment and Dropdowns

A Quick Checklist Before Adding contain

Final Thoughts

Helpful learning resources

What’s New and Different in Angular NgRX Store Version 22

The NgRX store you thought you knew

What caught me off guard: Selector memoization changes

Better typing for feature selectors

Breaking changes to note: StoreModule.forRoot and forFeature

Effects improvements and subtle runtime behavior changes

Why these changes matter: A real debugging story

Wrapping up the NgRX 22 upgrade

Helpful learning resources

Understanding Paint Containment and Composite Layers for Smooth Animations

The moment you realize something’s wrong

What is a compositing layer anyway?

Paint containment: telling the browser to isolate painting

How paint containment creates layers under the hood

The GPU angle: why compositing layers matter

Debugging paint containment and layers in DevTools

Practical tips to avoid jank

Real-world gotchas

Why understanding this matters

Helpful learning resources

How Angular Signals Really Work: Behind the Scenes of Reactivity

The moment a signal feels like magic , or doesn’t

Signals are reactive primitives with dependency tracking

When to Use `contain` in Production Apps

A Quick Checklist Before Adding `contain`

2. Importance: The `!important` trump card