LWC
Reactivity and immutable updates
Explain object updates, decorators, and stable list keys.
By Vishal Verma · Reviewed October 5, 2026
Practice these questions aloud. Give the principle, explain a concrete example, and finish with how you would verify the result.
1. Why might an object update not appear?
Suggested answer: Reactivity depends on how the value is observed and changed. Assigning a new object or array reference is a clear update pattern. @track supports observation of mutations in plain objects and arrays, with documented limitations.
Scenario / follow-up: Use this.items = [...this.items, newItem] when adding a list item.
2. Does every field need @track?
Suggested answer: No. Ordinary field assignments are reactive when the template or a used getter depends on them. Understand when tracking nested plain-object or array changes is needed.
Scenario / follow-up: Do not apply decorators mechanically to every property.
3. Why should list keys be stable?
Suggested answer: A stable unique key lets the framework identify items across changes. Use a record ID or stable identifier, not an array index for a changing list.
Scenario / follow-up: Consider how sorting affects identity and local row state.
Reviewed October 5, 2026. Check the linked documentation for your org’s API version and supported features.