Skip to main content

Lightning Component Basic and Advanced

Lightning Component also refer as Aura Component Or Aura Framework is base on View-Controller Architecture. Refer the Below Image which has been taken from Trailhead Module.
Aura architecture

Server-Side Controller (Apex):

Server calls are expensive, and can take a bit of time. Milliseconds when things are good, and long seconds when the network is congested. You don’t want apps to be locked up while waiting for server responses.
The solution to staying responsive while waiting is that server responses are handled asynchronously. What this means is, when you click the Create Expense button, your client-side controller fires off a server request and then keeps processing. It not only doesn’t wait for the server, it forgets it ever made the request!
Then, when the response comes back from the server, code that was packaged up with the request, called a callback function, runs and handles the response, including updating client-side data and the user interface.
If you’re an experienced JavaScript programmer, asynchronous execution and callback functions are probably your bread and butter. If you haven’t worked with them before, this is going to be new, and maybe pretty different. It’s also really cool.

There are only two specific things that make this method available to your Lightning Components code.

  • The @AuraEnabled annotation before the method declaration.
  • The static keyword. All @AuraEnabled controller methods must be static methods, and either public or global scope.
Note: “Aura” is the name of the framework at the core of Lightning Components. You’ve seen it used in the namespace for some of the core tags, such as <aura:component>. Now you know where it comes from.

Load Data From Server:
The next step is to wire up the expenses component to the server-side Apex controller.
<aura:component controller="ExpensesController">

However, pointing to the Apex controller doesn’t actually load any data, or call the remote method. Like the auto-wiring between the component and (client-side) controller, this pointing simply lets these two pieces “know about” each other. This “knowing” even takes the same form, another value provider. But the auto-wiring only goes so far. It remains our job to complete the circuit.

In this case, completing the circuit means the following.
  1. When the expenses component is loaded,
  2. Query Salesforce for existing expense records, and
  3. Add those records to the expenses component attribute.

Handler Tag in Component :
<aura:handler name="init" action="{!c.doInit}" value="{!this}"/>

Calling Server-Side Controller Methods

    // Load expenses from Salesforce
    doInitfunction(componenteventhelper) {
        // Create the action
        var action = component.get("c.getExpenses");
        // Add callback behavior for when response is received
        action.setCallback(thisfunction(response) {
            var state = response.getState();
            if (state === "SUCCESS") {
            else {
                console.log("Failed with state: " + state);
        // Send action off to be executed

The outline of what this code does:
  1. Create a remote method call.
  2. Set up what should happen when the remote method call returns.
  3. Queue up the remote method call.
var action = component.get("c.getSomething");
This line of code creates our remote method call, or remote action which has been Static and AuraEnabled in Apex.

Looks Similar?
Yes! It was “v.something” that we were getting, with v being the value provider for the view. Here it’s “c”, and yes, c is another value provider. And we’ve seen a c value provider before, in expressions like press="{!c.clickCreate}" and action="{!c.doInit}".


We saw $A briefly before, but didn’t discuss it. It’s a framework global variable that provides a number of important functions and services. $A.enqueueAction(action) adds the server call that we’ve just configured to the Aura component framework request queue. It, along with other pending server requests, will be sent to the server in the next request cycle.
That sounds kind of vague. The full details are interesting, and important for advanced use of Aura components. But for now, here’s what you need to know about $A.enqueueAction(action).
  1. It queues up the server request.
  2. As far as your controller action is concerned, that’s the end of it.
  3. You’re not guaranteed when, or if, you’ll hear back.
In this specific callback function, Salesforce do the following.
  • Get the state of the response.
  • If the state is SUCCESS, that is, our request completed as planned, then:
  • Set the component’s expenses attribute to the value of the response data.
Do the Following Trialhead for hands On : Lightning Component Basic and Advanced


Popular posts from this blog

Platform Developer I Certification Maintenance (Winter '23)

 Maintain Your Platform Developer I Certification for Winter ’23 1. Field update actions have changed in API Version 54.0. Which record-triggered flows do field update actions now execute? Answer: Before-Save after After-Save 2. Which Apex class is used to determine the hostnames for the domains that Salesforce hosts for your org? Answer: System.DomainCreator 3. Which modules can be used for notifications in a Lightning web component instead of native APIs? Answer: LightningAlert, LightningConfirm, and LightningPrompt 4. What determines an org’s “shape” in Salesforce? Answer: Features, settings, edition, limits, and licenses 5. Which lightning-modal-* component is required to create a modal? Answer: Body 6. How do you call an invocable action from Apex code? Answer: Reference Invocable.Action Get Hands-On With Apex Assertions 1. Create Two Apex class: Copy and Paste below codes (A.) TestFactory @isTest public class TestFactory {    public static Account getAccount(String accountName, B

Custom Table In LWC

I'm assuming you've Basic understanding of Lightning Web Component, I'll be explaining you the syntax that will be generic. HTML: < template > <!-- Header Part -->      < lightning-card   title = "Custom Data table in Lightning Web Components" >          < div   class = "slds-grid slds-gutters" >              < div   class = "slds-col" >                  < span ></ span >              </ div >              < div   class = "slds-col" >                  < span > <!--A Button For extra feature-->                      < lightning-button   label = "Show Selected Contacts"   onclick = {showContacts}   style = "margin-left: 40%"   variant = "brand" > </ lightning-button >                  </ span >              </ div >          </ div >< br />

LWC js-meta.xml Configuration File Tags

Each Lightning web component folder must include a configuration file named <componentName>.js-meta.xml. The configuration file defines the metadata values for the component, including the design configuration for the Lightning App Builder and Community Builder. Some Standard Key metadata values: apiVersion : A double value that binds the component to a Salesforce API version. isExposed : If isExposed is false, the component is not exposed to Lightning App Builder or Community Builder. To allow the component to be used in Lightning App Builder or Community Builder, set isExposed to true and define at least one <target>, which is a type of Lightning page. Some Standard Optional metadata values: description : A short description of the component, usually a single sentence. masterLabel : The title of the component. Appears in list views, like the list of Lightning Components in Setup, and in the Lightning App Builder and in Community Builder. targets : Specifies wher