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.

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, 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.

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.

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.

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 for examples of how to refactor your code.

See Also

• Avoid Mutating Objects
• Avoid Using Map Objects