Complete Frontend Tutorial

Vue and Angular solve the same problem from opposite ends, and their error messages show it. Vue tracks dependencies at runtime, so its failures are about reactivity that quietly stopped working — a reassignment the tracker did not see, a render that triggers itself forever. Angular resolves everything up front through dependency injection and template compilation, so its failures are loud and structural: a provider that does not exist, a directive that was never imported, a binding target the compiler has never heard of.

Neither is harder than the other, but the debugging instincts do not transfer. In Vue you ask what is the tracker watching? In Angular you ask what did the injector and the compiler see? Every article in this track is an instance of one of those two questions.

Vue: reactivity is a proxy, and proxies have edges

Vue 3 makes state reactive by wrapping it in a Proxy that intercepts property access. Read a property during a render and Vue records the dependency; write it and Vue re-runs whatever read it. That mechanism is why Vue feels effortless, and also why reactivity 'breaks' in a small number of predictable ways: anything that replaces the proxy rather than mutating through it escapes tracking.

The classic case is destructuring. Pulling a primitive out of a reactive object copies its current value and hands you a plain variable with no connection to the source. Nothing warns you; the UI simply stops updating.

import { reactive, ref, toRefs } from 'vue'

const state = reactive({ count: 0, user: { name: 'Ada' } })

// Breaks reactivity: count is now a detached copy of the number 0
let { count } = state

// Keeps reactivity: refs stay connected to the source
const { count, user } = toRefs(state)

// Also breaks it: the local binding is replaced, the proxy is discarded
let s = reactive({ items: [] })
s = { items: newItems }            // component still watches the old object

// Mutate through the proxy instead
s.items = newItems                 // tracked
// or hold the value in a ref and replace .value
const items = ref([])
items.value = newItems             // tracked

Angular: NullInjectorError names the missing edge in a graph

Angular's injector is a tree, and NullInjectorError: No provider for X means the request walked from the component up to the root and found no provider anywhere on the path. That is nearly always one of four things, and the error text tells you which if you read what is asking rather than what is missing.

Since standalone components became the default, a fifth cause dominates new codebases: the thing is not missing from providers at all, it is missing from the component's own imports array. A standalone component must import every directive, pipe and module its template uses — there is no surrounding NgModule to inherit from any more.

ExpressionChangedAfterItHasBeenChecked, explained properly

This error only appears in development mode, which makes people assume it is cosmetic. It is not — it is Angular running change detection twice and finding a different answer the second time. In production the second pass does not happen, so the view keeps whatever the first pass produced and you get a stale or inconsistent UI instead of a console message.

The cause is always a value that mutates as a side effect of being read or rendered: a getter that increments a counter, a parent property written from a child's ngAfterViewInit, a template calling a function that returns a new object each time. The fix is to make the value stable during a pass — compute it once and store it, or defer the write to the next tick so it belongs to the following cycle.

// Problem: the child writes a parent-bound value during the same pass
ngAfterViewInit() {
  this.parentTitle = this.measureSomething();   // throws in dev mode
}

// Option 1 - defer to the next change-detection cycle
constructor(private cdr: ChangeDetectorRef) {}
ngAfterViewInit() {
  Promise.resolve().then(() => {
    this.parentTitle = this.measureSomething();
    this.cdr.detectChanges();
  });
}

// Option 2 - the usually-better fix: don't compute in the template at all
// Template:  {{ title }}        not  {{ buildTitle() }}
// Compute in ngOnChanges / a signal / a computed observable so the value
// is already settled when rendering starts.

Hydration mismatches: two renders that disagree

Server-side rendering asks the same component tree to produce identical output twice — once on the server, once in the browser — and then reuses the server's DOM. A mismatch means the two runs disagreed, and the framework has to throw away the server markup and re-render, which costs you the performance you adopted SSR to get.

The causes are a short list and worth memorising, because the error message rarely names the culprit: anything time-dependent (Date.now(), relative timestamps), anything random, anything reading window, localStorage or a user agent, locale-sensitive formatting where server and client locales differ, and invalid HTML nesting that the browser silently repairs — a <div> inside a <p> produces a different tree in the browser than the string the server emitted.

The fix is to make the first client render match the server exactly and move the divergent value into an effect that runs after hydration. Rendering a stable placeholder and filling it in on mount is not a workaround — it is the correct shape for any value that only exists in the browser.