DEV Community: Ilyoskhuja

Optimizing an Angular Real-Estate App: SSR, a Map with Hundreds of Markers, and a Lighthouse Score That Went From 54 to 96

Ilyoskhuja — Sun, 05 Jul 2026 18:05:03 +0000

I build locus.uz, a real-estate search site for Uzbekistan — think Zillow for Tashkent. The https://locus.uz/buy page is the hard one: a Leaflet map with hundreds of listing pins on the left, an infinite-feeling list of photo cards on the right, three languages (Uzbek, Russian, English), all server-side rendered.

The stack, so you know exactly what this applies to: Angular 21 (standalone components, signals, zoneless change detection — the default for new apps since v21), @angular/ssr on an Express 5 server, Leaflet 1.9 for the map, deployed on a VPS behind nginx and Cloudflare. No NgRx, no component library. Everything here was written against Angular 21.x, and I've checked that none of the framework behavior described has changed in v22.0 (released June 2026).

One weekend I ran Lighthouse against /buy and got Performance 88, Accessibility 83, Best Practices 54. A few days of work later:

Category	Before	After
Performance	88	93 (LCP 1.0s, CLS 0, TBT 90ms)
Accessibility	83	96
Best Practices	54	96
SEO	100	100

This article covers the Angular techniques that got us there — and three production incidents along the way, because those taught us more than the wins.

The foundation: SSR + hydration, and the flag everyone misses

The app uses Angular's application builder with SSR and full hydration. Event replay (withEventReplay()) has been the CLI default for new SSR apps since v19 — the interesting line is the second one:

provideClientHydration(
  withEventReplay(),
  withHttpTransferCacheOptions({ includePostRequests: true })
)

Angular's HTTP transfer cache carries responses fetched during SSR to the browser so the client doesn't refetch them during hydration. But it only caches GET and HEAD by default (ALLOWED_METHODS = ['GET', 'HEAD'] in the source, unchanged through v22). Our listings come from a POST /map-search — the request body carries viewport bounds and filters, too much for a query string. So the server rendered twenty listing cards, the client re-issued the POST during hydration, and — because the response is async — Angular's first client render hit the empty @if branch while the server HTML contained the populated list. That structural mismatch is what throws NG0500 (the docs classify it under "differing server/client render output", not as an HTTP problem — if our loading state had the same DOM shape, we'd have gotten a silent duplicate request and a flicker instead of an error).

One flag fixed the mismatch, the duplicate fetch, and the console error at once. Two honest footnotes: the global flag is one way to do it — since v17 you can opt in a single request with http.post(url, body, { transferCache: true }), which is safer when only one endpoint is an idempotent read. And never enable this for POSTs that mutate state; ours is a search query that just happens to travel as POST.

Why not incremental hydration? Angular 20 stabilized it (withIncrementalHydration() plus @defer (hydrate on viewport) and friends), and from v22 it's the default. We stayed on full hydration because our main content is a client-only map that never gets server-rendered anyway — there's little dehydrated DOM to skip. If your page has heavy server-rendered sections users rarely touch, hydrate triggers are the modern way to cut initial JS execution, and you should reach for them before anything in this article.

Why not @defer for the map? Deferrable views (introduced in v17, stable since v18) with @defer (on viewport) are the idiomatic way to lazy-load heavy components, and on the server they render only their placeholder — so they'd also keep Leaflet out of SSR. We used route-level lazy loading plus a guarded dynamic import('leaflet') instead, for one reason: the map is the page's primary above-the-fold content. Angular's own defer guide warns against deferring initial-viewport content (layout shift), and a viewport trigger would fire immediately anyway. For a below-the-fold widget, @defer would have been the right call.

One more foundation piece: afterNextRender for anything that must not race hydration. We restore the user's saved language from localStorage — doing that in a constructor changes the first client render, which then no longer matches the server HTML (hello again, NG0500). Registering it in afterNextRender means the first render matches the server byte-for-byte and the preference applies immediately after.

The map: hundreds of dots without melting the main thread

The map renders ~280 pins at city zoom plus colored district polygons for all of Tashkent, and the page stays at 90ms Total Blocking Time.

A word on the library choice, since someone will ask: at this scale — hundreds of DOM features on raster tiles — Leaflet is a lighter, simpler tool than MapLibre GL, which earns its complexity with vector tiles and thousands-plus of GPU-rendered features. Leaflet 1.9.4 is still the current stable in mid-2026 (2.0 has been in alpha since August 2025; 1.x is in maintenance mode), and we'll migrate when 2.0 lands.

1. The viewport is the query. We never fetch "all listings". The map's moveend event sends the current bounds to the backend:

lMap.on('moveend', () => {
  const b = lMap.getBounds();
  this.api.loadListings({ northEast: b.getNorthEast(), southWest: b.getSouthWest(), ... });
});

The database does the spatial filtering; the browser only ever holds what's visible.

2. Signals drive the markers — which matters more in a zoneless app. The API service exposes listings as a signal, and the map redraws in an effect() (third-party rendering is explicitly one of the documented use cases for effects):

effect(() => {
  if (isPlatformBrowser(this.platformId) && this.mapReady()) {
    const markers = this.api.markers();
    const lang = this.i18n.currentLang(); // redraw popups on language switch
    this.drawMarkers(markers);
  }
});

Since the app is zoneless, the classic "wrap Leaflet in NgZone.runOutsideAngular" advice is moot — there's no zone to escape, and Leaflet's internal mousemove/drag storms can't trigger change detection in the first place. The risk actually inverts: a Leaflet event handler that should update the UI does nothing unless it writes to a signal. Ours all do, which is why the pattern above isn't just tidy — it's the mechanism.

3. Cheap markers, canvas polygons — and know which is which. Each pin is a divIcon (one styled <div>, no image request). The district boundaries are detailed GeoJSON polygons, and rendering them as SVG (Leaflet's default) means thousands of path nodes in the DOM — so that layer gets renderer: L.canvas(), painting every district into a single canvas element. We also simplify the geometry first: interior rings and all but the largest part of each MultiPolygon get stripped, because a boundary overlay doesn't need survey-grade precision.

One precision note, because map people will check: L.canvas()/preferCanvas only affects vector path layers like our polygons. divIcon markers are always DOM elements — if you need to scale markers into the thousands, the answer is clustering, circleMarkers, a canvas-marker plugin, or WebGL, not the canvas renderer. At ~280 pins, plain DOM markers are comfortably fine; the community rule of thumb is that you reach for Leaflet.markercluster (proven to tens of thousands of points) somewhere past 500–1,000.

4. Kill the feedback loops before they kill you. The map reloads listings on moveend. Search-by-district calls fitBounds. fitBounds fires moveend. Which reloads listings, which can move the map… We guard every programmatic move:

this.programmaticMove = true;
this.leafletElement.fitBounds(bounds, { padding: [50, 50], maxZoom: 15 });

// in the moveend handler:
if (this.programmaticMove) { this.programmaticMove = false; return; }

Same defensive posture around sizing: Leaflet 1.9's trackResize only watches window resize, so container-driven changes (sidebar toggles, flex reflows) need a manual ResizeObserver calling invalidateSize() — guarded to skip when the container is hidden, because Leaflet does not enjoy being resized while display: none. (The 2.0 alpha observes the container natively, so this workaround is 1.x-specific.)

5. Markers are UI, so they follow UI rules. Leaflet has made every keyboard-enabled marker a focusable role="button" since 1.8 — and by default a nameless one, which is a Lighthouse accessibility failure multiplied by 280. The built-in fix is the title option (Leaflet sets it on the icon element; the alt option only applies to image icons, so it's silently ignored for divIcons):

const title = [formatPriceCurrency(item.price, item.currency), item.location || item.district]
  .filter(Boolean).join(' — ');
const marker = this.leaflet.marker([lat, lng], { icon, title });

Now a screen reader announces "$52,500 — Sergeli" instead of "button". (A title attribute is a fairly weak name source; if you build custom divIcon HTML anyway, an aria-label inside it is more robust.)

The listing images: fast, stable, and no broken pictures

The right half of the page is a grid of photo cards, each with a swipeable gallery. Every card thumb looks like this:

<img class="thumb"
     [src]="imageError ? '/no_image.jpg' : photos()[current]"
     (error)="handleImageError($event)"
     [attr.loading]="priority() ? 'eager' : 'lazy'"
     [attr.fetchpriority]="priority() ? 'high' : null"
     [alt]="listing().location || listing().district || (…fallback | translate)" />

The reasoning, attribute by attribute:

loading="lazy" — for everything except the LCP image. Twenty cards render per page; only the ones near the viewport fetch their images, which (with the other fixes) took the page payload from 11MB to 3.4MB. But lazy-loading the image that is your Largest Contentful Paint is a well-documented anti-pattern — Angular has flagged it in dev mode since v17 (the NG0913 check inspects plain <img> tags too). So the first cards get a priority input: eager loading plus fetchpriority="high".
The container owns the layout, not the image. The wrapper has aspect-ratio: 4 / 3 with object-fit: cover, so cards occupy their final size before a single image byte arrives. That's the entire reason CLS is a flat 0 — explicit width/height attributes achieve the same thing, and map directly onto NgOptimizedImage's requirements if you migrate later.
One <img> per card, not one per photo. A listing can have fifteen photos, but the carousel is a single image element whose src swaps on navigation. Photos you never swipe to are never downloaded. The dots under the photo are real <button>s, visually 8px but with a 24×24 hit area via background-clip: content-box.
decoding="async" on the lazy images — a cheap, no-downside hint, though honestly a marginal one in 2026 (browsers largely decode off the main thread anyway), and deliberately not set on the priority image.
Broken images have two safety nets. Client-side, (error) swaps in a placeholder. Server-side, nginx does try_files $uri /no_image.jpg; so a missing photo returns a 200 placeholder instead of a 404 — Lighthouse counts every failed request as a console error, and twenty cards can generate a lot of 404s.

Why not NgOptimizedImage? Fair question — ngSrc has been Angular's documented image best practice since v15, and it's the first thing any reviewer will ask. The directive's headline wins are automatic srcset generation and placeholders, and both require an image loader backed by a resizing CDN (Cloudinary, ImageKit, Imgix…). Our photos are self-hosted in a single size — there's no srcset to generate, and automatic placeholders actually throw without a loader. What the directive would still give us loaderless — enforced dimensions, lazy-by-default, and the priority handling with SSR preload hints — we've replicated manually above. If we adopt an image CDN, switching to ngSrc with priority on the first cards is the drop-in upgrade, and it's the honest next step on this list.

Best Practices 54 → 96: security headers on the Express server

The score of 54 had a blunt cause: the site sent no security headers at all. The fix lives in the Express SSR server — a global middleware for HSTS, COOP, X-Frame-Options, nosniff and Referrer-Policy, plus a per-request nonce-based CSP on rendered HTML. The server mints a nonce, stamps it onto every <script> tag (and every <link rel="modulepreload"> — miss those and 'strict-dynamic' blocks your chunk preloads), and sends:

script-src 'nonce-...' 'strict-dynamic' 'self' 'unsafe-inline' https: http:

The trailing values are backward-compat fallbacks that nonce-aware browsers ignore. Angular's hydration and event-replay inline scripts all accept the nonce.

Except one thing did not, and it took the whole site's CSS down with it.

Strict CSP vs. Angular's critical CSS: know your options

Minutes after the CSP went live, our map disappeared, replaced by Canvas exceeds max size errors. Measuring the map container in a headless browser: 4,194,366 pixels tall — 2²², a doubling feedback loop that had run thirteen times, with 6,393 map tiles loaded into it.

A commit-by-commit bisect with a headless browser pointed at… my own CSP commit. The mechanism: Angular's inlineCritical optimization (on by default; since v19 powered by Beasties, the maintained Critters fork) inlines critical CSS and emits the full stylesheet as:

<link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'">

A non-blocking load that flips to media="all" via an inline event handler — which a strict CSP blocks. The stylesheet stayed stuck as a print stylesheet, so the page — including all of Leaflet's CSS — rendered unstyled. Unpositioned map tiles became ordinary in-flow images stacking vertically, the container grew, more tiles loaded, repeat. (Not literally silent, in fairness: the CSP violations were in the console. But nothing tells you "your stylesheet is now print-only", and the visible symptom — a canvas error from the map — pointed everywhere except CSS delivery.)

Here's the part I only fully understood afterwards, and it changes the recommendation. This failure only happens when Angular doesn't know your nonce. Since v16, if the served HTML carries an ngCspNonce attribute on the app root, Angular's build and @angular/ssr handle everything: the onload handler is replaced with a nonce'd loader script, inline critical styles get the nonce, and so do the hydration/event-replay scripts. That's the framework-blessed path for strict CSP with SSR, and it keeps the critical-CSS FCP win. (Two footnotes: the CSP_NONCE injection token alone is not enough for SSR — build-emitted scripts won't get the nonce; and the CLI's newer hash-based autoCsp option, experimental since v19, throws "Cannot set both SSR and auto-CSP" — it's a no-go for SSR apps.)

We chose the other lever:

"optimization": { "styles": { "minify": true, "inlineCritical": false } }

One line, no per-request HTML templating, at the cost of the stylesheet becoming a normal render-blocking link — a few milliseconds of first paint on our numbers. For a small self-hosted stylesheet that's a fine trade; for a bigger app already generating per-request nonces, wiring ngCspNonce is the better answer. What you cannot do is ship a strict CSP without choosing one of them — nothing in the build warns you about the combination, and the failure mode looks like anything but CSS.

Two more bugs the audit smoked out

Production was serving a month-old build. After the first round of fixes, the Lighthouse score didn't move — because nginx was serving a stale prerendered index.html from a June build. Our GitHub Actions deploy used scp, which copies but never deletes, and old files shadowed five consecutive deploys. The tell was in the response headers all along: last-modified: Fri, 26 Jun. HTML responses from an SSR server don't have a last-modified date. Now the pipeline wipes the target directories before copying, and nginx proxies everything except hashed assets to the Node server. If your deploy is scp/rsync without --delete, go check your server right now.

The language switcher un-switched itself in 6ms. Our i18n uses URL prefixes (/ru/buy) via a custom UrlSerializer whose parse() records the language as a side effect. (Angular's official i18n guidance is a different architecture entirely — one build per locale under a URL subPath — so a single-build runtime-locale setup like ours is community-pattern territory.) It turns out the Router re-parses the raw browser URL with your serializer during internal same-URL checks — isUpdatedBrowserUrl() in navigation_transition.ts, verified unchanged through 21.x. So if the address bar still said /ru/buy when you clicked "O'zbek", an internal re-parse stomped the language state back to Russian before the UI could blink. I found it by monkey-patching localStorage.setItem with stack traces. The fix: location.replaceState(newPrefixedUrl) before router.navigateByUrl, so any re-parse sees the new prefix. The lesson: the Router makes no promises about when or how often parse() runs — treat it as something that must be pure.

What actually mattered

includePostRequests: true (or per-request { transferCache: true }) if your SSR app reads data via POST — fixes hydration mismatches and double-fetching at once. Idempotent reads only.
Viewport-bounds queries + signal-driven effect() redraws + divIcon/canvas rendering carry a Leaflet map to hundreds of markers without jank. In a zoneless app, map-event-writes-to-signal isn't a style choice — it's the only way the UI updates.
loading="lazy" everywhere except the LCP image, which gets fetchpriority="high" — plus aspect-ratio containers and single-img carousels. CLS 0 is a design decision, not luck.
Strict CSP + SSR requires choosing: ngCspNonce (keeps critical CSS, framework-supported since v16) or inlineCritical: false (one line, render-blocking styles). Choosing neither breaks your CSS in a way that looks like anything but CSS.
Audit in incognito — DevTools Lighthouse runs your extensions inside the page, and their deprecation warnings count against you. My first "after" run said 73; a clean profile said 96.
Trust nothing about production until you've curled it. The most impactful fix of the week wasn't Angular at all — it was discovering which build users were actually receiving.

What's still red, honestly: the touch-target audit flags overlapping map pins — that's WCAG 2.2's target-size criterion (24×24 CSS px of unobscured area), and 280 pins at city zoom obscure each other by definition. The standard fix is Leaflet.markercluster with spiderfying for coincident pins; at our scale it's an accessibility-and-UX decision rather than a performance one (and note the default cluster icons need accessible names of their own). That's the next project.

The scores are the headline, but the real gains were quieter: pages hydrate cleanly instead of re-rendering, the map redraws only what changed, users stopped downloading photos they'd never see, and — after an embarrassing discovery — they're finally getting the build we shipped.

Power Up Your Angular App with Progressive Web Apps (PWAs)

Ilyoskhuja — Mon, 30 Jan 2023 10:07:07 +0000

As a web developer, you are always looking for ways to improve the user experience and performance of your applications. One solution that has gained popularity in recent years is Progressive Web Apps (PWAs). PWAs are web applications that use modern web technologies to provide a native-like experience on the web. In this article, we will discuss how you can power up your Angular app with PWAs.

What are PWAs?

PWAs are web applications that use modern web technologies, such as service workers and web manifests, to provide a native-like experience on the web. PWAs can be installed on a user's device, just like a native app, and can be launched from the home screen. PWAs can also work offline, providing users with a seamless experience even when there is no internet connection.

Why use PWAs with Angular?

Angular is a popular framework for building web applications. By combining Angular with PWAs, you can create fast, offline-capable, and installable web applications that provide a native-like experience to users. This can lead to improved user engagement and retention, as well as increased conversions and revenue.

How to add PWA to your Angular app?

Adding a PWA to your Angular app is relatively straightforward, and can be done with the help of Angular CLI and the @angular/pwa package. Here's a step-by-step guide on how to do it:

Install Angular CLI: If you haven't already installed Angular CLI, do so by running the following command: npm install -g @angular/cli.

Create a new Angular project: Run the following command to create a new Angular project: ng new my-app.

Install the @angular/pwa package: Run the following command to install the @angular/pwa package: npm install @angular/pwa.

Add the PWA module to your app: Open the app.module.ts file and add the following import statement: import { BrowserModule } from '@angular/platform-browser';.

Add the Service Worker: Run the following command to add a service worker to your app: ng add @angular/pwa.

Build and serve your app: Run the following command to build and serve your app: ng serve.

That's it! Your Angular app is now a PWA. You can test it by visiting the app in a browser and checking the "Add to Home Screen" option.

Conclusion

PWAs are a powerful way to improve the user experience and performance of your Angular applications. By combining Angular with PWAs, you can create fast, offline-capable, and installable web applications that provide a native-like experience to users. With the help of Angular CLI and the @angular/pwa package, adding a PWA to your Angular app is relatively straightforward. So, what are you waiting for? Power up your Angular app with PWAs today!

Web3 development with Angular: Making life easy with blockchain

Ilyoskhuja — Mon, 30 Jan 2023 04:55:56 +0000

The use of blockchain technology has become more and more widespread in recent years. The decentralization of data and the security provided by blockchain make it a perfect fit for many applications. However, incorporating blockchain into web applications can often be a challenging task. This is where Angular, a popular web development framework, can make life easier.

In this article, we will discuss how to incorporate blockchain technology into an Angular project and some best practices to keep in mind. We will also look at some ideas for creating reusable components and services for your application.

Integrating blockchain into Angular

The first step in incorporating blockchain into an Angular project is to choose the appropriate blockchain technology for your needs. Ethereum, for example, is a popular choice for decentralized applications. Once you have chosen your blockchain technology, you can start integrating it into your Angular application.

One approach is to use a pre-existing Angular library such as Angular-Ethereum. This library provides an easy-to-use interface for communicating with the Ethereum blockchain and can help to streamline the integration process.

Another option is to create your own custom library for communicating with the blockchain. This approach gives you more control over the communication and can help you to better tailor the library to your specific needs. When creating your own library, it is important to keep in mind the need for security and to follow best practices for communication with the blockchain.

Creating reusable components and services

Reusable components and services can help to streamline your Angular project and reduce development time. When it comes to incorporating blockchain into your Angular application, reusable components and services can also help to simplify the integration process.

One idea for a reusable component is a blockchain-powered login system. This component would allow users to log in to your application using their blockchain credentials and would help to secure the login process. Another idea is a blockchain-powered payment system, which would allow users to make payments directly from their blockchain wallets.

When creating reusable components and services, it is important to consider their modularity and ease of use. By making components and services easy to use, you can help to encourage adoption and make it easier for other developers to incorporate them into their own projects.

Conclusion

Incorporating blockchain into an Angular project can be a challenging task, but it doesn't have to be. By using Angular-Ethereum or creating your own custom library, you can streamline the integration process and make it easier to develop blockchain-powered applications. Reusable components and services can also help to simplify the development process and encourage adoption. With Angular and blockchain, the sky is the limit for what you can build.

Creating behavior tests for User Interfaces

Ilyoskhuja — Mon, 30 Jan 2023 04:14:16 +0000

Behavior Driven Development (BDD) is a software development methodology that emphasizes the behavior of a system and focuses on testing it against expected outcomes. BDD is particularly useful for testing user interfaces as it helps to validate that the UI behaves as expected given specific conditions.

In this article, we will explore how to set up a testing infrastructure for user interfaces using BDD in Angular. The following main bullet points will be covered:

What is BDD and how it applies to this talk: BDD is a software development methodology that focuses on the behavior of a system, as opposed to just its implementation. This approach is useful for testing user interfaces as it allows developers to validate that the UI behaves as expected.

Setting up the testing environment: The concept of mixins and test preamble will be discussed. Mixins are reusable code snippets that can be used across multiple tests, while the test preamble sets up the testing environment by defining the necessary dependencies and configuration.

Client satisfaction: We will learn how to organize our steps and make sure that all client requirements are covered using Gherkin syntax. Gherkin is a language used to write human-readable test scenarios that can be understood by both developers and clients.

Trying a new approach of coverage by extending our tests' use cases: By extending our test use cases, we can increase the coverage of our tests and improve the reliability of our test suite.

A bug was found: How to use regression testing to avoid it never comes back: If a bug is found, regression testing can be used to ensure that the bug does not reappear in future releases.

In conclusion, BDD is a useful approach for testing user interfaces in Angular as it focuses on the behavior of the system, rather than just its implementation. By setting up a testing infrastructure using BDD and following best practices such as mixins, Gherkin syntax, and regression testing, developers can create a robust and reliable test suite for their user interfaces.

Customizing Angular-Runtime modification of Web Apps with Module Federation

Ilyoskhuja — Mon, 30 Jan 2023 03:57:39 +0000

Module Federation is a feature in Angular that allows for modifying and customizing the runtime of web applications. It allows developers to split a monolithic application into smaller, independent modules that can be developed and deployed separately. This provides a number of benefits, including increased scalability, improved maintainability, and faster development times.

In this article, we will go through the steps to customize an Angular application using Module Federation. To follow along, you will need to have a basic understanding of Angular and its architecture.

Step 1: Set up the main application

To begin, we need to set up the main application that will host the federated modules. In this example, we'll call it the "shell" application. The shell application should have its own set of dependencies and a default routing configuration.

Step 2: Create the federated modules

Next, we will create the federated modules that will be added to the main application. Each module should have its own set of dependencies and a unique routing configuration.

Step 3: Configure the federated modules

To configure the federated modules, we need to add a "remotes" property to the shell application's angular.json file. This property should include the name and location of each federated module.

Step 4: Update the main application's routing configuration

Once the federated modules have been added to the shell application, we need to update the main application's routing configuration to include the routes from each module. This can be done by using the Angular Router's lazy-loading feature.

Step 5: Deploy the application

Finally, we can deploy the application and test it to see if everything is working as expected.

In conclusion, customizing the runtime of an Angular application using Module Federation provides a number of benefits, including increased scalability, improved maintainability, and faster development times. By following these steps, you can get started with customizing your own Angular application using Module Federation.

How to Build Angular Applications for Performance Optimization

Ilyoskhuja — Mon, 30 Jan 2023 03:53:01 +0000

Building high-performing Angular applications is critical for providing a smooth user experience and ensuring the application's success. Here are some steps to optimize Angular applications for performance:

Lazy Loading: Use lazy loading to defer loading of non-critical components until they are actually needed. This reduces the initial loading time and improves overall performance.

Use Ahead-of-Time (AoT) Compilation: AoT compiles Angular components and templates at build time, improving runtime performance and reducing the size of the application.

Minimize the Size of Dependencies: Keeping the size of dependencies small helps reduce the overall size of the application, making it faster to download and run.

Use Change Detection Strategies: Angular provides multiple change detection strategies, including OnPush and Default. Choose the most appropriate strategy for your use case to optimize change detection performance.

Use the Angular CLI: The Angular CLI provides a variety of performance optimization features, such as tree-shaking, which removes unused code, and minification, which reduces the size of the application.

Use a Production Build: Use a production build for deploying to production, as it includes performance optimizations such as minification and tree-shaking.

Monitor Performance: Regularly monitor the performance of your Angular application and make performance improvements as necessary. Use tools like the Angular Performance Tools and the Chrome DevTools Performance tab to get a detailed understanding of performance issues.

Example: Let's say we have an e-commerce application with a home page that displays a list of products. To optimize the performance of this page, we could:

Use lazy loading to defer loading the product details component until a user clicks on a product.

Use AoT compilation to compile the home page components at build time.

Minimize the size of dependencies by using a light-weight library for product images.

Use the OnPush change detection strategy, as the list of products is unlikely to change frequently.

Use the Angular CLI to build a production version of the application, which will include performance optimizations such as minification and tree-shaking.

Monitor the performance of the home page regularly, and make improvements as necessary.

By following these steps, you can build Angular applications that are optimized for performance, providing a smooth user experience and ensuring the application's success.

Import Maps- The Next evolution step for MicroFrontends

Ilyoskhuja — Mon, 30 Jan 2023 03:42:38 +0000

Import Maps is a relatively new browser feature that provides a way to control how modules are resolved and loaded in a web application. It enables developers to map a module identifier to a specific location, allowing them to load dependencies in a more organized and flexible manner. This feature is particularly useful for microfrontends, which are a popular architecture pattern in web development that involves breaking down a monolithic frontend application into smaller, independent components. In this article, we'll explore how Import Maps can be leveraged in Angular, a popular frontend framework, to further improve the development and maintenance of microfrontends.

Import Maps in Angular
Angular, like many other frontend frameworks, uses JavaScript modules to organize code into reusable components. With modules, you can import dependencies into your application and use them in your code. However, when building microfrontends, the module resolution mechanism can become more complicated, especially when trying to share common dependencies across multiple microfrontends.

Import Maps provide a solution to this problem by allowing developers to specify how module identifiers should be resolved and loaded in their applications. With Import Maps, developers can specify a mapping between a module identifier and a specific location where the module can be loaded from. This means that instead of hardcoding the module location in the application code, you can use an import map to configure it dynamically.

Setting up Import Maps in Angular
To use Import Maps in Angular, you first need to add the import maps polyfill to your application. The polyfill provides support for Import Maps in older browsers that do not support the feature natively. Next, you can create an import map file in your application and add the mappings you need. Here's an example import map:

{
  "imports": {
    "lodash": "/node_modules/lodash/lodash.js"
  }
}

In this example, we're mapping the lodash module identifier to the location of the lodash library in the node_modules directory.

Once you have created the import map, you can reference it in your application by adding the following code to your HTML file:

<script type="importmap">
  {
    "imports": {
      "lodash": "/node_modules/lodash/lodash.js"
    }
  }
</script>

With this setup, you can now use the lodash library in your Angular application by importing it using the module identifier lodash.

Benefits of Using Import Maps in Angular
The use of Import Maps in Angular provides several benefits, including:

Improved maintenance: By using Import Maps to map module identifiers to specific locations, you can make changes to the location of dependencies in your application without having to update the code that uses them. This makes it easier to maintain your microfrontends as they grow and change over time.

Better organization: Import Maps allow you to better organize your dependencies by mapping them to specific locations. This makes it easier to find and manage your dependencies, especially in large and complex applications.

Better performance: Import Maps provide a way to load dependencies in parallel, improving the overall performance of your application.

Improved compatibility: By using Import Maps, you can make sure that your dependencies are loaded correctly and consistently across different browsers and platforms, even if they have different module resolution mechanisms.

In conclusion, Import Maps are a powerful tool for improving the development and maintenance of microfrontends in Angular. By using Import Maps,

Hexagonal Architecture in Angular: An Overview with an Example

Ilyoskhuja — Mon, 30 Jan 2023 03:37:44 +0000

Hexagonal Architecture, also known as Ports and Adapters, is a software design pattern that focuses on the separation of concerns. It's a way to structure applications in such a way that they are decoupled from external factors like databases, third-party APIs, and user interfaces. In Angular, this architecture can be applied to build scalable and maintainable applications.

In a hexagonal architecture, the application is seen as a central core with different ports for different external systems. The core contains the business logic and interacts with external systems through adapters. The core is isolated from changes in external systems, making the application more flexible and adaptable.

Example of Hexagonal Architecture in Angular

Here is an example of how you can implement hexagonal architecture in Angular:

Core: The core contains the business logic of the application. It is the central component and should have no knowledge of external systems. The core is responsible for processing inputs and producing outputs.

Ports: Ports are the interfaces between the core and external systems. They define what the core needs from external systems and what it provides to them.

Adapters: Adapters are the components that implement the ports. They translate data between the core and external systems.

Let's consider a simple to-do application where the core is responsible for creating, reading, updating, and deleting to-do items. The user interface is an external system, and the database is another external system.

In this example, the core has two ports: one for the user interface and one for the database. The user interface port provides methods for retrieving and saving to-do items. The database port provides methods for reading and writing to-do items from the database.

The adapters for the user interface and database ports implement the methods defined in the ports. The user interface adapter communicates with the user interface to retrieve and save to-do items. The database adapter communicates with the database to read and write to-do items.

Benefits of Hexagonal Architecture in Angular

Increased Flexibility: The separation of the core from external systems makes the application more flexible. Changes to external systems do not affect the core, and the core can continue to operate even if external systems are unavailable.

Improved Testability: The isolation of the core makes it easier to test. The core can be tested in isolation, without the need for external systems. This improves the reliability and maintainability of the application.

Improved Scalability: The separation of the core from external systems makes it easier to add new features and scale the application. New external systems can be added without affecting the core.

Conclusion

Hexagonal architecture is a powerful design pattern that can be used to build scalable and maintainable applications in Angular. By separating the core from external systems, the application becomes more flexible, testable, and scalable. The example provided in this article is a simple demonstration of how hexagonal architecture can be applied in Angular. With this architecture, you can build complex applications that can adapt to changing requirements and grow over time.

Ngrx - Core Principles & New Features

Ilyoskhuja — Mon, 30 Jan 2023 03:30:22 +0000

Ngrx is a powerful and popular library for building reactive applications in Angular. It provides a complete set of tools for managing state and side effects in your application. In this article, we'll cover the core principles of Ngrx and explore some of its new features.

Core Principles

Immutable State: Ngrx stores state as an immutable data structure, which means that state cannot be changed directly. Instead, state changes must be performed through actions and reducers.
Unidirectional Data Flow: Ngrx follows the unidirectional data flow pattern, where data flows in a single direction from actions to reducers to state.
Separation of Concerns: Ngrx separates state management from business logic, making it easier to maintain and test your application.

New Features

Facades: Ngrx 8 introduces facades, which provide a simple and intuitive way to access and manipulate state from components. Facades are generated automatically for you, and you can use them just like any other service in Angular.
Example:

@Injectable()
export class ProductsFacade {
  products$ = this.store.pipe(select(selectAllProducts));

  constructor(private store: Store<AppState>) {}

  addProduct(product: Product) {
    this.store.dispatch(addProduct({ product }));
  }
}

Actions: Ngrx 8 also introduces a new and improved way to create actions, using the createAction function. This makes it easier to define and manage your actions, and also provides better type checking for your action payloads.
Example:


export const addProduct = createAction(
  '[Products] Add Product',
  props<{ product: Product }>()
);

Selectors: Ngrx 8 provides improved support for selectors, making it easier to select and manipulate state in your application. Selectors can now be created as simple functions, and you can also use memoization to optimize performance.
Example:

export const selectAllProducts = createSelector(
  selectProductsState,
  (state: ProductsState) => state.products
);

In conclusion, Ngrx provides a powerful and flexible toolset for building reactive applications in Angular. With its core principles of immutability, unidirectional data flow, and separation of concerns, and its new features like facades, actions, and selectors, Ngrx makes it easier to build and maintain complex applications.

Streamlined Page Title Accessibility in Angular

Ilyoskhuja — Mon, 30 Jan 2023 03:19:57 +0000

Page titles play a crucial role in website accessibility, as they provide context and help users understand the content of a web page. In Angular, setting the page title dynamically can be achieved through various methods, but a common and efficient approach is using the Title service.

Here's a step-by-step example of implementing dynamic page titles in Angular:

Import the Title service in the component:

import { Title } from '@angular/platform-browser';

Inject the Title service in the component's constructor:

constructor(private title: Title) {}

Set the title in the component's ngOnInit lifecycle hook or in a method that gets called whenever the title needs to change:

ngOnInit() {
  this.title.setTitle('Page Title');
}

Include the title tag in the component's template file:

<title>{{title}}</title>

With these steps, the page title will now dynamically change based on the component's logic.

It's also a good practice to add meaningful and descriptive titles for each page, making it easier for users and search engines to understand the content of a web page. Moreover, screen readers and other assistive technologies use the page title to provide context to users with disabilities.

In conclusion, implementing dynamic page titles in Angular is straightforward and can greatly improve the accessibility of a website. By using the Title service and following best practices, developers can ensure that their pages are accessible and user-friendly.

The State of End-to-end Testing with Angular - Prepare for Protractor Deprecation

Ilyoskhuja — Mon, 30 Jan 2023 03:10:56 +0000

Angular is a popular open-source framework for building web applications, and end-to-end (e2e) testing is a crucial part of ensuring that your application is working as expected. However, with the recent deprecation of Protractor, the e2e testing landscape for Angular has changed significantly. In this article, we'll explore the state of e2e testing with Angular and provide a step-by-step guide to prepare for the deprecation of Protractor.

What is End-to-end Testing?

End-to-end testing is a type of testing that involves testing an application from start to finish, simulating the user's experience. This type of testing helps to catch bugs and issues that may not have been detected through unit or integration testing. With Angular, e2e tests are written using the Protractor framework.

Why is Protractor being Deprecated?

Protractor was developed as an open-source e2e testing framework for Angular applications. However, over time, it has become increasingly complex, and its performance has become a concern for many developers. Additionally, Protractor is built on top of the deprecated WebDriverJS library, which has made it difficult to maintain and update. As a result, the Angular team has decided to deprecate Protractor and replace it with a new e2e testing tool called Playwright.

How to Prepare for Protractor Deprecation?

If you're currently using Protractor for e2e testing in your Angular applications, it's important to start planning for the transition to Playwright. Here's a step-by-step guide to help you prepare:

Review your existing e2e tests: Take a look at your existing e2e tests and make a list of any test cases that you need to migrate to Playwright.

Install Playwright: Playwright can be installed as a node module by running npm install -g playwright.

Write Playwright tests: Playwright tests are written in JavaScript and are similar in structure to Protractor tests. Start by writing simple tests for your most important features and work your way up to more complex tests.

Run your tests: Once you have written your tests, you can run them using the Playwright CLI by running playwright run .js.

Debug and refine: As with any new testing tool, you may encounter bugs or issues. Use the Playwright debugging tools to identify and resolve these issues.

In conclusion, the deprecation of Protractor marks an important turning point in the development of Angular e2e testing. However, by following the steps outlined in this article, you can prepare for this change and ensure that your Angular applications continue to be thoroughly tested and bug-free.

Angular CLI Auto-Completion: Streamlining Your Workflow

Ilyoskhuja — Mon, 30 Jan 2023 03:05:51 +0000

Angular CLI Auto-Completion: Streamlining Your Workflow

The Angular CLI is an essential tool for developers working on Angular projects. It provides a simple and efficient way to manage your project and perform common development tasks. One of its key features is the auto-completion capability, which streamlines your workflow and saves you time.

How to Enable Angular CLI Auto-Completion

To enable auto-completion for the Angular CLI, you will need to install the bash-completion package. This can be done by running the following command:

npm install -g bash-completion

Once the package is installed, you can activate auto-completion by adding the following line to your .bashrc file:

source <(ng completion)

Now, whenever you use the Angular CLI in your terminal, you will have access to the auto-completion feature.

Using Angular CLI Auto-Completion

To see the power of auto-completion in action, let's look at an example. Suppose you want to create a new Angular project. You can start by typing the following command:

ng new

Now, instead of typing out the entire command, you can press the Tab key. You will see a list of suggestions, including options like "--routing" and "--style". You can use the arrow keys to navigate the list and select the option you want to use.

The auto-completion feature is also available when you work with existing projects. For example, if you want to generate a new component, you can start by typing the following command:

ng generate component

Again, press the Tab key to see a list of suggestions, including options like "--inline-template" and "--inline-style".

Conclusion

The Angular CLI auto-completion feature is a valuable tool for streamlining your workflow and saving time. By providing suggestions for available commands and options, it reduces the need for manual typing and helps you avoid errors. Give it a try today and experience the difference it can make in your Angular development process.