Properties Evaluate as undefined in LWS
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, and what to do about it.
If your code, or a third-party library you’re using, stores values in the window object, it’s accessing the global scope. Lightning Web Security enforces JavaScript strict mode, which prevents 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.
Third-party libraries shouldn't explicitly set strict mode when LWS is enabled. See Third-Party Library Considerations for LWS.
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.
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.
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 Alternatives to Mutating Objects for examples of how to refactor your code.
It’s best to design your functions with immutability in mind to make them idempotent. For more information on the immutability coding paradigm, see this Redux guide.
See Also