# 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](/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](/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.md#objects-passed-to-components-are-read-only)