---
schema_version: "1"
id: b474f21c37039045a915dcd496109d0911f2962338f7134fd178f62b43306b00
title: Properties Evaluate as undefined in Lightning Web Security
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/lwc/lightning-components-security/guides/lws/lws-undefined.md
canonical_url: https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-undefined.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: f387c692c09fedb9fcde7e9600def6e6c4f1c77c3b7da2613cd960a8c91cea31
products:
  - Security for Lightning Components
  - lwc
---
# Properties Evaluate as `undefined` in Lightning Web Security

Lightning Web Security (LWS) can cause a value to evaluate as `undefined`.

Here are some conditions that cause properties to evaluate as `undefined` in components running with LWS.

## `undefined` Value Is in the Global Scope

If your code or a third-party library that you’re using stores values in the `window` object, it’s accessing the global scope. Lightning Web Security enforces [JavaScript strict mode](https://developer.salesforce.com/docs/platform/lightning-components-security/js/js-strict-mode-intro.md), which prevents the creation of global variables. The browser throws an error if you try to create a global variable.

LWS distortions permit changes to the virtual `window` object only in the component’s namespace sandbox. If a component attempts to access global scope properties that were created in another namespace, the value returned by LWS is `undefined`.

LWS sandboxing makes it appear that you can access global properties, but you’re actually accessing a virtual copy of the `window` object. Within a namespace sandbox, LWS lets you access global properties, but storing anything in global scope is considered bad practice. LWS allows it, but if the object with mutations is passed to code running outside the namespace sandbox, the changed properties aren’t accessible.

Instead, pass any shared data that can be accessed by functions or objects from other namespaces as function or constructor arguments.

**note:** Third-party libraries shouldn’t explicitly set strict mode when LWS is enabled. See [Third-Party Library Considerations for LWS](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-js.md).

## `undefined` Value Is Passed by Function Argument

If you discover that some values passed as arguments are `undefined` after you enable LWS, the problem can be due to object mutations or modifications on data that your components don’t own.

Data ownership is defined at the namespace level, which means that code defined within a namespace can freely modify its own data. However, if your code receives data from another namespace and modifies that data, the modifications aren’t always reflected outside your namespace.

**tip:** If the object being mutated is a plain JavaScript object, array, or typed array, LWS allows the mutation on the original object, and the change is reflected outside the namespace. We recommend using these objects instead of maps, in particular.

For global `window` objects and objects constructed from custom classes, LWS doesn’t allow mutations if the object isn’t owned by the namespace. A property that was added outside the namespace sandbox evaluates as `undefined`.

In this example `redFunction` is defined in namespace A and `blueFunction` is defined in namespace B.

```javascript
//module in namespace A

function redFunction(arg) {
  arg.foo = "bar"; // mutation on the arg object
  console.log(arg.foo); // "bar"
}

//module in namespace B

function blueFunction() {
  var someObject = {};
  redFunction(someObject); // blueFunction expects foo property added by redFunction
  console.log(someObject.foo); // undefined
}
```

When `blueFunction` uses `redFunction`, it doesn’t receive the mutation for the `foo` property that was done in namespace A. The namespaces can communicate by passing data to each other, but mutations don’t persist beyond the namespace boundary.

If your code mutates objects received from other namespaces, refactor your code.

See [Avoid Mutating Objects](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-mutation-alternatives.md) for examples of how to refactor your code.

**note:** It’s best to design your functions with immutability in mind to make them [idempotent](https://developer.mozilla.org/en-US/docs/Glossary/Idempotent). For more information on the immutability coding paradigm, see this [Redux guide](https://redux.js.org/tutorials/essentials/part-1-overview-concepts#immutability).

**See Also**

- [Avoid Mutating Objects](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-mutation-alternatives.md)
- [Avoid Using Map Objects](https://developer.salesforce.com/docs/platform/lightning-components-security/guide/lws-map.md)