1.

Lightning Data Service:

You can read, create, update, and delete records from database without even writing the Apex controller.
Lightning Data Service handles sharing rules and FLS for you. Additionally as not needing Apex, LDS improves
performance and user consistency.

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

2. My domain is very much required to develop lightning components.

3. What is Lightning Component Framework?

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.

4. When to use Lightning Components?

a. Develop single page applications.
b. Develop custom components if some functionality is not provided OOTB.
5. To check OOTB and custom components in your org:
Append ---componentReference/suite.app after …..lightning.force.com/
6. When you create a Lightning Component there will be altogether 8 files that will be included as part of the
component bundle. The 8 files are as:
a. Component.xml------Markup of the component. Whole and sole responsible for the UI display/rendering. In
MVC architecture Component.xml file is the View.
b. Controller.js----Client side controller. Normal javascript functions are written here which is in JSON format.
Handles the events being raised by the component.xml file. As for example: Let say after clicking on the
 submit button you want to perform a validation that username should be of 8 characters. In MVC
architecture Controller.js file is the Controller.
c. Helper.js-----If you want to interact with Apex controller or if you want to put on some logic which can be
reused you can use Helper.js. Logics written in Helper.js makes the logic reusable. Normal javascript
functions are written here which is in JSON format. In MVC architecture Helper.js file is the Model.

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.

8. What is Lightning App Builder?

a. Using Lightning App Builder one can create single page applications.
b. One can create Lightning Experience home pages.
c. One can create Lightning Experience record pages.

9. How to apply stylesheets/style to your component?

a. To access direct descendants as in let’s say that you have one <div>classname</div> in your component
then simply use:
.THIS.classname (No space in between “.THIS” and the next “.”)
 b. To access indirect descendants let’s say that you have one level deep component or you have a nested <div>
inside another <div> component then you can use the following:
.THIS .classname (one space between “.THIS” and the next “.”)

10. Why to avoid using HTML tags?

As a best practice always try to use the Standard Lightning Component instead of using the HTML tags. As
for example: Use <lightning:button> instead of<button>. Standard Lightning components offer many
advantages as in:

a. Automatically use SLDS

b. Secured and optimized for performance.
c. Lightning components provides some out of the box functionality which you may have to build
altogether if using HTML tags.
d. Styling can be applied to Lightning Components.

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.

Data types supported by attributes:

a. Boolean
b. String
c. Integer
d. Double
e. Long
f. Decimal
g. List
h. Set
i. Map
j. Object
k. Date
l. DateTime BSIDLDLSMODD

15. Access attribute to define the scope of an attribute:

a. Global: The attribute can be used in any namespace.
b. Public: The attribute can be used within the same namespace.
c. Private: The attribute can be used only within the container app, interface, component or an event and
cannot be referenced externally.

16. What are expressions?

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

17. Access attribute value:

a. {!v.attributeName} --- Here ‘v’ is the value provider. All the values being hold by all the attributes can
be fetched appending ‘v’.

b. {#v.attributeName)

18. Conditional MarkUp:

a. Use <aura:if> component to generate conditional markup. If the expression defined in <aura:if> is
True, certain markup will be generated/shown.
b. Example:
<aura:attribute name=”edit” type=”Boolean” default=”false” />
<aura:if isTrue=”{!v.edit}”>
<lightning:buttonLabel=”Edit”/>
<aura:set attribute=”else”>
You cannot edit this. </aura:set>
</aura:if>
19. Handling Events:
a. Lightning Component framework uses event-driven programming. We need to write handlers which
respond to the event as they occur.
b. Events can be triggered by the user (viz: OnClick, OnChange etc.) or can automatically be fired by the
framework (viz: system events)
c. Client side controller handles the event within the component. It’s a JavaScript file that has all the
actions being fired by the component.
d. Helper.js helps to offload heavy work from controller file which can be called from multiple controller
functions.

20. Client Side Controller Handler:

a. A client side controller handles events within a component. It’s a JavaScript resource that defines the
functions for all of the component’s actions.
({
myAction : function(component, event, helper){
//add code here
}
})
b. Component/cmp ---The component to which the controller belongs to.
c. Event --- The event that the action is handling.
d. Helper--- The component’s helper. It’s not mandatory. A helper contains functions that can be used
by any JavaScript code in the component bundle.

21. Getting and Setting Attribute value:

 a. You can get component attribute value in your controller/helper as:
var value = component.get(“v.attributeName”);

b. You can set component attribute value as:

var value = component.set(“v.attributeName”, value);

22. System Events:

The events which are fired by the Lightning Framework itself are the system events. You don’t have any
control over the System Events. Although it’s up to the developer whether those events are to be handled or
not.
There are two types of System Events:
a. Init:
Init event is fired when the component markup is initiated even before the markup in the
component has rendered.

<aura:handler name=”init” value=”{!this}” action=”{!c.doInit}” />

Makes the handler as a value Event

b. Render :
Fired after init and when the component markup is rendered completely or re-rendered.

<aura:handler name=”render” value=”{!this}” action=”{!c.onRender}” />

• ‘Init’ event is always fired before ‘render’ event.

Google about Lightning Locker Services.

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.

25. Server Side Controller:

a. Apex is used to write server side controller code.
b. Server side code can be called from client side controller or helper to perform server side action as in
saving or retrieving a record.
c. Server side controller are bit slower compared to client side controller as they tend to make a round
trip from client to server and back again.
d. To make Apex controller function available for lightning component, you must explicitly annotate
your function with @AuraEnabled.
e. This method must be either global or public and has to be static viz:

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

<aura: component controller=”MyServerSideControllerName”/>

g. One component should be always associated to not more than one server side controller.

26. Calling Server Side Controller:

-------To call a server side controller the following steps needs to be executed:

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:

getCarType: function(component , helper){

var action = component.get(“c.getCarTypes”);
action.setCallback(this, function(data){
var state= data.getState();
if(state === “SUUCESS”){
component.set(“v.Cars”, data.getReturnValue())
}else if(state === “ERROR”){
Alert(“Unknown Error”);
}
});
$A.enqueueAction(action)
}
And the corresponding Server side Controller is:

public with sharing class carTypeSearch

{
@AuraEnabled
public static List<Car_Type__c> getCarTypes()
{
return [Select id, name from Car_Type__c];
}
}

27. Inheritance in Lightning Component:

a. Using Inheritance is one way to share the common code between multiple components.
b. Inheritance in Lightning allows you to inherit parent component’s attributes, body attributes, events, helper
and client side controller.

c. To make a parent component, set extensible =”true” in the parent component’s definition viz:

<aura:component extensible =”true” />

d. To extend a parent component, add extends property in the child component’s definition viz:

<aura:component extends =”c:myParentComponentName” />

28. What are abstract components?

ANS: Object oriented programming languages like Java support the concept of abstract classes that provides a
partial implementation for an object but leaves the remaining implementation to concrete sub-classes. An
abstract class in Java cannot be instantiated directly but a non-abstract class can.
Similarly, the Lightning component Framework supports the concept of abstract components that have
partial implementation but leave the remaining implementation to concrete sub components.

NOTE: To use an abstract component you must extend it and fill out the remaining implementation. Viz:
 <aura:component abstract="true" extensible="true">

Comment your code in component markup, Use : <!-- and -- >

To comment your code in Javascript file use: /* and */ or // for single line comments.

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.

30. Component Events:

A component event can be fired from an instance (can be fired only within component markup) of a
component. It can be handled by the component itself or all the parent components in the component
hierarchy. Basic steps for creating, raising and handling component events include:
a. Defining a custom component.
b. Register the event using <aura:registerEvent> in your component.
c. Raising the event using event.fire() in your controller.
d. Define handlers for your event using <aura:handler>.
e. Define action in those handlers to handle the event and do post processing.

NOTE: By default when you create a Lightning Event it’s an Application Event that is created.

We need to change its type to ‘COMPONENT’ as per the requirement.

• The component that fires the event can set the event’s data.
• To set the attribute values, call event.setParam() or event.setParams().

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

30. a. Handling Component Events:

A component event can be handled by the component that fired the event or by a component higher in the component
hierarchy.

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

31. Grid Layouts:

The grid system in Lightning Design System is based on FlexBox(Flexible Box)—a CSS3 layout mode that makes
sure that elements will render properly on any scree size or display size.
Each cell by default has the same size, height, width and they size to fit by default.
Example:

<lightning:layouItem padding=”around-small” size=”12”

smallDeviceSize=”6”
mediumDeviceSize=”4”
largeDeviceSize=”3”>
The above example means that my entire page has been divided into 12 grids. Each component for mobile devices will
consume 6 grids, for tabs it will be 4 grids and for desktops it with 3 grids consumed per component.

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

For our project----Why we opted for <aura:method> in our CarSearchResult component?

ANS: We fired an event from CarSearchForm and handled it from CarSearch component. CarSearch component is the
parent of CarSearchForm component, so this can be done as Component events can be handled by the component itself
or the parent in the containment hierarchy.
The event that has been fired basically gets you the carTypeId. Now the carTypeId is present along with CarSearch
component. In order to get that carTypeId we cannot fire an event on CarSearch and handle them at
CarSearchResult component as CarSearchResult is the child component of CarSearch. That is the reason why
<aura:method> has been used.

Lightning App Builder:

We can create three kinds of pages using Lightning App Builder. They are:
a. Record Home pages.
b. Home pages
c. Application Pages.

Lightning Application Pages:

Use Lightning App Builder to create Lightning Application Pages.
 1. Lightning App Builder is a point and click tool that makes it easy to create custom pages for Salesforce mobile
app and LEX.
2. It gives the users what they need all in one place.

With Lightning App Builder you can build:

a. Single Page Applications that drill down into standard pages.
b. Dashboard style apps.
c. Custom record pages.
d. Custom home pages similar to your org’s home page.

Lightning Interfaces:

Interfaces are used to allow a component to be used in different contexts.

a. flexipage:availableForAllPageTypes:
A global interface that makes a component available to be used in the
Lightning App Builder, and for any type of Lightning Page be it your app page, home page or record page.

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.

Prepopulating Field values:

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.

Lightning Data Services:

1. Lightning Data Services handles sharing rules and field level security automatically for you. Viz: If you don’t have
FLS to a particular field LDS will automatically make that field non-visible for you.
2. Use LDS to read and modify Salesforce data in your components.
3. LDS works for only one record. So, if you want to fetch multiple records lets say multiple accounts on the same
page LDS is not the correct option for that better to write Apex controller here.
4. Data access with Lightning Data Service is simpler than the equivalent using a server-side Apex controller. As for
example for server-side Apex controller you need to take into consideration of the FLS and also the sharing
rules, but with LDS that is automatically handled.

BENEFITS OF USING LIGHTNING DATA SERVICE:

a. You can get rid of server-side controller or any apex code if you are doing operation on a single record.
b. It is built on highly efficient local storage that is shared across all components that use it.
c. Records loaded using Lightning Data Services are cached(client side) and shared across components.
d. When one component updates a record, the other components using it are notified and are refreshed
automatically.

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