Coder Legion - Recent posts tagged angular

Enterprise Angular Architecture: Lazy Loading, Dynamic Components & RBAC

Thu, 29 Oct 2026 05:29:15 +0000

Hey devs! I wrote a comprehensive breakdown on architecting large Angular applications for scale, performance, and security.

What the post covers:

Why canMatch guards are superior to canActivate for protecting sensitive bundles

Structuring standalone route trees for maximum bundle splitting

Dynamic component loading patterns for widgets and runtime plugins

Implementing reactive, role-based template directives using Signals

Read the complete article on SunnyWriteUps! How are you currently managing role-based access and bundle splitting in your large frontend codebases?
https://buildwithsunny.com/posts/how-would-you-architect-a-large-angular-app/

How We Architected a Zero-Drift, Reactive Timezone Engine for Enterprise Applications

Sun, 25 Oct 2026 13:02:53 +0000

Why naive UTC strings break financial ledgers—and how to build a self-healing timezone architecture using IndexedDB, HTTP Context Tokens, and the Onion Interceptor Pattern.

1. The $48,000 Six-Hour Blind Spot (A Real-World Story)
Imagine it is Monday morning. Your Operations Director in Dhaka (Asia/Dhaka, UTC+06:00) opens the company’s revenue dashboard to reconcile Sunday’s numbers (2026-10-25) against a local telecom carrier’s daily settlement report.

The carrier’s report says $248,200.

Your dashboard says $200,000.

Where did $48,200 go?

Nobody hacked the database. Not a single transaction was dropped. The culprit was a single letter—Z—appended by a well-meaning frontend date picker:

GET /internal/v1/stats/revenue?start_date=2026-10-25T00:00:00Z&end_date=2026-10-25T23:59:59Z

When the user in Dhaka selected October 25, they meant 00:00:00 to 23:59:59 Dhaka Time—which in UTC is actually October 24 at 18:00:00Z through October 25 at 17:59:59Z. By sending an explicit Z (or converting only the display strings on the client), the backend queried midnight-to-midnight in London (UTC), silently shifting six hours of peak morning transactions (00:00 to 06:00 local time) into yesterday’s ledger.

Even worse: what happens when an analyst in New York wants to inspect a campaign running in Tokyo, flips the timezone switcher in the top header from America/New_York to Asia/Tokyo, and expects all 12 charts on the screen to recalibrate automatically—without refreshing the browser or losing their active filters?

In demos and side projects, a hardcoded array of 20 timezones and localStorage.getItem('tz') is enough. In an enterprise fintech or ad-tech platform, timezone handling is a distributed state synchronization problem.

Here is the complete blueprint of how we engineered a universal, zero-boilerplate timezone engine that handles Daylight Saving Time (DST) shifts, IndexedDB persistence, cache stampede protection, centralized reactive auto-refetching, and network concurrency throttling.

Caption: The Enterprise Timezone Blueprint—comparing the Naive UTC ISO anti-pattern against Calendar Date + X-Timezone resolution and our 5-ring Onion Interceptor Pipeline.

2. Rule #1: Never Confuse a UTC Offset with an IANA Timezone
One of the most common mistakes in system design is storing or transmitting raw UTC offsets like "+06:00" or "-05:00".

An offset is a measurement at a single moment in time. An IANA identifier (America/New_York, Europe/London, Asia/Dhaka) is a historical and political rulebook.

Consider America/New_York:

In January, New York is on Eastern Standard Time (UTC-05:00).
In July, New York is on Eastern Daylight Time (UTC-04:00).
If a user queries a 6-month revenue chart spanning January to July and your frontend only sends UTC-05:00, four months of daily cutoffs will be off by an entire hour.

The Enterprise Contract Between Frontend and Backend:
i. Storage & Database: Every backend timestamp (created_at, updated_at, uploaded_at) is stored and returned in immutable UTC ISO-8601 (2026-09-01T12:00:00Z).
ii. Date-Range Queries: The frontend sends plain calendar dates (YYYY-MM-DD, such as start_date=2026-10-01&end_date=2026-10-05) with no trailing Z.
iii. Context Header (X-Timezone): The frontend attaches the active IANA identifier (X-Timezone: Asia/Dhaka or X-Timezone: America/New_York) via an HTTP request interceptor. The backend converts 00:00:00 and 23:59:59.999999 in that exact IANA zone into precise UTC database bounds and groups daily buckets (AT TIME ZONE) accurately across DST boundaries.

3. Caching Without Stampedes & The 4-Step Resolution Hierarchy
Because UTC offsets shift twice a year when regions enter or exit Daylight Saving Time, hardcoding timezone labels in the frontend bundle means your UI labels ((UTC-05:00) vs. (UTC-04:00)) will inevitably drift out of sync.

Instead, when the application shell (Header) initializes after login, it fetches the curated catalog from GET /api/v1/catalogs/timezones.

Preventing the "Cache Stampede"
What happens if the Header component, the TimezoneSelector dropdown, and an early dashboard API all request the timezone catalog within the same 5 milliseconds on startup? Without protection, the browser fires 3 identical network requests.

We route the catalog fetch through our universal two-tier cache (AppCacheService backed by StorageEngineService on IndexedDB with an automatic in-memory Map fallback for restricted/incognito browsers):
i. In-Flight Request Deduplication (shareReplay): The first caller opens the network stream and registers the Observable in an inFlightRequests map. Any concurrent caller asking for CATALOG_TIMEZONES_V1 before the network responds joins the exact same stream.
ii. 24-Hour Lazy TTL: Once resolved, the catalog is persisted in IndexedDB with a 24-hour expiration timestamp (expiresAt = Date.now() + 86_400_000). Subsequent page loads read from IndexedDB in under 3 milliseconds, while daily refreshes keep DST offsets accurate.

The 4-Step Deterministic Resolution Hierarchy
We must distinguish between two very different user lifecycle events:

Fresh Login: The user just authenticated. We should detect their physical browser timezone (Intl.DateTimeFormat().resolvedOptions().timeZone).
Page Reload (F5): The user was working in Asia/Dhaka, switched the dropdown to America/New_York to audit US traffic, and hit Refresh. We must never wipe out their selected timezone on reload.
Even trickier: what if a user is on an older Windows or Android build where the OS clock returns a deprecated historical IANA string like Asia/Dacca instead of Asia/Dhaka, or Asia/Calcutta instead of Asia/Kolkata, or a smaller city not present in the backend's curated list of ~45 timezones? Instead of maintaining brittle hardcoded alias tables, we use a 4-Step Dynamic Resolution Hierarchy:

Caption: Our 4-Step Deterministic Resolution Hierarchy in TimezoneService—preserving IndexedDB state across reloads while gracefully handling legacy OS timezone names via numeric UTC offset matching.

i. Step 1 — IndexedDB User Preference (Page Reload): If USER_SELECTED_TIMEZONE_V1 exists in IndexedDB, restore it immediately. (On logout, AuthService.teardownSession() wipes IndexedDB so the next login starts fresh).
ii. Step 2 — Exact IANA Identifier Match (Fresh Login): Match the browser's Intl.DateTimeFormat().resolvedOptions().timeZone against the backend catalog (tz.id === rawBrowserTz).
iii. Step 3 — Numeric UTC Offset Fallback (OS Alias Resilience): If the exact city string isn't in the curated catalog, compute the browser's live offset in minutes (-new Date().getTimezoneOffset(), e.g., +360 minutes for UTC+06:00) and match tz.offsetMinutes === browserOffsetMinutes. An OS returning Asia/Dacca or Asia/Thimphu (+360 mins) automatically resolves to (UTC+06:00) Dhaka without a single hardcoded string!
iv. Step 4 — Ultimate Safety Net (UTC): If all else fails, select the pinned UTC entry from the catalog.

4. The Onion Interceptor Rule & Why Global Header Injection Is a Trap
Many backend guides suggest adding X-Timezone to every outbound request in a global interceptor. In a real-world enterprise frontend, blind global header injection causes two production bugs:

CORS Preflight Failures on Cloud Storage: When uploading or streaming binary attachments directly to/from presigned S3 or DigitalOcean Spaces URLs, attaching a custom X-Timezone header violates the presigned signature and triggers a 403 Forbidden or CORS preflight rejection.
Static Catalog Noise: Endpoints like /api/v1/catalogs/geos or /auth/refresh are timezone-agnostic.

Solution: Opt-In HttpContextToken + The Onion Pipeline
Instead of guessing by URL regexes, we use Angular’s strongly-typed HttpContextToken (USE_TIMEZONE, which defaults to false). Only endpoints that explicitly opt in via context: withTimezone() receive the X-Timezone header and participate in reactive timezone switching.

Furthermore, interceptor registration order matters deeply. We enforce The Onion Rule via a self-sorting pipeline (resolveInterceptorPipeline):

Ring 0 (Layer 5 — REACTIVE_CONTEXT): timezoneInterceptor sits at the outermost ring closest to the UI components.
Ring 1 (Layer 10 — UI_ERROR): errorInterceptor catches downstream HTTP failures and displays deduplicated error modals.
Ring 2 (Layer 20 — CLIENT_CACHE): AppCacheService handles IndexedDB caching.
Ring 3 (Layer 30 — TELEMETRY): Correlation trace IDs and latency metrics.
Ring 4 (Layer 40 — AUTH_NETWORK): authInterceptor sits at the innermost network airlock, attaching Authorization: Bearer and silently queuing/replaying 401 token refreshes before Ring 1 ever sees an error.

Why must timezoneInterceptor live at Ring 0 (Outermost)? Because when a user switches the timezone in the Header, Ring 0 re-triggers the request down through Rings 1 -> 2 -> 3 -> 4, ensuring every automatic re-fetch gets fresh telemetry, error handling, and JWT authentication!

5. Solving the "Startup Race Condition" & Component Skeleton States
When a user hits F5 (Reload) on a deep-linked dashboard page, two things happen concurrently:
i. The Header begins reading the saved timezone from IndexedDB (~3–5ms async).
ii. The dashboard component's ngOnInit() fires getRevenueStats() immediately (0ms).
If getRevenueStats() fired before IndexedDB finished reading, the first API request would go out with the browser's default timezone instead of the user's saved timezone!

We solved this by exposing initializedTimezoneId$ on TimezoneService—a BehaviorSubject filtered to emit only after IndexedDB restoration completes. Meanwhile, the Header trigger box renders an in-place shimmer (<app-input-skeleton-loader variant="timezone-pill">) so the layout never shifts.

To give components full control over their loading skeletons without writing boilerplate subscriptions to TimezoneService, we created a custom RxJS operator: bindTimezoneLoading(this.isLoading).

Caption: timezone-context.token.ts—defining the opt-in USE_TIMEZONE token and the bindTimezoneLoading operator that synchronizes component skeleton loaders on both initial load and subsequent timezone switches.

6. Centralizing Auto-Refetch Without Memory Leaks or "Thundering Herds"
Here is the hardest architectural question:
"When a user changes the timezone in the Header, how do all timezone-dependent APIs on the current page automatically re-fetch—without every component manually subscribing to TimezoneService?"
In Angular, HttpClient.get() normally emits once and completes. However, inside our outermost timezoneInterceptor (Ring 0), we can return timezoneService.initializedTimezoneId$.pipe(switchMap(tzId => next(clonedReq))).
Whenever initializedTimezoneId$ emits a new timezone ID, switchMap automatically cancels any stale in-flight request, clones the original HttpRequest with the updated X-Timezone header, and pushes the fresh response straight into the component’s existing .subscribe() block!

Anticipating the 4 Production Traps of Long-Lived HTTP Streams
If you stop at a basic switchMap, a senior engineer will rightly point out four edge cases. Here is how we engineered around every single one of them inside timezone.interceptor.ts:
Trap 1: What about POST, PUT, PATCH, or DELETE requests?

_The Danger: _If a mutation stayed open on switchMap, changing the timezone dropdown 2 minutes later would re-submit the form or re-delete a record!
Our Fix: Only GET requests with AUTO_REFETCH_ON_TIMEZONE_CHANGE = true stay reactive. All mutations (POST/PUT/PATCH/DELETE) use take(1)—they receive the X-Timezone header once and complete immediately.

Trap 2: Same-Page "Zombie Subscriptions" When Filters Change

The Danger: Suppose a user stays on the Revenue page and changes the date picker 5 times, calling this.loadRevenue() each time. If the previous 4 streams are still open waiting for timezone changes, switching the timezone would fire 5 parallel requests (4 for old dates, 1 for current dates).
Our Fix (activeEndpointListeners Supersede Registry): Inside timezoneInterceptor, we track active listeners by endpoint key (GET:/internal/v1/stats/revenue). Whenever the same endpoint is requested again, the interceptor automatically triggers supersede$.next() on the previous listener, completing and garbage-collecting it before registering the new one. At most 1 listener per endpoint can ever exist in memory.

Trap 3: Rapid Dropdown Clicking

The Danger: A user opens the timezone dropdown, accidentally clicks Europe/London, and 150ms later clicks Europe/Paris.
Our Fix (Asymmetric Debounce): Using debounce(() => (attempt === 0 ? EMPTY : timer(200))), the initial page load (attempt === 0) fires with 0ms delay, while subsequent timezone switches wait 200ms for the user to settle before hitting the network.

Trap 4: The 50-API Dashboard "Thundering Herd"

The Danger: What if an executive dashboard has 50 micro-widgets, each calling a different GET endpoint? In RAM, 50 RxJS subscribers take only ~17.5 KB (~350 bytes each) and 0% idle CPU. The real bottleneck is network concurrency: flipping the timezone would fire 50 simultaneous HTTP requests, saturating the browser’s TCP pool and spiking database connections.
Our Fix (8-Slot Concurrency Airlock): We pipe automatic timezone re-fetches through a bounded semaphore (MAX_CONCURRENT_REFETCHES = 8). Initial page loads run immediately, while timezone re-fetches glide through in controlled batches of 8.

7. The Payoff: Zero-Boilerplate Developer Experience
Because all the heavy lifting—IndexedDB persistence, 24h catalog caching, header injection, zombie-listener cleanup, debouncing, and concurrency throttling—is encapsulated in TimezoneService and timezoneInterceptor, consuming this system in feature modules requires two lines of declarative code:

Look at what the component doesn’t have to do:

It doesn't import localStorage or format X-Timezone headers.
It doesn't write manual subscriptions to timezoneService.selectedTimezone to trigger re-fetches.
It doesn't worry about memory leaks on route navigation (cancelOnAbort(this.destroyRef) tears down the stream the instant the component unmounts or the browser goes offline).

8. Anticipating the Architecture Review: 5 Edge Cases Answered
Whenever we share this pattern in architecture reviews, five sharp questions always come up. Here is the cheat sheet:

Q1: "Doesn't skipping take(1) on keepAlive: true streams break forkJoin?"
Yes—and by design! In RxJS, forkJoin([a$, b$]) waits for all inner Observables to complete before emitting a single value. Because a reactive keepAlive: true stream stays open to listen for future timezone changes, forkJoin would wait forever.

The Rule: For static one-shot setup calls in forkJoin, keep the default keepAlive: false. When combining multiple live timezone-reactive streams, use combineLatest([a$, b$]), which emits as soon as all streams produce their first response and automatically re-emits whenever a timezone change updates them.

Q2: "What if a standard RxJS timeout(15000) is applied to a long-lived stream?"
A naive timeout(15000) measures the gap between emissions—meaning it would throw a false TimeoutError 15 seconds after page load while the user is simply reading the screen! That is why our pipeline uses timeout({ first: 15000 }) (and applies a fresh { first: 15000 } inside the interceptor’s inner switchMap), timing only the network round-trip of each HTTP call.

Q3: "What if one widget fails with a 500 error when the user switches timezones?"
If an inner request throws an unhandled error inside switchMap, it kills the outer initializedTimezoneId$ subscription—meaning switching the timezone a second time wouldn't re-trigger that widget. In our interceptor (see lines 35–38 of timezone.interceptor.ts), after errorInterceptor (Ring 1) displays the error modal, any failed re-fetch (isRefetch === true) is caught and converted to EMPTY, keeping the outer timezone listener alive for the user's next selection.

Q4: "Why use IndexedDB instead of localStorage?"
While localStorage works for a single string, it is synchronous (blocking the main UI thread on large reads), capped at ~5 MB, and separated from our enterprise catalog cache (StorageEngineService). Storing both the 24-hour timezone catalog and the active TimezoneOption object in IndexedDB (with automatic in-memory fallback for strict privacy modes) keeps our storage engine unified, asynchronous, and wiped cleanly in a single clearAll() transaction upon logout.

Q5: "How should UTC timestamps in table cells be formatted?"
Every record timestamp (created_at, updated_at, uploaded_at) arrives from the backend in UTC ISO-8601 (...Z). We format them on the fly using Intl.DateTimeFormat('en-US', { timeZone: timezoneService.activeTimezoneId(), ... }). Because activeTimezoneId() is an Angular computed() Signal, any template binding or pipe reading it updates instantaneously the moment the user selects a new timezone—without even waiting for the network!

Final Thoughts
Great enterprise architecture isn't about making simple things complicated—it's about absorbing real-world complexity inside core infrastructure so feature code stays simple, declarative, and impossible to misuse.

By separating calendar intent (YYYY-MM-DD), IANA rulebooks (X-Timezone), two-tier IndexedDB caching, and Ring 0 reactive interception, your application treats timezones not as an afterthought, but as a first-class reactive dimension of your data layer.

Spec to Ship: Implementing Agentic Engineering in Modern Angular

Sun, 18 Oct 2026 12:58:24 +0000

Hey devs! I wrote a deep dive on applying agentic engineering patterns to Angular development.

What the guide covers:

Breaking down feature specs into typed Angular component contracts

Running closed verification loops with the Angular CLI to catch errors before code review

Using agents for boilerplate, unit tests, and migration logic while keeping humans in the loop

Read the complete write-up on SunnyWriteUps! Have you started experimenting with autonomous agent loops in your frontend workflows?
https://buildwithsunny.com/posts/Angular-Agentic-Engineering-From-Spec-to-Ship/

Securing an Angular Application: Part 3 — Implementing CSP with Nginx

Sun, 18 Oct 2026 10:55:08 +0000

Continuing my series on hardening Angular applications, Part 3 moves into the actual Nginx server configuration and Content Security Policy (CSP) implementation.

In this part, I walk through the docker-nginx-server.conf configuration used to serve a real Angular application and explain how the different pieces work together.

Some of the topics covered:

⚙️ Angular server configuration with Nginx
🔀 Angular SPA routing
📦 Static asset handling and caching
🚫 Blocking hidden and sensitive files
🔐 Security headers
🛡️ Content Security Policy directives
🔑 Dynamic CSP nonce handling
🧩 Injecting the nonce into Angular HTML
⚠️ Error page handling
🔒 Trusted Types and other CSP protections

Rather than using a generic CSP policy, the goal is to understand which resources the Angular application actually needs and how those requirements translate into individual CSP directives.

This part also shows how the CSP nonce is handled using Nginx:

set $csp_nonce $request_id;

sub_filter_once off;
sub_filter '__CSP_NONCE__' '$csp_nonce';

This allows the nonce used by the CSP policy to be injected into the Angular application's HTML for each request.
With the Nginx configuration and CSP in place, the next part moves one layer deeper into the deployment process: Dockerizing the Angular application and packaging the Nginx configuration into a production-ready container.

📖 Read Part 3:
https://medium.com/@jangidamit800/angular-content-security-policy-csp-implementing-the-nginx-server-configuration-c70593b9136a?sharedUserId=jangidamit800

#Angular #AngularSecurity #CSP #ContentSecurityPolicy #Nginx #WebSecurity #DevSecOps #Docker #FrontendSecurity

Securing an Angular Application: Part 2 — Preparing the Nginx Layer

Mon, 12 Oct 2026 11:43:40 +0000

Continuing my series on hardening Angular applications, Part 2 moves from browser security concepts into the server layer.

In this part, I focus on the Nginx configuration used to serve an Angular application and build the foundation required before introducing Content Security Policy (CSP).

Some of the topics covered:

⚙️ Nginx configuration basics
📦 Serving Angular static assets
🗜️ Gzip compression
💾 Static asset caching
🔀 Angular SPA routing
🚫 Restricting access to sensitive files
⚠️ Error page handling
🔧 Preparing the Nginx layer for CSP

The goal is to understand why each configuration exists rather than simply copying an Nginx configuration from somewhere else.

This part establishes the Nginx foundation. In the next part, I'll move into the actual Angular server configuration and CSP implementation, including how the policy is built around the application's resource requirements.

📖 Read Part 2:
https://medium.com/@jangidamit800/angular-csp-configuring-content-security-policy-with-nginx

#Angular #AngularSecurity #Nginx #CSP #WebSecurity #DevSecOps #FrontendSecurity #Docker

Implementing FullCalendar with Drag-and-Drop in Angular

Sun, 11 Oct 2026 16:07:43 +0000

Hey devs! I put together a practical guide on integrating FullCalendar into Angular applications.

Key topics covered:

Scaffolding FullCalendar with modern Angular standalone components

Configuring plugins for month, week, and day views

Implementing drag-and-drop and resize event handlers for real-time scheduling

Check out the complete tutorial on SunnyWriteUps! What scheduling or calendar libraries do you typically use in your frontend projects?

https://buildwithsunny.com/posts/angular/fullcalendar-in-angular-from-setup-to-drag-and-drop

Angular Security Headers: A Practical Guide to Securing Your Angular Application

Sat, 10 Oct 2026 12:37:43 +0000

I've started a new series focused on hardening Angular applications using browser and HTTP security controls.

In Part 1, I cover the fundamentals of security headers and how they add another layer of protection between an Angular application and the browser.

Some of the topics covered:

🔒 HSTS — enforcing HTTPS
🛡️ X-Content-Type-Options
🧭 Referrer-Policy
🎯 Permissions-Policy
🚫 X-Frame-Options
🔄 Cross-Origin Opener Policy (COOP)
🌐 Cross-Origin Resource Policy (CORP)
🔐 Content Security Policy (CSP)
The goal of this series isn't to simply copy a list of security headers, but to understand what each header does, what problem it addresses, and how these controls fit into a real Angular deployment.

This is Part 1, where we establish the foundation. The upcoming parts will move into the actual CSP, Nginx, and Docker configuration used to serve the application.

📖 Read Part 1:

https://medium.com/@jangidamit800/hardening-an-angular-application-understanding-security-headers-0c65644b981b

Would love to hear how others approach security hardening for Angular applications.

#Angular #AngularSecurity #WebSecurity #CSP #Nginx #DevSecOps #FrontendSecurity #WebDevelopment

Automating Angular Upgrades with an Autonomous Agent Loop

Sat, 03 Oct 2026 06:42:58 +0000

Hey devs! I wrote a post on solving one of the most common enterprise pain points: keeping Angular applications up to date with its 6-month release cadence.

What the post covers:

Structuring an autonomous agent loop (CLI runner + LLM fixer + test validator)

Handling schematic edge cases and compiler diagnostics

Turning multi-day migration sprints into automated pull requests

Read the full article on SunnyWriteUps! Are you experimenting with AI agent loops for codebase maintenance or dependency upgrades in your projects?
https://sunnyblog.apexmansunny.workers.dev/posts/angular/agent-loop-to-handle-angular-upgrades/

Improve your Angular app performance by using this simple Observable cache decorator

Tue, 29 Sep 2026 10:53:16 +0000

When we were about to finish development of our applications in SwiftViews we noticed a pattern in all our data-fetching user flows. In spite of the fact that the apps are all data-driven and looked really dynamic, what really was changing in the same user session wasn’t that much, but we were making http requests for new content regardless.
The easiest solution was caching
Caching where? On the server? We already have that, but this doesn’t stop all our apps hitting our services and thus — increasing the load on them.
Maybe we could use service worker since it allows caching API calls?
Yes, that was one of the options since it already has a pretty nice integration with Angular and allowed for a simple solution to selectively cache resources and APIs. However, what we wanted is to be able to not only choose what to cache, but also when to do it.
Just to give you a quick example — we basically wanted to cache all API call results for the page below, but only if we were certain that the data source did not change in some way.

Since this is my personal inventory page, the only way it can actually change is if I add an item from this platform (currently the only way to do so), so I have the information about when this page will change and how long I can return cached content for.
We figured the best way to apply this caching in a selective and configurable way will be to use what the platform already gives us
Since we are using Angular and Typescript ❤️, and all our data calls go through RxJs, we figured that we can create a Cache Observable decorator, which we’d use to only give the caching power to certain methods.
So, before, this was our method which called our server to get the products on the page above:

and that became:

Notice that the @Cacheable() has been applied just to the method we wanted and was also passed cacheBusterObserver which is basically our Subject-based mechanism to tell this exact decorated method to relieve all its caches, when any value is emitted in that stream.
For example, the method below will “cache-bust” the caches of the method above, if the Observable it returns emits a value

This might be the most complex example we have but we also have other configurations implemented like maxCacheCount, maxAge, slidingExpiration and custom cache deciders and resolvers which give us a fine-grain control on what, when and how to cache. See those in the README file.
In the two gifs below, you can see the difference between our app’s performance without and with caching.

https://www.loom.com/share/71a03e4cd478407fa53f131fc112e09a
No Cacheable
The cacheable decorator is not applied yet, so every page load will actually fetch data from the server

https://www.loom.com/share/380a1fa93a9c42d0a5adaa987cd51efb
Cacheable decorator applied
The cacheable decorator is applied and we can see that all consecutive page loads are faster. Also the user profile page loads instantly, because we have already called the /user/{id}endpoint on the inventory page. Also, the cache busts after we add a new item so our user gets fresh data
So, to sum up, this simple decorator allowed us to:
Selectively cache observable methods (not just endpoints, but maybe also computation-heavy calculations in streams)
Improve the performance of our app, without any business logic refactoring (thanks TS decorators ❤️)
Greatly reduce the load on our servers
If you want to use this decorator in your project, just install it from NPM!
npm install ngx-cacheable
If you have any questions about it or want to contribute, don’t mind opening a pull request @github or commenting below.
Also, if you liked the application, please register and build your own inventory @ swiftviews.
Thank you!

Can't bind to 'formgroup' since it isn't a known property of 'form'

Tue, 22 Sep 2026 16:38:44 +0000

Today, we're going to discuss another error that's also very common in Angular: Can't bind to 'formgroup' since it isn't a known property of 'form'. This happens when the user tries to bind the formGroup property to the component variable from the in the .component.html. However, the user might forget importing ReactiveFormsModule in the app.module.ts. In this study blog, we'll see what is "Can't bind to 'formgroup' since it isn't a known property of 'form'", why it occur and how to resolve it. Dont'fret; it's just a few simple steps to fix!

What is "Can't bind to 'formgroup' since it isn't a known property of 'form'" #

Before understanding the problem, let's understand what's FormGroup. In Angular, FormGroup is used to aggregate a bundle of FormControl which tracks and validate the value and status of each individual form control in a reactive form. Let's look at the example:


import { FormGroup, FormControl, Validators } from '@angular/forms';

We first import FormGroup and FormControl that's necessary to build the reactive form. Next, we build a reactive form using the FormGroup and FormControl. See below:


user = new FormGroup
  (
    {
      firstName: new FormControl('', Validators.required),
      lastName: new FormControl('', Validators.required),
      age: new FormControl(''),
    }
  )

With this, we've a reactive form, called user and it has three form controls, that're firstName, lastName, and age.

Tip If you want to create multiple forms faster in a more convenient way, do check out FormBuilder for further information. In this tutorial, we'll continue using FormGroup.

Let's continue. In .component.html, we'll create a form using :



    
<input type="text" name="lastName" formControlName="lastName" />
<input type="text" name="age" formControlName="age" />

<span class="alert-header">Note</span>
<span class="alert-body">In reactive form, we use <em>FormControlName</em> to bind the <em>FormControl</em> value with each form control in the <form>. So, Be aware of the consistency between name of the form control.</span>

See the output:



Can't bind to 'formGroup' since it isn't a known property of 'form'.ngtsc(-998002)

Why you've configure the reactive form correctly, bind it correctly to a form in .component.html, but still getting error? Don't worry, I'll tell you why.

Causes #

The reason behind the error is because FormGroup and FormControl are the classes provided by ReactiveFormsModule. If you didn't import ReactiveFormsModule in your app.module.ts, our Angular application will not recognize FormGroup and FormControl as parts of our application, and thus throwing the error: Can't bind to 'formgroup' since it isn't a known property of 'form' while we're using them. Let's see the next section for solution.

Solution #

There's a very simple and quick solutions for this error.

1. Open your app.module.ts


import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';



@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule,
  ],
  providers: [],
  bootstrap: [AppComponent]
})

export class AppModule { }

2. import ReactiveFormsModule in your app.module.ts.


import { ReactiveFormsModule } from '@angular/forms';

3. Place ReactiveFormsModule in the imports:[ ] under @NgModule directive.


imports: [
    BrowserModule,
    AppRoutingModule,
    ReactiveFormsModule,
  ]

In this case, we're able to use the providers and classes in the ReactiveFormsModule. Now, go back your .component.html and you'll find that the error has gone! Great, you've resolved this problem! Easy, right?

Note If you have another sub-module, and you use the reactive form within the components of that sub-module, Please follow this solution in your sub-module.

The Conclusion #

Today, we've learned about another common error in Angular: Can't bind to 'formgroup' since it isn't a known property of 'form', why it happens and how to resolve it correctly. When we're using Angular framework, we should understand the providers, classes and directives which are available in different built-in modules. This may help us to debug and find out some error like this in a more efficient way. Hope you guys enjoy and thank you!

The Reference #

For further information, please visit:

Angular Reactive Form: https://angular.io/guide/reactive-forms#reactive-forms
FormBuilder: https://angular.io/api/forms/FormBuilder
Angular Reactive Form APIs: https://angular.io/guide/reactive-forms#reactive-forms-api

Cannot find module '@angular/http'

Sun, 13 Sep 2026 06:40:43 +0000

Today, we're going to discuss an error that's very common in Angular: Cannot find module '@angular/http'. This happens when the user is trying to import http service from @angular/http module. In the following section, we'll discuss what's "Cannot find module '@angular/http'", why it occurs and how to solve it using a very simple fix.

What is "Cannot find module '@angular/http'" #

This problem happens when we're trying to import some services, such as http service from @angular/http module. This is because Angular has deprecated and removed the module, and thus prompting this error whenever a user's trying to access it. Let's look at the example:


import { http } from '@angular/http';

Here, we're trying to import a http service from @angular/http module in a .service.ts. This is the result:


Cannot find module '@angular/http' or its corresponding type declarations.ts(2307)

So, why does this happen? Let's go to the next section.

Causes #

The reason behind this problem is because whenever a new version of Angular is released, it'll sometimes deprecate and eventually remove some existing APIs or replace them with the other to maintain stability and the best pratices in using the dependencies. In this case, both the http service and @angular/http module have been deprecated, removed, and replaced by alternative service and module to maintain the performance of Angular. Hence, we'll need to use that alternative service and module to ensure our Angular application working smoothly. So how? Let's see the next section.

Note http is deprecated and removed in Angular 5 while @angular/http is removed in Angular 8.

Solution #

Well, this problem can be fixed very easily, just by importing HttpClient service from @angular/commom/http. Let's see the step:

First, you need to import HttpClientModule from @angular/common/http in the app.module.ts


import { HttpClientModule } from '@angular/common/http';

Next, you must put the HttpClientModule in the imports: [] in the @NgModule directive in app.module.ts.


imports: [
    BrowserModule,
    AppRoutingModule,
    HttpClientModule
  ],

Finally, we import HttpClient from @angular/common/http in the file we want to use:


import { HttpClient } from '@angular/common/http';

That's all. Simple right? The problem is now resolved and you can continue communicating your APIs using HttpClient!

Tip Important removal and replacements in relations: Http -> HttpClient, HttpModule -> HttpClientModule, URLSearchParams -> HttpParams

Note You should always import HttpClientModule before using HttpClient service.

The Conclusion #

In this study blog, we've learned what's Cannot find module '@angular/http' in Angular, the reason behind it and how it's resolved. Bear in mind, you should always check the deprecation and removal of APIs in different version of Angular to avoid annoying yourself with the similar problems like this. Hope you guys enjoy this blog and have a nice day. :)

The Reference #

You may go through this reference for more information:

Angular Deprecated APIs: https://angular.io/guide/deprecations#deprecated-apis-and-features
Communicating with backend services using HTTP: https://angular.io/guide/http
Using Services in Angular: https://angular.io/guide/dependency-injection-overview

Building Role-Based Student, Teacher, and Admin Experiences in EchoEd

Wed, 26 Aug 2026 21:28:49 +0000

A role-based product should involve more than hiding navigation links.

Students, teachers, and platform administrators have different goals, data needs, privacy constraints, and consequences attached to their actions. EchoEd’s recent UI/UX work separates these roles into three
canonical product areas:

/learn for students
/teach for teachers
/admin for platform administrators

The attached demo videos show each experience in its current form.

Student Learn

{% embed https://www.youtube.com/watch?v=cch47qSHPHY %}

The Student experience prioritizes continuation over navigation complexity.

The /learn home composes existing course, progress, badge, certificate, and learner-product APIs to show:

The next governed learning action
Current courses and progress
Available learning
Progress summaries
Badges and certificates

Course overviews use a reusable curriculum component for units and lessons. Lesson entry still goes through the existing start-course and progress APIs, so the UI cannot bypass backend sequencing rules.

Final assessment submissions use a shared confirmation dialog. Lesson completion exposes saving and failure states rather than optimistically assuming persistence.

No backend contracts were changed for the Student phase.

Teacher Teach

{% embed https://www.youtube.com/watch?v=t3wBziH96N4 %}

The Teacher experience introduces a canonical route family:

/teach
/teach/classes
/teach/classes/:id
/teach/curriculum
/teach/courses/:courseId/preview
/teach/assignments
/teach/learners/:learnerId

The Teacher home focuses on classes, learner progress, and curriculum. Class detail composes existing section APIs into overview, roster, assignment, progress, and discussion views.

Learner detail is scoped through class-roster context. Assignment creation uses confirmation and preserves form values after API failures.

The UI does not expose persistent feedback, manual review, or destructive discussion moderation because those workflows do not yet have sufficiently scoped backend contracts.

Platform Admin

{% embed https://www.youtube.com/watch?v=Gj_T4a8uiiw %}

The Admin experience uses canonical routes for overview, users, organizations, courses, badges, and reports.

Important implementation decisions include:

User lists omit unnecessary fields.
Role mutations wait for API confirmation before updating the UI.
Self-role changes and self-deletion are blocked in the interface.
Destructive actions use exact consequence language.
Organization visibility remains constrained by current membership-scoped APIs.
Course oversight does not grant Content Studio authoring.
Super Admin capabilities are based on verified authorization, not role-name assumptions.
Unsupported moderation and lifecycle controls remain absent.

During seeded browser testing, the user-detail flow exposed a backend issue: FastAPI accepted the user ID as a string while SQLAlchemy compared it with a UUID column.

The repair typed detail and update parameters as uuid.UUID. We also moved the static /api/users/students route before /api/users/{user_id} so the dynamic route could not shadow it.

Regression tests now cover both behaviors.

Shared UX and Accessibility

All three areas reuse the same production foundations:

Semantic design tokens
Role-aware shell navigation
Route guards
Shared loading and state components
Confirmation dialogs with focus trapping and restoration
Keyboard-operable controls
Visible focus indicators
Reduced-motion behavior
Semantic desktop tables
Stacked mobile record layouts
Legacy deep-link compatibility

The frontend improves presentation and workflow clarity, but backend authorization remains authoritative.

Current Verification

Frontend unit tests: 245 passing
Backend tests: 224 passing
Seeded Playwright scenarios: 3 passing
Production build: passing
Strict OpenSpec validation: passing

The Playwright suite currently covers the seeded Student workflow, the Platform Admin workflow, and rejection of an unauthorized Student deep link into Admin.

Known Gaps

Several workflows need stronger backend contracts before the UI can safely support them:

Persistent teacher feedback
Scoped teacher review
Authenticated discussion moderation
Platform-wide organization oversight
Account suspension and restoration
Administrative audit events
Badge lifecycle management
Explicit Super Admin permission inheritance
Privacy-minimized Admin user response schemas

These are documented gaps, not frontend placeholders.

Community Review

I would value feedback from people working across education and software:

Do the boundaries between Learn, Teach, and Admin match real responsibilities?
Which Teacher information should be visible at class level versus learner level?
What information should a platform administrator never see in a broad user list?
Which workflows should receive deeper screen-reader and keyboard testing?
Which backend gap would you prioritize before expanding the next UI phase?

The Student, Teacher, and Platform Admin production phases are complete for EchoEd’s currently supported APIs.

The full UI/UX overhaul is still underway. Content Studio, organization-admin self-service, Community, parent, and viewer experiences remain outside these completed phases.

The Future of Frontend Architecture: Inside a Gemini-Powered Compiler

Mon, 17 Aug 2026 14:15:52 +0000

AI isn’t just for writing boilerplate code anymore—it’s getting good enough to help design complex system architectures.

In my latest post, I break down the architecture of a new experiment: a Gemini-powered Angular "Lite" compiler prototype. I explore how AI-assisted workflows change the way we think about parsing, compiling, and rendering on the frontend.

If you are interested in the intersection of AI and frontend tooling, check out the full deep dive here:

https://sunnyblog.apexmansunny.workers.dev/posts/angular-compiler-with-gemini/

Orchestrating Chaos: The Hidden Power of angular.json

Wed, 05 Aug 2026 17:34:38 +0000

You write the code, but what manages the workspace? Uncover the secrets of angular.json, the unsung hero and central command center of every Angular application. Join me for a tour of the control room.

https://sunnyblog.apexmansunny.workers.dev/posts/angular/the-control-room-of-your-angular-workspace/

The Hidden Nightmare of Scaling Massive Angular Monoliths

Thu, 25 Jun 2026 08:00:00 +0000

Everyone loves to talk about new frameworks.

Almost nobody wants to talk about what most senior Angular devs actually live in every day:

a 6+ year old enterprise app,
one Angular “app” that’s actually 40 products,
20+ minute build times on CI,
circular dependencies hiding in every corner.

The docs tell you:

Use esbuild. Use Nx. Use module boundaries. Problem solved.

Then you try it in a real bank, healthcare, or legacy SaaS codebase and discover:

you didn’t adopt a tool,
you adopted a new category of pain.

Modern tooling doesn’t magically fix legacy monoliths. It just makes their problems visible — and sometimes even more expensive.

When “Just Switch to esbuild” Turns Into “Why Is This Build 30 Minutes Now?”

esbuild is a genuinely impressive piece of technology:

extremely fast bundling,
great for modern Angular apps,
lighter config than classic Webpack.

But real-world reports from large Angular monoliths are… mixed:

teams migrating from Webpack to esbuild see blazing fast local builds,
then discover production or CI builds get slower or more fragile because of chunking and splitting behavior in huge apps.

One Nx issue described:

a module federation setup where initial build time jumped from ~90 seconds to close to 30 minutes after changes — due to complex chunking strategies and the way dependencies were wired.

In another case, a team with “one of the largest monolithic Angular apps in the world” moved to esbuild and ended up with:

local dev: better,
production bundling: complicated chunk management,
final solution: two separate projects in angular.json — esbuild for dev, Webpack for prod.

That’s not a failure of esbuild.

It’s what happens when you bolt a modern bundler onto an app that:

was never designed with clear boundaries,
uses dynamic imports everywhere,
and treats lazy-loaded routes as a dumping ground.

f your architecture is a junk drawer, a faster compiler just lets you open the drawer quicker. It doesn’t organize what’s inside.

Nx, Monorepos, and the “Modularization Will Save Us” Myth

Nx and monorepos can be game-changers when used from the start:

incremental builds,
affected-only testing,
module boundaries enforced,
CI time dropping from ~20 minutes to under 2 in large, well-designed workspaces.

But migrating a giant, messy Angular app into Nx is where a lot of teams hit the Enterprise Monolith Trap.

You:

drop the app into an Nx workspace,
run nx graph,
discover a terrifying dependency diagram with cycles everywhere.

The docs tell you:

enable @nx/enforce-module-boundaries,
break circular dependencies by moving shared pieces into new libraries,
create a clean layer structure.

All correct.

But on a legacy app, that means:

weeks or months of refactoring just to make the tooling happy,
teams blocked on breaking cycles instead of shipping features,
regression risk across critical flows when you move “shared” code around.

Talks about modular monoliths show beautiful patterns:

clear domain layers,
private APIs,
top-down dependency rules.

In greenfield projects, that works brilliantly.

In a legacy enterprise frontend, you’re often starting from:

shared utils imported directly from /src/app everywhere,
cross-feature imports that ignore any sense of boundaries,
tight coupling between “unrelated” modules because of convenience imports.

Nx doesn’t turn your monolith into a modulith. It just stops pretending your monolith is fine — and forces you to pay down chaos you’ve been borrowing against for years.

The Silent Killer: Build Pipelines That Eat Your Day

The biggest productivity killer in large Angular apps usually isn’t the framework.

It’s the pipeline.

Symptoms you see in banks, healthcare, and legacy SaaS:

10–30 minute builds in CI for every branch.
pipelines that must run extra code generators (proxies, API clients, etc.) before Angular even starts building.
flaky steps: tests, lints, and bundlers failing intermittently, forcing devs to rerun jobs.
“tiny” changes that still trigger full rebuilds because incremental builds weren’t designed in from the start.

Nx can help with:

caching,
incremental builds,
rebuilding only what changed.

But only if you’ve:

actually split code into buildable libraries,
wired all apps and libs to use the right executors,
aligned build target names across projects and libraries (or targetDefaults) so incremental executors can work.

Otherwise you get the worst of both worlds:

Nx complexity,
plus still building everything, every time.

And if your build also:

runs abp CLI proxies,
bundles multiple Angular apps,
packs everything into a deployment artifact,

you end up with a pipeline where nobody truly understands which step is slow, only that the whole thing is crushing morale.

You can’t have a healthy engineering culture if every experiment costs you a 30-minute CI penalty.

When “Just Modularize It” Becomes a Multi-Year Migration Trap

Enterprise talks make modularization sound simple:

extract domains into libraries,
define boundaries,
profit.

In reality, long-lived Angular apps usually have:

features that started as experiments and became core products,
modules that secretly depend on each other in both directions,
design systems and shared components that leak business logic.

When you try to modularize this:

you discover dozens or hundreds of circular dependencies.
you create “shared” libraries that quickly become new dumping grounds,
you end up either:
— endlessly slicing code into more libs, or
— merging libs back together because cycles are unmanageable.

The official Nx guidance on circular dependencies is sensible:

move small pieces from one project to another,
create a new shared lib for common dependencies,
or merge two libraries if they’re truly inseparable.

But in legacy frontends, everything feels inseparable:

because business logic and UI are tangled,
because features were never designed as domains,
because “shared” abstractions depend on concrete modules.

You can absolutely succeed with gradual modularization.

You just can’t pretend:

it’s a “quick Nx migration,”
or that tools alone will rescue you without rewriting some business logic and boundaries.

Large-scale migration isn’t a strategy. It’s what you call it when you don’t want to admit you’re rewriting while pretending you’re just ‘moving things around’.

The Enterprise Developer’s Reality: You’re Not Doing It Wrong

If you’re maintaining a massive Angular monolith, you’re probably:

doing on-call for a business-critical system,
juggling EOL reminders (Angular 19 end-of-life, libs that are no longer maintained),
forced to be cautious about every “cool” refactor because downtime has real cost.

When blog posts and conference talks say:

“Just adopt esbuild, it’s 10x faster,”
“Just move to an Nx monorepo,”
“Just break everything into micro frontends,”

they often ignore:

regulatory constraints,
long CI pipelines you can’t rewrite from scratch,
the risk of mass refactors in a system nobody fully understands anymore.

Your frustration is not a lack of skill.

It’s a rational response to:

brittle pipelines,
historical decisions,
and tools that were designed for idealized codebases.

Enterprise frontends aren’t broken because seniors are clueless. They’re broken because trade-offs compound — and tools arrived ten years after the architecture was decided.

What Actually Helps: Constraints, Not Silver Bullets

If you’re responsible for one of these monsters, here’s the boring but effective playbook grounded in what real teams report:

Accept the monolith, then modularize within it

Think “modulith” before micro frontends: one deployable, internally modular.
— Introduce clear layers and boundaries gradually — not everything at once.

Fix the worst pipeline bottlenecks first

Profile where time actually goes: bundling, tests, codegen, artifact uploads.
— Use Nx incremental builds where possible, even if only for part of the codebase at first.

Use tools to reveal problems, not to declare victory

nx graph to see dependency chaos.
— @nx/enforce-module-boundaries to prevent new damage while you slowly untangle the old.

Treat circular dependencies as design feedback, not just lint errors

if two libs constantly depend on each other, maybe they’re the same domain; merge them.
— if “shared” is depending on “feature,” you don’t have a shared lib — you have inverted design.

Limit how many technologies you add to the party

don’t add module federation, custom bundlers, a new design system, and a new monorepo in the same quarter.
— every move that touches build + architecture at once multiplies risk.

The goal isn’t to turn your enterprise monolith into a conference talk. It’s to make it slightly less painful every quarter without blowing it up in production.

I’m an Independent Technology Partner for SMEs. If you’re looking to optimize your architecture or accelerate your MVP, let’s connect at karolmodelski.pl.

Angular State Management: The Never-Ending Search for the “Perfect” Architecture

Thu, 11 Jun 2026 08:00:00 +0000

Nothing exposes developer anxiety like the words “state management” in an Angular enterprise project.

You have:

Signals,
SignalState,
SignalStore,
classic NgRx Store,
NGXS,
custom services as “mini-stores.”

And then you have a room full of mid and senior devs trying to design a system that has to survive five years of shifting requirements and team churn.

So what happens?

three weeks of meetings,
fourteen architecture diagrams,
benchmarking discussions nobody will ever repeat in practice.

Modern Angular state management gives you better primitives than ever. It also gives you a hundred new ways to overthink yourself into paralysis.

The State Management Buffet: Too Many Good Options, Not Enough Discipline

The ecosystem in 2025–2026 is not short on tools:

Plain Signals — built-in, zero-dependency, great for local or feature-level state.
SignalState / lightweight stores — NgRx’s signal-based API for smaller, isolated state, often at component or feature level.
SignalStore — structured, centralized state with Signals under the hood, meant for shared or domain-level state.
Classic NgRx Store — the “enterprise classic”: actions, reducers, effects, selectors, time-travel DevTools.
NGXS and others — simpler Redux-like abstractions trying to cut boilerplate.

Every blog post ends the same way:

There is no single best solution. It depends on your project size, team structure, and complexity.

Which is true.

And completely unhelpful when you have to make a call.

We keep asking “What’s the best state library?” when the better question is “How many different patterns can our team realistically keep in their heads?”

Decision Paralysis: The Architecture That Exists Only in Miro

The most realistic description of state management in large Angular apps right now looks like this:

State in services.
State in components.
State in classic NgRx.
State in SignalStore.
A few experiments with NGXS or Akita leftover from previous phases.

No single source of truth.
No single mental model.

What you do have:

a beautiful architecture diagram in Miro,
a 40-minute Loom recording titled “State Management Strategy v3.1,”
and a repo where every feature team solved state differently based on whichever conference talk they watched last.

Developers on Reddit and LinkedIn keep saying the same thing:

“Please don’t use Redux everywhere.”
“Have an explicit, consistent way of dealing with state across the application(s).”
“Pick two or three patterns and stick with them.”

The over-engineering trap is not picking NgRx or Signals.

The trap is:

trying to design a state architecture that covers every possible future scenario,
while your current codebase quietly rots under the weight of indecision.

Architecture diagrams don’t reduce complexity. Shipping boring, consistent patterns does.

The Over-Engineering Trap: Chasing the Perfect Store While Ignoring the Code

Here’s how over-engineered state management usually happens:

Someone reads a “Complete Guide to NgRx SignalStore” and gets excited.
Someone else wants classic NgRx for DevTools and strict flows.
Another person says “Signals alone are enough; stores are overkill.”

So you compromise:

global NgRx Store for “core” state,
SignalStore for some features,
local Signals in some components,
a few services still holding state because nobody had time to migrate them.

You spend weeks:

debating event plugins, inter-store communication, DDD boundaries,
arguing about whether shared state belongs in domain stores or feature stores.

Meanwhile, the things that actually kill scalability are much more boring:

services doing too many things at once,
no clear separation between server state and client state,
child components that both own and consume state,
APIs that force ugly workarounds no matter which store you use.

Most enterprise apps don’t collapse because they picked the ‘wrong’ state library. They collapse because nobody enforced simple rules on where state is allowed to live.

What the Tools Are Actually Good At (When You Use Them Like an Adult)

If you strip away the hype, the recent state of Angular guidance is surprisingly sane.

A lot of solid resources converge on a simple mapping:

Plain Signals
— for local, primitive or small, isolated state (component or small feature).
SignalState / lightweight stores
— for local but more complex objects or nested state, where you want structure without full-blown store ceremony.
SignalStore
— for shared, structured, domain-level or global state that needs to outlive components and be consumed across features.
Classic NgRx Store
— when you truly need Redux-style traceability, advanced DevTools, or are maintaining an existing NgRx-heavy codebase.

Summarized nicely in one article:

local, primitive → plain Signals ,
local, complex → SignalState ,
global, structured → SignalStore ,
complex orchestration / events between stores → SignalStore + Events plugin.

The problem is not that this mapping is wrong.

The problem is that many teams:

treat every feature as “global, complex, mission-critical,”
default to the heaviest tool for everything,
or mix all tools with no clear boundary.

Signals didn’t make NgRx obsolete. NgRx didn’t make services obsolete. The only thing that’s obsolete is pretending one hammer is right for every nail.

The Real Cost: State Strategy as a Drag on Scalability

State management was supposed to create scalability.

Instead, in many teams, it is killing it.

Ways state strategy makes things worse:

Onboarding pain
New devs have to learn: “In this feature we use Signals; over here we use SignalStore; for this legacy part we use classic NgRx.”
Inconsistent mental models
Some features mutate state in stores, some in services, some in components. No one can answer “Where does this value actually live?” without a search party.
Over-abstracted logic
Simple flows are buried in generic reducers or over-generic SignalStores instead of simple functions or services.
Cross-store complexity
Lightweight stores in multiple layers (UI, feature, domain, util) needing coordination, risking redundancy and cycles if you’re not careful.

Architects dealing with SignalStore are already warning:

don’t let stores talk to each other directly,
use orchestration services and events,
be deliberate about where stores live in your layered architecture.

All of that is fine — if you’re actually using those ideas to simplify.

Most teams don’t reach that stage.

They stall earlier, in analysis paralysis.

State management is supposed to remove accidental complexity. When your state strategy requires a diagram and a workshop to explain, you’ve just relocated the complexity instead of reducing it.

A Simpler Way to Think: Rules Instead of Endless Debates

You don’t need a perfect state architecture.

You need a few clear rules that everyone can remember.

For example (adapted from community guidance and modern best practices):

Default to Signals + services

For most feature-level state, create a service with Signals and computed values. — Expose readonly Signals and methods; keep mutation inside.

Use SignalStore for real shared state

Domain-level data used across multiple features? — Long-lived app-wide state? — Use SignalStore and keep all business logic there.

Keep classic NgRx where it already works

If you already have NgRx and it’s doing its job, don’t “rewrite to Signals” just because it’s trendy. Introduce SignalStore gradually for new areas.

Limit yourself to 2–3 patterns app-wide

For example: — plain Signals in components for simple UI bits, — Signal-based services for feature state, — SignalStore for shared state. — Everything else needs a very strong justification.

Explicitly document “when to use what”

One short ADR or page: — “If your state only matters to this component → do X” — “If it’s shared within a feature → do Y” — “If it’s global or domain-wide → do Z.”

The hardest part of state management isn’t picking a library. It’s having the courage to say ‘no’ to everything that doesn’t fit your agreed rules.

The Unsexy Advice: Start Simple, Then Add Structure When Reality Demands It

If you’re architecting a big Angular project today, here’s the boring, high-leverage path most experienced people quietly recommend:

Start with services + Signals for most state.
Add SignalStore when:
— state is shared across multiple features,
— you feel the pain of duplication and inconsistency.
Keep classic NgRx in existing apps where it’s already working; don’t rip it out proactively.
Resist the urge to “frameworkize” everything on day one.

You will be wrong about some decisions.

You will refactor some state flows later.

But you will be wrong based on real usage , not based on theoretical arguments in a meeting.

Scalability is not born from choosing the perfect state library. It’s born from making simple decisions consistently, and being willing to refactor when reality proves you wrong.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Stop Complaining About Boilerplate: Why Angular’s Structure Is an AI Superpower

Thu, 04 Jun 2026 08:00:00 +0000

For years the joke has been:

React is “simple and flexible.”
Angular is “bloated” and “full of ceremony.”

Then AI coding tools showed up.

And suddenly, the framework everyone mocked for having too many rules started to look like the one best aligned with how LLMs actually work.

Because here’s the uncomfortable truth:

LLMs don’t understand your app. They pattern‑match.

The more predictable the patterns, the better they perform.

And Angular is nothing if not predictable.

In an AI-assisted world, Angular’s ‘rigidity’ stops being a burden and becomes a map the model can actually follow.

Why AI Struggles More With Chaos Than With Ceremony

Language models are not magical architects.

They’re probability machines trained on:

code examples,
docs,
tutorials,
open-source projects.

They do best when:

file locations are predictable,
naming conventions are consistent,
the framework has “one obvious way” to do something.

That’s exactly what opinionated frameworks give them. Articles about AI and opinionated stacks point out: when there’s a single, well-defined way to structure routes, components, and services, AI can reproduce useful patterns far more reliably.

Angular leans hard into:

components, services, DI, and modules/standalone structure,
TypeScript first,
clear, documented best practices.

React, by contrast, is deliberately flexible:

no single enforced folder structure,
multiple competing state patterns,
dozens of meta‑framework and library combinations.

That’s great for human experimentation.

It’s not great for a model that’s trying to guess “how this project probably works” based on partial context.

AI doesn’t get confused by ceremony. It gets confused by ten different patterns that all claim to be ‘the React way’.

Angular’s Opinionated Defaults Are a Feature, Not a Bug, for LLMs

Angular’s “heavy” structure gives AI a narrower search space :

components live in obvious places,
services follow DI patterns,
routing is standardized,
forms, HTTP, and state have blessed approaches.

Angular devs working with AI are already noticing this:

“Organized frameworks tend to be more user‑friendly with AI. When a framework presents one well‑defined approach, AI can replicate it precisely.”
“Angular’s modules, components, services and DI create a cohesive map models can follow more easily.”

On top of that, Angular now ships official AI guidance :

a best‑practices prompt file for LLMs that spells out how to structure components, signals, templates, services, and accessibility.
guidance like:
— use standalone components,
— use signal()/computed() for state,
— prefer inject() DI,
— use new control flow,
— keep components small and focused.

You can literally feed this document into your AI tooling as system instructions so it knows the rules beforehand.

Contrast that with “just React”:

AI must first infer whether you’re using CRA, Vite, Next.js, Remix, a custom setup, or something else entirely.
Then it has to guess your state approach, routing, file layout, and styling stack.

Angular doesn’t just give humans conventions. It gives AI a contract: ‘If you follow these rules, you will probably generate code that fits.

Why Angular’s “Boilerplate” Becomes a Turbocharger With AI

All the things people call “boilerplate” in Angular?

They’re actually signal beacons for AI:

Predictable file naming and structure
— *.component.ts, *.service.ts, *.directive.ts, etc.
— Easy for tooling and LLMs to locate and extend.
TypeScript everywhere
— models, interfaces, enums, generics.
— static types give models strong hints about what goes where and how to call it.
Built‑in patterns for services and DI
— providedIn: ‘root’, inject() usage, clear service responsibilities.
Standardized Angular CLI + schematics
— Angular and Nx schematics encode best practices; AI can mimic them or call them safely.

Developers are already using AI like a supercharged ng generate:

“Create a component with these inputs/outputs and these services,” then let AI fill in wiring and boring glue.
let AI write form controls, validation, basic templates, while the human focuses on flows and architecture.

In one LinkedIn post, a dev described Angular + AI like this:

predictable structure is “a well-drawn map,”
TypeScript is “gold” for AI,
modularity helps AI focus on small pieces,
CLI & schematics standardize code so AI can generate consistent snippets.

The more ‘ceremonial’ the framework, the more surface area AI has to latch onto and the less creative guessing it has to do.

React’s Flexibility vs Angular’s Rigidity in an AI World

None of this means React is “bad” with AI.

In fact:

React and Next.js currently get more AI‑optimized examples and templates, which is why many tools default to them.
There’s more open-source React training data overall.

But there’s a split emerging:

LLM performance at “toy” and prototype scale
— AI tools default to Next.js/React for quick landing pages, dashboards, and demos, because the ecosystem around them is heavily tuned for that.
LLM reliability at “actually complex” app scale
— devs observe that Angular’s strict structure reduces the range of bad options the AI can pick in large codebases.

One discussion summed it up neatly:

the stricter the framework, the fewer random patterns AI will invent,
the more flexible the framework, the more ways AI can accidentally make a mess unless the human is very opinionated.

That maps perfectly onto what we already know:

Angular’s defaults reduce accidental inefficiencies and guard rails teams into safer patterns.
React offers a higher performance and flexibility ceiling — but only if the team enforces their own conventions.

Now add AI:

in Angular, AI tends to color within well-defined lines,
in React, AI can accidentally mix styles, patterns and libraries drawn from a noisy training set.

AI doesn’t care about your identity as a ‘framework person.’ It cares about how easy it is to predict where things go — and Angular hands it that predictability.

Angular + AI: From Vibe Coding to Agentic Workflows

The real future isn’t “AI writes all your code.”

It’s agentic workflows — AI assistants that understand your repo, follow your rules, and act like junior devs embedded in your architecture.

Angular is already leaning into that:

official docs on “develop with AI” and prompt files tailored for Angular repos;
workshops teaching advanced Angular devs how to integrate AI in a traceable , policy‑driven way (not just copy‑paste vibe coding);
guidance on using Angular’s strict mode, linting, Nx, and style guides as guardrails for both humans and AI.

That means you can:

plug in AI agents that respect your module boundaries and coding standards,
let AI propose refactors, add tests, or modernize code (standalone components, Signals, new control flow) while you review diffs,
keep a clear audit trail of what changed and why.

In other words:

Angular provides the rails; AI supplies the acceleration.

Without those rails, AI is just as likely to:

split logic randomly across files,
pick inconsistent state solutions,
or introduce subtle bugs under the banner of “productivity.”

Angular’s rigidity isn’t about gatekeeping humans. It’s about giving both humans and AI a structure where their speed doesn’t devolve into chaos.

The Thesis: Angular Is Quietly Future‑Proof in an AI World

If you’re an Angular dev, you’ve probably spent years defending your framework against:

“too heavy,”
“too much boilerplate,”
“too opinionated.”

AI flips that narrative.

In a world where:

tools generate huge chunks of code,
assistants refactor entire modules,
agents run in your CI and IDE,

the frameworks that win are:

strict enough that AI can’t go completely off the rails,
structured enough that teams can reason about AI‑driven changes,
typed and patterned enough that suggestions line up with reality.

That describes Angular almost perfectly.

So the next time someone tells you:

“Angular is too rigid,”
“we should use something simpler,”
“AI works better with flexible frameworks,”

remember:

AI doesn’t want freedom. It wants structure. Angular gave you that structure years before AI showed up — and now that ‘boring’ choice looks like one of the most future‑proof bets you could have made.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

Your AI Assistant Is a React Fanboy and You Should Be Worried

Thu, 28 May 2026 08:00:00 +0000

Ask most AI coding tools to “build me a web app” and watch what happens.

Nine times out of ten, you’ll get:

React,
Next.js,
Tailwind,
maybe a sprinkle of popular auth and UI libraries.

No context.
No questions about your team.
No questions about your constraints.

Just React‑by‑default.

If you listen to AI long enough, you could easily conclude:

React is obviously the “right” choice,
Next.js is obviously the framework for everything,
Angular is for… nobody, apparently.

AI doesn’t pick stacks based on your reality. It picks stacks based on its training data — and that’s not the same thing.

Why AI Tools Keep Recommending React and Next.js

This isn’t a conspiracy.

It’s a side effect of how these models learn and how AI builders integrate frameworks.

A few reasons:

Training data dominance
Public React and Next.js codebases, tutorials, templates, and snippets massively outnumber public Angular projects.
Many Angular apps live in closed enterprise repos, so models simply see less Angular.
Tool vendor choices
Firebase Studio, no‑code builders, AI prototyping tools — many officially support Next.js as their first or only framework and plan to “add others later.”
That means AI integrations, examples, and docs are tailored for that stack.
AI optimization efforts
Some companies are literally optimizing React/Next.js code for AI use, publishing curated “best practices” repos tuned for model consumption.
Ecosystem momentum
AI‑friendly tutorials, AI‑generated starter kits, and vibe‑coding demos on YouTube skew heavily toward React + Next.js.

So when you throw a vague prompt like:

Build a SaaS dashboard with user auth, billing, and admin controls

into an AI assistant, the model defaults to the pattern it has seen the most:

React + Next.js. Not because your problem needs it — because the internet is full of it.

AI isn’t your architect. It’s a statistical mirror of what everyone else already did — mostly with React.

When Letting AI Choose Your Stack Actively Hurts You

For small demos or personal projects, React/Next.js as a default is fine.

For serious systems, blindly following AI’s bias can backfire hard.

Examples of where this goes wrong:

Your team is mostly Angular or .NET people
The AI happily scaffolds a React/Next.js app because it looks “modern.”
Now your entire team has to:
— learn a new mental model,
— rebuild internal patterns,
— juggle two ecosystems.
You’re building a long‑lived enterprise product
React’s flexibility is great short‑term. Long‑term, it demands discipline, conventions, and extra libraries to get the “framework” behavior Angular gives you out of the box.
AI doesn’t know how disciplined your team is.
You need consistency across multiple teams and services
Angular’s opinionated structure often makes multi‑team maintenance easier over years. React’s “assemble your own framework” dynamic amplifies inconsistency when different squads pull in different stacks and patterns.

Yet AI will almost never ask you:

“How many teams will work on this?”
“What’s your current stack?”
“Who will maintain this in 3–5 years?”

It just picks the thing it has been trained to spit out confidently.

Letting AI choose React for your team because ‘that’s what it generated’ is like letting Google autocomplete decide your system architecture.

The New Villain: AI Bias in Tech Stack Selection

The Angular vs React fight is old.

The new villain is the invisible bias sitting inside AI tools.

We’re already seeing developers point out that:

AI agents tend to “suck with Angular” — they hallucinate APIs, ignore DI, and fight the framework instead of using it correctly.
React and Next.js feel “more AI‑friendly” because models have more examples and clearer integration paths.
People gravitate toward stacks where AI “feels better,” even if it’s not better for their project.

This creates a loop:

AI works better with React/Next.js →
More people choose React/Next.js because AI feels smoother →
More React/Next.js code goes into training data →
AI becomes even more biased toward React/Next.js.

Angular gets squeezed out of AI’s “comfort zone,” despite remaining incredibly strong in exactly the kinds of systems AI is bad at reasoning about: long‑lived, multi‑team, enterprise apps.

The danger isn’t that React wins. It’s that AI quietly removes Angular from the menu before the humans even sit down.

“Most Popular” Is Not the Same as “Most Productive for You”

Stack Overflow surveys and GitHub stars show React still leads in usage.

But that does not automatically mean:

React is the most productive for your team,
React is the best choice for your domain,
React + Next.js is the right default for AI-assisted development in every case.

Developers with experience in both stacks keep reporting:

Angular is often easier to maintain long‑term when teams and requirements change, because it gives you structure and consistency.
React is often nicer to write in for small to medium projects, especially for solo devs or startups.

For AI‑heavy frontends:

React has more AI‑tailored component libraries and examples , especially for chat UIs and dashboards.
Angular offers better enterprise integration , type safety, and form handling for complex, bureaucratic systems.

The key point:

AI is biased toward what is most common and most explicitly optimized for it, not what fits your team and your business.

If you confuse ‘most popular in the training data’ with ‘most productive for my context,’ you’re letting statistics, not strategy, run your stack.

Why I Would Still Return to Angular After AI Pushes Next.js

AI tools love Next.js as the “structured React default.”

For a lot of quick prototypes and SaaS frontends, that makes sense.

But if:

the project will live 5+ years,
multiple teams will touch it,
you care about strict types, form complexity, and consistency,

there are still many cases where I would actively steer back to Angular — even if AI keeps demoing Next.js.

Reasons:

Opinionated architecture
— less “choose your own adventure” in folders, state, routing, and DI,
— easier onboarding when devs come and go.
Enterprise alignment
— Angular’s model aligns with how a lot of larger organizations actually work — modules, teams, domains, shared libraries.
Consistency over time
— fewer wild swings in patterns every six months,
— less chance of a Frankenstack assembled from every hot React meta‑framework.

Does that mean Angular is “objectively better”?

No.

It means AI’s default suggestion is not a substitute for thinking about the lifecycle of your system.

AI can scaffold your first month. It doesn’t have to live with your third year.

How to Use AI Without Letting It Pick Your Stack for You

You don’t need to fight AI.

You just need to move stack selection back where it belongs: human judgment.

Practical steps:

1. Decide the stack before you touch AI

Start from constraints:

team skills,
existing systems,
lifespan of the project,
regulatory and scalability needs.

Pick a stack from that, then tell AI:

We are using Angular here. Follow Angular best practices and do not switch frameworks.

or:

This company is a React shop. Use React, not Next.js, unless I explicitly ask.

2. Be explicit about “no stack switching”

AI assistants will happily suggest migrations:

“We could move this to Next.js for better SEO.”
“Let’s use this React library; it’s more popular.”

Shut that down early:

“Do not propose changing the main framework. Work within Angular.”
“Respect the existing tech stack; no rewrites unless explicitly requested.”

3. Feed it your own patterns

If you want AI to be less React‑biased:

give it Angular examples from your codebase,
show it your module, state, and component conventions,
ask it to follow those patterns.

You’re not going to overpower global training data, but you can tilt its answers toward your reality.

4. Separate “AI for scaffolding” from “AI for architecture”

Use AI for:

components,
forms,
tests,
boilerplate.

Do not outsource:

domain modeling,
system boundaries,
long‑term architecture choices.

AI should fill in code inside a decision, not make the decision for you.

The Real Takeaway: AI Reflects the Crowd, Not What’s Right

AI is not secretly on React’s payroll.

It is doing exactly what it was designed to do:

approximate the most likely answer,
based on the data it has seen the most.

Right now, that means:

React and Next.js for most “build me an app” prompts,
Angular often underrepresented despite its strength in enterprise.

If you know this and act accordingly:

AI becomes a useful power tool inside whatever stack you intentionally choose.

If you don’t:

AI becomes a quiet, persuasive force pushing every problem toward the same default stack — whether it fits or not.

Your AI assistant is a React fanboy by training. Your job is to be the adult in the room who knows when that bias is helping you and when it’s quietly wrecking your architecture.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

I Choose Angular Over React for Large Projects. Here’s Why.

Wed, 27 May 2026 15:52:43 +0000

title: I Choose Angular Over React for Large Projects. Here’s Why.
published: true
date: 2026-04-29 01:55:37 UTC
tags: react,frontenddevelopment,angular

canonical_url: https://medium.com/@mgm_squared/i-choose-angular-over-react-for-large-projects-heres-why-02385ec71903

I know what you’re thinking. The job boards say React. The bootcamps say React. Every “top frameworks 2025” listicle says React. I’m not here to tell you React is bad — it isn’t. But after 15 years across five industries, teams ranging from 3 to 20 engineers, and frontend codebases that had to survive long past their original authors, I keep reaching for Angular when the stakes are high. Here’s the honest case for why.

Let me establish some credibility first

I’m not an Angular developer who hasn’t touched React. I’ve shipped React in production — TypeScript, hooks, the whole ecosystem — on real teams with real users. I know the flexibility. I’ve felt the speed of spinning something up.

I’ve also led Angular teams building platforms and component libraries that are still in production today, maintained by engineers who had nothing to do with writing them. That last sentence is the whole argument, really.

React’s ecosystem is a feature. On large teams, it’s also a trap.

React gives you a rendering library and says “figure out the rest.” For a senior engineer who has already figured it out, that’s liberating. For a 15-person team with mixed experience levels, it’s a slow-motion debate club.

Pick your state management: Redux? Zustand? Jotai? Recoil? MobX? Context with useReducer? Each has passionate advocates and legitimate use cases. So your team has a meeting. Then another. Someone posts a benchmark. Someone else posts a counter-benchmark. Two weeks later you’ve adopted Zustand, three engineers aren’t sure why, and two secretly wish you’d picked Redux because that’s what they know.

Now do the same exercise for data fetching. React Query or SWR? RTK Query? Plain useEffect with a custom hook? Axios or fetch? And folder structure — features-based or type-based? Where do shared utilities live? What about form handling — React Hook Form, Formik, or something homegrown?

None of these are wrong questions. All of them are genuinely debatable. But on a large team, every unanswered convention is a future argument, a future inconsistency, and a future onboarding headache. The flexibility that makes React feel fast in a solo project accumulates into friction at scale.

Angular answers most of these questions before you write a single line of code. Services for state and data. HttpClient for API calls. Reactive Forms for complex form handling. A CLI that generates consistent, predictable scaffolding. You can disagree with Angular’s answers — but everyone on your team is working with the same answers, and that consistency compounds over years.

Onboarding is where this really shows up

I’ve watched senior engineers drop into large React codebases and spend weeks just mapping the terrain. Not because they weren’t capable — they absolutely were — but because every codebase has made different decisions. Different state patterns, different folder conventions, different data-fetching abstractions, all layered on top of each other as the team’s opinions evolved over time. There’s no map. You have to draw your own.

With Angular, I’ve handed a junior developer a quick tutorial and some guidance and watched them make meaningful contributions within days. Not because Angular is simpler — it isn’t — but because the conventions are already there. A new engineer knows where services live, knows how components are structured, knows how to inject a dependency. The framework is the map.

The guardrails aren’t limitations. They’re structure. And structure is what lets engineers at every level focus on solving the actual problem instead of navigating codebase archaeology.

Angular isn’t your grandfather’s framework

If the last time you seriously looked at Angular was the AngularJS era or even Angular 2–8, you’re carrying a mental model that doesn’t match the current reality. The framework has evolved dramatically.

Standalone components removed the NgModule overhead that used to be one of Angular’s most common friction points. Now a component declares its own dependencies directly — you open one file and see everything it needs. No hunting through module declarations to understand the dependency graph. With modern IDE tooling, jumping to any dependency is a keystroke away.

Signals brought a modern, explicit reactivity model that rivals anything in the React ecosystem. Zone.js is becoming optional. The bundle sizes are competitive. The developer experience — template type checking, language service, CLI — has matured to the point where it genuinely gets out of your way.

The Angular of 2026 is not what critics are usually criticizing. The framework has quietly had one of the most impressive evolution arcs in frontend history, and a lot of the React community hasn’t noticed because they stopped paying attention a few versions ago.

TypeScript first, not TypeScript adjacent

Angular was designed with TypeScript from the ground up. The compiler catches template type errors at build time — pass the wrong type to a component input, reference a property that doesn’t exist in your template, and the build fails. You find out immediately, not in production.

React with TypeScript is genuinely good. But TypeScript is optional in React, and optionality in a large codebase is a liability. You’ll inherit files written before TypeScript was added. You’ll find any used as an escape hatch. You'll see prop interfaces that diverged from reality months ago. Angular's compiler is less forgiving — and on a large team, less forgiving is a feature.

Dependency injection changes how you architect

This is the one React developers tend to wave away until they’ve lived with it. Angular’s DI system makes service boundaries explicit. You define a service, declare where it lives in the injector hierarchy, inject it where you need it. Testing becomes trivial — swap the real service for a mock and your component tests have no idea the difference.

React’s answer is context, custom hooks, and discipline. Context works. Custom hooks are elegant. But discipline is not a framework feature — it degrades over time, especially as teams grow and change. I’ve seen React codebases where data fetching logic had migrated into components because “just this once,” and that pattern had replicated itself across dozens of files. Angular’s DI doesn’t prevent bad decisions, but it makes the good patterns the path of least resistance.

Where React genuinely wins

Intellectual honesty matters here. React is the right call in real scenarios:

Ecosystem breadth — more third-party libraries, more community examples, and frankly more AI awareness. React’s dominance means LLMs have seen more React code, which matters when AI-assisted development is part of your workflow.
Hiring — more React engineers available, and that matters when you’re scaling fast
Rapid prototyping — React plus Next.js is hard to beat for getting something live quickly
React Native — if mobile is in scope, the story is much cleaner
Small teams with strong opinions — if everyone has been writing React for years with aligned conventions, you may not feel the pain points I’m describing

The framework isn’t the bottleneck. The team is.

The right framework is the one your team can stay consistent with at your current size and growth rate.

Small team, short time horizon, everyone senior — React’s flexibility is an asset. The overhead of Angular’s conventions may slow you down more than the structure helps.

Large team, long time horizon, mixed experience levels — Angular’s conventions are load-bearing. The structure isn’t overhead, it’s the thing that keeps twenty engineers pointing in the same direction eighteen months from now.

I’ve been on both sides of this. I know which late-night debugging sessions I’d rather not repeat.

At M²S², we help engineering teams make exactly these kinds of decisions — not based on what’s trending, but based on what actually works at your scale. If you’re weighing your options, let’s talk.

Original Kubernetes Dashboard — retired upstream, upgraded to Angular 21.

Mon, 25 May 2026 17:58:46 +0000

Original Kubernetes Dashboard — retired upstream, upgraded to Angular 21.

Background

The official Kubernetes Dashboard was archived in January 2026. The Angular codebase was unmaintainable, the toolchain was fragile, and the upstream maintainers called it quits.

What happened till now

So time ago I posted this here We Rebuilt the Kubernetes Dashboard From Scratch — Here's What We Added and I liked the result, it works properly without any issues but somehow it does not "feel correct".

For years we used the Kubernetes Dashboard provided by The Kubernetes Authors and we somehow got used to the WebUI with that blue ribbon or those green "pies" that sometimes got yellow or red in Workloads.

FYI

Before I go any further, I would like to make a statement: I am not a developer, do not pretend to be one and hope one day maybe to be one.

I am active in Secure Systems Engineering and my knowledge of coding languages are the ones I use in my job such as Python or PowerShell or Bash but mainly in "execution mode" and sometimes in "troubleshooting mode" when they do not work...

With the emergence of AI such as ChatGPT, Gemini, Mistral or Claude, "coding" has become more accessible to humans without any coding knowledge. I will pass on the the "Vibe Coding" Topic fully as it's not in focus of this post.

Since the tools are there I decided to use them and do some projects, so yes I may be a "Vibe Coder" and I can live with that tag but the projects always apply Secure Systems Engineering Principals and when there is a knowledge lack I do not hesitate to ask my colleagues developers at work for advice.

Why it was rebuilt with React + MUI?

With help of Claude Code (the man's 2nd best friend after the dog...) we forked the original GitHub Repository, updated the Go Backend without any issues. When it came to the Angular update, well the things got complicated as the original project was in Angular 16 and we needed to update to Angular 21. So what went wrong? Well the human decided to not listen to his AI Assistant and we upgraded from 16 to 21 directly and unfortunately that was not a good idea. The WebUI did work but had lots of issues. We started fixing some but the result was not satisfactory and abandoned the upgrade project and built the React + MUI WebUI.

What happened next?

I was not fully satisfied of the React + MUI outcome as it somehow betrayed the spirit of the initial project so I decided to start all over again.

Claude Desktop was tasked to a deep technical and functionality analysis of the old stack

Claude Web did all the online research for the Angular Migration path, issues, hurdles,...

Claude Code was tasked to perform Angular Upgrade from 16 to 21 in steps and every time the stack was tested before upgrading to the next version.

What was the outcome?

We managed to perform properly the Angular Upgrade from 16 to 21 and got the original WebUI working properly with maybe some very very very very minor visual deviations that are hardly noticeable unless you do a side by side comparison with the old WebUI, which we did to correct bugs such as "Tooltips" or "Status Pills" and many more.

We are proud to present some screenshots of the final result:

What's next up?

Well for the moment nothing, we sit back and wait to see if it gets popular like the native one....

Final words

We understood why the initial team did not address the Angular Upgrade as the outcome is not certain and the effort is considerable for maybe a not satisfactory outcome.

We are pleased to have achieved this migration even if it was a hell of a work and hope the result will please the users of the native but now retired Kubernetes Dashboard.

Links

Kubernetes Dashboard: https://kubernetes-dashboard.com/

GitHub: https://github.com/isms-core-project/kubernetes-dashboard

Angular Migration

Angular Migration: https://kubernetes-dashboard.com/migration.html

Technical Paper:

Migrating a Retired Kubernetes Dashboard from Angular 16 to 21 using Claude Code

https://kubernetes-dashboard.com/paper.html

Acknowledgements

This project would have not being possible without Claude "in all flavours" (the man's 2nd best friend after the dog...)

How to make splash screen with progress tracking in Angular?

Wed, 06 May 2026 09:50:27 +0000

Preface

Loading all initialization data in an Angular application can sometimes take a while—especially over slow internet connections. Displaying a blank screen during this time can lead to a poor user experience.

To mitigate this, we can introduce a splash (or loading) screen to provide users with immediate visual feedback, making the app feel more responsive and polished.

Demo Project

The demo below showcases a working implementation of a splash screen:

⚡ Try this code on StackBlitz or GitHub

Should the Splash Screen Be a Component?

Short answer: ❌ no.

Here's why:

Angular components aren’t rendered until after the framework bootstraps. This means any splash screen defined as a component would appear too late to be useful.
Initialization tasks like HTTP requests should be handled in provideAppInitializer, before Angular even begins rendering the UI.

File: app/app.config.ts

⚡ View on StackBlitz

    provideAppInitializer(async () => {
      const initializers: AsyncInitializer[] = [
        inject(ConfigLoaderService),
        inject(ConnectionCheckerService),
        inject(StorageInitializerService),
        inject(TranslationLoaderService),
      ];

  for (const initializer of initializers) {
    await performAsyncInitialization(initializer);
  }

  await splashFadeOut();
}),


> For demonstration purposes, `performAsyncInitialization()` simulates a delay by waiting one second.

> The `splashFadeOut()` function starts the fade-out animation and waits for it to complete.

##  Where Should Splash Screen Styles and Scripts Go?

You can embed splash screen styles and scripts directly inside the `<app-root>` tag in index.html. This ensures they appear instantly and can be easily removed once the app is initialized, leaving no residue behind.

**File**: `index.html`

> ⚡ [View on StackBlitz](https://stackblitz.com/~/github.com/ArkadiuszPabian/NgSplashScreen?file=src/index.html)
```html
<app-root>
  <!-- START Splash screen -->

  <!-- Styles -->
  <style>
    [...]
  </style>

  <!-- Content -->
  <div class="splash-container" id="splash">
    <div class="circle-outline"></div>
    <svg>
      [...]
    </svg>
    <div class="loading-text">
      <span id="updater">Loading Angular app</span>
      <span class="jumping-dots">
        <span class="dot"></span>
        <span class="dot"></span>
        <span class="dot"></span>
      </span>
    </div>
  </div>

  <!-- Place for scripts -->

  <!-- END Splash screen -->
</app-root>

If the splash screen code is large, consider moving styles and scripts into external files for better maintainability. However, this introduces a trade-off: additional HTTP requests will slightly delay the splash screen's appearance. Also, these files must reside in the public folder, increasing the final build size.

Can I Update the Splash Screen Dynamically?

Yes, you can dynamically modify the splash screen—for example, to show real-time progress updates.

To do this, reference a DOM element by its id and update its content during app initialization. Be mindful: both the HTML and Angular logic must reference the same id, so consistency is key.

File: index.html

⚡ View on StackBlitz
<span id="updater">Loading Angular app</span>
File: app/core/utils/splash-screen.utils.ts

⚡ View on StackBlitz

export function updateTitle(text: string): void {
  const elem = document.getElementById('updater');
  if (elem) {
    elem.textContent = text;
  }
}

Bottom line

Splash screens in Angular are not only possible—they're practical.
Since Angular lacks a built-in solution, a custom inline approach is the most efficient and reliable.
Keep splash logic minimal and inline, and ensure it is removed cleanly once the app is initialized.

What's Next (Advanced Topics)

To elevate this implementation and make it suitable for production-grade apps, here are some advanced areas worth exploring:

⚡ Optimize Splash Screen Load Time After First Load
Cache initialization data (e.g. app config, feature flags) using LocalStorage or IndexedDB, so it can be reused without delay.
️ Integrate with Service Worker for Offline & Fast Loads
Ensure splash screen assets (HTML, images, inline styles) are cached by your Angular Service Worker.

Angular Change Detection: The Evolution from Zone.js to Signals

Tue, 28 Apr 2026 18:18:11 +0000

Introduction

As applications grow in complexity, understanding how Angular detects and propagates changes becomes critical for performance. For years, developers relied on the "magic" of Zone.js, but the modern Angular landscape has shifted toward more explicit, high-performance patterns — OnPush first, and now fine-grained reactivity with Signals.

As a Principal Architect, I've seen teams struggle with jank and unnecessary re-renders that stem from a shallow understanding of change detection mechanics. This is the architectural guide to mastering change detection in the modern Angular era: how Zone.js actually works, what OnPush buys you, and how Signals change the picture entirely.

The Era of "Magic": Zone.js and the Default Strategy

By default, Angular uses Zone.js to monkey-patch every asynchronous API in the browser: setTimeout, setInterval, Promise.then, XMLHttpRequest, fetch, event listeners. When Angular boots, it runs your entire application inside a zone. When any patched async operation completes — a timer fires, a Promise resolves, a click handler runs, an HTTP response arrives — Zone.js notifies Angular: "Something happened; you should probably check."

Angular responds by walking the entire component tree from root down. For each component, it compares the current value of every template expression against its previous value. If anything changed, it updates the corresponding DOM nodes.

The key insight: Angular doesn't watch your data. It watches for async operations, because async operations are what change data. When something async happens, Angular assumes something might have changed and checks everything.

The good: It works out of the box. You update a variable, and the UI updates. The mental model is simple.

The bad: It's dirty-checking at its most expensive. In a large app, clicking a single button can trigger change detection across hundreds of components that haven't changed at all. As the component tree grows, this top-down check becomes a major performance bottleneck.

The Performance Bridge: ChangeDetectionStrategy.OnPush

OnPush changes the contract for a component. Instead of checking it on every async event, Angular only checks it when one of four conditions is met:

An @Input() reference changes. Not a mutation — a new reference. If the parent mutates an existing object, OnPush children are not triggered.
An async pipe emits a new value. The async pipe internally calls markForCheck() when its Observable or Promise emits. This is why the async pipe is the best friend of OnPush.
markForCheck() is called explicitly via ChangeDetectorRef. This is the correct escape hatch when you need to trigger detection outside the standard mechanisms.
A DOM event originates from the component or its children. Click handlers and input events within an OnPush component still trigger detection for that component.

@Component({
  selector: 'app-user-card',
  template: `<div>{{ user.name }}</div>`,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserCardComponent {
  @Input() user!: User;
}

With this configuration, UserCardComponent is skipped entirely if the parent triggers change detection 100 times but hasn't passed a new user reference.

The async pipe handles the second trigger condition for you automatically:

@Component({
  selector: 'app-user-list',
  template: `
    @if (users$ | async; as users) {
      @for (user of users; track user.id) {
        <app-user-card [user]="user" />
      }
    }
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserListComponent {
  users$ = this.userService.getUsers(); // Observable<User[]>

  constructor(private readonly userService: UserService) {}
}

The async pipe subscribes to users$, and when the Observable emits, it calls markForCheck() internally — the component re-renders with the new data without you touching ChangeDetectorRef at all.

When you do need to call markForCheck() explicitly — for example when updating state from a callback that runs outside Angular's normal data flow:

@Component({
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class NotificationComponent implements OnInit {
  message = '';

  constructor(
    private readonly cdr: ChangeDetectorRef,
    private readonly notificationService: NotificationService
  ) {}

  ngOnInit(): void {
    // Third-party library callback — runs outside Angular's zone
    this.notificationService.onMessage((msg: string) => {
      this.message = msg;
      this.cdr.markForCheck(); // Tell Angular to check this component on next cycle
    });
  }
}

Immutability is mandatory. Since OnPush checks reference equality, you cannot mutate object properties:

// Will NOT trigger OnPush child to re-render
this.user.name = 'New Name'; // Same reference

// Will trigger re-render
this.user = { ...this.user, name: 'New Name' }; // New reference

This is a feature, not a limitation. Immutable state updates are predictable and traceable. OnPush makes mutability visible by breaking your UI when you do it — which is exactly what you want in a large codebase.

Running Outside Angular's Zone

Some async operations don't affect the UI: logging, analytics, background processing. Running these inside Angular's zone triggers unnecessary change detection cycles. NgZone.runOutsideAngular() lets you escape:

constructor(private readonly ngZone: NgZone) {
  this.ngZone.runOutsideAngular(() => {
    // High-frequency WebSocket messages processed here
    // No change detection triggered per message
    this.websocket.messages$.subscribe(msg => {
      this.latestState = processMessage(msg);
      // Only re-enter the zone when the view actually needs to update
      if (this.stateChanged) {
        this.ngZone.run(() => this.cdr.markForCheck());
      }
    });
  });
}

This pattern is particularly important for high-frequency data streams. Processing WebSocket messages outside the zone and only re-entering when something the view renders has changed is the correct architecture for reactive, data-intensive Angular applications.

What to avoid: Injecting ChangeDetectorRef to call detectChanges() repeatedly throughout your components. If you find yourself doing this often, it's a signal that your data flow is too complex or your state management isn't reactive enough. The correct tools are the async pipe and signals. detectChanges() is appropriate for Canvas or WebGL components that manage their own render loop and need a single explicit trigger — not as a general-purpose workaround.

The Modern Frontier: Signals and Fine-Grained Reactivity

Angular Signals, stable in Angular 17+, represent the most significant shift in change detection since the framework's inception. They move Angular from "checking the tree" to "notifying the specific node."

A signal is a value wrapped in a reactive container. When you read a signal in a template, Angular tracks the dependency. When the signal changes, Angular knows precisely which components depend on it and marks only those for re-rendering — no tree walk, no zone notification, no checking of unrelated components.

@Component({
  selector: 'app-counter',
  template: `
    <p>Count: {{ count() }}</p>
    <p>Double: {{ double() }}</p>
    <button (click)="increment()">Increment</button>
  `
})
export class CounterComponent {
  count = signal(0);
  double = computed(() => this.count() * 2);

  increment(): void {
    this.count.update(c => c + 1);
  }
}

Why signals are a game changer:

Fine-grained updates. Unlike Zone.js which triggers a global check, a signal knows exactly where it is used. When its value changes, Angular updates only that specific part of the DOM.

Computed signals are lazy. computed() only recomputes when read after a dependency has changed. If double is not read after count changes, no computation occurs. This laziness is the performance model.

Zoneless potential. Signals are the prerequisite for a fully zoneless Angular. Removing Zone.js reduces initial bundle size and eliminates the overhead of monkey-patching browser APIs.

No more ExpressionChangedAfterItHasBeenCheckedError. Because signal updates are synchronous and predictable, this notorious error — which has haunted Angular developers for years — becomes a thing of the past.

Signals vs RxJS: Different Tools

The first question developers ask about signals is whether they replace RxJS. They don't — they solve different problems.

Signals are for synchronous reactive state: values that change over time and drive the UI. Simple to create, simple to read, naturally integrated with Angular's template system.

RxJS is for asynchronous event streams: HTTP responses, WebSocket messages, complex event sequences, time-based operations. The operator ecosystem — switchMap, debounceTime, combineLatest, catchError — has no equivalent in signals.

The practical pattern is to use both. toSignal() and toObservable() from @angular/core/rxjs-interop bridge between them:

import { toSignal, toObservable } from '@angular/core/rxjs-interop';

@Component({ ... })
export class ProductsComponent {
  private readonly products$ = this.productService.getProducts();

  // Observable → Signal for use in template
  products = toSignal(this.products$, { initialValue: [] });

  // Signal → Observable for RxJS pipeline
  private readonly searchTerm = signal('');
  private readonly results$ = toObservable(this.searchTerm).pipe(
    debounceTime(300),
    switchMap(term => this.productService.search(term))
  );
  results = toSignal(this.results$, { initialValue: [] });
}

Here's the same local state pattern in both approaches:

// ❌ Before: BehaviorSubject for local state
@Injectable({ providedIn: 'root' })
export class UserStore {
  private _users = new BehaviorSubject<User[]>([]);
  private _loading = new BehaviorSubject<boolean>(false);

  users$ = this._users.asObservable();
  loading$ = this._loading.asObservable();
  count$ = this._users.pipe(map(u => u.length)); // New observable per derivation

  setUsers(users: User[]): void {
    this._users.next(users);
  }

  setLoading(loading: boolean): void {
    this._loading.next(loading);
  }
}

// ✅ After: Signals for local state
@Injectable({ providedIn: 'root' })
export class UserStore {
  private readonly users = signal<User[]>([]);
  private readonly loading = signal(false);

  // Derived values — lazy, no subscription management
  readonly userList = this.users.asReadonly();
  readonly isLoading = this.loading.asReadonly();
  readonly count = computed(() => this.users().length);

  setUsers(users: User[]): void {
    this.users.set(users);
  }

  setLoading(loading: boolean): void {
    this.loading.set(loading);
  }
}

No subscription management. No pipe(map(...)) for every derived value. No asObservable() to prevent external mutation. The signal version is shorter, more readable, and the computed() derivation is lazy by default.

effect() runs a side effect whenever its signal dependencies change, replacing subscribe() patterns for reactive side effects:

export class UserProfileComponent {
  readonly selectedUserId = signal<string | null>(null);

  constructor(private readonly userService: UserService) {
    // Runs once immediately, then re-runs whenever selectedUserId changes
    effect(() => {
      const id = this.selectedUserId();
      if (id) {
        this.userService.loadUser(id).subscribe(...);
      }
    });
  }
}

Reserve RxJS Subjects for genuinely asynchronous, multi-consumer event streams where the operator ecosystem (debouncing, switching, combining) adds real value.

Architectural Recommendations

Default every component to OnPush. There is rarely a reason to use the Default strategy in a high-performance enterprise application. Make OnPush the standard in your lint rules and code review checklist, not an opt-in optimization.

Adopt signals for local and feature state. For state that drives the UI within a component or a feature library, signals outperform BehaviorSubjects: less boilerplate, lazy derived values, no subscription management. Keep RxJS for HTTP, WebSocket, and complex async orchestration.

Use the async pipe over manual subscriptions in templates. The async pipe handles markForCheck() for you in OnPush components, manages subscription lifecycle, and avoids memory leaks. Manual subscriptions in components with subscribe() require careful ngOnDestroy cleanup and don't integrate with OnPush automatically.

Minimize detectChanges(). If you find yourself calling it frequently, the underlying data flow is the problem — not change detection. Refactor toward reactive state (signals or async pipe) rather than adding more detectChanges() calls.

The Zoneless Future

Signals enable a zoneless application. With provideExperimentalZonelessChangeDetection() (Angular 18+), you can run Angular without Zone.js entirely:

// main.ts
bootstrapApplication(AppComponent, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

In a zoneless application, change detection triggers only via signal changes and markForCheck() calls. No Zone.js patching, no detection triggered by timers or HTTP responses that don't affect signals. Angular renders exactly what needs to render, when it needs to render, because the signal dependency graph tells it precisely what changed.

Summary

The evolution of Angular change detection is a journey from implicit magic to explicit reactivity:

Zone.js (Default): Provided the ease of use that made Angular popular. Every async event triggers a full tree check. Correct for all cases, expensive at scale.

OnPush: Gave us the tools to scale performance through immutability and explicit check triggers. Requires discipline around references and the async pipe, but dramatically reduces unnecessary work in large component trees.

Signals: Provide the future-proof, fine-grained reactivity needed for the next generation of zoneless Angular applications. Angular renders exactly the components that depend on a changed signal, and nothing else.

By mastering these three pillars, you ensure your application remains fluid and responsive regardless of how large the component tree grows — and you position your codebase to take full advantage of where Angular is heading.

TypeScript Utility Types Every Angular Developer Should Know

Tue, 28 Apr 2026 18:17:26 +0000

Introduction

TypeScript ships with a set of built-in generic types called utility types. They transform existing types into new ones — making properties optional, readonly, or required; picking or omitting specific keys; extracting return types from functions. They let you express complex type relationships without duplicating type definitions.

Most Angular developers use a handful of them — Partial and Observable come to mind — but the full set is underused relative to how much it can simplify type-heavy Angular code. This article covers the utility types that appear most frequently in Angular applications, with concrete examples drawn from the patterns you encounter every day: form handling, HTTP services, component inputs, NgRx state, and API response modeling.

Partial

Partial<T> makes all properties of T optional. Every property becomes T[key] | undefined.

The most common Angular use case is update payloads. When patching a resource, you only send the fields that changed — not the entire object.

interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'viewer';
  lastLogin: Date;
}

@Injectable({ providedIn: 'root' })
export class UserService {
  updateUser(id: string, changes: Partial<User>): Observable<User> {
    return this.http.patch<User>(`/api/users/${id}`, changes);
  }
}

// Caller only provides what changed — TypeScript enforces this
this.userService.updateUser(userId, { name: 'Jane', role: 'admin' });

Partial also appears in form state modeling. A form in progress may not have all fields populated yet:

interface ProductForm {
  name: string;
  price: number;
  description: string;
  category: string;
}

// Form state before the user has filled everything in
type DraftProduct = Partial<ProductForm>;

// TypeScript won't complain about missing fields
const draft: DraftProduct = { name: 'Widget' };

Required

Required<T> is the inverse of Partial — it makes all optional properties required. This is useful when you've modeled something with optional fields during construction but need to assert that all fields are present at a later stage.

interface Config {
  apiUrl?: string;
  timeout?: number;
  retries?: number;
}

function validateConfig(config: Config): Required<Config> {
  if (!config.apiUrl) throw new Error('apiUrl is required');
  if (!config.timeout) throw new Error('timeout is required');
  if (!config.retries) throw new Error('retries is required');

  // After validation, we assert the config is fully populated
  return config as Required<Config>;
}

// From this point on, TypeScript knows all fields are defined
const validated = validateConfig(rawConfig);
console.log(validated.apiUrl); // string, not string | undefined

Readonly

Readonly<T> makes all properties of T non-writable. Attempts to mutate properties on a Readonly<T> type fail at compile time.

In Angular applications with OnPush change detection, immutability is the contract that makes the strategy work correctly. Readonly<T> lets you enforce this at the type level rather than just by convention:

interface AppState {
  users: User[];
  selectedUserId: string | null;
  isLoading: boolean;
}

// State is never mutated — only replaced
type ImmutableState = Readonly<AppState>;

function reducer(state: ImmutableState, action: Action): ImmutableState {
  switch (action.type) {
    case 'SET_LOADING':
      // Return new object — cannot mutate state directly
      return { ...state, isLoading: action.payload };
    default:
      return state;
  }
}

For deeply nested immutability, Readonly<T> only applies at the top level — nested objects remain mutable. For deep immutability, use ReadonlyArray<T> for arrays and recursive Readonly wrappers, or a library like immer.

Pick<T, K>

Pick<T, K> creates a new type containing only the properties of T whose keys are in the union K.

The most valuable Angular use case is creating view models from full entity types. Your API returns a rich User object, but a particular component only needs three fields:

interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'viewer';
  createdAt: Date;
  lastLogin: Date;
  preferences: UserPreferences;
  address: Address;
}

// The user card only needs these three fields
type UserCardViewModel = Pick<User, 'id' | 'name' | 'email'>;

@Component({
  selector: 'app-user-card',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserCardComponent {
  @Input() user!: UserCardViewModel;
  // Component can't accidentally access fields it shouldn't need
}

This pattern enforces component encapsulation at the type level. A component that displays a user card has no business accessing preferences or address. Pick makes that boundary explicit and compiler-enforced.

Omit<T, K>

Omit<T, K> is the complement of Pick — it creates a type containing all properties of T except those in K.

The canonical Angular use case is create payloads. When creating a new resource, server-generated fields like id and createdAt don't exist yet:

interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'viewer';
  createdAt: Date;
}

// For creation, id and createdAt are server-generated
type CreateUserPayload = Omit<User, 'id' | 'createdAt'>;

@Injectable({ providedIn: 'root' })
export class UserService {
  createUser(payload: CreateUserPayload): Observable<User> {
    return this.http.post<User>('/api/users', payload);
  }
}

// TypeScript error if you try to pass id in the payload
this.userService.createUser({
  name: 'Jane',
  email: 'jane@example.com',
  role: 'viewer'
  // id: '...' — TypeScript error: Object literal may only specify known properties
});

Record<K, V>

Record<K, V> creates a type representing an object whose keys are of type K and whose values are of type V. It's the typed alternative to { [key: string]: V }.

In Angular applications, Record is useful for lookup tables, state maps, and any dictionary-style structure:

type UserId = string;
type LoadingState = 'idle' | 'loading' | 'success' | 'error';

// Track loading state per entity ID
type EntityLoadingMap = Record<UserId, LoadingState>;

// In an NgRx reducer or component state
interface UserState {
  entities: Record<UserId, User>;
  loadingStates: Record<UserId, LoadingState>;
  selectedId: UserId | null;
}

Record with a union key type is particularly powerful — it constrains the valid keys to only the members of the union:

type Route = 'home' | 'products' | 'orders' | 'settings';
type RoutePermissions = Record<Route, boolean>;

const permissions: RoutePermissions = {
  home: true,
  products: true,
  orders: false,
  settings: false,
  // TypeScript error if any Route key is missing
  // TypeScript error if any key outside Route is added
};

ReturnType

ReturnType<T> extracts the return type of a function type T. This is most useful when you want to derive a type from a function's output without declaring the type separately.

In Angular, this pattern appears most clearly with factory functions and NgRx selectors:

// A factory function that builds a complex object
function createUserViewModel(user: User, permissions: Permissions) {
  return {
    id: user.id,
    displayName: `${user.name} (${user.role})`,
    canEdit: permissions.includes('user:edit'),
    canDelete: permissions.includes('user:delete'),
  };
}

// Derive the type from the function without duplicating it
type UserViewModel = ReturnType<typeof createUserViewModel>;

// Now use it as an @Input type
@Component({ ... })
export class UserDetailComponent {
  @Input() viewModel!: UserViewModel;
}

With NgRx selectors:

export const selectUserViewModel = createSelector(
  selectCurrentUser,
  selectPermissions,
  (user, permissions) => ({
    id: user.id,
    displayName: user.name,
    canEdit: permissions.canEditUsers,
  })
);

// Derive the output type from the selector
type UserViewModelState = ReturnType<typeof selectUserViewModel>;

Parameters

Parameters<T> extracts the parameter types of a function as a tuple. Less commonly used than ReturnType, but valuable when you need to pass or store function arguments as typed values.

function searchUsers(
  query: string,
  filters: UserFilters,
  pagination: PaginationOptions
): Observable<PaginatedResult<User>> {
  return this.http.get<PaginatedResult<User>>('/api/users', {
    params: buildQueryParams(query, filters, pagination)
  });
}

// Extract parameter types without re-declaring them
type SearchParams = Parameters<typeof searchUsers>;
// SearchParams is [string, UserFilters, PaginationOptions]

// Useful for caching search arguments
function cacheSearch(params: SearchParams): void {
  const [query, filters, pagination] = params;
  // ...
}

NonNullable

NonNullable<T> removes null and undefined from a type union. Useful after null checks when you need to assert to TypeScript that a value is definitely present:

interface RouteData {
  userId: string | null;
  productId: string | undefined;
}

function processRoute(data: RouteData) {
  if (!data.userId) throw new Error('userId required');
  
  // Without NonNullable, TypeScript still thinks userId could be null here
  // because it doesn't narrow across function calls
  const userId: NonNullable<typeof data.userId> = data.userId;
  // userId is now typed as string
}

A more practical Angular pattern — using NonNullable with the async pipe and strict null checks:

@Component({
  template: `
    @if (user$ | async; as user) {
      <!-- Inside this block, user is NonNullable -->
      <app-user-card [user]="user" />
    }
  `
})
export class UserPageComponent {
  user$: Observable<User | null> = this.store.select(selectCurrentUser);
}

Extract<T, U> and Exclude<T, U>

Extract<T, U> extracts from T the types that are assignable to U. Exclude<T, U> does the opposite — it removes from T the types assignable to U.

These are most useful with union types:

type Status = 'idle' | 'loading' | 'success' | 'error';

// Only the terminal states (not loading or idle)
type TerminalStatus = Extract<Status, 'success' | 'error'>;
// TerminalStatus = 'success' | 'error'

// Everything except loading
type NonLoadingStatus = Exclude<Status, 'loading'>;
// NonLoadingStatus = 'idle' | 'success' | 'error'

In Angular applications, this pattern is valuable for narrowing action types in effects or reducers:

type UserAction =
  | { type: 'LOAD_USER'; id: string }
  | { type: 'LOAD_USER_SUCCESS'; user: User }
  | { type: 'LOAD_USER_FAILURE'; error: string }
  | { type: 'UPDATE_USER'; changes: Partial<User> }
  | { type: 'DELETE_USER'; id: string };

// Only the actions that affect loading state
type LoadingActions = Extract<
  UserAction,
  { type: 'LOAD_USER' | 'LOAD_USER_SUCCESS' | 'LOAD_USER_FAILURE' }
>;

Combining Utility Types

The real power comes from composing utility types. A few patterns that appear frequently in production Angular codebases:

Create vs Update payloads from a single interface:

interface Product {
  id: string;
  name: string;
  price: number;
  categoryId: string;
  createdAt: Date;
  updatedAt: Date;
}

type CreateProductPayload = Omit<Product, 'id' | 'createdAt' | 'updatedAt'>;
type UpdateProductPayload = Partial<Omit<Product, 'id' | 'createdAt' | 'updatedAt'>>;

Safe subset for a component input:

// Only expose the fields a display component needs, as readonly
type ProductCardInput = Readonly<Pick<Product, 'id' | 'name' | 'price'>>;

Discriminated union response type:

type ApiResponse<T> =
  | { status: 'success'; data: T }
  | { status: 'error'; message: string }
  | { status: 'loading' };

type SuccessResponse<T> = Extract<ApiResponse<T>, { status: 'success' }>;
// SuccessResponse<T> = { status: 'success'; data: T }

Conclusion

TypeScript's built-in utility types are the vocabulary of type-level programming in Angular. They let you express the relationships between your types — between a full entity and its create payload, between a rich API response and the view model a component needs, between a union of all possible states and the subset a particular handler cares about — without duplicating type definitions.

The individual types are each simple. The discipline of reaching for them consistently — instead of writing any, loosening types, or duplicating interfaces — is what makes a large TypeScript codebase maintainable. Each utility type usage is a constraint you're encoding once and getting for free everywhere the type is used.

Stop Treating Angular as a Second-Class Framework for UI Components

Thu, 16 Apr 2026 08:00:00 +0000

You’ve been promised “Angular support” more times than you can count.
What you got instead was a React library in an Angular costume.

A thin compatibility layer. A demo that technically works, but feels wrong the second you try to build something serious with it.

Angular support is not the same as Angular respect.

And the more you look at how Angular tooling is actually built, the less patience you have for ecosystems that treat Angular like an afterthought.

The Lie Behind “Angular Support”

You’ve seen it.

A UI library announces Angular support.
You click the docs.
You get excited for about 15 seconds.

Then you realize what “support” really means:

awkward APIs that feel imported from another ecosystem,
missing Angular ergonomics,
strange lifecycle edges,
styling and composition patterns that clearly weren’t designed for Angular first.

Technically, yes, it works.

But if your first reaction is “why does this feel like React with extra steps?” , then it’s not a native Angular experience.

”A wrapper is not a first-class developer experience.”

And Angular developers know the difference immediately.

React Gets Products. Angular Gets Adapters

This is the part nobody wants to say too loudly.

In a lot of modern tooling ecosystems, React gets the real product.
Angular gets the adaptation layer.

React gets:

the first-class API,
the best examples,
the cleanest DX,
the product decisions designed around its mental model.

Angular gets:

“integration”,
“compatibility”,
“support coming soon”,
or a wrapper that exposes just enough to close the sales objection.

That doesn’t mean every React-first library is bad.
It means Angular is too often treated as a market checkbox instead of a platform that deserves design respect.

And once you’ve felt that enough times, you stop reading “Angular support” as a positive signal.

You start reading it as a warning label.

Most multi-framework libraries are really one framework with export options.

The Problem Isn’t Just Pride. It’s Product Quality

This is not framework tribalism for its own sake.

Wrapper-heavy ecosystems create real problems:

worse developer experience,
inconsistent abstractions,
harder debugging,
awkward state integration,
weaker performance characteristics,
APIs that don’t fit Angular’s strengths.

When a library is born in one ecosystem and then “ported” into Angular without fully embracing Angular’s patterns, you pay for it everywhere:

in the template layer,
in reactivity,
in change detection assumptions,
in styling APIs,
in the mental overhead of using something that never really feels native.

That cost compounds fast in real products.

A bad wrapper is not just ugly.
It becomes architecture debt.

The ecosystem quality you tolerate today becomes the architecture debt you inherit tomorrow.

Angular Developers Are Not Asking for Special Treatment

The ask is much simpler:

If you say your library supports Angular, then build for Angular like it matters.

That means:

APIs that feel natural in Angular,
composition patterns that respect Angular architecture,
state handling that fits Angular’s reactive model,
docs written for Angular devs, not translated from another framework,
examples that look production-ready, not “we made this demo work once.”

Angular is not some fringe hobby framework.
It powers serious enterprise apps, internal tools, fintech platforms, compliance systems, and big teams that care about long-term maintainability.

So the expectation is not unreasonable.

If the framework is good enough to power critical systems, it’s good enough to deserve native tools , not compatibility leftovers.

If Angular is good enough for core systems, it’s good enough to deserve first-class tools.

Why Developers Are Spending Months on Angular-First Tools

At some point, complaining stops being interesting.

You either keep using wrappers and live with the friction, or someone builds the thing they wish existed.

That’s why you increasingly see stories of developers who spend months building Angular-first tools — including rich text editors — instead of gluing React-centric libraries into their apps.

Not because the world desperately needed yet another editor.
And not because anyone wanted a vanity side project.

They did it because they were tired of pretending Angular developers should be grateful for second-hand abstractions.

They wanted things that felt native from the inside out:

designed around Angular patterns,
built with Signals in mind,
not fighting Angular templates,
not leaking another framework’s assumptions into every integration point.

If your “Angular integration” feels like React with extra steps, it’s not Angular-native.

The deeper you look at these case studies, the clearer the pattern becomes:

Most “Angular ports” aren’t really ports. They’re translations with compromises.

Because once someone tries to build something properly for Angular, it becomes obvious how many “multi-framework” tools are really just one framework with export options.

Signals Changed the Standard

Angular’s ecosystem has a chance right now to stop copying old patterns and start building better ones.

Signals matter here.

Because an Angular-native future should not be:

old wrapper patterns with new branding,
React mental models translated into Angular syntax,
or generic abstractions that ignore what Angular is actually good at.

It should be:

signal-first APIs,
cleaner state flows,
better template ergonomics,
components designed for Angular’s architecture instead of awkwardly tolerated by it.

This is where Angular devs need to get more ambitious.

Not “Can we get this React thing working in Angular?”
But:

What would the best possible Angular-native version of this tool look like?

That’s a much better question.
And honestly, it’s long overdue.

The Angular Community Needs More Conviction

One of Angular’s biggest ecosystem problems is not technical.

It’s psychological.

Too many Angular developers have been trained to accept less:

fewer native libraries,
slower ecosystem momentum,
weaker mindshare,
and “good enough” wrapper support.

That creates a strange defeatism.

People start talking like Angular is lucky just to be included.

It isn’t.

Angular deserves builders who act like it’s worth building for.

Angular doesn’t need more compatibility. It needs conviction.

That means more developers creating:

Angular-first component systems,
Angular-native editors, tables, charts, and design tools,
signal-based primitives,
and products that don’t apologize for not being React.

Because if Angular developers keep waiting for React ecosystems to save them, they will keep getting what they’ve always gotten:

Adapters.
Wrappers.
Second-class support.

If you keep acting like Angular is second-class, don’t be surprised when the ecosystem treats it that way.

This Isn’t About Beating React

React is not the villain here.

React won the mindshare war for a reason:

huge ecosystem momentum,
lower barrier to experimentation,
enormous commercial gravity around component libraries and UI tooling.

Fine.

But Angular developers keep making the mistake of treating that as proof that Angular should just consume whatever React produces.

That’s not strategy.
That’s dependency.

The real question is not:

How do we get more React libraries into Angular?

The real question is:

What tools should exist because Angular exists?

That’s how you build a healthier ecosystem.

Not by begging for parity through wrappers, but by creating products that are unmistakably native.

Native Angular Tools Will Always Feel Better

A real Angular-native tool gives you things wrappers rarely do:

APIs that match Angular instincts,
predictable integration into Angular architecture,
cleaner mental models,
fewer translation layers,
less framework dissonance.

And when the product itself is designed for Angular from day one, the quality difference shows up everywhere:

in how fast teams onboard,
in how easy it is to debug,
in how natural it feels to extend,
in how much trust there is in the tool long-term.

That trust matters.

Because teams don’t just adopt components.
They adopt maintenance futures.

A wrapper always feels like borrowed infrastructure.

And borrowed infrastructure is the first thing people want to rip out when things go wrong.

The Manifesto

So here’s the position, clearly:

Stop calling wrappers “great Angular support.”
Stop rewarding ecosystems that treat Angular as a checkbox.
Stop acting grateful for tools that were never truly designed for Angular developers.
Stop lowering the bar for what “Angular-native” should mean.

Start building:

better Angular-first libraries,
signal-based primitives,
tooling that respects Angular architecture,
products that feel like they belong in Angular, not merely tolerate it.

If Angular is good enough for the hardest problems, it’s good enough to deserve first-class tools.

If you are building for Angular, build with standards high enough that nobody has to ask whether it was native.

They should feel it instantly.

Angular Deserves Better

This is bigger than one editor, one library, or one complaint.

It’s about whether Angular developers keep accepting second-class tooling in a first-class framework.

You can read plenty of stories of teams who inherited Angular apps full of awkward wrapper libraries and half-baked integrations.
Once those abstractions land in a codebase, they stay there for years.

That’s why this matters.

The shortcuts you accept at the library level become the nightmares you debug at the product level.

The ecosystem quality tolerated today becomes the architecture debt inherited tomorrow.

Angular deserves better than wrappers.

And if the ecosystem is not going to hand Angular better native tools, then Angular developers will have to build them.

That’s not just a technical decision.

It’s a standards decision.
A community decision.
A respect decision.

So yes — stop treating Angular as a second-class framework for UI components.

And start building like it isn’t one.

I fix the Angular apps that generalists break.

I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.

If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/

From Learning to Building2: My Journey as a Young Developer

Tue, 07 Apr 2026 12:56:54 +0000

This article was originally published here:
https://dev.to/yomna/from-learning-to-building-my-journey-as-a-young-developer-2pa

This is a submission for the 2026 WeCoded Challenge: Frontend Art

StudyMood: A Frontend Experience for Focus and Balance
Show us your Art
Live Application: https://study-mood.vercel.app (frontend ready, backend in progress)
Portfolio: https://yomnachelly.github.io/yomna.github.io/

StudyMood is a Pomodoro-based productivity web application designed to help users stay focused, organized, and balanced during their study sessions.

The interface is clean, minimal, and distraction-free, allowing users to fully concentrate on their tasks while managing their time efficiently.

In addition to this project, I also built my personal portfolio using HTML, CSS, and JavaScript, focusing on simplicity, responsiveness, and clear presentation of my work. It reflects my frontend fundamentals and my ability to design user-friendly interfaces.

Inspiration
The inspiration behind StudyMood comes from a simple idea:

staying productive is not just about working more, but working better.

As a student and developer, I often struggled with focus and time management. I wanted to create a tool that is not only functional, but also visually calming and motivating.

The goal was to design an experience that:

reduces distractions
encourages consistency
promotes a healthy study rhythm
Through this project, I also wanted to express how frontend development can be used to create meaningful and helpful user experiences.

My Code
GitHub Repository: https://github.com/yomnachelly/StudyMood.git

Technical Stack
Frontend: Angular
Backend: Supabase
Deployment: Vercel
Portfolio: HTML, CSS, JavaScript
Tools: Git & GitHub
This project focuses on frontend design, usability, and smooth interaction. While some backend features are still being improved, the main goal was to build a complete and user-friendly interface.

This project represents my transition from learning concepts to building real, usable applications.

Angular-Aware E2E Testing: Query Components by @Input and Signals in Playwright

Thu, 02 Apr 2026 12:12:00 +0000

The Gap Between Angular and Its Tests

Angular applications are composed of typed components with declared @Input() properties, signal() state, and @Output() events. Yet most E2E tests interact with these apps through raw CSS selectors — completely ignoring the component model.

This leads to tests that know too much about the DOM and too little about the Angular contract. @playwright-labs/selectors-angular fills that gap.

Installation

npm install -D @playwright-labs/selectors-angular

Quick Setup

// playwright.config.ts
import { selectors, defineConfig } from "@playwright/test";
import { AngularEngine } from "@playwright-labs/selectors-angular";

selectors.register("angular", AngularEngine);

export default defineConfig({
  use: { baseURL: "http://localhost:4200" },
});

Or use the all-in-one import that registers the engine automatically:

import { test, expect } from "@playwright-labs/selectors-angular";

The `angular=` Selector

Query components by their @Input() values instead of DOM attributes:

// By exact @Input value
page.locator('angular=app-button[label="Submit"]')

// By nested property
page.locator('angular=app-user-card[user.role="admin"]')

// By substring
page.locator('angular=app-button[type*="primary"]')

// Multiple conditions (AND)
page.locator('angular=app-button[type="danger"][disabled]')

// Regex
page.locator('angular=app-button[label=/^Sub/i]')

// Case-insensitive
page.locator('angular=app-button[label="submit" i]')

Supported operators mirror CSS attribute selectors:

Syntax	Meaning
`[prop]`	truthy
`[prop="val"]`	exact match
`[prop*="val"]`	contains
`[prop^="val"]`	starts with
`[prop$="val"]`	ends with
`[prop~="val"]`	word in list
`[prop\\|="val"]`	exact or hyphen-prefix

The `$ng` Fixture

Access component state directly from test code:

test("reads component properties", async ({ page, $ng }) => {
  await page.goto("/");

  // @Input value
  const label = await $ng("app-button").first().input<string>("label");
  expect(label).toBe("Submit");

  // WritableSignal value
  const count = await $ng("app-counter").first().signal<number>("count");
  expect(count).toBe(0);

  // List inputs
  const inputs = await $ng("app-button").first().inputs();
  expect(inputs).toContain("disabled");

  // Check directives
  const dirs = await $ng("router-outlet").directives();
  expect(dirs.some((d) => d.includes("RouterOutlet"))).toBe(true);
});

Custom Matchers

import { expect } from "@playwright-labs/selectors-angular";

test("component matchers", async ({ page }) => {
  const btn = page.locator("app-button").first();
  const counter = page.locator("app-counter").first();

  await expect(btn).toBeNgComponent();
  await expect(btn).toHaveNgInput("label");
  await expect(btn).toBeNgInput("label", "Submit");
  await expect(btn).toHaveNgOutput("clicked");

  await expect(counter).toHaveNgSignal("count");
  await expect(counter).toBeNgSignal("count", 0);
});

A Before/After Comparison

Before:

// Depends on template class names — breaks on refactor
const deleteBtn = page.locator("button.danger:disabled");
await expect(deleteBtn).toHaveCount(1);

After:

// Queries the Angular component contract directly
const deleteBtn = page.locator('angular=app-button[type="danger"][disabled]');
await expect(deleteBtn).toHaveCount(1);

The second version continues to work even if the template is rewritten to use different class names, a different element, or a different disabled mechanism — because it queries the component, not the DOM.

Signal-Based Inputs (Angular 17+)

The engine transparently handles input() signal-based inputs alongside traditional @Input():

@Component({ selector: "app-badge" })
export class BadgeComponent {
  count = input<number>(0);   // signal-based input
  @Input() label = "";         // traditional input
}

// Both work identically in selectors:
page.locator('angular=app-badge[count=5]')
page.locator('angular=app-badge[label="New"]')

Requirements

Angular 14+ in development mode (ng serve or --configuration=development)
Playwright 1.40+

Conclusion

By teaching Playwright to speak Angular's language, @playwright-labs/selectors-angular makes E2E tests that are more resilient, more readable, and more aligned with how the application is actually built.

Source: github.com/vitalics/playwright-labs

The Senior Angular Take‑Home That Made Me Rethink Tech Interviews

Thu, 02 Apr 2026 08:00:00 +0000

I spent an entire weekend building a “small” take‑home assignment.
Friday to Monday. Stock data app. Real‑time updates. Angular, WebSockets, Supabase mock.

On Monday, I submitted the repo.
On Tuesday, I got the rejection.

No call. No detailed feedback. Just “we’ve decided not to move forward.”

That was the moment I realized something: most companies have no idea what they’re actually testing when they give senior devs take‑home assignments.

The Assignment That Ate My Weekend

The brief, simplified, looked like this:

Build a small Angular app that displays stock data for up to 4 companies
Load initial data via HTTP from a public API
Implement real‑time price updates using:
— a custom WebSocket server (backend)
— and a mocked implementation in Angular
Allow toggling updates per stock card (enable/disable)
Reflect price changes visually (increase / decrease / disabled states)
Create a responsive UI (desktop + mobile)

On paper, it was reasonable.
It touched all the right buzzwords: HTTP, WebSockets, real‑time updates, responsiveness, toggles per card.

If you’ve only shipped todo apps, this is a sexy challenge.
If you’ve spent years in production Angular codebases, it’s just a very compressed slice of real work.

I got the task on Friday. I submitted on Monday.
In between, I did what seniors are supposed to do: I treated it like a real mini‑project, not a quick coding kata.

My Goal: Not Just “Make It Work”, But “Show How I Work”

I wasn’t trying to just tick boxes with the bare minimum implementation.

My goals were:

show architecture decisions ,
show how I handle messy APIs ,
show how I think about real‑time behavior ,
keep overall code quality at a level I’d be happy to merge into a real repo.

So I:

structured the app so HTTP and WebSocket logic weren’t glued to the UI,
made sure each card’s real‑time subscription could be toggled cleanly,
handled visual state for price up / down / disabled,
paid attention to responsiveness for both desktop and mobile.

And then the data source decided to be… the internet.

The API Was Flaky, So I Did What Production Me Would Do

The assignment used public, free stock data.
That sounds fine, until you remember what “public, free” usually means:

rate limits,
inconsistent responses,
occasional downtime,
weird edge cases on weekends and off‑hours.

The WebSocket data wasn’t consistent either.
Sometimes it would lag, sometimes it would drop, sometimes it would just stop updating.

For a weekend project, you have two choices:

Pretend it’s fine, hack around the issues, and hope the reviewer doesn’t notice.
Treat it like a real integration: build a mock , stabilize your domain logic, and make your app deterministic for review.

I chose option 2.

I built a mock WebSocket implementation in Angular so I could:

simulate consistent price updates,
test toggling updates on/off per stock card,
guarantee the app behaves correctly even if the real API is having a bad day.

From my perspective as a senior dev, that was the right call:

decouple the app from a flaky external system,
make real‑time behavior testable,
keep the “real API” path around, but not rely on it for correctness.

In other words: I tried to behave like someone who’s shipped production apps, not like someone doing a school exercise.

What the Company Probably Saw Instead

Here’s my guess about what happened on their side.

They cloned the repo.
They followed the steps.
They ran the app with the “real” public data.

And depending on the timing and the API mood, they may have seen:

delayed or missing updates,
weird lulls in price changes,
behavior that didn’t look “smoothly real‑time”.

If they didn’t read the README carefully, or didn’t flip into the mock mode, my architectural decision probably looked like… a bug.

No context. No understanding that I built the mock because the public stream is unreliable.
Just: “The WebSocket behavior is not solid. Next candidate.”

That mismatch is what made me rethink the entire premise of senior take‑home assignments.

What This Assignment Actually Tested (and What It Didn’t)

On the surface, it looked like it tested:

Angular skills,
HTTP and WebSocket handling,
real‑time UI,
responsiveness.

In practice, it tested something else:

who is willing to burn a weekend to impress a company,
who optimizes for the demo , not for production reality,
who can guess what the reviewer cares about , without any conversation.

Because here’s the thing: as a senior, you are constantly balancing trade‑offs.

If this were a real client project, I would have:

clarified API reliability up front,
negotiated scope (“do you want a pretty demo or a robust integration?”),
documented the limitations,
decided with the team how much time to spend on mocks vs building around the real feed.

In a take‑home, you get none of that.
You just guess, implement, and hope your guess lines up with whatever the reviewer imagines “good” looks like.

If you optimize for elegance and robustness, they might say you “over‑engineered a small task”.
If you optimize for a quick, hard‑coded demo, they might say you “lacked senior‑level architecture thinking”.

You’re taking a test with no answer key.

That’s not a tech interview. That’s a silent compatibility test with someone’s private taste.

The Senior Work That Never Shows Up in Take‑Homes

The more I thought about it, the more I realized how much real senior work this assignment couldn’t see:

Clarifying incomplete or unrealistic requirements.
Pushing back on scope when someone tries to cram a sprint into a weekend.
Deciding when to build a mock, when to live with flakiness, and when to say “this API is not acceptable for production”.
Communicating trade‑offs to non‑technical stakeholders.
Designing an architecture that won’t explode in six months.

Instead, the process mostly evaluated:

how quickly I could implement a small greenfield UI,
how much free time I had between Friday and Monday,
how well my decisions matched a reviewer I’ve never spoken to.

That’s not a tech interview.
That’s a silent compatibility test with someone’s private taste.

Why I Think Most Senior Take‑Homes Are Misaligned

This experience clarified a few things for me.

1. They confuse “time sacrifice” with “commitment ”

If you’re willing to burn your weekend to build a polished app, it’s read as “motivated”.
If you timebox yourself and refuse to over‑invest, it’s read as “not hungry enough”.

In reality, the person who protects their time and still delivers a solid, well‑scoped solution is probably a better long‑term hire.

2. They test mid‑level implementation, not senior judgment

Building a small stock app from scratch shows you can:

wire up components,
call APIs,
handle events,
add some responsiveness.

That’s mid‑level baseline.
It doesn’t tell you how someone:

handles legacy code,
refactors a 500‑line component,
improves CI,
unblocks a team stuck on a bad architecture decision.

If you want to know whether I can rescue your Angular app, don’t ask me to build a toy in a weekend.

If you want to know whether I can rescue your Angular app, don’t ask me to build a toy in a weekend.
Show me your worst component and ask how I’d detox it.

3. They ignore how seniors actually work in 2026

In real life, I use Claude Code and Antigravity heavily.

Not to cheat, but to:

scaffold modules,
explore alternative designs,
generate boring boilerplate,
fuzz‑test APIs and policies.

If your assignment bans AI and expects me to pretend it’s 2014, you’re not testing my real workflow. You’re testing my ability to role‑play a slower version of myself.

The future senior is the one who brings the architecture and judgment , uses AI to implement faster, and still understands what’s happening under the hood.

What a Better Senior Angular Take‑Home Could Look Like

Instead of “build a stock app from scratch over the weekend”, here’s what I’d consider a good senior‑level assignment:

1. Smaller, paid, time‑boxed task

2–3 hours max.
Paid at a reasonable rate.
Clear that they care more about how you think than how many screens you can ship.

2. Refactor an existing messy component

Give a real‑world Angular component that:

is 400+ lines,
mixes data fetching, state, and UI,
has a couple of hidden bugs.

Ask the candidate to:

refactor it,
explain their decisions,
write a couple of tests,
list what they’d tackle next.

That’s a senior skill.

3. Architecture review, not pixel‑perfect clone

Provide a small codebase and ask:

“How would you introduce real‑time updates here?”
“How would you make this testable?”
“Where would you put toggles and state?”

Let the candidate use real tools, real patterns, and real AI support — just like they would on the job.

What I’ll Do Differently Next Time

I don’t regret doing this assignment.
It gave me a free, honest look at how I behave when nobody is watching.

Here’s what I’m changing going forward:

I won’t spend full weekends on unpaid assignments.
I’ll timebox, signal my priorities in the README, and let the result speak for itself.
I’ll over‑communicate constraints and trade‑offs.
If an API is flaky and I build mocks, I’ll make that impossible to miss — in the README and in the UI.
I’ll focus on clarity over cleverness.
Clean, readable, obviously structured code beats elegant but over‑abstracted architecture, especially in a small assignment.
I’ll treat take‑homes as two‑way interviews.
If a company expects free, multi‑day work with vague feedback, that’s a data point.
I’m not just being evaluated — I’m evaluating them.

I’m not just being evaluated in take‑homes anymore; I’m evaluating the companies that ask for them.

I’m still going to build things on weekends.
But from now on, I’d rather ship my own AI‑driven SaaS and fix real bottlenecks than over‑optimize for silent reviewers I’ll never meet.

If you’re a senior dev:

What’s the last take‑home you did that actually tested your real job — not just your free time?

I fix the Angular apps that generalists break.

Karol Modelski is a senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.
If your Angular app is slowing your team down, start here: https://www.karol-modelski.scale-sail.io/

7 Years of Angular Made Me Realize I Don’t Actually Know Web Development

Thu, 26 Mar 2026 09:03:37 +0000

I used to introduce myself as “a Senior Angular Developer.”
Seven years of components, RxJS streams, NgModules, Signals, Nx monorepos, CI pipelines, performance audits — the whole thing.
On paper, I looked production‑ready.

Then I started building my own AI‑driven SaaS.

No corporate backend team. No DevOps department. No “someone else” handling auth, storage, or migrations.
Just me, Supabase, Stripe, AI integrations… and a lot of gaps I didn’t know I had.

Suddenly it became painfully obvious:

I know how to operate Angular.
I don’t really know the web — and it’s actively blocking me.

My AI SaaS Forced Me to Wear a Backend Hat

On client projects, there’s always a safety net.

You have a backend squad, a DevOps person, maybe a database architect. I could stay in my lane: fix Angular apps generalists broke, do Component Detoxes , tame Signals, squeeze TBT and LCP, and ship features.

On my own product, there is no “lane”. It’s just reality:

AI‑driven SaaS that needs real users ,
real payments,
real dashboards,
and real‑time data.

No one else is coming to wire it together.

I picked Supabase to move fast. “Serverless Postgres with auth, storage, and real‑time built in” sounded perfect.

Except here’s what that actually meant in practice.

The Non‑Angular Concepts That Exposed Me

Here’s the exact breakdown of the non‑Angular and advanced web development concepts I had to learn/use for this project — and where the lack of them slowed me down.

1. Backend, Database, and Real‑time Infrastructure

Even though I’m not writing a custom C# or Node API, I still had to wear the Backend Developer hat.

PostgreSQL & database design

I’m using Supabase, which means:

designing tables for things like orders, settings, subscriptions,
deciding how relations should work,
thinking about migrations and how to evolve the schema without breaking production.

This isn’t “just clicking in the UI”. It’s real database design.
Seven years of Angular didn’t prepare me for writing a schema that won’t bite me six months from now.

Real‑time WebSockets

In my orders.service.ts, the app subscribes to live database changes via something like:

this.supabase
  .channel('public:orders')
  .on('postgres_changes', { event: '*', schema: 'public', table: 'orders' }, ...)
  .subscribe();

This isn’t Angular magic.
It’s WebSockets, pub/sub, and real‑time event streams.

To use it well, you need to understand:

how channels work,
what happens when the network drops,
how to avoid memory leaks and duplicate subscriptions,
how to reconcile real‑time updates with local state.

Angular gives me Observables. Supabase gives me events.
But thinking through real‑time architecture? That’s on me.

Cloud storage

I’m handling file uploads (car photos, documents) to Supabase Storage buckets:

dealing with signed URLs,
thinking about public vs private buckets,
handling failures and retries,
understanding multipart form data and file sizes.

Again: none of this lives in angular/core.
It’s just the web.

Authentication & Row Level Security

Securing the database isn’t just “turn on auth”.

I’m writing PostgreSQL RLS policies so malicious users can’t:

query other people’s data,
bypass my frontend checks,
abuse the public endpoints.

That’s real backend security.
Angular can’t save you if your policies are wrong.

The Hard Truth: I Only Know Angular

Here’s the part I’m not proud of:

I only know Angular.
That’s it. No React, no Svelte, no mobile, no real backend stack.

Seven years in and I basically have one tool.

It’s a powerful tool. I’ve done serious work with it.
But it’s still one tool.

It didn’t really matter when I was:

embedded in big teams,
focused on one side of the stack,
operating inside someone else’s architecture.

It matters a lot when:

I’m building my own product,
I’m responsible for the entire experience,
there is no “backend team” to blame.

Right now, my own lack of broader web skills is a bottleneck in my own company.
And that’s a stupid place to be.

Even My Own Ecosystem Is Pushing Me Out

There’s another uncomfortable trend: Angular freelance opportunities are just fewer.

And the ones that do show up often look like this:

“Angular + .NET”
“Angular + Java Spring”
“Full‑stack Angular dev (C#, SQL)”

That’s not where I want to go. I don’t want to become a .NET or Java backend engineer just to keep using the one framework I know.

So even inside my own ecosystem, the market is basically saying:

Being very good at just Angular isn’t enough anymore.
Bring backend, mobile, or something else to the table.

At the same time, I’ve just started my own solo company:

building AI‑driven SaaS ,
offering automation consulting.

Both of those need:

web that isn’t always Angular,
mobile that definitely isn’t Angular.

Right now, I can’t do either outside of Angular without a fight.
That’s not a nice‑to‑have problem anymore. That’s a strategy risk.

I’m Not Ditching AI Tools — I’m Changing How I Use Them

There’s one more twist.

I use Claude Code and Antigravity heavily. And I’m going to keep using them.

They’re not the problem. In fact, they’re the reason I can:

move fast with Supabase,
scaffold endpoints,
debug RLS policies,
sketch non‑Angular architecture without spending months reading docs.

The problem is who’s driving.

There are two ways to use tools like Claude Code:

As the primary brain :
— “Write the schema for me.”
— “Design the RLS policies.”
— “Give me a Supabase + Angular architecture.”
You accept what it outputs, maybe tweak a bit, and move on.
As a turbocharger for your own thinking :
— You decide on the shape of the schema,
— you define the security model,
— you outline the architecture…
Then you ask the tool to implement, optimize, or challenge your idea.

Right now, in pure Angular land, I’m in group 2.
I know what “good” looks like. I use the tools to get there faster.

Outside Angular? I can feel myself slipping into group 1.
That’s dangerous.

I don’t want to be the founder who outsources the core architecture of his own SaaS to a chatbot.

What “Fixing My Stack” Actually Means

So when I say I want to “fix my stack fast”, I don’t mean:

memorizing every CSS property manually,
hand‑coding everything from scratch without help,
pretending I don’t have AI in my toolbox.

I mean something much more specific:

I want to understand web and backend fundamentals well enough
that Claude Code and Antigravity are implementation accelerators ,
not architecture substitutes.

Concretely, that means:

1. Owning my Supabase architecture

Designing tables and relations myself, then asking Claude to sanity‑check.
Writing my own RLS policies first, then asking the tool to fuzz them for edge cases.
Being able to explain why a real‑time channel is wired in a certain way, not just “because the docs said so.”

2. Treating frontend as “web”, not “only Angular”

Building some flows without Angular at all, just to refresh my mental model of the DOM and browser APIs.
Understanding what the browser is doing before Angular boots.
Caring about semantic HTML, accessibility, and CSS performance as much as I care about Signals and change detection.

3. Adding at least one non‑Angular delivery surface

My AI SaaS and automation consulting both need:

a marketing site,
a simple dashboard,
probably a mobile touchpoint at some point.

They don’t all need Angular.

I don’t need to become a React influencer overnight.
But I do need to be able to say:

“This one is better as a minimal, framework‑less page.”
“This one can be a simple React/Next client.”
“This is the part Angular is actually good for.”

4. Using AI to test my understanding, not replace it

For example:

I design a schema → ask Claude Code: “Where will this break in 6 months?”
I write a security policy → ask it to “think like an attacker and break it.”
I sketch a simple SPA without Angular → ask it to critique my state handling.

If I can’t independently evaluate the feedback, that’s a red flag.
That’s the gap I need to close.

Senior Means Being Bigger Than Your Framework

I still fix the Angular apps generalists break.
I still offer surgical Angular interventions as micro‑engagements.
I still like being the person you call when your 500‑line component is blocking an entire release.

But building my own AI‑driven SaaS forced me to admit something:

I became a senior operator of a single framework.
I didn’t become a senior web developer.

Seven years of Angular got me very far.
It paid well. It built my reputation. It opened doors.

Now it’s also the thing that can quietly cap my upside if I let it.

So this is the reboot:

keep Angular as my sharpest tool ,
rebuild my foundation as an actual web developer,
use Claude Code and Antigravity as force multipliers , not autopilots,
and make sure my own product doesn’t get blocked by the limits of my comfort zone.

If you’ve spent years living inside one framework, this isn’t an accusation.
It’s a status report from someone in the same position.

Your turn:

What part of your stack is quietly bottlenecking you — and are you driving your tools, or are they driving you?

I fix the Angular apps that generalists break.

Angular leverage declaration merging with Interfaces, how does it relate to the component metadata

Wed, 25 Mar 2026 15:00:20 +0000

First: What is Declaration Merging?

In TypeScript, declaration merging means:

Multiple declarations with the same name are combined into a single definition.

Example:

interface User {
  name: string;
}

interface User {
  age: number;
}

Becomes:

interface User {
  name: string;
  age: number;
}

Where Angular Uses This Concept

Angular doesn’t explicitly say “we use declaration merging here,” but it leverages the same idea indirectly in how it structures:

Component metadata typing
Decorator configuration (@Component, @Directive)
Extensible configuration interfaces

The Key Player: `Component` Metadata Interface

When you write:

@Component({
  selector: 'app-demo',
  template: `<p>Hello</p>`
})

That object is typed against an internal interface:

Component → extends Directive

Conceptually:

interface Directive {
  selector?: string;
}

interface Component extends Directive {
  template?: string;
  styles?: string[];
}

Where Declaration Merging Comes In

Angular’s design allows extending these interfaces across the framework and ecosystem.

Example (conceptual):

declare module '@angular/core' {
  interface Component {
    customFeatureFlag?: boolean;
  }
}

Now you can write:

@Component({
  selector: 'app-demo',
  template: `...`,
  customFeatureFlag: true
})

This works because:

TypeScript merges the interface
Angular’s metadata object accepts the new property

⚡ Important Clarification

Angular runtime does NOT automatically use your merged properties

TypeScript → allows it (compile-time)
Angular → ignores unknown metadata (runtime)

So this is mainly useful for:

Tooling
Custom decorators
Framework extensions

Real-World Use Case

1️⃣ Extending Component Metadata for Internal Frameworks

In large enterprise apps, teams sometimes build custom Angular abstractions.

Example:

declare module '@angular/core' {
  interface Component {
    permissions?: string[];
  }
}

Then:

@Component({
  selector: 'admin-panel',
  template: `...`,
  permissions: ['admin']
})

Now you can build:

Custom decorators
Build-time analyzers
Schematics

That read this metadata.

2️⃣ Custom Decorators on Top of `@Component`

You can wrap Angular decorators:

function SecureComponent(config: Component) {
  return function (target: any) {
    // read config.permissions
    Component(config)(target);
  };
}

Declaration merging ensures:

Your extended metadata is type-safe

Relation to Angular Internals

Angular itself uses a similar pattern:

Component extends Directive
Shared metadata is reused
Type system remains flexible

This is not classic “merging” inside Angular code, but:

It’s designed to support merging externally

⚠️ Limitations

Angular compiler ignores unknown fields
No runtime behavior unless you implement it
Not commonly used in small apps

Key Insight

Declaration merging enables extensible metadata typing, not runtime behavior.

Mental Model

Think of it like:

TypeScript → “You can add new fields”
Angular → “I’ll only use what I understand”

TL;DR

Angular metadata (@Component) is typed via interfaces
TypeScript declaration merging allows extending those interfaces
This enables:
- Custom metadata fields
- Better tooling
- Framework-level abstractions
But Angular runtime ignores unknown properties unless you handle them

If you're building enterprise Angular tooling or custom frameworks, this pattern becomes incredibly powerful.

Are you interested in learning these also follow to get more info!

How Angular compiler (ɵcmp) actually stores metadata
Or how to build a custom decorator that reads merged metadata

A Complete Guide to Angular Component Testing with Cypress

Tue, 24 Mar 2026 01:37:36 +0000

Angular's latest versions have introduced exciting features like signals, computed, and enhanced reactivity. Paired with Cypress Component Testing, developers now have a powerful toolkit to write fast, realistic, and robust tests. This post dives deep into Angular component testing using Cypress, including how to test components that use signals, observables, and mock services with confidence.

✨ Why Cypress for Angular Component Testing?

Cypress isn't just for end-to-end tests. With Cypress Component Testing, you can:

Render Angular components in isolation
Interact with them as a user would
Spy on inputs/outputs
Work seamlessly with Angular DI, modules, and modern features like signals

Setting Up Cypress Component Testing
Install Cypress and initialize component testing:

npm install cypress @cypress/angular --save-dev
npx cypress open --component

Follow the UI wizard to configure your Angular workspace. It will auto-generate a Cypress configuration compatible with Angular.

️ Example Component with Signals & Outputs

Let's test a simple CounterComponent that demonstrates:

Input binding
Output emission
Signals and computed values

// counter.component.ts
import { Component, Input, Output, EventEmitter, signal, computed } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <div>
      <h2>{{ title }}</h2>
      <p>Count: {{ count() }}</p>
      <button (click)="increment()">Increment</button>
      <button (click)="reset()">Reset</button>
      <p>Double: {{ doubleCount() }}</p>
    </div>
  `
})
export class CounterComponent {
  @Input() title = 'Default Counter';
  @Output() onReset = new EventEmitter<void>();

  private _count = signal(0);
  count = this._count.asReadonly();
  doubleCount = computed(() => this._count() * 2);

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

  reset() {
    this._count.set(0);
    this.onReset.emit();
  }
}

Basic Cypress Tests

✅ Rendering with Default and Custom Inputs

// counter.component.cy.ts
import { mount } from 'cypress/angular';
import { CounterComponent } from './counter.component';

describe('CounterComponent', () => {
  it('renders with default title', () => {
    mount(CounterComponent);
    cy.contains('Default Counter');
    cy.contains('Count: 0');
  });

  it('accepts custom title', () => {
    mount(CounterComponent, {
      componentProperties: { title: 'Custom Counter' }
    });
    cy.contains('Custom Counter');
  });
});

⚖️ Testing Signals and Computed Values

it('increments count and updates double', () => {
  mount(CounterComponent);
  cy.get('button').contains('Increment').click().click();
  cy.contains('Count: 2');
  cy.contains('Double: 4');
});

Spying on Output Events

it('emits reset event', () => {
  const resetSpy = cy.spy().as('resetSpy');

  mount(CounterComponent, {
    componentProperties: {
      onReset: { emit: resetSpy } as any
    }
  });

  cy.get('button').contains('Reset').click();
  cy.get('@resetSpy').should('have.been.calledOnce');
});

Testing with Observables

// message.component.ts
@Component({
  selector: 'app-message',
  template: `<p *ngIf="message">{{ message }}</p>`
})
export class MessageComponent {
  private _message = signal('');
  message = this._message.asReadonly();

  @Input()
  set messageInput$(value: Observable<string>) {
    value.subscribe(msg => this._message.set(msg));
  }
}
it('renders observable message', () => {
  const message$ = of('Hello from Observable!');
  mount(MessageComponent, {
    componentProperties: { messageInput$: message$ }
  });
  cy.contains('Hello from Observable!');
});

Advanced Mocking Techniques

⚙️ Injecting Angular Services

class MockLoggerService {
  log = cy.stub().as('logStub');
}

mount(MyComponent, {
  providers: [
    { provide: LoggerService, useClass: MockLoggerService }
  ]
});

Mocking HTTP Calls with HttpClientTestingModule

import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';

beforeEach(() => {
  cy.intercept('GET', '/api/data', { fixture: 'data.json' });
});

mount(MyHttpComponent, {
  imports: [HttpClientTestingModule]
});

Stubbing Child Components

@Component({
  selector: 'app-child',
  template: '' // stubbed template
})
class StubChildComponent {}

mount(ParentComponent, {
  declarations: [StubChildComponent]
});

Conclusion

Cypress Component Testing is a game-changer for Angular developers. By combining the real browser testing experience with Angular’s new reactivity features like signals and computed, we can create robust, testable, and modern UIs.

Key Takeaways:

Mount Angular components with Cypress easily
Test signals, computed, observables
Use spies and stubs for robust unit isolation
Mock services and HTTP with Angular-friendly tooling

Angular Signals vs Observables: A Deep Dive into Modern Reactivity

Tue, 24 Mar 2026 01:36:58 +0000

With the release of Angular 16, the framework introduced a powerful new reactive primitive: signals. Signals provide a new way to manage reactivity in your applications, enabling more predictable and efficient UI updates. But how do they compare with the well-established observables? When should you use one over the other? And how do features like computed() come into play?

In this post, we’ll explore Angular signals in depth, compare them with observables, and provide practical use cases to guide your decision-making.

What Are Angular Signals?

Signals are reactive values that notify dependents when their value changes. They are designed to be synchronous, fine-grained, and easy to use.

A signal is created using the signal() function and acts as a state container:

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

const count = signal(0);

console.log(count());   // Reading value: 0
count.set(5);           // Setting value
count.update(c => c + 1); // Updating value: 6

Key Characteristics:

Synchronous: Reading a signal gives you its value immediately.
Dependency Tracking: When used inside a computed signal or an effect, it registers itself as a dependency.
Reactive: Automatically propagates changes to anything that depends on it.

Using `computed()` with Signals

One of the most powerful aspects of signals is the computed() function. It allows you to create derived signals, similar to computed properties in other reactive frameworks like Vue.js.

import { signal, computed } from '@angular/core';

const price = signal(100);
const quantity = signal(2);

const total = computed(() => price() * quantity());

console.log(total()); // Output: 200

quantity.set(3);
console.log(total()); // Output: 300

The computed signal automatically recalculates when any of its dependencies change. No manual subscriptions are needed.

Signals vs Observables

Let’s compare Angular signals with RxJS observables across different dimensions:

When to Use Signals

✅ Use Signals When:

Managing local UI state (e.g. toggle, counters, forms)
Creating computed values that derive from other signals
You need fine-grained change detection (only dependent parts re-render)
You want simpler and more declarative reactivity

Example: Component-local state

@Component({
  selector: 'app-counter',
  template: `
    <button (click)="increment()">Add</button>
    <p>Count: {{ count() }}</p>
  `
})
export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(c => c + 1);
  }
}

Avoid Signals When:

You’re dealing with asynchronous data (e.g. HTTP requests, WebSocket streams)
You need to compose multiple async streams using RxJS operators (mergeMap, switchMap, etc.)
You’re integrating with libraries heavily based on RxJS

When to Use Observables

✅ Use Observables When:

Working with asynchronous streams (e.g. user inputs, API responses)
Using RxJS operators to transform streams
Handling event-based programming (e.g. WebSockets, form events)
Managing global app state with side effects (e.g. NgRx)

Example: Async HTTP data

@Component({
  selector: 'app-data',
  template: `
    <ng-container *ngIf="data$ | async as data">
      <p>{{ data.title }}</p>
    </ng-container>
  `
})
export class DataComponent {
  data$ = this.http.get('/api/data');

  constructor(private http: HttpClient) {}
}

Interoperability: Signals and Observables

Angular provides utility functions to convert between signals and observables:

toSignal() – Observable to Signal

import { toSignal } from '@angular/core/rxjs-interop';

const signalFromObservable = toSignal(myObservable$, { initialValue: null });

toObservable() – Signal to Observable

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

const observableFromSignal = toObservable(mySignal);

This enables seamless integration of both paradigms.

Use Case Summary

Final Thoughts

Signals represent a shift toward synchronous, declarative state management in Angular. While Observables will always have a place—especially for async operations—signals make state management in UI components much simpler and more intuitive.

Use signals for local, synchronous UI state and computed values. Use observables for asynchronous workflows and complex stream operations. And when needed, bridge the two with Angular’s interop utilities.

The future of Angular is signal-first but observables aren’t going anywhere. Choosing the right tool for the job is key.

Creative Ways to Leverage JavaScript Frameworks for Modern Development

Sat, 14 Feb 2026 07:33:52 +0000

Introduction

As a JavaScript developer, you know that libraries and frameworks provide powerful tools for building applications. However, tapping into their full potential often requires thinking outside the box. Let's explore some innovative ways to leverage frameworks like React, Vue, and Angular.

1. Component Reusability

Instead of building every new feature from scratch, focus on creating highly reusable components.

Example: Suppose you're developing an e-commerce site. Create a generic ProductCard component that can adapt to different product types by passing props, simplifying future updates and feature additions.

2. Custom Hooks in React

Custom hooks can significantly streamline your code and improve maintainability. You can encapsulate common logic into hooks.

Example: If multiple components need to fetch user data, develop a useFetchUser hook that handles fetching, loading, and error states. This keeps components clean and promotes logic reuse.

3. Vue Mixins for Shared Functionality

While Vue has a robust composition API, mixins are still a potent tool for sharing functionality across components.

Example: Create a mixin that includes validation methods. This can simplify form controls across various components, ensuring consistency and reducing duplication.

4. Angular Schematics

Angular's schematics allow you to automate the creation of components, services, and more. This feature improves efficiency by generating boilerplate code.

Example: Customize schematics for your app, so when you generate a new component, it automatically includes CSS styles, tests, and related files. This drastically reduces setup time.

5. State Management through Context API

For small to medium apps, you might not need a heavy state management library like Redux. Instead, consider using the Context API to manage state effectively without the overhead.

Example: Build a simple global store for user authentication status, which can be easily accessed across components without prop drilling.

6. Progressive Web Apps with Frameworks

Both React and Vue support PWA features enabling you to create fast, reliable apps.

Example: Use Create React App’s built-in PWA support to enhance your web app, making it installable and improving performance metrics.

Conclusion

By adopting these unconventional techniques in your JavaScript projects, you can streamline your workflow and develop high-quality applications more efficiently. Don’t hesitate to mix and match practices from different frameworks to find what works best for your needs.

Share your thoughts on these strategies or suggest other creative approaches you've implemented.

Getting Started with Angular Toolbar

Thu, 12 Feb 2026 01:37:37 +0000

You're building an internal business application. Your QA team needs to test what an Admin sees versus a regular user. Your stakeholder wants to demo the new dashboard that's still behind a feature flag. And IT wants to verify that the "Bulk Export" feature is properly gated to licensed users only.

Three requests. Normally, that's three database changes, three test accounts, and a lot of context switching.

Or... you could just use the Angular Toolbar.

In the previous article, we introduced ngx-dev-toolbar and why it's useful for internal business applications. Now let's get it running and set up Feature Flags, Permissions, and App Features—the three tools that make testing different scenarios instant.

Quick Setup

Initialize the toolbar in your main.ts:

import { bootstrapApplication } from '@angular/platform-browser';
import { isDevMode } from '@angular/core';

async function bootstrap() {
  const appRef = await bootstrapApplication(AppComponent, appConfig);

  if (isDevMode()) {
    const { initToolbar } = await import('ngx-dev-toolbar');
    initToolbar(appRef);
  }
}

bootstrap();

The dynamic import ensures zero production bundle impact—the toolbar code only loads in development.

How It Works

All three tools work the same way:

Register your options with setAvailableOptions()
Read the values with getValues()

The toolbar stores any overrides in localStorage, so they persist across page reloads. When you read values with getValues(), you get your original values with any toolbar overrides already applied.

Feature Flags

Remember that new dashboard your stakeholder wants to demo? That's a feature flag. Let's wire it up.

//  feature-flags.service.ts
import { ToolbarFeatureFlagService } from 'ngx-dev-toolbar';

@Injectable({ providedIn: 'root' })
export class FeatureFlagsService {
  private toolbarService = inject(ToolbarFeatureFlagService);

  //  Real flag values from your flag provider
  private realFlags = toSignal(
    this.flagProvider.getFlags(),
    { initialValue: [] }
  );

  //  All flags with toolbar overrides already applied
  private flags = toSignal(
    this.toolbarService.getValues(),
    { initialValue: [] }
  );

  constructor() {
    // Register flags with the toolbar when they load
    effect(() => {
      const flags = this.realFlags();
      if (flags.length) {
        this.toolbarService.setAvailableOptions(
          flags.map(f => ({
            id: f.key,
            name: f.name,
            description: f.description,
            isEnabled: f.value,
          }))
        );
      }
    });
  }

  getFlag(id: string): Signal<boolean> {
    return computed(() => {
      const flag = this.flags().find(f => f.id === id);
      return flag?.isEnabled ?? false;
    });
  }
}

The getValues() method returns all flags with any toolbar overrides already merged in—no manual merging required.

Your flag provider might return data in a different format than the toolbar expects. You can map the values when registering:

// LaunchDarkly returns: { key: 'dark-mode', value: true }
// Toolbar expects: { id, name, description, isEnabled }

this.toolbarService.setAvailableOptions(
  flags.map(f => ({
    id: f.key,                     // key → id
    name: this.formatName(f.key),  // 'dark-mode' → 'Dark Mode'
    description: this.descriptions[f.key],
    isEnabled: f.value,            // value → isEnabled
  }))
);

Use it in your components:

//  dashboard.component.ts
@Component({...})
export class DashboardComponent {
  private featureFlagsService = inject(FeatureFlagsService);

  showNewDashboard = this.featureFlagsService.getFlag('new-dashboard');
}

@if (showNewDashboard()) {
  <app-new-dashboard />
} @else {
  <app-classic-dashboard />
}

Permissions

Now for that QA scenario—testing what an Admin sees versus a regular user. That's all about permissions.

Permissions work the same way as feature flags, but with three possible states: original value, forced granted, or forced denied.

For permissions, you might want more control over how overrides are applied. Instead of getValues(), you can use getForcedValues() which returns only the permissions that were overridden in the toolbar:

//  permissions.service.ts
import { ToolbarPermissionsService } from 'ngx-dev-toolbar';

@Injectable({ providedIn: 'root' })
export class PermissionsService {
  private toolbarService = inject(ToolbarPermissionsService);

  //  Real permissions from your auth backend
  private realPermissions = toSignal(
    this.authService.getPermissions(),
    { initialValue: [] }
  );

  //  Only the permissions overridden in the toolbar
  private forcedPermissions = toSignal(
    this.toolbarService.getForcedValues(),
    { initialValue: [] }
  );

  constructor() {
    // Register permissions with the toolbar
    effect(() => {
      const perms = this.realPermissions();
      if (perms.length) {
        this.toolbarService.setAvailableOptions(
          perms.map(p => ({
            id: p.id,
            name: p.name,
            isGranted: p.granted,
          }))
        );
      }
    });
  }

  hasPermission(id: string): Signal<boolean> {
    return computed(() => {
      //  Check toolbar override first
      const forced = this.forcedPermissions()
        .find(p => p.id === id);
      if (forced) return forced.isGranted;

      //  Fall back to real permission
      const real = this.realPermissions().find(p => p.id === id);
      return real?.granted ?? false;
    });
  }
}

This pattern gives you explicit control: real values from your backend, with toolbar overrides layered on top only when set.

getValues() vs getForcedValues()

Both methods work, but serve different needs:

getValues() — Returns all options with overrides already applied. Simpler to use when you want the toolbar to manage everything.
getForcedValues() — Returns only the options that were manually overridden. Use this when your backend is the source of truth and you want to explicitly layer toolbar overrides on top.

Choose getValues() for simpler integrations. Choose getForcedValues() when you need to preserve the distinction between real values and test overrides.

App Features

And finally, that "Bulk Export" feature IT wants to verify? That's a license-gated app feature.

App Features are perfect for testing subscription tiers and license-based functionality:

//  app-features.service.ts
import { ToolbarAppFeaturesService } from 'ngx-dev-toolbar';

@Injectable({ providedIn: 'root' })
export class AppFeaturesService {
  private toolbarService = inject(ToolbarAppFeaturesService);

  //  Real features from your licensing backend
  private realFeatures = toSignal(
    this.licensingService.getFeatures(),
    { initialValue: [] }
  );

  private features = toSignal(
    this.toolbarService.getValues(),
    { initialValue: [] }
  );

  constructor() {
    effect(() => {
      const features = this.realFeatures();
      if (features.length) {
        const options = features.map(f => ({
          id: f.id,
          name: FEATURE_METADATA[f.id]?.name ?? f.id,
          description: FEATURE_METADATA[f.id]?.description,
          isEnabled: f.enabled,
        }));
        this.toolbarService.setAvailableOptions(options);
      }
    });
  }

  isEnabled(id: string): Signal<boolean> {
    return computed(() => {
      const feature = this.features().find(f => f.id === id);
      return feature?.isEnabled ?? false;
    });
  }
}

Did you notice the FEATURE_METADATA mapping? Your licensing API typically returns just feature IDs and enabled status—no user-friendly names or descriptions. We added both name (to control how it appears in the toolbar) and description locally:

//  app-features.models.ts
export enum Feature {
  Analytics = 'analytics',
  BulkExport = 'bulk-export',
  WhiteLabel = 'white-label',
  Notifications = 'notifications',
  ApiAccess = 'api-access',
}

export const FEATURE_METADATA: Record<
  string,
  { name: string; description: string }
> = {
  [Feature.Analytics]: {
    name: 'Analytics Dashboard',
    description: 'Advanced reporting and visualization',
  },
  [Feature.BulkExport]: {
    name: 'Bulk Export',
    description: 'Export datasets to CSV or Excel',
  },
  [Feature.WhiteLabel]: {
    name: 'White Label',
    description: 'Custom branding with your logo',
  },
  [Feature.Notifications]: {
    name: 'Notifications',
    description: 'Real-time push notifications',
  },
  [Feature.ApiAccess]: {
    name: 'API Access',
    description: 'REST API for integrations',
  },
};

This keeps your feature definitions type-safe and your descriptions in one place.

Now you can test what users on different subscription tiers see—without touching the database.

Combining for Realistic Scenarios

Here's where it all comes together.

Remember those three requests from the beginning? With the toolbar set up, you can handle all of them without touching the database. Toggle the new dashboard flag for the demo. Grant "can-admin" permission to simulate an admin user. Enable "Bulk Export" to verify the license gate.

The real power comes when you combine all three tools. Want to test what an "Admin with Enterprise license" sees? Enable the app features and grant the permissions. Testing a "Regular user on Basic tier"? Adjust accordingly.

In the next article, we'll see how to save these combinations as Presets—so you can switch between user personas with a single click.

What's Next

Now that you know how to use the built-in tools, check out the next article on Presets to learn how to save and share your configurations with your team.

Happy developing!

Angular Signals Explained

Sun, 25 Jan 2026 06:01:39 +0000

What Are Angular Signals?

Signals are a new reactive primitive in Angular for managing state.

At a high level:

A signal holds a value
Angular tracks where that value is read
When the value changes, Angular updates only what depends on it

No subscriptions. No manual cleanup. No async pipe.

Signals were introduced in Angular 16 and refined further in Angular 17+.
If you’re using Angular 16 or later, you can start using them today.

Why Should You Use Angular Signals?

Signals exist to solve some very real pain points in everyday Angular development.

Why they’re nice:

Less boilerplate
No Subject, BehaviorSubject, or .subscribe()
Automatic change detection
Angular knows exactly what needs to update
Better performance by default
Fewer unnecessary re-renders
Simpler mental model
State updates are synchronous and explicit
Great for UI state
Counters, toggles, filters, loading flags, selections

If you’ve ever thought:

“This feels like too much code for a simple counter…”

Signals are probably what you’re looking for.

A Simple Real-World Example: Cart Item Count

Let’s keep this very real.

Problem:

You want to show how many items are in a shopping cart and update the UI when users add or remove items.

This is a perfect use case for signals.

Step 1: Create a Service Using Signals

import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class CartService {
  cartCount = signal(0);

  addItem() {
    this.cartCount.update(count => count + 1);
  }

  removeItem() {
    this.cartCount.update(count => Math.max(0, count - 1));
  }
}

What’s happening here:

signal(0) creates a reactive state value

update() changes the value

Angular automatically tracks where cartCount is used

No RxJS. No subscriptions.

Step 2: Use the Signal in a Component

import { Component } from '@angular/core';
import { CartService } from './cart.service';

@Component({
  selector: 'app-cart',
  template: `
    <h3> Cart Items: {{ cartService.cartCount() }}</h3>
    <button (click)="cartService.addItem()">Add Item</button>
    <button (click)="cartService.removeItem()">Remove Item</button>
  `
})

export class CartComponent {
  constructor(public cartService: CartService) {}
}

Key things to notice:

Signals are read like functions → cartCount()

No async pipe
No ngOnDestroy
No manual change detection

Angular updates the UI automatically when the signal changes.

When You Should Not Use Signals

Signals are powerful but they’re not a replacement for everything.

Avoid signals when:

You’re working with event streams
WebSockets
Live search with debouncing
Continuous user input
You rely heavily on RxJS operators
switchMap, merge, retry, debounceTime
You’re managing complex global state
Large apps may still benefit from NgRx or similar libraries

A good rule of thumb:

Signals are great for state. RxJS is great for events. They work best together, not as competitors.

Conclusion

Angular signals make simple things simple again.

They’re especially useful for:

Local component state
Shared service state
UI flags and counters
Cleaner, more readable templates

If you’re already on Angular 16+, try signals in a small feature first and build from there. You don’t have to rewrite everything - signals fit nicely alongside existing RxJS patterns.

How I Build SEO-Friendly Angular Applications in Real Projects

Mon, 19 Jan 2026 21:28:06 +0000

Why Did My “Perfect” Angular App Fail on Google?

A few years ago, I launched what I thought was a perfect Angular app. It was fast. The UI looked clean. The codebase was organized. My client loved it.

Then… silence

There was no organic traffic. I barely saw any impressions in the Search Console. Pages that should have ranked didn’t exist in Google’s view.

That moment forced me to ask a painful question: “Is Angular bad for SEO, or am I building it the wrong way?”

Spoiler: Angular isn’t the issue. The way we use it often is.

In this article, I’ll share how I build SEO-friendly Angular applications in real projects. I’ll explain what works, what failed, and what I now do differently. This isn’t just theory or marketing advice. It’s based on real experience from debugging, client pressure, and many experiments.

If you’re involved in Angular development or work with Angular developers, this might save you months of trial and error.

The Early Mistake: Treating Angular Like a Traditional Website

When I first started building Angular apps, I approached them like classic SPAs:

Client-side rendering only
Heavy reliance on JavaScript
No server-side strategy
Minimal meta handling

Technically, it worked. From a user perspective, it felt great. But search engines faced challenges.

Google can now render JavaScript, but it doesn't always do so quickly, reliably, or at scale. Angular developers pay close attention to this. Other search engines are even slower. Some pages load empty, metadata is often missing, and crawling budgets get wasted.

That’s when I realized: SEO has to be part of the architecture, not an afterthought.

Step 1: Choosing the Right Rendering Strategy

The biggest change I ever made was switching from pure client-side rendering to a hybrid model. Now, I use Angular Universal in almost every production project.

Why?

Because server-side rendering gives search engines:

Fully rendered HTML
Instant access to content
Correct meta tags
Faster perceived load time

In real projects, I’ve seen:

Faster indexing
Higher crawl rates
Better initial rankings

It doesn’t mean everything must be SSR. But at least your:

Landing pages
Blog pages
Product pages

Should be server-rendered. This one change alone fixed about 60% of my SEO problems.

Step 2: Routing Like an SEO Engineer (Not Just a Developer)

Angular routing is powerful, but dangerous if misused.

Early on, I made mistakes like:

Deep nested routes with no structure
Inconsistent URLs
Parameters everywhere
No canonical handling

Now, I follow a few strict rules:

Clean, Human-Readable URLs

I avoid:

IDs in primary URLs
Excessive query params
Random path segments

Instead:

/blog/angular-seo-guide

/products/cloud-hosting

Search engines understand them. Users trust them.

Route-Based Preloading
For important pages, I:

Preload critical routes
Avoid lazy-loading SEO pages too aggressively

Performance still matters, but discoverability matters more.

Step 3: Meta Tags Are Not Optional (They’re Architecture)

One of the biggest misconceptions I see among Angular Developers is:

“Google will figure out my titles and descriptions.”

Sometimes it does. Often, it doesn’t.

Now, every SEO-critical page has:

Unique title
Custom description
Proper Open Graph data
Canonical URL

I manage metadata using Angular’s Meta and Title services. I do this for each route, not globally. A real lesson from production: Duplicate titles ruined one client’s entire category section until we fixed the dynamic meta generation. Metadata isn’t just decoration; it matters for structure.

Step 4: Content Rendering Strategy (This Is Where SEO Is Won or Lost)

Here’s a mistake I made several times: Rendering content after user interaction or API delay. From a crawler’s perspective, that content didn’t exist.

Now, I follow one rule:

If it must rank, it must exist in the initial HTML.

That means:

Pre-render critical text
Avoid hiding SEO content behind interactions
Render headings and main copy server-side

I still load dynamic features later, but content comes first.

This single principle has saved multiple projects.

Step 5: Performance Is SEO (Whether We Like It or Not)

Angular apps can become heavy quickly. In one project, everything performed well until the Core Web Vitals updates were released. Traffic fell overnight.

Since then, performance is part of my SEO workflow:

What I always optimize:

Bundle splitting
Tree shaking
Critical CSS
Image lazy loading
Font preloading

And I track:

LCP
CLS
TTFB

Search engines reward fast experiences. Users demand them.

In modern Angular Development, performance tuning is no longer optional; it’s SEO engineering.

Step 6: Structured Data Is My Secret Weapon

This is something many teams skip.

I add structured data wherever it makes sense:

Articles
FAQs
Products
Breadcrumbs

Why?

Because:

It improves click-through rates
Enables rich results
Helps search engines understand context

In one blog project, adding FAQ schema increased impressions by 40% without changing rankings. It was a small change that had a big impact.

Step 7: Handling Indexing, Crawling, and Real-World Edge Cases

Real projects always bring edge cases.

Here’s what I now standardize in every Angular SEO setup:

Sitemap Generation
Dynamic routes? I generate sitemaps from the backend or prerender build.

Robots & Headers
I:

Avoid blocking JS and CSS
Control indexing via headers, not just robots.txt

Pagination & Filtering
For filters:

Canonical main category
Noindex parameter-heavy pages

Without this, crawl budgets explode.

Step 8: Working With Designers and Clients (The Human Side of SEO)

Here’s the part nobody talks about. SEO in Angular struggles not due to the code, but because of communication. Designers want animations. Clients want infinite scrolling. Product teams want everything to be dynamic.

Now, I explain early:

Which pages must be crawlable?
What content must load first?
Where interaction is safe

When everyone understands the SEO layer, it makes decisions easier. I wish I had learned that sooner.

What I’ve Learned After Multiple SEO-Focused Angular Projects

After several production systems, here’s my honest takeaway:

Angular is not bad for SEO
Poor architecture is
Server rendering is essential
Content strategy matters more than frameworks
Performance wins long-term

And most importantly, SEO-friendly Angular apps are built intentionally, not by chance. This change in thinking has transformed how I tackle each new project.

Conclusion: SEO in Angular Is Engineering, Not a Plugin

If there’s one thing I’d leave you with, it’s this:

SEO-friendly Angular applications aren’t built with tools alone; they’re built with intent.
From routing and rendering to content and performance, every decision affects how search engines view your product.

For anyone involved in Angular development or working with skilled Angular developers, focusing on SEO early can save money, rankings, and sanity down the road.

Angular can work well for SEO if you understand how the web functions.

And Once you grasp this, Google stops being your enemy and begins to be your biggest source of traffic.

Frequently Asked Questions (FAQs)

1. Is Angular bad for SEO?

No. Angular works well for SEO when server-side rendering, proper routing, and metadata handling are implemented correctly.

2. Do I need Angular Universal for SEO?

In most real-world projects, yes. Server-side rendering significantly improves indexing, crawl efficiency, and performance.

3. Can Google index client-side Angular apps?

Google can, but it’s slower and less reliable. SSR ensures consistent and faster indexing.

4. How important are meta tags in Angular apps?

Very important. Without proper meta handling, pages often lose rankings or appear incorrectly in search results.

5. What is the biggest SEO mistake in Angular projects?

Relying entirely on client-side rendering and loading important content after JavaScript execution.

Integrating Angular with AI & Machine Learning using Google Cloud APIs

Sun, 14 Dec 2025 06:52:50 +0000

A Practical Guide Using Google Cloud APIs

Artificial Intelligence is no longer a “future feature.” Today, modern frontends — including Angular applications — integrate AI capabilities such as text generation, image labeling, translation, sentiment analysis, and voice recognition.

Google Cloud offers one of the most developer-friendly AI ecosystems with production-ready APIs that Angular apps can consume securely and efficiently.

In this blog, we’ll explore how to integrate Angular with Google Cloud’s AI/ML services, recommended architecture, real-world examples, and best practices for secure production deployments.

Why Bring AI into Angular Applications?

AI-powered features significantly enhance the user experience:

Automatic document analysis
️ Image labeling and moderation
Language translation
️ Speech-to-text & text-to-speech
✨ Generative AI (content generation, summarization, embeddings)
Intelligent form validation and fraud detection

Angular’s modular architecture, strong typing, and interceptors make it perfect for building scalable AI-powered frontends.

️ Architecture Overview: Angular + Google Cloud AI

Here’s the recommended production-friendly architecture:

Angular App
   |
   |  HTTPS Requests
   v
Backend API (Node.js / Firebase Functions / Cloud Run)
   |
   |  Authenticated Server-to-Server Calls
   v
Google Cloud AI Services

Why NOT call Google Cloud AI directly from Angular?

❌ Exposing your API keys is a major security risk.
❌ Some APIs require service account authentication.
❌ Rate-limiting and payload size must be handled server-side.

Solution

Use Angular → Your Backend → Google AI → Response back to Angular.

⚙️ Step 1: Choose Your Google Cloud AI Services

Here are the most popular ones for Angular projects:

1. Vertex AI (Generative AI APIs)

Text generation (LLMs)
Chat completion
Embeddings
Image generation
Code generation

️ 2. Vision API

Image labeling
OCR (text detection)
Face & landmark recognition
Safe search filtering

3. Translation API

Multi-language translation
Language detection

️ 4. Speech-to-Text / Text-to-Speech APIs

⚙️ Step 2: Set Up Backend to Connect with Google AI

You can use:

Express.js
NestJS
Firebase Cloud Functions
Cloud Run

Example: Using Node.js + Vertex AI

Install Google AI SDK:

npm install @google-cloud/ai

Backend example (ai.controller.ts):

import { TextServiceClient } from "@google-cloud/ai";

const client = new TextServiceClient({
  projectId: "your-project-id",
  location: "us-central1"
});

export async function generateText(prompt: string) {
  const result = await client.generateText({
    model: "gemini-1.5-flash",
    prompt: { text: prompt }
  });

  return result.outputText;
}

Create an API endpoint:

app.post("/api/ai/generate", async (req, res) => {
  const { prompt } = req.body;
  const output = await generateText(prompt);
  res.json({ output });
});

⚙️ Step 3: Consume Google AI from Angular

Create an Angular service:

@Injectable({ providedIn: 'root' })
export class AiService {
  private apiUrl = '/api/ai';

  constructor(private http: HttpClient) {}

  generateText(prompt: string) {
    return this.http.post<{ output: string }>(
      `${this.apiUrl}/generate`,
      { prompt }
    );
  }
}

Use it inside a component:

@Component({
  selector: 'app-ai-demo',
  template: `
    <textarea [(ngModel)]="prompt"></textarea>
    <button (click)="askAI()">Ask AI</button>

    <div *ngIf="response">
      <h3>AI Response:</h3>
      <p>{{ response }}</p>
    </div>
  `
})
export class AiDemoComponent {
  prompt = '';
  response = '';

  constructor(private ai: AiService) {}

  askAI() {
    this.ai.generateText(this.prompt).subscribe(res => {
      this.response = res.output;
    });
  }
}

Real-World AI Use Cases in Angular Applications

Use Case 1: ️ Image Labeling (Vision API)

Perfect for:

E-commerce product uploads
Social media content moderation
Insurance document processing

Backend:

import vision from "@google-cloud/vision";

const client = new vision.ImageAnnotatorClient();

export async function analyzeImage(base64: string) {
  const [result] = await client.labelDetection({
    image: { content: base64 }
  });
  return result.labelAnnotations;
}

Angular:

uploadAndAnalyze(file: File) {
  const reader = new FileReader();
  reader.onload = () => {
    this.http.post('/api/vision', { image: reader.result })
      .subscribe(console.log);
  };
  reader.readAsDataURL(file);
}

Use Case 2: Realtime Language Translation

translate(text: string, target: string) {
  return this.http.post('/api/translate', { text, target });
}

Integration uses the Translation API:

Perfect for multilingual apps
Chat translation
Global user base

Use Case 3: Generative AI Assistant Using Vertex AI

Create your own:

chatbot
customer service bot
document summarizer
content generator

Example prompt:

this.ai.generateText("Explain Angular signals like I'm 12.")

Security Best Practices for AI in Angular

✔ Never expose Google Cloud API keys in Angular
✔ Use service accounts on backend only
✔ Enable quotas & monitoring
✔ Validate all image/file input
✔ Use Firebase App Check for public APIs
✔ Rate-limit AI endpoints

⚡ Bonus: Add Caching for Faster Results

LLM and image recognition calls can be expensive.

Use caching:

Redis
Cloud Memorystore
Cloud CDN
In-memory cache for deterministic prompts

Final Thoughts

AI supercharges Angular applications — and Google Cloud provides the APIs to make it production-ready. By using a secure backend, Angular apps can safely access AI models for:

Generating content
Analyzing documents & images
Translating text
Enhancing user interactions

Once you adopt this pattern, integrating new AI features becomes as easy as adding new endpoints.

AI assisted development workflows in angular

Thu, 11 Dec 2025 12:53:39 +0000

AI-assisted development workflows in Angular significantly boost developer productivity, enforce best practices, and automate repetitive tasks. These workflows treat the AI model (like Gemini or GitHub Copilot) as a context-aware developer partner that deeply understands Angular's architecture, conventions, and modern features like Standalone Components and Signals.

There are two primary ways AI assists Angular development: Code Generation/Automation and Contextual Guidance.

✍️ 1. AI for Code Generation and Automation

AI tools and assistants integrated into the developer environment (IDE, CLI) reduce boilerplate and accelerate the creation of Angular artifacts.

A. Component and Service Scaffolding

Rapid Generation: AI can instantly generate entire Angular artifacts (components, services, pipes, directives) from a single prompt, including the .ts, .html, and .css files.
Best Practice Adherence: By providing the AI with a Prompt Guide (a file that defines your team's style and Angular's official rules), the generated code automatically adheres to modern best practices like:
- Using Standalone Components (standalone: true).
- Employing Signals for state instead of BehaviorSubject for simple state.
- Using the inject() function for dependency injection instead of the constructor.
- Implementing Typed Forms for type safety.
Contextual Logic: The AI can generate the component's template logic (e.g., using @for loops, @if blocks) and the component's TypeScript logic (e.g., fetching data using HttpClient within a service) based on the prompt.

B. Testing and Refactoring

Automated Unit Test Generation: AI can analyze a generated or existing component/service and automatically create corresponding Jasmine/Karma unit tests with correct mocks (like HttpClientTestingModule).
Multi-File Refactoring: The AI agent can manage changes across multiple files for a single feature. For example, a single prompt to "change the User model to include an address object" could simultaneously update:
1. The user.interface.ts file.
2. The user.service.ts to handle the new API response.
3. The user-profile.component.ts to use the new property.
4. The user-profile.component.html to display the new address.

C. Design-to-Code and Prototyping

Visual-to-Code: Platforms can use AI to convert designs created in tools like Figma into clean, production-ready Angular code, significantly reducing the gap between design and development.
Rapid App Generation: Tools integrated with models like Gemini can generate an entire application structure and baseline features from a single, high-level prompt (e.g., "Create an e-commerce dashboard with user authentication and a product list table").

2. Contextual Guidance and Architectural Support

Modern AI assistants can be integrated to understand the entire Angular project structure, enabling more accurate and strategic suggestions.

A. Model Context Protocol (MCP) Server

New integrations, such as the Angular team's support for the Model Context Protocol (MCP) Server, allow AI assistants to communicate directly with the Angular CLI and codebase. This provides the AI with:

Project Awareness: The ability to read angular.json to know the project structure, libraries, and available applications.
Tooling Access: The ability to use functions like get_best_practices or search_documentation to ensure suggestions are current and correct.
Consistent Architecture: The AI can recognize and follow a team's monorepo architecture (e.g., in an Nx workspace), ensuring new code is placed in the correct feature, data-access, or ui library.

B. Conversational Development and Tutoring

AI Tutors: Tools can be configured to act as an interactive Angular Tutor, guiding developers step-by-step through building a feature. They can check the developer's code against the expected solution and offer hints or detailed instructions.
Debugging and Explanation: When encountering complex code or an unfamiliar file, the developer can ask the AI to "explain this component's lifecycle and inputs," which is invaluable for onboarding new team members or dealing with legacy code.

️ Best Practices for AI-Assisted Angular Coding

To maximize the benefits of AI assistance in an Angular project while maintaining code quality, developers should adopt AI-Assisted Coding over "vibe coding":

Principle	Description
Small, Scoped Prompts	Instead of "Build the whole user feature," use "Create the `UserProfileCard` dumb component using Signals inputs" followed by "Generate unit tests for that component."
Enforce Architecture	Use Prompt Guides (`llms.txt` or similar files) to explicitly tell the AI to use Standalone Components, the Facade Pattern, and your team's naming conventions.
Secure API Keys	Never embed AI API keys (like Gemini or OpenAI keys) directly in the Angular frontend (client-side code). Always route requests through a secure backend proxy (e.g., a Firebase Function or Cloud Run service) to protect credentials.
Human in the Loop	AI-generated code must be reviewed and tested just like human-written code. The developer's role shifts from writing boilerplate to architectural design and code verification.

Let’s stay connected:

Instagram: https://www.instagram.com/angular_development/

Facebook: https://m.facebook.com/learnangular2plus/

Threads: https://www.threads.net/@angular_development

Medium: https://medium.com/@eraoftech

coderlegion: https://coderlegion.com/user/Sunny

Quora: https://neweraofcoding.quora.com/

YouTube: https://www.youtube.com/@neweraofcoding

LinkedIn: https://www.linkedin.com/company/infowebtech/

Hashnode: https://neweraofcoding.hashnode.dev/

GitHub: https://github.com/angulardevelopment/ | sunny7899

BlueSky: https://bsky.app/profile/neweraofcoding.bsky.social

Substack Newsletter: https://codeforweb.substack.com/

Pinterest: https://in.pinterest.com/tech_nerd_life/

dev.to: https://dev.to/sunny7899

Looking for web dev trainings: https://beginner-to-pro-training.vercel.app/

Software development services: https://infowebtechnologies.vercel.app/

Contribution to the web development community: https://code-for-next-generation.vercel.app/

Book a session: https://topmate.io/softwaredev

Telegram Channel: https://t.me/neweraofcoding

Slack Community: Invite

Discord Community: http://discord.gg/Nuc9YRngHz

Buy me a coffee on Ko-fi: https://ko-fi.com/softwaredev

Ebooks: https://apexsunshine.gumroad.com

Thank you for being a part of the community. Happy coding!

Alvor Bank Architecture (.NET + Angular)

Sat, 06 Dec 2025 21:02:56 +0000

Hey everyone

I’ve been working on a full-stack digital banking platform called Alvor Bank, built with:

.NET 10 (microservices + Clean Architecture)
Angular 21 (monorepo-style frontend)
PostgreSQL, RabbitMQ, YARP API Gateway
Docker & GitHub Actions CI/CD

To move beyond “hello world” tutorials, I put together a small architecture & quality roadmap for the system, and I’m sharing the slides here.

In the slides you can see:
-The high-level architecture diagram
-VS solution structure and how the projects are organized
-How I enforce test coverage as a quality gate
-A glimpse of the CI/CD pipeline (build, test, lint, Docker)
-The security/IAM setup (centralized auth, roles, tenants)
-The final project scope for the platform

I’m also documenting everything step-by-step in an early-access book where I build this system from scratch, chapter by chapter:

Modern Full-Stack Banking Microservices (in progress on Leanpub)
https://leanpub.com/fullstack-banking-microservices

I’d really like to hear from other engineers here:

How do you enforce quality gates (tests, coverage, linting, security) in your own projects?

Happy to discuss architecture choices, trade-offs, or anything in the slides.

I’m not building another TODO app. I’m building a production-grade digital bank. Here's what that actually looks like in code

System overview: Microservices, event-driven notifications, and full IAM

Real project structure: Clean Architecture layers, separate service projects, shared building blocks.

We treat tests as a priority, not an afterthought. Coverage gates in CI ensure quality

Everything ships through CI/CD from day one. Green builds and enforced quality thresholds

Coverage report test on CI/CD from Gih=thub Actions

This is from my book Modern Banking Microservices with Clean Architecture, DDD, TDD, .NET 10, and Angular 21 (nx Monorepo). Go beyond tutorials. Build systems that matter. Link: 1: https://leanpub.com/fullstack-banking-microservices.

Building Truly Inclusive Interfaces: An Angular Developer's Guide to ARIA

Tue, 02 Dec 2025 19:09:55 +0000

Accessibility (often shortened to a11y) isn't just a compliance requirement—it's a critical aspect of modern software development. A well-built interface should be usable by everyone, regardless of disability or the assistive technologies they rely on.

In the world of Angular, achieving high accessibility standards, especially for complex interactive components, just got significantly easier with the introduction of Angular Aria.

What is ARIA and Why is it Essential?

ARIA (Accessible Rich Internet Applications) is a set of attributes that you can add to HTML elements. Its purpose is to define ways to make web content and web applications, especially those developed with JavaScript, more accessible to people with disabilities.

While standard HTML elements (like <button> and <input type="radio">) have built-in accessibility, many modern UI patterns (like complex menus, tabs, and grids) are built using generic elements (<div>, <span>). ARIA attributes provide the necessary semantic information to assistive technologies (like screen readers) that these generic elements lack.

However, implementing these W3C Accessibility Guidelines correctly—handling complex keyboard interactions, focus management, and dynamic ARIA attributes—can be a significant and specialized effort.

Introducing Angular Aria: Accessible Components, Your Way

Angular Aria is a collection of headless, accessible directives designed to simplify the implementation of common WAI-ARIA patterns.

The term "headless" is key here:

You provide the HTML structure, the CSS styling, and the business logic.
Angular Aria provides the accessibility implementation.

These directives handle all the tedious, error-prone aspects of a11y, including:

Keyboard Interactions: Ensuring users can navigate components (e.g., opening a menu with Enter, navigating options with arrow keys, closing with Escape).
ARIA Attributes: Automatically setting and updating necessary attributes like aria-expanded, aria-selected, and aria-label.
Focus Management: Moving focus logically between elements for seamless interaction.
Screen Reader Support: Providing clear announcements of a component's state and available options.

Installation:

npm install @angular/aria

What's Included in Angular Aria?

Angular Aria provides pre-built accessibility logic for a wide range of common UI patterns, organized into three categories:

1. Search and Selection

Component	Description
Autocomplete	Text input with filtered suggestions as the user types.
Listbox	Single or multi-select option lists with keyboard navigation.
Select	Single-selection dropdown pattern.
Multiselect	Multiple-selection dropdown pattern with a compact display.
Combobox	Primitive directive for coordinating a text input with a popup.

Component	Description
Menu	Dropdown menus that can include nested submenus and keyboard shortcuts.
Menubar	Horizontal navigation bar for persistent application menus.
Toolbar	Grouped sets of controls with logical keyboard navigation.

3. Content Organization

Component	Description
Accordion	Collapsible content panels (can expand individually or exclusively).
Tabs	Tabbed interfaces with automatic or manual activation modes.
Tree	Hierarchical lists with expand/collapse functionality.
Grid	Two-dimensional data display with cell-by-cell keyboard navigation.

When to Use Angular Aria (and When Not To)

Angular Aria is a powerful tool, but it's not meant to replace every other accessibility solution.

Use Angular Aria When...	Consider Alternatives When...
Building a Design System: Your team needs accessible implementations that match specific visual standards.	You Need Pre-Styled Components: Use Angular Material or similar libraries if you want components that look complete out-of-the-box.
Custom Branding is Required: The interface must match precise design specifications that pre-styled component libraries cannot easily accommodate.	Building Simple Forms: Native HTML controls like `<button>` and `<input type="checkbox">` offer built-in, reliable accessibility.
Creating Enterprise Component Libraries: You are creating reusable, WCAG-compliant components for multiple applications.	Rapid Prototyping: Pre-styled component libraries offer faster initial development time for validating concepts quickly.

By separating the accessibility logic (Angular Aria) from the visual presentation (your HTML/CSS), Angular empowers developers to build bespoke, beautiful, and completely inclusive components without becoming ARIA experts overnight.

Start exploring the directives—the Toolbar is an excellent place to begin—and transform your approach to web accessibility today!

Architecture Pattern: "Compound Components" and Advanced Projection with `ngProjectAs`

Sat, 29 Nov 2025 17:37:29 +0000

When building a Design System or a library of shared components, the most difficult challenge is balancing consistency with flexibility.

You want all your Modals to look the same (consistency), but some Modals contain forms, others contain text, and others contain complex grids (flexibility).

The Architectural Pattern that solves this is Content Projection (specifically Multi-Slot Projection).

The Basics: The "Select" API

When you build a container, you define its API not by Inputs, but by Slots.

@Component({
  selector: 'app-layout',
  template: `
    <header>
      <ng-content select="nav"></ng-content>
    </header>
    <main>
      <ng-content></ng-content>
    </main>
  `
})
export class AppLayoutComponent {}

The Senior "Gotcha": Wrapper Elements

Here is a problem 99% of devs hit.

Imagine your app-layout expects a <nav> tag because of select="nav".

But you want to project a custom component called <app-top-bar>.

<app-layout>
  <app-top-bar></app-top-bar>
</app-layout>

Your app-top-bar will fall into the default slot (Main), not the Header slot.

The Junior Fix:
Wrap it in a nav tag.

<app-layout>
  <nav> <app-top-bar></app-top-bar>
  </nav>
</app-layout>

Problem: You just introduced an extra DOM node (<nav>) that might mess up your Flexbox or Grid layout.

The Senior Fix: ngProjectAs
Angular has a special attribute that allows you to "disguise" an element so it matches a specific selector, without adding extra DOM nodes.

<app-layout>
  <app-top-bar ngProjectAs="nav"></app-top-bar>
</app-layout>

This tells Angular: "Treat this component as if it were a <nav> tag for the purposes of projection."

The "Projected Content" Lifecycle Risk

As a Senior Developer, you need to know the performance cost.

Projected content is instantiated EAGERLY.

If you project a heavy component:
<app-modal><app-heavy-chart></app-heavy-chart></app-modal>

The app-heavy-chart is created, its constructor runs, and its ngOnInit runs immediately, even if the modal is hidden via display: none.

The Optimization:
If the content is extremely heavy, do not use basic Content Projection. Use Template Projection (ng-template).

<app-modal [contentTemplate]="myChart"></app-modal>

<ng-template #myChart>
  <app-heavy-chart></app-heavy-chart>
</ng-template>

// Child (Modal)
@Input() contentTemplate: TemplateRef<any>;

<ng-container *ngTemplateOutlet="contentTemplate"></ng-container>

This ensures the chart is not instantiated until the Modal actually renders the template outlet.

Mastering these nuances—ngProjectAs and TemplateRef—is what separates a component library author from a component user.

Deep Dive: Solving Race Conditions and Concurrency with RxJS Operators

Tue, 25 Nov 2025 05:39:27 +0000

Race conditions are the nightmares of frontend development. They happen when your code assumes that network request A will finish before network request B, but the internet decides otherwise.

In React or Vue (without RxJS), managing complex concurrency often requires boolean flags (isLoading), timestamp checks, or AbortControllers.

In Angular, we solve this elegantly with RxJS Mapping Operators.

But RxJS gives us four different tools: mergeMap, switchMap, concatMap, and exhaustMap. Choosing the wrong one isn't just a style choice; it determines whether your app creates bugs or prevents them.

Let's break down exactly which concurrency strategy each operator uses.

1. `switchMap`: The "Latest and Greatest" (Fixing Read Races)

The Strategy: Cancel the previous request if a new one arrives.

The Scenario:
Imagine a user is on a "User Details" page.

They click "User A". (Request A starts - Slow Network).
They get bored and click "User B" immediately. (Request B starts - Fast Network).

The Bug (without switchMap):
Request B finishes first and shows User B. Then, Request A finishes and overwrites the screen with User A. The URL says "User B", but the screen shows "User A". This is a dirty UI state.

The Fix:

this.route.params.pipe(
  // When params change, cancel any pending request!
  switchMap(params => this.userService.getUser(params.id))
).subscribe(user => {
  // We are GUARANTEED that 'user' matches the current URL.
  this.displayUser(user);
});

Best For: GET requests (Search, Route Params, Filters).

2. `concatMap`: The "Single File Line" (Fixing Write Races)

The Strategy: Wait for the current request to finish before starting the next.

The Scenario:
An "Auto-Save" feature in a text editor.

User types "Hello". (Request A sent).
User immediately types " World". (Request B sent).

The Bug (with switchMap):
If you used switchMap, Request B would cancel Request A. The server only receives " World". The word "Hello" is lost forever.

The Fix:
We need a Queue. Request B must wait in line.

this.textInput.valueChanges.pipe(
  // Queue the requests. Request B waits for Request A to complete.
  concatMap(text => this.api.saveDraft(text))
).subscribe();

Best For: PUT/POST requests where order matters (Auto-saves, sequential steps).

3. `mergeMap`: The "Free-for-All" (Parallel Execution)

The Strategy: Run everything immediately. I don't care about order.

The Scenario:
A "Bulk Delete" feature. The user selects 5 items from a list and clicks "Delete Selected".

The Strategy:
We don't want to wait for Item 1 to delete before starting Item 2 (too slow). And we certainly don't want to cancel Item 1 if Item 2 starts (bug). We want them all to fly to the server at once.

The Fix:

const idsToDelete = [1, 2, 3, 4, 5];

from(idsToDelete).pipe(
  // Fire 5 network requests in parallel
  mergeMap(id => this.api.deleteItem(id))
).subscribe(deletedId => {
  console.log(`Deleted ${deletedId}`);
});

Best For: DELETE requests or fetching unrelated data (e.g., getting Widget A and Widget B at the same time).

4. `exhaustMap`: The "Do Not Disturb" (Spam Prevention)

The Strategy: Ignore new requests while I am busy.

The Scenario:
A "Pay Now" button or a Login form.
A nervous user clicks the button 10 times in one second because the spinner didn't appear instantly.

The Bug (with mergeMap):
You charge the user's credit card 10 times.

The Bug (with switchMap):
You cancel the payment 9 times, and only the 10th one works (maybe).

The Fix:
We want to completely ignore clicks 2 through 10.

fromEvent(this.payButton, 'click').pipe(
  // If a payment is processing, IGNORE this click.
  exhaustMap(() => this.paymentService.chargeCard())
).subscribe();

Best For: Non-idempotent POST requests (Login, Payment, Submit).

Summary Cheat Sheet

Operator	Concurrency Strategy	Ideal Use Case
switchMap	Kill the previous	Reads (Search, Routing)
concatMap	Wait in line	Ordered Writes (Save)
mergeMap	Run in parallel	Parallel Writes (Delete)
exhaustMap	Ignore the new	Submit Buttons (Auth)

RxJS operators are tools for managing time. Master these four, and you master concurrency.

The Senior Developer's Blueprint: Implementing Container vs. Presentational Architecture in Angular

Sat, 22 Nov 2025 08:47:37 +0000

In my 8 years as a frontend engineer, I’ve seen many trends come and go. But one architectural principle has remained the absolute bedrock of scalable application design: the separation of Container (Smart) and Presentational (Dumb) components.

This isn't unique to Angular—it’s a core concept in React and Vue as well. But Angular's structured nature makes it particularly powerful to implement.

If your codebase feels brittle, if you can't reuse UI widgets, or if your unit tests require endless mocking of services just to check if a <div> exists, it's time to adopt this pattern.

The Problem: Coupled Chaos

Let's look at a typical "junior" implementation of a Product List.

You might have a ProductListComponent that:

Injects ProductService and CartService.
Injects ActivatedRoute to read query params for filtering.
Has an ngOnInit that calls this.productService.getProducts().
Has methods like addToCart(id) that call the cart service.
Crucially, its template defines the exact HTML and CSS for how a product card looks.

You have tightly coupled your Business Logic (fetching data, managing cart state) with your UI Concern (rendering a product image and title).

If you want to show a "Recommended Products" section on the cart page, you can't reuse this component. You'd have to copy-paste the HTML/CSS of the product card, leading to code duplication and UI inconsistencies.

The Solution: The Smart/Dumb Split

We need to take a machete to that component and split it into two distinct roles.

1. The Presentational Component ("Dumb")

This component’s sole responsibility is rendering UI. It should be pure and predictable.

Inputs: It receives everything it needs to render via @Input().
Outputs: It communicates user interaction via @Output() events.
Dependencies: NONE. It should not know that services exist.

Let's extract the product card UI.

// product-card.component.ts (Dumb)
@Component({
  selector: 'app-product-card',
  template: `
    <div class="card">
      <img [src]="product.image" [alt]="product.name">
      <h3>{{ product.name }}</h3>
      <p>{{ product.price | currency }}</p>
      <button (click)="addToCartClicked.emit(product.id)">
        Add to Cart
      </button>
    </div>
  `,
  // Pure UI components should always use OnPush for performance
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class ProductCardComponent {
  // The data required to render
  @Input({ required: true }) product!: Product;

  // The event to signal the parent
  @Output() addToCartClicked = new EventEmitter<string>();
}

This component is now a reusable UI asset.

2. The Container Component ("Smart")

This component is the "glue." It connects the application to the UI. It usually corresponds to a specific view or route.

Responsibilities: State management, communicating with services, handling routing.
Template: Mostly contains other components, passing data down and listening for events up.

// product-catalog.page.ts (Smart)
@Component({
  template: `
    <div class="catalog-page">
      <h1>Our Products</h1>
      <div class="grid">
        <app-product-card
          *ngFor="let p of products$ | async"
          [product]="p"
          (addToCartClicked)="handleAddToCart($event)">
        </app-product-card>
      </div>
    </div>
  `
})
export class ProductCatalogPage {
  // Inject dependencies
  private productService = inject(ProductService);
  private cartService = inject(CartService);

  // Manage data streams
  products$ = this.productService.getAll();

  // Define business logic
  handleAddToCart(productId: string) {
    console.log('Smart component handling logic for ID:', productId);
    this.cartService.addItem(productId);
  }
}

The Transformative Impact

By adopting this pattern, you change how you work:

Parallel Development: One developer can build the "Dumb" UI library using Storybook, focusing purely on CSS and visual states, while another developer builds the "Smart" containers and business logic.
Fearless Refactoring: You can completely rewrite your ProductService or change your state management library from NgRx to Elf, and you won't have to touch a single line of code in your ProductCardComponent. The UI is isolated.
Design Consistency: Since your UI components are reusable, you ensure that a Product Card looks the same everywhere in the app.

It requires discipline to not just inject a service into a component "real quick" because it's easier. But resisting that urge is what builds professional, scalable frontend architecture.

The Complete Guide to Angular Subscriptions: Template vs. Component Logic

Wed, 19 Nov 2025 18:25:11 +0000

Every Angular developer eventually faces the dilemma: How do I get my data out of the Observable?

There are two correct answers, and they serve different purposes. Let's look at the code for both.

Scenario 1: Pure Display (The Happy Path)

If your data is just going onto the screen, use the Async Pipe. It is Declarative, meaning you describe what you want (the stream value), not how to get it.

The Code:

// component.ts
data$ = this.service.getData(); // No subscription here!

<p>{{ data$ | async }}</p>

Verdict: Use this 90% of the time. It prevents memory leaks automatically.

Scenario 2: Component Logic (The Necessary Evil)

Sometimes, the Async Pipe isn't enough. You might need to:

Filter data based on local state.
Trigger a side effect (like a Toast notification).
Patch a Form Control value.

Here, you must subscribe. And to avoid Zombie Components (listeners that stay alive after the component dies), you need the takeUntil pattern.

The Code:

export class MyComponent implements OnDestroy {
  private destroy$ = new Subject<void>();

  ngOnInit(): void {
    this.dataService.getData()
      .pipe(takeUntil(this.destroy$)) // Use takeUntil with the destroy$ subject
      .subscribe(response => {
        this.data = response;
        this.form.patchValue(response); // Specific logic!
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next(); // Emit a value to signal completion
    this.destroy$.complete(); // Complete the subject
  }
}

Key Takeaway:
Don't be afraid of manual subscriptions, but respect them. They require explicit cleanup logic. If you can avoid them by using | async, do it. If not, use takeUntil.

How to use mat-tab-group in Angular (Material) — practical guide, tips & how to modify tabs?

Thu, 13 Nov 2025 14:43:48 +0000

mat-tab-group from Angular Material is a polished, accessible tab component that makes organizing UI into multiple panels easy. This post covers how to use it, best practices, and all the common ways you might modify tabs (dynamic tabs, programmatic selection, lazy content, styling, accessibility, and performance tips).

✅ Why use `mat-tab-group`?

Built-in accessibility and keyboard navigation.
Clean UX for grouped content (settings, dashboards, profile pages, etc.).
Works well with Angular change detection and templates.
Easy to style to match your app.

1) Quick setup

Install Angular Material (if not already):

ng add @angular/material

Import the tabs module in your Angular module:

// app.module.ts
import { MatTabsModule } from '@angular/material/tabs';

@NgModule({
  imports: [
    // ...
    MatTabsModule,
  ],
})
export class AppModule {}

2) Basic usage

<mat-tab-group>
  <mat-tab label="First">Content for first tab</mat-tab>
  <mat-tab label="Second">Content for second tab</mat-tab>
  <mat-tab label="Third">Content for third tab</mat-tab>
</mat-tab-group>

3) Best practice: lazy-loading tab content

Use ng-template matTabContent to avoid rendering heavy DOM for inactive tabs:

<mat-tab-group>
  <mat-tab label="Light">
    <ng-template matTabContent>
      <!-- heavy/expensive content goes here -->
      <app-chart *ngIf="showChart"></app-chart>
    </ng-template>
  </mat-tab>

  <mat-tab label="Info">
    <ng-template matTabContent>
      <p>Some info...</p>
    </ng-template>
  </mat-tab>
</mat-tab-group>

Why? Lazy loading reduces initial render cost and speeds up tab group mounting.

4) Dynamic tabs — add/remove tabs at runtime

A very common need is to generate tabs from an array and let users open/close tabs.

Component TypeScript

// dynamic-tabs.component.ts
import { Component, ViewChild } from '@angular/core';
import { MatTabGroup } from '@angular/material/tabs';

interface Tab {
  id: string;
  title: string;
  content: string;
  closable?: boolean;
}

@Component({
  selector: 'app-dynamic-tabs',
  templateUrl: './dynamic-tabs.component.html',
})
export class DynamicTabsComponent {
  @ViewChild(MatTabGroup) tabGroup!: MatTabGroup;

  tabs: Tab[] = [
    { id: 'home', title: 'Home', content: 'Welcome home' },
    { id: 'about', title: 'About', content: 'About us' },
  ];

  selectedIndex = 0;

  addTab() {
    const newTab: Tab = {
      id: `tab-${Date.now()}`,
      title: 'New tab',
      content: 'Dynamically created content',
      closable: true,
    };
    this.tabs.push(newTab);
    // select the newly added tab on next tick
    setTimeout(() => (this.selectedIndex = this.tabs.length - 1));
  }

  closeTab(index: number) {
    this.tabs.splice(index, 1);
    // adjust selected index safely
    if (this.selectedIndex >= this.tabs.length) {
      this.selectedIndex = Math.max(0, this.tabs.length - 1);
    }
  }
}

Template

<!-- dynamic-tabs.component.html -->
<button mat-raised-button (click)="addTab()">Add tab</button>

<mat-tab-group [(selectedIndex)]="selectedIndex">
  <mat-tab *ngFor="let t of tabs; let i = index; trackBy: trackById">
    <ng-template mat-tab-label>
      {{ t.title }}
      <button *ngIf="t.closable" mat-icon-button (click)="closeTab(i); $event.stopPropagation();" aria-label="Close tab">
        <mat-icon>close</mat-icon>
      </button>
    </ng-template>

    <ng-template matTabContent>
      <div class="tab-content">{{ t.content }}</div>
    </ng-template>
  </mat-tab>
</mat-tab-group>

trackBy function (optional, for performance)

Add to the component:

trackById(index: number, tab: Tab) {
  return tab.id;
}

Notes:

Use [(selectedIndex)] to keep selection synchronized with your model.
Stop propagation on close button to avoid changing selection when closing.
setTimeout for selection is a simple sync trick; you can also run change detection manually if needed.

5) Programmatic control & events

selectedIndex property: set which tab is active.
(selectedTabChange) emits MatTabChangeEvent when user selects a tab.

<mat-tab-group (selectedTabChange)="onTabChange($event)" [(selectedIndex)]="selectedIndex">
  ...
</mat-tab-group>

onTabChange(event: MatTabChangeEvent) {
  console.log('Selected tab index', event.index, 'label', event.tab.textLabel);
}

You can get a reference to the MatTabGroup with @ViewChild to call methods or inspect tabs.

6) Styling & theming

Prefer using your global stylesheet or component-level styles with :host ::ng-deep only when necessary.

Example (in styles.scss or global stylesheet):

/* style the ink bar and labels globally */
.mat-tab-group .mat-ink-bar {
  height: 3px;
}

.mat-tab-label {
  font-weight: 600;
  text-transform: none;
}

If modifying from inside a component and view encapsulation blocks styling, either:

Put styles in styles.scss (global), or
Use ::ng-deep carefully (deprecated but still used), or
Set encapsulation: ViewEncapsulation.None for that component.

Angular Material tabs provide keyboard support and ARIA attributes out of the box. Still:

Ensure meaningful tab labels.
Avoid long interactive content without landmarks inside tabs — screen reader users benefit from headings.
If you add custom close buttons or controls, provide aria-labels.

8) Routing + tabs (optional patterns)

If you want tab-per-route behavior, use:

mat-tab-nav-bar + routerLink for navigation-like tabs, or
Synchronize selectedIndex with the router (listen to ActivatedRoute and set the selected tab).
Use mat-tab-nav-bar when each tab should be its own URL.

9) Performance tips

Use ng-template matTabContent to lazy-render heavy components.
Use trackBy in *ngFor for dynamic tabs to avoid unnecessary DOM churn.
If you render complex child components, consider detaching change detection during creation and reattaching after initialization (advanced).

10) Is it possible to modify tabs? (Short answer: Yes — many ways)

You can:

Dynamically add/remove tabs by changing the backing array (Angular updates the DOM).
Change labels and content by updating the model bound to the tab.
Programmatically select a tab using selectedIndex or @ViewChild(MatTabGroup).
Do multi-file or dynamic behavior like loading content from a server and injecting components into a tab.
Style and theme tabs by overriding Material styles globally or at component-level.

All modifications are supported and are standard Angular patterns (data-driven UI, event bindings, ViewChild).

Example: Putting it all together (short)

<!-- app.component.html -->
<button (click)="addTab()">+ New</button>
<mat-tab-group [(selectedIndex)]="selectedIndex" (selectedTabChange)="onTabChange($event)">
  <mat-tab *ngFor="let t of tabs; let i = index; trackBy: trackById">
    <ng-template mat-tab-label>
      {{ t.title }}
      <button *ngIf="t.closable" mat-icon-button (click)="closeTab(i); $event.stopPropagation()">
        <mat-icon>close</mat-icon>
      </button>
    </ng-template>

    <ng-template matTabContent>
      <app-heavy-widget *ngIf="t.lazyLoaded" [data]="t.data"></app-heavy-widget>
      <div *ngIf="!t.lazyLoaded">{{ t.content }}</div>
    </ng-template>
  </mat-tab>
</mat-tab-group>

Final checklist / best practices

Use matTabContent for heavy content (lazy loading).
Drive tabs from data (array) and use trackBy.
Keep tab labels short and descriptive.
Use selectedIndex for programmatic control.
Prefer global or scoped styles rather than ::ng-deep where possible.
Maintain accessibility by adding aria labels to controls.
Always review generated DOM when dynamically adding components to tabs.

Scaling Angular: Standalone Components, Monorepos, and Strategic DDD

Sun, 09 Nov 2025 12:22:54 +0000

Building modern, large-scale applications can quickly become an exercise in complexity. As your codebase grows, managing dependencies, coordinating teams, and ensuring architectural consistency becomes a monumental task. The good news? Angular, combined with contemporary architectural practices like Strategic Domain-Driven Design (DDD) and the structure of a Mono Repo, provides a powerful solution.

Let's explore how Angular Standalone Components revolutionize component management and how the Mono Repo/DDD approach provides the blueprint for a truly scalable architecture.

Standalone Components: The Angular Revolution

The introduction of Standalone Components is perhaps one of the most significant changes in modern Angular. They offer a pathway to simpler, more efficient component architecture.

What Are They?

Traditionally, every Angular component, directive, or pipe had to be declared within an NgModule. This module system, while powerful, often led to:

"Module Hell": Endless, often boilerplate-filled, NgModule files simply declaring components.
Increased Bundle Size: Even with lazy loading, unused declarations could sometimes bloat modules.
Complexity: Understanding which component belonged to which module could be difficult for new team members.

Standalone Components eliminate this requirement. A component can now be defined as standalone: true, allowing it to directly import its own dependencies (other components, modules, pipes, etc.) without needing an owning NgModule.

// standalone component example
import { Component } from '@angular/core';
import { CommonModule } from '@angular/common';
import { UserProfileComponent } from './user-profile/user-profile.component'; // a standalone component

@Component({
  standalone: true,
  selector: 'app-main-view',
  templateUrl: './main-view.component.html',
  styleUrls: ['./main-view.component.css'],
  imports: [
    CommonModule,
    UserProfileComponent, // direct import!
  ]
})
export class MainViewComponent {
  // ... component logic
}

The Advantage for Scale

Tree-Shaking: Easier for build tools to eliminate truly unused code, leading to smaller bundles.
Simplified Imports: Clear, explicit dependencies right in the component file.
Better DX (Developer Experience): Less boilerplate, faster development.

️ Architectural Backbone: Monorepo and Strategic DDD

While Standalone Components improve the internal structure of your features, a Mono Repo paired with Strategic DDD provides the necessary external structure for a large application.

1. The Power of the Mono Repo

A Mono Repo is a single repository containing code for many projects, libraries, and applications. For large Angular ecosystems, tools like Nx are often used to manage this structure.

Key Benefits:

Atomic Commits: Changes across multiple features or libraries can be made and tested together in a single commit.
Dependency Management: Enforcing library dependencies becomes centralized and transparent.
Code Sharing: Utilities, UI components, and domain logic can be easily shared and reused across different applications (e.g., a customer portal and an admin dashboard).
Tooling Consistency: Standardized linting, testing, and build processes across all projects.

2. Strategic DDD: Defining Boundaries in the Monorepo

The Mono Repo gives you a physical structure, but Strategic DDD gives you the design structure. DDD, popularized by Eric Evans, is a software development approach that models implementation based on the domain of the business.

The Core Concept: Bounded Contexts

The most crucial concept in Strategic DDD is the Bounded Context.

A Bounded Context is a logical boundary that encapsulates a specific part of your domain model, ensuring that terms and concepts within that boundary are unambiguous.

In a large application, the concept of a "User" in the Inventory context (for tracking who updated stock) is not the same as the "User" in the Billing context (for managing subscriptions).

Mapping DDD to the Monorepo

In an Nx-style Angular Mono Repo, you use the directory structure to enforce these Bounded Contexts.

DDD Concept	Monorepo Artifact (Nx Library Type)	Description
Bounded Context	Feature/Domain Folder	The top-level folder for a major business capability (e.g., `libs/inventory`, `libs/billing`).
Ubiquitous Language	Types/Interfaces	Consistent naming conventions used across the context's library structure.
Aggregates/Entities	`data-access` Library	Libraries responsible for state management, API calls, and business logic for a specific context.
Presentation/UI	`ui` and `feature` Libraries	Libraries holding shared UI components (`ui`) and the specific, route-able pages (`feature`) for the context.

By structuring your Standalone Components within these Bounded Context libraries, you achieve high cohesion and low coupling. A component in the billing feature library should only import logic from billing/data-access or shared libraries—never directly from inventory/data-access.

The Synergistic Outcome

When you combine these three elements, you get an architecture built for speed, stability, and growth:

Standalone Components provide internal modularity and development efficiency (Developer Experience).
The Mono Repo provides a unified build system and centralized dependency control (Tooling and Consistency).
Strategic DDD provides a logical, business-aligned structure that prevents architectural decay (Scalability and Maintainability).

By embracing this triad, your large Angular application transforms from a monolithic tangle into a collection of well-defined, independently scalable, and collaboratively managed Bounded Contexts.

From Idea to Angular App: Prototyping in Google AI Studio

Wed, 05 Nov 2025 19:19:57 +0000

The days of spending hours on initial project setup and boilerplate code are rapidly ending. With the integration of Angular into environments like Firebase Studio and the power of the Gemini AI model, developers can now leap from a natural language idea straight to a working application prototype.

This integration isn't just about generating snippets; it's about generating a coherent, full-stack application blueprint that you can instantly begin to refine.

The AI Studio Workflow: Vibe Coding Your App

Google AI Studio (or the App Prototyping agent within Firebase Studio) serves as a rapid prototyping environment. It moves beyond the simple chat interface to offer a space where AI can build, test, and iterate on complex application structures.

Step 1: Define Your Vision with a Prompt

The process starts with a descriptive, natural language prompt. You describe the features, user workflows, and data requirements of your app.

Example Prompt: "Create a responsive, mobile-first Angular application that allows users to search for recipe ideas based on uploaded photos of ingredients. If no food is detected, suggest a random dessert recipe. Use a clean, light blue color scheme."

The power here is in being specific. You can include everything from the core features to the desired style and required data handling. You can even upload an image to suggest a color palette or layout!

Step 2: Configure for Angular

This is the crucial step that directs the AI's output. While AI models can generate code in many languages, you need to explicitly tell it to use your preferred framework.

In the advanced settings of the prototyping environment (often found under System Instructions), you select the "Angular (TypeScript)" template.

This selection does three things:

Framework Compliance: Instructs the Gemini model to use modern Angular syntax (e.g., Standalone Components, Signals).
Language Consistency: Ensures the application logic is written in TypeScript.
Project Structure: Guides the AI to set up the appropriate module (or standalone component) structure.

Step 3: Blueprint, Code, and Iteration

After submitting your prompt, the App Prototyping agent performs three key actions:

Blueprint Generation: It first returns a proposed plan (the blueprint) covering the app name, key features, and styling details. This is your chance to review and adjust the high-level plan conversationally before any code is written.
Code Generation: Once confirmed, the agent generates the full-stack code, including the Angular front-end, and often provisions a Firebase project and sets up the necessary Gemini API keys if the app requires AI features (like image analysis or text generation).
Live Preview: You get a live, interactive web preview of the generated application directly in the studio. You can test user flows immediately.

Step 4: Export to Production Ready Tools

The goal of AI Studio is not to trap your code. Once you're happy with the prototype, you have well-lit paths to move to a production workflow:

Export to GitHub: Export the generated code directly to a GitHub repository for version control, collaboration, and integration into your CI/CD pipeline.
Integrated Deployment: The environment often integrates directly with deployment platforms like Cloud Run or Firebase App Hosting for a single-click deployment of the full-stack application.

Why This Matters for Angular Developers

The AI Studio integration isn't just a novelty; it's a profound workflow acceleration:

Rapid Kickoffs: Shorten the time from an idea's conception to a functional prototype from weeks to mere minutes.
AI-Powered Apps: Easily develop applications that utilize the Gemini API as a core feature, moving beyond simple front-end rendering into true agentic applications.
Best Practice Adherence: By using high-quality system prompts and refining the process with tools like the Web Codegen Scorer, you can ensure the generated Angular code follows modern, safe standards.

This is the power of AI assisting human developers: focusing creative energy on unique features and complex problems, while the boilerplate and initial structure are handled instantly.

If you're interested in seeing this in action, check out how easily you can prototype a functional app using Google AI Studio.

Note: if you are getting this error while using Gemini CLI or NotebookLM. Seeing the "Model is overloaded" error (often a 503 Service Unavailable error) is a common frustration, especially during peak hours or when using high-performance models like Gemini 3 Pro.

Essentially, the backend servers assigned to process your request have reached their capacity and cannot handle more "thinking" tasks at that exact moment.

Immediate Fixes You Can Try

Wait and Retry (The "30-Second Rule"): Most overloads are transient. Wait 30 seconds and try your request again. If you are a developer, use exponential backoff (waiting progressively longer between retries).
Start a New Conversation: If your current chat has a very long history or large file uploads, the "context" might be putting too much strain on the backend. A fresh chat often resolves this instantly.
Switch Models: If you are using Gemini 3 Pro, try switching to Gemini 3 Flash. Flash is designed for high speed and can usually handle much higher traffic volumes even when the Pro models are struggling.
Check the Official Status: You can verify if there is a global outage by checking the Google AI Studio Status Page.

Why Is This Happening?

Peak Traffic: Just like a website crashing during a big sale, AI models have physical hardware limits. If thousands of users are asking complex questions simultaneously, the backend "queues" fill up.
Context Load: If you have uploaded multiple PDFs or a massive codebase (like in NotebookLM or Antigravity), the model has to "read" all of that for every new message. This requires significant compute power that can sometimes time out.
Regional Limits: Sometimes specific data centers (like US-Central) are busier than others. If you are using the API, switching your region can sometimes bypass the local overload.

For Developers & Power Users

If you are seeing this frequently while building an app or using the CLI:

Quota Management: Check your Google AI Studio dashboard to ensure you haven't hit your "Requests Per Minute" (RPM) limit.
Move to Vertex AI: Google's enterprise platform, Vertex AI, typically offers much higher stability and "Reserved Throughput" options compared to the free-tier AI Studio.

Try out these also: Google AI Pro & AI Ultra

Let’s stay connected:

Instagram: https://www.instagram.com/angular_development/

Facebook: https://m.facebook.com/learnangular2plus/

Threads: https://www.threads.net/@angular_development

Medium: https://medium.com/@eraoftech

coderlegion: https://coderlegion.com/user/Sunny

Quora: https://neweraofcoding.quora.com/

YouTube: https://www.youtube.com/@neweraofcoding

LinkedIn: https://www.linkedin.com/company/infowebtech/

Hashnode: https://neweraofcoding.hashnode.dev/

GitHub: https://github.com/angulardevelopment/ | sunny7899