LWCAdvancedapiimmutabilityanti-pattern
Review LWC that mutates @api object properties from parent
Real World Scenario
Code review finds child LWC directly assigning this.recordData.Status = "Closed" on object passed from parent @api property.
Expected Answer
• Reject mutation of @api objects — breaks unidirectional data flow and LDS assumptions
• Child should emit custom event with proposed change; parent owns state update
• Clone @api objects if local draft editing required before save
• Use @track or reactive plain objects for internal draft state only
• Document @api contract as read-only in JSDoc
• Add ESLint rule or PR checklist for @api assignment patterns
• Test parent re-render does not lose sibling state when one child mutates shared object
Follow-Up Questions & Answers
Click to expand — each follow-up includes a direct, interview-ready answer
Main difference: use case and scale. Reject mutation of @api objects — breaks unidirectional data flow and LDS assumptions. Child should emit custom event with proposed change; parent owns state update. Pick based on your integration pattern and team capability. Mutable @api props cause Heisenbugs across record pages — enforce read-only boundary in code review. Optimize for scale and operational observability.
Architect Perspective
Mutable @api props cause Heisenbugs across record pages — enforce read-only boundary in code review.