Last Thursday at 11 PM, I was staring at a NullInjectorError that made absolutely zero sense. If you write Angular, you know the exact feeling. The stack trace was a useless wall of Zone.js garbage, and my app was completely white-screening on load.
I was migrating an older enterprise dashboard to Angular 19.2. We had standalone components everywhere, signals mixed with legacy RxJS behavior subjects, the works. But somewhere in a 40-deep component tree, a core service was instantiating twice, completely wiping out the user session state.
I spent two hours putting console.log('init') inside constructors. A terrible approach, I know. But when you’re tired and the standard Chrome debugger isn’t helping, you get desperate.
Then I remembered the Resource Visualization tab they recently pushed into Angular DevTools. I hadn’t actually bothered clicking it yet because I usually just stick to the component tree inspector. I assumed it was just another performance profiler I didn’t need.
I fired it up. And honestly? It felt like someone finally turned the lights on in a dark room.
Instead of a flat, unreadable list of providers, it renders an actual dependency graph. You can see exactly which component is holding which instance of a service, its lifecycle state, and exactly when it gets destroyed.
Here’s the kind of mess that usually breaks silently in large codebases:
@Injectable({ providedIn: 'root' })
export class UserContextService {
// Seems fine until a lazy-loaded route decides
// to provide its own instance of MetricsService
private auth = inject(AuthService);
private metrics = inject(MetricsService);
private state = signal<UserState>('pending');
constructor() {
this.initializeSession();
}
}I found my bug in about 45 seconds using the visualizer. It turned out a lazy-loaded settings route was providing its own isolated instance of UserContextService because a junior dev left a providers: [UserContextService] array inside a wrapper component six months ago. The DevTools drew a very obvious, detached node showing the orphaned instance completely separated from the root singleton.
Before this update, finding that exact issue required either writing custom diagnostic scripts to track instance IDs or just getting lucky with a global text search. As the author of Stop Trusting Your Logs: Debugging Flask Properly, I can attest to the frustration of relying on logging alone for complex application issues.
I’m officially deleting my old custom logging interceptors. I don’t need them anymore. Being able to visually trace the lifecycle of a rogue dependency without touching the code is exactly what this framework needed.
The Catch (Because There’s Always One)
The docs don’t really mention this, but you need to be careful with how you use this tool on massive apps. I tested the visualizer on our staging environment—a massive monorepo with about 800+ provided-in-root services.
If you try to visualize the entire root injector at once, the DevTools will absolutely tank your browser performance. My M3 MacBook Pro actually spun up its fans, and the Chrome tab locked up for a solid ten seconds while it tried to render the SVG nodes.
The trick I figured out is to filter by specific feature modules or component sub-trees before you open the graph view. Narrow down your component tree first, then switch to the resource tab. It drops the rendering time from “go get a coffee” to instant.
Also, heads up: make sure your Angular DevTools extension is actually updated to the latest version. I was running an older build on my secondary monitor and noticed a bug where the dependency graph wouldn’t reset properly on hot module reloads (HMR). You’d change a file, the app would reload, but the graph would keep drawing duplicate ghost nodes from the previous compilation. The current version fixes this, but Chrome is notoriously lazy about auto-updating extensions.
Anyway. Back to deleting boilerplate.
