Salesforce Lightning Aura interview Questions Part-1

 

What are the different programming models available for Lightning components?

For Lightning components, there are two different programming models. The first is to build out Aura components using the Aura framework, and the second is to use the newer Lightning Web Components (LWC) framework.

• Aura Framework: Aura is a user interface framework for creating dynamic web apps for mobile and desktop devices, with a scalable long-lived lifecycle to allow the development of growth-oriented apps. It allows for the creation of partitioned multi-tier components that connect the client and server. Aura, which has been around since 2013, allows developers to create apps that are not dependent on Salesforce data, allowing for minimal disruption to day-to-day customers. Because programs don't have to be optimized for each device, Aura allows for more efficient development. 

• Lightning Web Components Framework: Lightning Web Components is a W3C Web Components standard implementation. It supports the aspects of Web Components that work well in browsers and only adds what's required to work in all Salesforce-supported browsers. It is a collection of advanced lightweight frameworks based on the most recent web standards. It's a reusable code-based document object model element. It's used to create sophisticated interfaces without the need for JS or the creation of a library. This functionality makes it simple to use and faster, saving developers a lot of time and work on the web stack.

Why would you choose one programming model over the other?

Lightning Web Components should be the go-to approach for development due its increased performance, ease of development and alignment with modern web standards. However, there are some scenarios where Aura components are still required, these include building community templates and URL accessible components, although LWC is quickly reaching feature parity.

Is it possible to use Aura Components with Lightning Web Components and vice versa?

Aura components can't be used in Lightning Web. You can, however, incorporate Lightning Web components into Aura components.

What is Lightning Component Framework and What is Aura Framework?

Lightning Component framework is a UI framework for developing single page applications for mobile and desktop devices.

·       It uses JavaScript on the client side and Apex on the server side. 

·       Lightning Component framework makes developing apps that work on both mobile and desktop devices far simpler than many other frameworks.

·        Lightning component Framework is based on Aura Framework.

·       Aura Framework is design by Salesforce which is open-source framework for creating ui components.

         What is Lightning App Builder?

Lightning app builder is used to create lightning pages for Salesforce Lightning experience and mobile apps. The Lightning App Builder is a point-and-click tool. Lightning Pages are built using Lightning components which are compact, configurable, and reusable elements that you can drag and drop into regions of the page in the Lightning App Builder.

 We can create different types of pages using lightning app builder,

 1)App Page

2)Home Page

3)Record Page.

 What is the use of $A.enqueueAction(action) and how to call server side action from client side?

$A.enqueueAction(action  ) adds the server-side controller action to the queue of actions to be executed.The actions are asynchronous and have callbacks.

 When we call a server-side controller i.e (Apex controller) method from a client-side controller i.e (Javascript controller), Apex controller method return results. In the javascript controller, We use action.setCallback which runs after the apex method execution gets completed in the apex controller.

What is Value provider and What is action provider in Salesforce Lightning component?

 Value provider is a way to access data, with value provider "v" we can fetch value of attribute from component markup in javascript controller. Value provider is denoted with v(view) and action provider is denoted with "c "(controller).

Value provider:

This value provider enables us to access value of component attribute in component markup and javascript controller.

<aura:component>

 <aura:attribute type="string" name="myfirstattribute" default="first text"/> 

{!v.myfirstattribute}

</aura: component>

Action provider:

This enable us to handle actions, event, handlers for the component.

Ex:<aura: handler  name="init" value="{!this}" action="{!c.doinit}"/>

In JavaScript controller,

({

doinit:function (component, event, helper) {

// some operations here

}

})

 What are Attributes in Salesforce Lightning component?

Attributes act like a variable to store different types of values.

Name and type are mandatory.

 <aura:attribute name="fruits" type="String[]" default="['apple','mango',’Banana’,'orange']" />

What is the use of interface force:hasRecordId and flexipage:availableForAllPageTypes in   Salesforce Lightning component?

By using force:hasRecordId interface in lightning component we can assign the id of the current record to lightning component. This interface adds an attribute named "recordId" to the component. The type of attribute is string and has 18-character Salesforce record ID.

To make our component available for record page and any other type of page, we need to implement the interface flexipage:availableForAllPageTypes.

 What is the use of interface Lightning:actionOverride in Salesforce Lightning component?

Lightning:actionOverride  interface Enables a component to be used as an override for a standard action. We   can override the View,New, Edit, and Tab standard actions on most standard and all custom components. The component needs to implement the interface Lightning:actionOverride after which the component appear in the Lightning Component Bundle menu of an object action Override Properties panel.

 What is the use of interface of flexipage:availableforrecordHome in Salesforce Lightning component?

Interface flexipage:availableForRecordHome make the component available for record pages only.

 What is the use of interface force:appHostable in Salesforce Lightning component?

Interface force:appHostable in component allow it to be used as a custom tab in Lightning Experience or the Salesforce mobile app.

In the Salesforce Lightning component, what is the difference between force:lightningQuickAction and force:lightningQuickActionWithoutHeader?

force:lightning - QuickAction allows you to use the component in Lightning Experience or the Salesforce mobile app as a custom action. Component interface shows in a panel with typical action controls, such as a Cancel button, when force:lightningQuickAction is used in a component.

 force:lightningQuickActionWithoutHeader - The component can be used as a custom action in Lightning Experience or the Salesforce mobile app thanks to the force:lightningQuickActionWithoutHeader interface. When force:lightningQuickAction is used in a component, the component interface appears in a panel without any normal action controls, such as a cancel button.

 What is the use of aura:handler  init event in Salesforce Lightning component?

This is also called as the constructor of lightning component. The init event is called once the component construction is over. As an example if I am creating a simple registration page and I want to display some default text value after page load in my input boxes I can do this by calling the javascript controller method and setting some default value in the attributes.                       

Basic Syntax:

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

 What is the use of aura:handler change event in the Salesforce Lightning component?

The change event is called when the value in one of the attribute changes.

As an Example If i am having  attribute " Anyname", on change of attribute "Anyname" if I want to call javascript method i can do this as:

Syntax:

<aura:attribute name="Anyname" type="String" />

<aura:handler  name="change" value="{!v.Anyname}" action="{!c.doinit}"/>

What are types of events in Salesforce Lightning component?

 Event – Any kind of interaction that happen in a webpage either automatically or by human interaction is an event.

 Types of events:

Component event: It is an event that is fired by component. A component event can be handled by component itself or it can be handled by any other component which is present in the hierarchy that receives the event.

 Application event: it is generally like broadcast message. If you send a broadcast, then all the receivers that are configured to accept that broadcast message receive that message. Similarly, an application event is fired by a component and all other components that have the handler defined to receive that event are notified when the event is fired. Application events are not bound by any hierarchy or relationship.

 Standard Out of the Box Events - These are some events that are provided to us by the framework that we can make use of without creating them. One example is the Show Toast event.

 What are the phases of Application event and how it is handled?

 1. Default Phase

2. Bubble Phase

3. Capture Phase

 Create the Event

Create the Application Event by selecting File > New > Lightning Event in the Developer Console and add the following code:

 <aura:event type="APPLICATION" description="Event template">

  <aura:attribute name="message" type="String" />

</aura:event>

Save it as LightningSimpleEvent.

 Fire the Event

In the component that needs to fire the event, add the following lines as part of the markup:

 <aura:registerEvent name="appEvent" type="c:LightningSimpleEvent"/>

 in the controller:

 var appEvent = $A.get("e.c:LightningSimpleEvent");

appEvent.setParams({ "message" : "Special Message" });

appEvent.fire();

 Handle the Event

For the component handling the event, we need to add the following to the component markup:

 <aura:handler event="c:LightningSimpleEvent" action="{!c.handleApplicationEvent}"/>

And we also add a method called handleApplicationEvent in the controller:

 

handleApplicationEvent : function (component, event, helper) {

  var message = event.getParam("message");

  component.set("v.receivedMessage", message);

}

 

Application Events in Default Phase

I created a small application to observe how Application Events work. It looks like this:

 

We have an application that contains two components. The two components, in turn, contain two more components to a create a total six components inside an application. Each component (as well as the application) has the ability to fire the application event we defined above (LightningSimpleEvent) through a button click, and each component also handles the same event and logs to the console when the event is handled.

 What happens when we click the Send Event button on Application 1:0? We see the following in the console:

 

As you can see, the two innermost components 43:0 and 70:0 got to handle the event first and then their parent 22:0. Next, the innermost components 124:0 and 151:0 followed by their parent 103:0. Finally the top level application gets to handle the event.

 What happens if I click one of the innermost buttons?

 

Exactly the same. It doesn’t matter where the event came from in the hierarchy. All components will get a chance to handle it.

Application Events in Bubble Phase

The example we saw above was handling events in “default” phase. When placing a handler, you have the option to handle the event in the “bubble” phase:

 <aura:handler event="c:LightningSimpleEvent" action="{!c.handleApplicationEvent}" phase="bubble"/>

 Before discussing what the bubble phase is, let’s change all the handlers in our example application to have phase="bubble". When I click 70:0 while all the handlers are handling in the bubble phase, I see the following in the console:

 

 

As you can see, in the bubble phase the event was first handled by the innermost component, the one that was clicked. Next, the parent got to handle the event and then the parent’s parent.

 Clicking 22:0 does something similar — firing component handles first and then we go all the way up to the root:

 

 The element that fires an event gets a chance to handle it first, its parent element second, grandparent third and so on until the application root gets to handle the event.

 Application Events in Capture Phase

We’ll start by doing exactly what we’ve been doing so far: code an example. For the next experiment, I changed all my event handlers to have phase="capture" instead of phase="bubble". Let’s observe what happens when we send an event from 70:0:

 

 As you can see, when the components were handling the event in the “capture” phase, the application root got to handle the event first, and then the event travelled down to the component that actually fired it. The component that fired the event got to handle it last.

If the event was fired by 22:0, the application root would get to handle it in the capture phase first, 22:0 would get to handle it second, and no other components would be able to handle the event during the capture phase:

 What is Application event Lifecycle?

·       Whenever an application event is fired, the capture phase is the first to begin.

·        The event is first “captured” by the outermost component, the application root. If the application root has a phase="capture" handler attached to it, it will be able to handle the event.

·       Once the application root has handled the event, the event will continue travelling down to the component that fired it and will be handled the next component in line — the child of the application root that leads to the target component. If the child has a phase="capture" handler, it will be able to handle the event.

·       The event continues to flow down until it reaches the component that fired the event. Since the event has now reached the target, the “capture” phase is complete.

·       The bubble phase begins right after capture is complete. In the bubble phase, the event is first received by the component that fired it. If the component has a handler for the event with phase="bubble", it will get a chance to handle it.

·       Next, the event “bubbles” to the parent. If the parent has a phase="bubble" handler, the parent gets to handle it.

·       The “bubbling” continues until the event has bubbled to the application root where the event can be handled with a phase="bubble" handler. You can probably see by now why this phase is called “bubble” — the event is rising up just like a bubble in water rises to the top.

·       Once the bubble and capture phases are complete, the third phase is the default phase. In this phase, like we saw earlier, all components as well as the root get a chance to handle the event.

The above lifecycle is broken if we use stopPropagation() somewhere in the capture or bubble phases.    

What are the phases of Component event and how it is handled?

 1.     Capture Phase

2 .   Bubble phase

 Creating Component Events

Just like application events, component events need to be defined in an event file that looks like this:

 <aura:event type="COMPONENT" description="Event template">

  <aura:attribute name="message" type="String" />

</aura:event>

 Firing Component Events

A component event needs to be registered in the component markup:

 <aura:registerEvent name="compEvent" type="c:LightningComponentEvent"></aura:registerEvent>

 The firing component also needs the following code to fire the event:

var evt = component.getEvent('compEvent');

evt.fire();

Handling Component Events

<aura:handler name="compEvent" event="c:LightningComponentEvent" action="{!c.handleEvent}"></aura:handler>

 The phase attribute is optional — the framework will handle events in the bubble phase by default. To handle component events propagating in the capture phase, phase="capture" needs to added to the aura:handler.

 

Capture and Bubble Phases in Component Events

Like we discussed, capture and bubble phases in component events work just like they work in application events. One handling the event in the bubble phase, and one in the capture phase:

 

<aura:handler name="compEvent" event="c:LightningComponentEvent" action="{!c.handleEventCapture}" phase="capture"></aura:handler>

<aura:handler name="compEvent" event="c:LightningComponentEvent" action="{!c.handleEventBubble}" phase="bubble"></aura:handler>

 

Let’s see what happens when we click one of the innermost components:

 

 You can see very clearly how the event was captured by the component and how it bubbled back to application root. If we click 22:0:

 

 

As expected, the parents all get the event in both phases, but there is no way for either the children or other sub-trees to handle the event.

 stopPropagation()

Stop propagation has a very simple job: Stop the capture and bubble process wherever it is. For an experiment, I used the following event handler in the component 22:0

 <aura:handler name="compEvent" event="c:LightningComponentEvent" action="{!c.handleEventBubble}" phase="bubble"></aura:handler>

I modified the action associated with this handler to stop the propagation of events:

 handleEventBubble: function (component, event, helper) {

  console.log('event in bubble phase received by outer controller: '

    + component.getGlobalId());

  event.stopPropagation();

}

Whenever component 22:0 handles compEvent in the bubble phase, the propagation would stop and no other components will receive the event. Let’s send the event from component 70:0 and see what happens:

 

 

As you can see, the capture phase was completed successfully, but the bubble phase was interrupted and the event never bubbled to the application root.

 What happens if we call event.stopPropagation() in the capture handler in component 22:0? Let’s have a look:

 

 

The capture phase began with the application root handling the event, continued with the component 22:0 handling the event but the cycle was stopped because the handler in component 22:0 called the stopPropagation() method. The capture phase was never completed and the bubble phase never started.

 

MORE QUESTIONS TO COME ..........