Lightning Aura Components Developer Guide

What Is the Lightning Component Framework?
Quick Start
Creating Components
Using Components
Communicating with Events
Creating Apps
Styling Apps
Developing Secure Code
What is Lightning Locker?
JavaScript Strict Mode Enforcement
DOM Access Containment
Secure Wrappers
eval() Function is Limited by Lightning Locker
MIME Types Permitted
Access to Supported JavaScript API Framework Methods Only
What Does Lightning Locker Affect?
Lightning Locker Tools
Disabling Lightning Locker for a Component
Don’t Mix Component API Versions
Lightning Locker Disabled for Unsupported Browsers
Content Security Policy Overview
Freeze JavaScript Prototypes
Using JavaScript
Working with Salesforce Data
Using Apex
Testing Components with Lightning Testing Service
Debugging
Performance
Reference
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Don’t Mix Component API Versions

For consistency and ease of debugging, we recommend that you set the same API version for all custom components in your app, containment hierarchy (component within component), or extension hierarchy (component extending component).

If you mix API versions in your containment or extension hierarchy and Lightning Locker is enabled for some components and disabled for other components, your app will be harder to debug.

Extension Hierarchy

Lightning Locker is enabled for a component or an application purely based on component version. The extension hierarchy for a component doesn’t factor into Lightning Locker enforcement.

Let’s look at an example where a Car component extends a Vehicle component. Car has API version 39.0 so Lightning Locker is disabled. Vehicle has API version 40.0 so Lightning Locker is enabled.

Now, let’s say that Vehicle adds an expando property, _counter, to the window object by assigning a value to window._counter. Since Lightning Locker is enabled for Vehicle, the _counter property is added to SecureWindow, the secure wrapper for window for the component’s namespace. The property isn’t added to the native window object.

Lightning Locker is disabled for Car so the component has access to the native window object. Car can’t see the _counter property as it’s only available in the SecureWindow object.

This subtle behavior can cause much gnashing of teeth when your code doesn’t work as you expect. You’ll never get that debugging time back! Save yourself some grief and use the same API version for all components in an extension hierarchy.

Containment Hierarchy

The containment hierarchy within an application or a component doesn’t factor into Lightning Locker enforcement.

Let’s look at an example where a Bicycle component contains a Wheel component. If Bicycle has API version 40.0, Lightning Locker is enabled. If Wheel has API version 39.0, Lightning Locker is disabled for Wheel even though it’s contained in a component, Bicycle, that has Lightning Locker enabled.

Due to the mix of component API versions, you’re likely to run into issues similar to those for the extension hierarchy. We recommend that you set the same API version for all components in your app or component hierarchy, when possible.