Professional Documents
Culture Documents
Lightning
Lightning
• Data access with Lightning Data Service is simpler than equivalent using a server side Apex controller.
• Read only access can be entirely declarative in your component’s markup but for code that modifies
data your component’s JavaScript controller is roughly the same amount of data and you eliminate the
Apex entirely. All your data access code is consolidated in your component which reduces the
complexity.
• It is built on highly efficient local storage that is shared across all components that use it. Records loaded
in Lightning Data Service are cached and shared across components.
• Components accessing the same record see significant performance improvements, because a record is
loaded only once, no matter how many components are using it.
• Shared records also improve user interface consistency. When one component updates a record, the
other components using it are notified, and in most cases, refresh automatically.
a. Lightning Component Framework is geared towards developing custom dynamic mobile and web apps for
Lightning Experience or Lightning platform using single page applications.
b. It is based on HTML, Javascript and CSS that follows the MVC pattern.
c. Model—represents database interaction, will always go to database and perform DML operations.
d. View—represents the UI
e. Controller---- Interacts with the model and provides the result to the view and also takes the input from the
view and then provides the request to the model. It handles the business logics
f. It is tightly coupled with apex for server-side calls.
g. Component framework uses JSON format for all requests and responses. It does not support the XML
format.
h. It supports responsive design which means it automatically adjusts to the screen size of desktop, tablet etc
with the same codebase.
i. Lightning Framework is built on Aura Framework. AURA framework is an open source framework that is
developed by Salesforce.com. Salesforce modified the Aura Framework and created the Lightning
Framework.
Controller 1 Helper 1
Controller 2 Helper 2
Controller 3 Helper 3
d. The above diagram justifies the reusability concept of the
Helper.js. You cannot call one controller function from another controller function in a controller file.
Although a helper function amongst many helper functions in a helper file can be called from any other
helper function or any Controller function.
e. Style.css---- Style for the component.
f. Documentation.auradoc--- Used to define a component means what the component is doing, what one
method is doing etc.
g. Rendered.js----Handles the rendering of events. Client-side rendering to override the default rendering. Let’s
say there are some operations that you want to perform before rendering or after rendering, there will be
two functions as pre render or post render. As for example say:
That you want to make a callout even before a page displays the UI we can use the above functions.
h. Design.design----Makes the app more dynamic.
i. SVG.svg----Custom icon resource.
7. While creating a Lightning Component the checkboxes that come in the naming screen are the interfaces that
helps you to deploy the component across the Lightning ecosystem.
11. If you want to create different sections on your layout you need to use <lightning:layout> which serves the
function as <div> in HTML.
12. Standalone Lightning app has accustom URL and can be hosted and run using the URL and the apps have .app
extension.
13. Lightning components can be hosted inside Lightning Tabs, Lightning pages or Lightning app builder.
14. What are component attributes?
------ Component attributes makes your component more dynamic and can store values of different type
which can be referred or accessed by components.
---------------------Now what after defining attributes? You need to access the values in an attribute. Expression
serves that function. Expression allows you to access the attribute values or make calculations. Expression does
not support function calls.
a. Expression can be used for dynamic output.
b. Expression syntax:
1. {!expression} – Called as “bound expression”. Fetch new value of attribute automatically as
soon as attribute value is modified by the component.
2. {#expression} – Called as “unbound expression” which means it will not refresh the new
attribute value automatically when the attribute value is modified by the component until and
unless the whole component/page is refreshed.
b. {#v.attributeName)
b. Render :
Fired after init and when the component markup is rendered completely or re-rendered.
23. Lightning standalone application is similar to LEX experience but there are some considerations for the
standalone application as for example there are certain events that cannot be handled/supported inside your
standalone application. One of them is:
a. You cannot use force:createRecord inside your Lightning standalone application.
24. Creating a new record inside LEX using force:createRecord system Event:
a. First we have to define when the system event will fire, viz: onclick or onchange etc.
b. Next we have to define the functioning of the onclick event ‘createRecord’ as mentioned in
the above snip as:
var createRecordEvent = $A.get(“e.force:createRecord”);
This line denotes the usage of the system event ‘force:createRecord’ to create new records.
createRecordEvent.fire();
This line fires the system event as discussed above.
@AuraEnabled
Public static String getName(Id recordId)
f. To bind your component with server side apex class, you must define the server side controller
attribute in your component definition.
a. First of all to call a Server Side Action we need to create an Apex file that will contain the logic for
further processing.
b. Bind the server side controller to your component as discussed above.
c. Create an action for server side controller call. The action will be created on the client side code. The
action is something that will be going to call the server side controller and will be fetching the data
and then showing the result.
d. Optionally set the parameter.
e. Enqueue action. Enqueuing means put your action in queue which helps in reducing the network
traffic by batching multiple server side calls in one request.
f. Handle response.
26.c. An action should be created on the client side controller file which will interact with the server side
controller to fetch the data as required and then displaying them.
Sample action code in client side controller:
c. To make a parent component, set extensible =”true” in the parent component’s definition viz:
d. To extend a parent component, add extends property in the child component’s definition viz:
NOTE: To use an abstract component you must extend it and fill out the remaining implementation. Viz:
<aura:component abstract="true" extensible="true">
29. Fundamental concept of event driven programming is to write handlers that respond to the user-driven or
system event as and when fired:
Lightning Framework supports two types of events:
a. Component Events: The events that can be handled by the component itself or the parent components.
b. Application Events: These events can be handled by any component in your application. It is similar to
publish-subscribe model. All the components that are subscribed to an event will be alerted when an
event is fired.
NOTE: By default when you create a Lightning Event it’s an Application Event that is created.
• The component that handles the event can fetch the event data. To retrieve the attribute value
in this event, call event.getParam(“message”) in the handler’s client side controller.
• The name attribute in the <aura:handler> must match the name attribute in the
<aura:registerEvent> tag in the component that fires the event.
• The action attribute in the <action:handler> sets the client side controller action to handle the
event.
• The event attribute specifies the event being handled. The format is namespace:eventName.
• In the client side controller action use event.getSource() to find out which component fired the
event.
<aura:method>
32. When to use <aura:method>?
ANS: It is to be used when events are fired on the parent component but you want to handle those events in your child
component.
• This enables you to directly call a method in a component’s client-side controller instead of firing and handling a
component event.
• Use aura:method to communicate down the containment hierarchy. For example, a parent component calls an
aura:method on a child component that it contains.
Lightning Interfaces:
b. flexipage:availableForRecordHome:
This interface is used to make the component only available to record
pages.
c. forceCommunity:availableForAllPageTypes:
Interface to make the component available for use in the
community builder.
d. force:appHostable:
Allows a component to be used as a custom tab in LEX or the Salesforce app.
e. force:lightningQuickAction:
Allows a component to display in a panel with standard action controls as quick
action. For example Cancel button, submit for approval button.
f. force:lightningQuickActionWithoutHeader:
Allows a component to display in a panel without additional
controls.
The difference between the above two is that if you use lightningQuickAction it will also give you standard
Cancel button along with standard model box which you will not get for lightningQuickActionWithoutHeader.
You cannot use both lightningQuickActionWithoutHeader and lightningQuickAction at the same time.
g. force:hasRecordId:
Enables the Lightning Component to be assigned the ID of the current record.
NOTE: If you are using force:hasRecordID and your component is being displayed on the home page then
force:hasRecordID will return null value as the home page does not provide you with any id of any record.
h. force:hasSObjectName:
Enables the Lightning component to be assigned to the API name of the current record’s
sObject type.
i. lightning:actionOverride:
To enable the component to be used to override a standard action on an object.
force:createRecord:
This event opens a page to create a record for the specified entityApiName, for example “Account” or any custom
object.
To display the record, create page for an Object, set the object name on the entityApiName attribute and fire the event.
recordTypeId is optional and if provided, specifies the record type for the created object.
defaultFieldValues is optional, and, if provided, specifies values to use to prepopulate the create record form.
This event is handled by the one.app container. It is supported in Lightning Experience, the Salesforce app, and Lightning
communities. This event presents a standard page to create a record.
The defaultFieldValues attribute lets you prepopulate the create record form with default or calculated field values.
Specify default field values as name-value pairs in a Javascript object.
You can specify or prepopulate values for fields even if they are not available in the create record form.
• If the field is hidden because it is not on the page layout, the value specified in
defaultFieldValues is saved with the new record.
• If the current user doesn’t have create access to the field, due to FLS, attempts to save the
record results in an error.
• Error messages can’t reference fields the current user doesn’t have access to. This constraint
means that the user won’t be able to decipher the root cause of the error.
Firing the force:createRecord event tells the app to use the standard create record page. You cannot catch errors there
or alter the create page interface or behavior.
For this reason, it’s essential to perform access checks in your own code, before firing the event.
You can’t prepopulate system-maintained fields, such as Id or record modification time stamps. Default values for these
fields are silently ignored.
Difference between console Lightning Application and Lightning App Builder application.
35:31
force:navigateToSObject
This event enables you to navigate to an sObject record specified by the recordId.
To display the record view, set the record ID on the recordId attribute and fire the event.
Record IDs corresponding to ContentNote aren’t supported.
The record view contains the slide that display the Chatter feed, the record details, and related information. The
following example displays the related information slide of a record view for the specified record ID.
You can set a specific slide in Salesforce one app but not on LEX experience.
createRecord: function(component,event,helper){
var navEvt = $A.get(‘e.force:navigateToSobject’);
navEvt.setParams({
“recordId” : “00QB0000000ybNX”;
“slideDevName” : “related”
});
navEvt.fire();
}
In the Salesforce app, you can specify the slide within the record view to display initially. The following slide names are
supported.
• detail: The record detail slide. This is the default value.
• chatter: The chatter slide.
• related: The related information slide.
This event is handled in one.app container. It is supported in LEX, the Salesforce app and Lightning Communities.
Application Events:
• Application events follow a traditional publish-subscribe model. A component event can only be handled by the
component itself as well as any parent present in the same hierarchy.
• An application event is fired from an instance of a component. All components that provide a handler for the
event are notified.
• In application event there is no need to register the event in your component markup which is very much unlike
a component event.
• Application events can be fired directly in the controller file using the following syntax:
35