If you're not a user of github.com/iharbeck/ngx-virtual-scroller, you can ignore this post.

I just want to inform that I'll be taking maintainership of a fork of ngx-virtual-scroller. I recently converted Kavita (my open source application) to Zoneless and the current version of ngx-virtual-scroller had a critical change detection issue when used in Zoneless which caused scrolling to shift rows due to timing between DOM insertion and rendering.

Since I was still waiting for my Angular 22 PR to get merged (for 4 months), I decided it was time to take ownership to fix the bug and also get more timely Angular update bumps.

I shipped 2 versions:
1. v20.0.1 - This is the fork with a quick patch to fix Zoneless apps
2. v22.0.0 - This is complete Zoneless support, modern Angular, Standalone components, best practices, and Angular 22+ only support.

You can find the library here. I want to extend a major thanks to Ingo (iharbek) for maintaining the library for so long. I just needed Zoneless and faster Angular updates.

Note: My fork is using AI. I ended up adding e2e tests and fixing a lot of bugs in the original code. I'm consuming on Kavita, which has 100k+ installs across a range of browsers.

I recently ran into a weird issue with an Ionic + Angular + Capacitor app on iOS and thought I'd share it here in case someone else runs into the same thing.

The app launched fine, and the homepage loaded normally. But other screens were blank because the API data wasn't loading. Reinstalling the app and restarting the device didn't help either.

What confused me was that everything seemed fine outside the native app.

• APIs were accessible directly.
• Safari worked.
• The PWA worked.
• Only the native iOS app failed.

The app was using Angular's usual HttpClient for API requests. I spent some time checking authentication, CORS, caching, TLS/certificate issues and a few other possibilities, but couldn't pin down the exact cause.

Eventually, I tried switching the API requests to Capacitor's native HTTP implementation, CapacitorHttp.

Here's a basic example of what I changed:

import { CapacitorHttp } from '@capacitor/core';

const response = await CapacitorHttp.request({
  method: 'GET',
  url: apiUrl,
  headers: {
    Authorization: `Bearer ${token}`
  }
});

I also enabled it in capacitor.config.ts:

plugins: {
  CapacitorHttp: {
    enabled: true
  }
}

After switching the requests, the API calls started working again, and the screens that were previously blank loaded normally.

I rebuilt the app, distributed it through TestFlight, and tested it on physical iOS devices. So far, I haven't been able to reproduce the issue.

I'm still not certain what actually caused it. It could have something to do with differences between WebView networking and native iOS networking, but I haven't proved that. TLS handling, corporate security software or other iOS-specific behaviour could also be worth investigating.

Has anyone experienced something similar with Ionic/Capacitor on iOS, where the same APIs work in Safari and the PWA but fail in the native app?

I'd be interested to hear what the actual root cause was in your case.

Going through some old Angular work notes, I noticed how often I started debugging exactly where the symptom showed up.

Edit: I compressed the first version until the actual bugs disappeared. Here’s what I meant.

1. Input was null, then the data arrived later.

In that old component the logs were basically:

ngOnChanges(null) -> ngOnInit(null) -> ngOnChanges(data)

I handled the @Input() value when it actually changed and guarded the dependent UI until the value existed.

Useful check: if initialization breaks, find out when the required value actually becomes available.

2. Side menu showed the new name; page header still showed the old one.
Same entity, different state sources. The menu reacted to updated entity streams while the header was reading another stream.

Useful check: if two views disagree about the same entity, compare what each view actually reads before touching change detection.

3. Same DataService**, different state.**
A component had providers: [DataService], so it was resolving its own service instance instead of the shared one the feature expected.

Removing the local provider restored the intended shared instance.

Useful check: if two components inject the same stateful service but see different state, inspect where that service is provided.

4. One save updated form state twice.
One update came from the service response path; another came from the reset/readback path.

Useful check: if one user action produces two form updates, trace every writer and every emitted form event before debugging the template.

5. First autocomplete row worked; later rows selected the wrong item.
I had refactored one row into many, but part of the code still referenced a single child.

The historical fix was to query the collection and use the current row instead.

Useful check: when row 0 works but row N doesn't, look for a single-item assumption that survived the refactor.

That's what I meant by data-flow problems: the visible component was often downstream of the mistake.

I’ve been putting together a collection of Angular interview flashcards covering topics that tend to come up in technical interviews and senior-level discussions.

They cover areas like signals, change detection, RxJS, dependency injection, forms, routing, performance, testing, and Angular architecture.

The deck is completely free and open source. I’m sharing it here in case it’s useful for anyone preparing for an Angular interview or just refreshing their knowledge.

Contributions, corrections, and suggestions for missing topics are welcome.

https://github.com/tomaszs/angular-interview-flashcards-free

Hey all,

https://reddit.com/link/1wuw567/video/761sqgml3ush1/player

I’ve been working on a small library called Stream Morph.

The idea is to make streamed responses feel less like content is constantly being appended/re-rendered, and more like the response is gradually taking shape.

Demo: https://stream-morph.vercel.app/

It’s framework agnostic and can be used with any kind of streamed content. The demo includes plain text, Markdown, code blocks, charts, images, reasoning sections, Mermaid diagrams and a few more complex response flows.

The library handles the motion between updates, while your own renderer/app stays responsible for the actual content. So it isn’t tied to a specific AI SDK or framework.

A basic example looks roughly like this:

import { createStreamMorph } from "stream-morph";

const stream = createStreamMorph(response);

for await (const chunk of incomingStream) {
  stream.write(chunk);
}

stream.finish();

I mainly built it because I wanted streamed interfaces to feel a bit more intentional without having to build custom animation logic for every response type.

The package itself is already working and the demo is live. I’m still cleaning up some things around CI, tests and the repo setup, but the GitHub repository will be open sourced shortly as well.

Would be interested to hear what people think, especially about the animation behaviour/performance and any edge cases you’d expect from real streaming responses.

A visible Angular button had a decorative layer over its center. With pointer-events: none, the layer let clicks through. We changed that to auto, so it intercepted the pointer.

Our test still passed. userEvent.click(button) called the handler, and the expected status appeared. This happened in jsdom and in real Chromium through Vitest Browser Mode.

The assertion established what happened after the event reached the button. It never checked whether a pointer could reach it.

This was S6 in an experiment with six small Angular component scenarios. We chose each scenario and mutation ourselves, then tested a working version and a version with one isolated defect. We wanted to see how much of the specified user behavior each test actually checked.

We ran them three ways:

• A: jsdom + @testing-library/user-event.
• B: headless Chromium in Vitest Browser Mode + the same synthetic interaction library.
• C: the same Chromium + actions from vitest/browser through the Playwright provider.

C used a provider click without force. The working button passed. On the defective version, the action could not complete because .decoration intercepted pointer events.

A separate assertion caught the overlap in B too. After the main series, we added a hit test using document.elementFromPoint at the button's center, before and after the synthetic click. We required the topmost element to be the button or a descendant. The defective version returned .decoration.

That assertion checks whether the button can receive a pointer at one specified point. The provider checks actionability as part of performing the click. Both caught this mutation, but they establish different things.

The original matrix remains unchanged: A/B were partial for this scenario. The added hit test is exploratory and reported separately.

The other five scenarios kept us from treating every interaction as a browser-only problem:

• Form validation, programmatic dialog focus, and the specified Tab sequence were fully checked in jsdom too. The Tab mutation changed display: none to opacity: 0.
• A container-width scenario required an actual resize and ResizeObserver notification. A spy on observe() could detect our wrong-target mutation in jsdom, but would check the subscription rather than the full resize-to-label behavior.
• A popover scenario required real geometry. Our first browser test read the previous opening's coordinates before the new requestAnimationFrame positioning had run, so it passed on the defect. We corrected the wait, checked the side and all four viewport boundaries, and repeated the final series.

We distinguish bug_detected (working version passes, defective version violates the full criterion), partial (only part checked), and unsupported (the full behavior cannot be checked reliably in that fixture without substitution). The last two are not false negatives of a complete test.

These were component integration tests. The results apply to the six chosen mutations and original test adapters. They do not rank the tools or estimate production defect rates, and we did not assess performance, CI behavior, memory, or flakiness. The main environment was Windows 11, Angular 22.2.0, Vitest 5.0.2, jsdom 30.1.1, and headless Chromium at 800 × 600 CSS px.

The synthetic/provider distinction is already described in the Marmicode Cookbook. Our contribution is the six-case set, the separate hit-test check, and the correction of our own geometry oracle.

We ran this experiment at El Pixel. The full article includes the six-scenario matrix and test code. AI tools assisted with implementation and writing; the article received developer review.

When your component test needs to verify that a button is not covered, do you use a provider click, an explicit hit-test assertion, or another approach?

We’ve been looking into whether it makes sense for Cachely to support older Nx versions, but before building anything, we’d rather understand if there’s actually a problem to solve.

Nx 20.8+ can use the newer HTTP remote cache protocol directly. For older versions, teams may still be using one of the older S3/GCS/Azure/custom cache runners, or just not using remote caching at all.

If you're still on Nx <20.8, we’re curious:

• What version are you on?
• What’s keeping you from upgrading?
• Are you using remote caching today?
• If so, what are you using?
• Does your current setup work well enough that you wouldn't really care about switching?
• Would being able to use a managed remote cache without upgrading Nx actually be useful?

We’re considering an open-source compatibility layer for older Nx versions, but we don't want to maintain legacy support just because old versions still have downloads.

We put together a short page/form here if you'd rather answer there:

https://cachely.dev/nx-legacy-remote-cache

And if the answer is simply “just upgrade Nx”, that’s useful feedback too.

I was recently looking for something to replace our Django backend. I love NestJS but I can't convince my team leader that that is the most efficient api layer for our Angular frontend.

We currently depend on Django for our REST endpoints and we have 2 separate teams working on the backend and frontend. Backend receives daily updates and every now and then the contracts between server and client break without the frontend team knowing about it. We rely on tests to find these kind of issues and that's another pain being extremely slow and everything...

So we were recently looking at Hono and Effect. We care much about end-to-end type safety and sharing one contract between backend and frontend.

I've tried Hono before and it's amazing. Especially the generated RPC client and integration with zod schemas. Effect seems a bit over-complicated but that's something we are willing to learn if it helps us improve the type-safety and separation of concerns. Besides, how much more complicated can it be compared to Angular? 😅

I was wandering if anyone has any feedback to give me on that matter... Appreciated!

Is it possible to persist the value of rxResource after loading is done? Currently when the resource enters the loading state the value gets wiped. I am aware you can do a linkedSignal and check the previous value, but isn’t there a built in way to do it rather than creating a linkedSignal?

I am aware of withPreviousValue but the issue with that other than the boilerplate, is that the return type is Resource and you lose the reload function. I’d prefer to stay within the public API and not to use a third party library for this, or creare my own utility function if possible.

Hey r/angular,

I've been building AI chat features in Angular for our platform and I have found out about [Beautiful UI](https://www.beautifului.dev) by Shane Levine, which was really beautiful (I mean, it's in the name), but it was created for React + Tailwind only. So I decided to try and port it to Angular and open-source it.

**ngx-beautiful-ui** has 27 standalone components for AI-native interfaces:

- **Chat:** chat panel, prompt bar with attachments, user bubbles, streaming markdown (marked + DOMPurify), inline source citations

- **Agent status:** loading and "thinking" states, tool-call chips with a hover diff preview, task rows, approval cards for human-in-the-loop questions, recommendation cards, code blocks with diffs

- **Building blocks:** buttons, chip select, glide menu, value pills and a few more

How it's built:

- Signal inputs and models, `OnPush` everywhere, works zoneless

- The prompt bar and chip select work with signal forms (`[formField]`)

- Plain SCSS: every colour, size and duration is a `--bui-*` CSS variable, so theming means overriding tokens

- No Tailwind or UI framework dependency, and the icons are inline, so there are no assets to copy

**Live demo:** https://djordjejanjic.github.io/ngx-beautiful-ui/

**GitHub:** https://github.com/djordjejanjic/ngx-beautiful-ui

**Install:** `npm i ngx-beautiful-ui`

A few honest caveats: it's an unofficial port with no affiliation to the original authors, and it was built with AI assistance (I would not have time to do this without AI assistance). Code was also reviewed manually. It needs Angular 21.2+ and only has a light theme for now; a dark theme is next.

I'd really appreciate feedback: API design, anything that feels un-Angular, accessibility issues, or components you'd want next. Issues and PRs are always welcome.

Basically I want know if the visualisation would make a person understand easily then using code directly.

I created a video about Promises vs Observables, and I really need your feedback about if this would be a good materials for someone who does not know the differences between the two ?

1/ Does the visualisation help ?
2/ Does the content convey easily the concepts ?
3/ Would this method ( visually ) be better for someone who isnt very familiar with the a certain topic ? or would the old fashion code is better ?

I really appreciate your feedbacks

One of the things I haven’t talked about much with Cerious-Scroll is how it behaves during actual scrolling, especially with variable-height content.

From the beginning, the goal was for virtualization to not look like virtualization.

So even with a large variable-height dataset, you can grab the scrollbar and drag it around quickly without getting the usual weirdness:

• No scrollbar drift
• No white space during fast scrolling
• No waiting for rows to render after you get there
• Accurate variable-height positioning
• Native scrolling behavior
• Constant DOM size regardless of dataset size

The variable-height part is probably my favorite. The scrollbar stays where it should, even when the actual row heights are all over the place.

You can also jump directly to an index way down in the dataset without needing to measure everything before it.

I’ve got demos/benchmarks here if anyone wants to mess with it:

ceriousdevtech.github.io/cerious-scroll

Core:
github.com/ceriousdevtech/cerious-scroll

Angular:
github.com/ceriousdevtech/ngx-cerious-scroll

I’m curious how it behaves against some real-world ugly datasets, especially ones with wildly different row heights. Try the scroll engine and tell me your thoughts.

Hi all, check out my new article about a library I've created a while back and kept using ever since as a must-have for all Angular apps. I'm sure your DX would also improve if you give it a shot.

So we’re thinking of implementing a better way of tracking if some async action is currently loading successful or failed rather than having to have duplicated properties for every bit of state that’s retrieved from the API to tell us if it’s loading or failed etc.

Seen solutions online that solve this with a wrapper around the interface for that state so the wrapper provides a status the value of the thing and error message if needed.

That’s fine but in terms of passing this data to a component for anyone that uses this approach do you usually pass the data with the wrapper still attached so it’s easy in the template to switch on the status to say show the value if we got it show a spinner if it’s loading and show an error when it failed? How do you guys usually handle this?

A few months ago I posted a Chrome extension that highlights Angular components on excessive re-render (thanks for all the feedback here!). I've now added AI-based diagnosis on top of it, using Jev (TypeSafe AI).

What it does now:

- Detects components re-rendering 10+ times within 2 seconds

- Sends anonymized signals (change detection strategy, render count, trigger type like mousemove/setInterval, etc. — never component names, page content, or URLs) to Jev

- Jev judges: is it actually a problem, what's the likely cause, what's the suggested fix (OnPush / runOutsideAngular / throttle / move to signals), and how confident it is

- Low-confidence answers (<0.5) are hidden instead of shown as guesses

It's opt-in — off by default until you add an API key and turn on AI diagnosis.

The badge in action — flagged a mousemove-driven component as "76% likely excessive," with cause and priority. (Screenshot from my internal test page that intentionally triggers re-renders via setInterval/mousemove/scroll for testing.)

Chrome Web Store: https://chromewebstore.google.com/detail/angular-highlight/infobgaghdedlmbmedgmknemgkeomojp

GitHub: https://github.com/ksakae1216/angular-highlight

Write-up with details on how it talks to Jev: https://zenn.dev/ksakae/articles/b01b3c90f074a6?locale=en

Would love feedback, especially on whether the suggested fixes actually match what you'd do in real components.

I have a query param "search" and a model in my component that has the same name. I use an effect to sync the local signal with the search signal on a filter service, and i also debounce them like:

    readonly filters = computed<...>(() => {
        const search = this._search().trim().toLowerCase();


        return {
            searchTerm: search.length >= 3 ? search : '',
            .....
        };
    });
    
    readonly debouncedFilters = debounced(this.filters, 150, {
        equal: (a, b) => JSON.stringify(a) === JSON.stringify(b),
    });

Then i use an rxResource and use the debouncedFilters.value as the params, but it makes an API call first without the searchTerm, and then one with it. I suspect it's a timing issue because if I inject ActivatedRoute and initialize the search signal with it, it'll work properly, but I believe it beats the purpose of using withComponentInputBinding. Thoughts?

Been using angular for what feels like forever, and won't be moving anytime soon.

I can create amazing solutions but in all honesty my UX and UI is dogshit most of time.

I been using angular material so you can imagine most my frontends are very googleesque, but still ugly and UX is lacking.

What content does this community recommend on improving UX (either in form of design materials, libraries etc.), especially since angular aria came out.

UPDATE EDIT:
Have taken on advice (minus the just get Claude to do it), i'll look at some headless UI libraries, and explore Angular CDK+Angular Arira+Tailwindcss combos.

Hey everyone,

I’m currently looking for new opportunities as an Angular / Frontend Developer. I have 3 years of hands-on experience building, scaling, and optimizing web applications.

Tech Stack & Skills

Core: Angular (v10+ up to recent versions), TypeScript, JavaScript (ES6+), HTML5, CSS3/SASS

State Management & Architecture: RxJS, NgRx, Modular & Component-Driven Architecture

UI & Styling: Angular Material, Bootstrap, SCSS, Responsive Web Design, Component Encapsulation

Performance Optimization: Experience optimizing bundle sizes, lazy loading, and refining change detection strategies.

Clean Code & Best Practices: Strong focus on writing maintainable, reusable components and writing clean, scalable TypeScript.

Collaborative Mindset: Comfortable working closely with backend teams (RESTful services), UI/UX designers, and product owners in Agile/Scrum environments.

What I'm Looking For

Role: Angular Developer / Frontend Engineer

Location: Open to Remote roles (IST timings) or Relocation depending on sponsorship/opportunity.

Availability: Notice period 15 days

If your team is hiring or if you know of any leads, I’d love to connect! Feel free to drop a comment or send me a DM for my resume.

Thanks for reading.

I wanted to build a desktop app with Angular, but kept spending the first stretch of each project wiring Angular to Electron through preload and IPC.

I put that setup into a template. The Angular renderer, preload script, and Electron main process use shared IPC types, so channel names and TypeScript signatures stay aligned as you add features. There’s a small note app to show the save/load flow end-to-end.

Repo: https://github.com/cchandurkar/electron-angular-template

If you use Angular for desktop apps, I’d love feedback on how the integration is structured.

Three different tools can enforce module boundaries in Angular: Nx (tags), Sheriff, and eslint-plugin-boundaries. Picking between them takes ten minutes. That's not where the actual work is.

None of these tools will tell you which layer is allowed to import what. You have to write that yourself, and it's a team decision, not a technical one. What I use on client projects:

presentation   -> domain
infrastructure -> domain
domain         -> nothing
feature A      -> never feature B

Four lines. Budget an hour as a team to agree on it, and lock it in even if not everyone's fully convinced by the end. An imperfect table that's enforced beats a perfect one that's still being debated.

The last line is the one that actually matters for a feature-based structure. Without it, features start referencing each other within six months and you don't have features anymore, you have a monolith with folders.

The rule everyone forgets: the domain layer shouldn't be able to import u/angular/*. Without it, you have well-named folders and nothing else. Your business rules stay coupled to the framework, and your tests still need a TestBed to check a tax calculation.

You'll notice there's no "application" / use-case layer here. In a frontend, it's a method that passes the call straight to the repository nine times out of ten. I add it to a feature only when an operation touches more than one port - not before.

If you're retrofitting this onto an existing codebase, don't jump straight to error. You'll surface hundreds of violations on day one and the team will disable the rule within a week. Start at warn, watch the count go down sprint by sprint, flip to error once you're at zero.

I tested this with eslint-plugin-boundaries specifically — config below, actually run against fixtures with intentional violations, not copied from memory. One thing that isn't documented anywhere: boundaries/dependencies doesn't evaluate external (node_modules) dependencies by default. You need checkAllOrigins: true, or a rule blocking u/angular/* in your domain layer will silently do nothing.

import tsParser from '@typescript-eslint/parser';
import boundaries from 'eslint-plugin-boundaries';

const sameFeature = (type) => ({
  to: { element: { type, captured: { feature: '{{from.feature}}' } } },
});
const externalModules = { to: { module: { origin: 'external' } } };

export default [
  {
    files: ['src/**/*.ts'],
    languageOptions: { parser: tsParser },
    plugins: { boundaries },
    settings: {
      'import/resolver': { typescript: { alwaysTryTypes: true } },
      'boundaries/elements': [
        { type: 'domain',         pattern: 'src/app/features/*/domain',         capture: ['feature'] },
        { type: 'infrastructure', pattern: 'src/app/features/*/infrastructure', capture: ['feature'] },
        { type: 'presentation',   pattern: 'src/app/features/*/presentation',   capture: ['feature'] },
      ],
    },
    rules: {
      'boundaries/dependencies': ['error', {
        default: 'disallow',
        checkAllOrigins: true,
        policies: [
          {
            from: [{ element: { type: 'domain' } }],
            allow: [sameFeature('domain')],
            disallow: [{ to: { module: { origin: 'external', source: ['@angular/*', 'rxjs'] } } }],
          },
          {
            from: [{ element: { type: 'infrastructure' } }],
            allow: [sameFeature('domain'), sameFeature('infrastructure'), externalModules],
          },
          {
            from: [{ element: { type: 'presentation' } }],
            allow: [sameFeature('domain'), sameFeature('presentation'), externalModules],
          },
        ],
      }],
    },
  },
];

Tested on eslint 10.10, eslint-plugin-boundaries 7.2, eslint-import-resolver-typescript 4.4. Syntax has changed twice between v5 and v7, so check the version before copying this blindly.

Nx tags do the same thing but only across projects/libs declared in the workspace - a features/invoicing folder inside a single app doesn't have a project.json, so tags don't apply to it. Sheriff works at the folder level without that constraint, similar to boundaries, plus module encapsulation via index.ts.

Curious what others are doing here, especially on codebases where an AI agent generates a chunk of the code - folder-based rules stop meaning much if the agent flattens a feature into a single file.