---
schema_version: "1"
id: b78a34f2052804f0c0855e4b3401413a2504975ca48949335ce270ac56711625
title: Avoid Mutating Objects
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/lwc/lightning-components-security/guides/lws/lws-mutation-alternatives.md
canonical_url: https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-mutation-alternatives.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 2f788ec264fb85b8b5d3e8e81f82bba91325374f6c401ea695b0d7383a27b15c
products:
  - Security for Lightning Components
  - lwc
---
# Avoid Mutating Objects

A common problematic coding practice is mutating objects that the namespace doesn’t own. When you mutate an object, you add or remove properties of the object or change values of properties. You change the "shape" of the object. When you mutate an object in a component that’s running in Lightning Web Security (LWS), that change isn’t propagated outside the namespace sandbox, which leads to errors.

Mutations can cause values to be `undefined`. For more information, see [Properties Evaluate as undefined in LWS](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-undefined.md).

This section discusses alternatives to mutations on these properties.

- Function arguments
- Class instance properties
- Objects received in events

## Mutation Alternative for Function Arguments

In this example, a function `foo()` mutates the argument `obj` by adding a property with value `foo`. Then `foo()` calls `otherFunction`, which expects that `prop = foo` is defined on `obj`.

```javascript
function foo(obj) {
  obj.prop = "foo"; // 'prop' did not exist on obj
  otherFunction(obj);
}
```

This mutation is problematic because `foo()` can receive `obj` from different callers. Then `foo()` can send `obj` to different consumers that expect `obj` to be differently shaped. Mutating `obj` introduces uncertainty and inconsistency. A change could unknowingly break other code, especially when the code base is large and complex.

Instead of adding a property to an object, create a [shallow clone](https://developer.mozilla.org/en-US/docs/Glossary/Shallow_copy) with relevant properties of the object. In the example code, refactor `foo()` to create a clone of the object and add `prop` to the clone.

Here’s a single-line change that removes the mutation by using a cloned object.

```javascript
function foo(obj) {
  const newObj = { ...obj, prop: "foo" };
  otherFunction(obj);
}
```

## Mutation Alternative for Class Instance Property

For classes, we recommend exposing getters and setters for properties that can be mutated. Avoid directly mutating class properties that are used for computations.

JavaScript now supports [private class fields](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields). A best practice in any object-oriented programming language is to define all internal state properties as private, and expose [getters](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get) and [setters](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set) only for the properties that external code can mutate.

## Mutation Alternative for Objects Received in Events

For events, there’s no easy workaround because events propagate through the DOM.

Possible solutions are:

- Clone the event data, mutate it, and redispatch the same event but with the new data.
- Clone the event data, mutate it, and dispatch a new event with a different name.

**See Also**

- [Properties Evaluate as undefined in LWS](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-undefined.md)
- [_Lightning Web Components Developer Guide_: Objects Passed to Components Are Read-Only](/docs/platform/lwc/guide/create-components-data-flow.html#objects-passed-to-components-are-read-only)