Lightning Components Developer Guide

What is the Lightning Component Framework?
Quick Start
Creating Components
Using Components
Use Lightning Components in Lightning Experience and the Salesforce Mobile App
Get Your Lightning Components Ready to Use on Lightning Pages
Configure Components for Lightning Pages and the Lightning App Builder
Lightning Component Bundle Design Resources
Configure Components for Lightning Experience Record Pages
Create Components for Lightning for Outlook and Lightning for Gmail
Create Dynamic Picklists for Your Custom Components
Create a Custom Lightning Page Template Component
Lightning Page Template Component Best Practices
Make Your Lightning Page Components Width-Aware with lightning:flexipageRegionInfo
Tips and Considerations for Configuring Components for Lightning Pages and the Lightning App Builder
Use Lightning Components in Community Builder
Add Components to Apps
Integrate Your Custom Apps into the Chatter Publisher
Use Lightning Components in Visualforce Pages
Add Lightning Components to Any App with Lightning Out (Beta)
Communicating with Events
Creating Apps
Debugging
Fixing Performance Warnings
Reference
PDF

Newer Version Available

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

Configure Components for Lightning Experience Record Pages

After your component is set up to work on Lightning pages and in the Lightning App Builder, use these guidelines to configure the component so it works on record pages in Lightning Experience.

Record pages are different from app pages in a key way: they have the context of a record. To make your components display content that is based on the current record, use a combination of an interface and an attribute.

  • If your component is available for both record pages and any other type of page, implement flexipage:availableForAllPageTypes.
  • If your component is designed only for record pages, implement the flexipage:availableForRecordHome interface instead of flexipage:availableForAllPageTypes.
  • If your component needs the record ID, also implement the force:hasRecordId interface.
  • If your component needs the object’s API name, also implement the force:hasSObjectName interface.

If your managed component implements the flexipage or forceCommunity interfaces, its upload is blocked if the component and its attributes aren’t set to access="global". For more information on access checks, see Controlling Access.

Note

force:hasRecordId

Useful for components invoked in a context associated with a specific record, such as record page components or custom object actions. Add this interface if you want your component to receive the ID of the currently displaying record.

The force:hasRecordId interface does two things to a component that implements it.
  • It adds an attribute named recordId to your component. This attribute is of type String, and its value is an 18-character Salesforce record ID, for example: 001xx000003DGSWAA4. If you added it yourself, the attribute definition would look like the following markup:
    1<aura:attribute name="recordId" type="String" />

    If your component implements force:hasRecordId, you don’t need to add a recordId attribute to the component yourself. If you do add it, don’t change the access level or type of the attribute or the component will cause a runtime error.

    Note

  • When your component is invoked in a record context in Lightning Experience or the Salesforce app, the recordId is set to the ID of the record being viewed.

Don’t expose the recordId attribute to the Lightning App Builder—don’t put it in the component’s design resource. You don’t want admins supplying a record ID.

The recordId attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home. In all other cases, such as when you invoke the component as a global action, or create the component programmatically inside another component, recordId isn’t set, and your component shouldn’t depend on it.

force:hasSObjectName

Useful for record page components. Implement this interface if your component needs to know the API name of the object of the currently displaying record.

This interface adds an attribute named sObjectName to your component. This attribute is of type String, and its value is the API name of an object, such as Account or myNamespace__myObject__c. For example: 
1<aura:attribute name="sObjectName" type="String" />

If your component implements force:hasSObjectName, you don’t need to add an sObjectName attribute to the component yourself. If you do add it, don’t change the access level or type of the attribute or the component will cause a runtime error.

Note

The sObjectName attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home. In all other cases, such as when you invoke the component as a global action, or create the component programmatically inside another component, sObjectName isn’t set, and your component shouldn’t depend on it.