An Angular template shows [object HTMLTextAreaElement] where a component's note text should be; how can template variable shadowing cause this, and how do you fix it?

## How Angular resolves a bare name Inside a template expression, `this` is implied: `{{ title }}` normally means the component's `title`. But the template can also declare names of its own: - **template reference variables**: `#note`; - **`@let` declarations**: `@let note = ...;`; - **template input variables**: `let-note` on an `<ng-template>`, the `@for` item and its aliases; - **`@if (x; as note)`** aliases. When the compiler meets an unqualified name, it resolves it through **scopes**: first the view the expression is in, then each enclosing view, and only if nothing matches, the **component instance**. A template name therefore **shadows** a component member with the same name for every expression in its scope. Angular's docs state this directly and give the escape hatch: write `this.` to reference the class member unambiguously. ## The bug in the question ```ts import {Component, signal} from '@angular/core'; @Component({ selector: 'app-order-note', template: ` <p>Saved note: {{ note }}</p> <textarea #note></textarea> <button (click)="save(note.value)">Save</button> `, }) export class OrderNote { note = 'Leave at the door'; save(text: string): void { this.note = text; } } ``` Step by step: 1. `#note` declares a reference in the top-level view. 2. References are resolved for the whole view, so even `{{ note }}` **above** the textarea resolves to the reference, not to the field. 3. The reference holds the `HTMLTextAreaElement`; interpolation stringifies it as `[object HTMLTextAreaElement]`. 4. The strict template type checker is satisfied: interpolating an element is legal, and `note.value` is a real property, so nothing is reported. ## Fixes | Fix | Example | When to prefer it | |---|---|---| | rename the template name | `<textarea #noteBox>` and `save(noteBox.value)` | almost always: removes the ambiguity for every reader | | qualify the member with `this.` | `{{ this.note }}` | when the local name must stay, for example a `@let` that deliberately mirrors a member | | remove the reference | bind the textarea to a signal instead | when the element was only used to read its value | A naming convention helps: suffix references with what they are (`noteInput`, `rowTpl`) so they cannot collide with state. ## Shadowing with @let `@let` shadows in the same way, with one extra trap. Suppose the component has `total = computed(...)`: - `@let total = total();` is an **error**: inside its own initializer, `total` already resolves to the `@let`, which is read before it has been defined. - `@let total = this.total();` works: `this.` bypasses the template scope and reads the member, and from then on `total` in that scope means the `@let` value. Deliberately mirroring a member like this is legitimate; the `this.` form is what makes it compile. ## What does not shadow silently Some collisions are reported instead of shadowing: - a `@let` that reuses the name of another template symbol **in the same scope**, such as a `#ref`, is a conflicting-declaration error; - declaring the same reference twice on one element is an error; - an alias in a `@for` `let` clause cannot reuse the item's name. Across **different** scopes, an inner template name simply wins over outer ones and over the component. ## How to catch it 1. Read the rendered output: `[object HTMLInputElement]`, `[object Object]` or a `TemplateRef` where text was expected points to a shadowed name. 2. Use the language service's go-to-definition on the name in the template; it lands on the `#ref` or `@let`, not on the class field. 3. Adopt the naming convention above in review, since type checks will not catch type-correct shadowing.