What Angular Actually Re-renders When a Model Streams Your UI

When a model streams a UI into an Angular app, the spec behind the screen changes many times per second. Two questions follow from that, and both are easy to answer by guessing:

1. Angular has no render(node) function that calls itself. So how does it draw a tree when nobody knows how deep it goes?
2. On every patch, does Angular redraw everything? And when one deep child changes, how does Angular even know?

I measured instead of guessing, and read Angular's source where the answer wasn't obvious.

The examples come from ngx-json-render, an Angular renderer for json-render specs. If the format is new to you, my first article explains it. But the mechanics below are plain Angular: NgComponentOutlet, @for, dependency injection and signals.

How Angular draws a tree it has never seen

A spec describes a tree as a flat map of elements:

{
  "root": "card",
  "elements": {
    "card":  { "type": "Card", "props": {}, "children": ["title", "list"] },
    "title": { "type": "Text", "props": { "content": "Hello" } },
    "list":  { "type": "List", "props": {}, "children": ["a", "b"] },
    "a":     { "type": "Text", "props": { "content": "A" } },
    "b":     { "type": "Text", "props": { "content": "B" } }
  }
}

There is no recursive function in the renderer. The recursion is made of three ordinary Angular tools that call each other through templates.

Tool 1: NgComponentOutlet picks a component class at runtime. One small component does only that: take a key, find the element, create the matching component.

@Component({
  selector: 'jr-element',
  imports: [NgComponentOutlet],
  template: `
    @if (component()) {
      <ng-container *ngComponentOutlet="component(); injector: injector" />
    }
  `,
})
export class JrElement {
  readonly elementKey = input.required<string>();
  // "Card" → CardComponent, looked up in the registry
}

Tool 2: @for renders the children, one jr-element per child key:

@Component({
  selector: 'jr-children',
  imports: [JrElement],
  template: `
    @for (key of childKeys(); track key) {
      <jr-element [elementKey]="key" />
    }
  `,
})
export class JrChildren {}

Tool 3: your own component puts <jr-children /> wherever its children should go:

@Component({
  selector: 'app-card',
  imports: [JrChildren],
  template: `<section class="card"><jr-children /></section>`,
})
export class CardComponent {}

Put them together and you get the loop:

jr-element "card"  → app-card
  jr-children      → jr-element "title" → app-text
                   → jr-element "list"  → app-list
                       jr-children      → jr-element "a" → app-text
                                        → jr-element "b" → app-text

Nobody calls anything recursively. Components create components, and the tree grows as deep as the data says.

How does a child know where it is?

The parent passes only one input: the key. Everything else travels through dependency injection. Each jr-element creates a small injector for the component it renders:

readonly injector = Injector.create({
  providers: [
    { provide: RENDER_CONTEXT, useValue: this.renderContext }, // props, events
    { provide: RENDER_PATH, useValue: this.path },             // my ancestry
  ],
  parent: inject(Injector),
});

Your component calls injectRenderContext() and gets its props as signals. The next jr-element down injects the parent's RENDER_PATH and adds itself to it.

That's the part I find elegant: Angular's injector tree plays the role of the call stack. In a recursive function, each call sees its caller's arguments. Here, each level sees its parent's providers.

And since every component was compiled ahead of time, the runtime never compiles anything. It only decides which already-compiled component to create next.

The cost of recursion that lives in Angular

Angular creates and checks views with plain recursive JavaScript functions. And each level of the JSON becomes several nested Angular views: jr-element, its @if block, your component, jr-children, its @for block.

So the depth of the JSON becomes the depth of the JavaScript call stack. That has a price: two elements that name each other as children are enough to run the stack out and kill the tab. Where that recursion has to stop is a story of its own.

Streaming: does Angular redraw everything?

With streaming, the model doesn't send a finished spec. It sends small patches, one per line:

{"op":"add","path":"/elements/card","value":{"type":"Card","props":{},"children":["title","list"]}}
{"op":"add","path":"/elements/title","value":{"type":"Text","props":{"content":"Hello"}}}
{"op":"replace","path":"/elements/a/props/content","value":"A2"}

Each patch produces a new spec object, which reaches the renderer through a signal. The natural fear: new object at the top means every component redraws, dozens of times per second.

I measured it instead of guessing. The spec above, with counters in every component: how many components were created, and how many component templates ran again.

So no, it doesn't redraw everything. Four ideas make that work, and the first one isn't about Angular at all.

Idea 1: a patch replaces only what it touches

The patch doesn't mutate the old spec, and it doesn't deep-copy it either. It copies only the objects on the path to the change:

before:  spec  → elements  → card, title, list, a,  b
patch:   replace /elements/a/props/content
after:   spec' → elements' → card, title, list, a', b
                              (same objects)   (new)

card, title, list and b are the same objects in memory as before. So "did this element change?" becomes a single ===.

Idea 2: each element watches only its own piece

Every jr-element reads its element through a computed:

readonly element = computed(() => this.root.spec()?.elements?.[this.elementKey()]);

When the spec changes, all these computeds run again, and each one is a single lookup. But a computed only reports a change when the new value is a different object. For card, title, list and b the lookup returns the same object, so the change stops right there. Nothing that depends on them runs.

Idea 3: Angular refreshes views, not the whole tree

This is the answer to "how does Angular know a deep child changed?"

It doesn't search for it. In modern Angular every view has its own reactive consumer, which remembers exactly which signals its template read. I checked this in Angular 21's source. When one of those signals changes:

1. that view is marked dirty;
2. its parents only get a flag saying "a child below needs checking". Their own templates don't run (markAncestorsForTraversal);
3. before refreshing a dirty view, Angular checks whether the signals it read really got new values, and skips the view if not (consumerPollProducersForChange).

So on a deep change, Angular walks down the path to that one view, runs its template, and updates only the DOM bindings whose values actually differ. The parents stay untouched.

In a zoneless app, and zoneless is the default for new apps since Angular 21, there's nothing else that could trigger a check. The signal notification is what schedules the update.

Idea 4: new children don't rebuild the list

@for (key of childKeys(); track key) compares children by key. When list gets a third key, Angular keeps the two existing views and creates one new one.

Streaming adds a twist: a parent often lists a child before the child's element has arrived. That's fine. The jr-element for the key is created and renders nothing. When the element arrives, only that one component is created. That's rows 3 and 4 of the table.

What isn't free

To be fair about the limits of this:

• Every patch still does a small amount of work per element. Each element's computed runs once, and Angular walks the tree to find dirty views. It's cheap, but it grows with the size of the spec.
• Data is not structure. That one deserves its own section.

When the data changes, not the UI

Specs also carry data. A text can read { "$state": "/user/name" }, a list can repeat over /todos. A user types into a field, or the stream sends a new value, and the data changes while the structure stays the same.

The state store itself does this well. It copies only the path to the changed value, and writing the same value again does nothing at all.

The renderer layer is where precision gets lost today. Every element resolves its props against the current state, and resolving always builds a new props object, even when every value inside it is the same. A new object counts as a change, so Angular re-runs every component's template. The DOM still changes only where a value really differs, but the template work covers the whole tree.

I measured it on a small spec: a card, a static text, a text bound to /user/name, and a todo list. Then I tried one small change: treat two props objects as equal when all their values are the same (a shallow compare on the props computed).

Same idea as with patches: keep identity, and "nothing changed" becomes cheap. The fix just has to restore identity one step later, after props are resolved.

When I wrote this, it was an experiment, not a shipped change. It isn't free of trade-offs:

• Every element still re-resolves its props on every data change. The compare saves Angular's work, not that JavaScript. The next step would be remembering which state paths each element reads, and skipping the rest.
• Props that resolve to nested objects or arrays are new objects every time, so the shallow compare doesn't help them. It's no worse than today, though.
• An external store that mutates objects in place could be shown stale, because the reference stays the same while the content changes. That case is exactly why the renderer treats every store update as a change today.

Update (0.5.1): this is now shipped. A resolved element keeps its previous object when its props hold the same values, and the right-hand column of the table is what the release's tests measure. Three details differ from the experiment:

• With the built-in store, object and array values compare by reference. The store copies every path it writes, so a { "$state": "/todos" } prop keeps its identity until /todos itself changes. Literal objects with expressions inside, and $computed results, are still rebuilt on every resolution.
• With an external store, object and array values always count as changed, because such a store may write into its snapshot in place. Primitives still compare by value.
• Elements with a $bindState or $bindItem prop keep the old behaviour. Their input can hold text that state hasn't seen yet, and the component's props effect has to run to put the DOM right.

The short version

How Angular recurses

• There's no recursive function: NgComponentOutlet → your component → @for → NgComponentOutlet.
• The injector tree works as the call stack. Each level sees its parent's context.
• JSON depth becomes JavaScript stack depth.

What streaming re-renders

• Patches keep unchanged objects, so "unchanged" is a ===.
• Each element watches only its own piece through a computed.
• Angular doesn't search for changes. It refreshes only views whose signals really changed, and walks through the parents without re-running them.
• @for ... track key keeps existing children and creates only new ones.

What data changes re-render

• Before 0.5.1, every template. The DOM still changed only where values differed.
• A shallow compare on resolved props brought it down to the one affected element in my test, and 0.5.1 ships it.

Fast streaming in Angular isn't about rendering fast. It's about keeping object identity, so that "nothing changed" is a === and Angular can skip almost everything.

• Repo · npm · Live demo