Explore topic-wise InterviewSolutions in .

We should USE the FORCE:hasRecordId interface to retrieve the RECORD’s ID from the record DETAIL page.

For navigating to a page reference or constructing a URL from the given page Reference, we use lightning: navigation. The page reference object MUST be defined in order to navigate. page Reference is a JAVASCRIPT object that refers to a page and provides a defined structure that specifies the page's type and values.
We can access the following features that are SUPPORTED:

• Lightning Component
• Named Page
• Knowledge Article
• Record Page
• Object Page
• Navigation Item Page
• Web Page
• Record Relationship Page.

There are NUMEROUS approaches to COMPONENT debugging. The simplest and quickest is to use console logging statements to log variables THROUGHOUT code execution. However, this is a rather limiting technique, and there are far BETTER ways to debug our components. To remove minification and provide clearer error messages, the first step is to enable "Lightning Debug Mode." Additionally, we can utilise our browser's debugging tools to set breakpoints to inspect the precise execution of code within our components, evaluate variables at runtime, and walk through our code to better understand what's going on and figure out what's WRONG.

Attributes are variables that are used to store VALUES. The NAME, type, default, description, and ACCESS of the attribute are all defined. The aura:attribute> tag is used, which requires the name and type attributes to be FILLED in.

However, only the parameters name and types are necessarily required.

Lightning components, Salesforce1 mobile app, custom STANDALONE apps, and template-based communities MAY all be used DIRECTLY in Lightning Experience. The Visualforce page uses Lightning components for use in Salesforce Visualforce communities as well as the conventional environment. So, YES it is possible to use a lightning component that works with both mobile and desktop interfaces.

The Aura: method tag can be used to specify a component API function. As a result, there's no need to fire and handle a component event, and we may CALL the method in the component's controller directly from the CLIENT. It also makes the code REQUIRED for a parent component to invoke a method on a child component that is a PART of the parent component easier to understand.

As it's not feasible to add generic elements to custom components, AURA components can't be used in Lightning Web components (in other WORDS, a parent Lightning Web component can only be made up of Lightning Web components). You can, however, incorporate Lightning Web components into Aura components (i.e. parent Aura components can contain both Aura Components and LWC). They can ALSO deal with one other's events.

Yes, Lightning MAY be used in CONJUNCTION with other FRAMEWORKS, such as Angular. Aura components can ALSO be used with a third-party FRAMEWORK. However, a third-party framework cannot be used directly within Lightning Web Components.

No, there is no RESTRICTION to the NUMBER of COMPONENTS that can be USED in an APPLICATION.

• BOUND Expression: {!v.str} is the symbol for bound expression. This expression will reflect any changes in the STRING's value and will also influence the COMPONENTS where it is used, thus we can say the value changes dynamically through this expression.
• UNBOUND Expression: {#v.str} is the symbol for unbound expression. This expression will not reflect any changes in the string's value; we can argue that the value REMAINS static as a result of this expression.

YES, ONE Lightning COMPONENT can be included within ANOTHER Lightning.

A Mark-ups, JavaScript controller, a Helper, a Renderer, and other COMPONENTS make up each Lightning Component (Component Bundle). A screenshot of components in the developer console view is shown below.

The Types of Lightning Component Bundles are as follows:

• Component: Components are required while CREATING a Lightning app. Using Lightning Components, it holds the mark-up for the app design.
• Controller: This is a controller that runs on the client's SIDE. A component's events are handled by a client-side controller. Following are the uses of the Controller :
  • Controllers are required to listen to user events as well as other events such as Component Events and Application Events.
  • Allows business logic to be delegated to helper methods.
  • DML operations should not be triggered during component initialization. When we do DML in init(), we risk a CSRF (Cross-Site Request Forgery) attack.
  • In the Controller, the DOM is not changed. If we change the DOM in the controller, it will call the renderer method, which will return an error.
• Helper: The server-side controller is known as a Helper. It's typically utilised for server-side activities and data or task processing. A client-side controller or renderer can invoke Helper's java-script function. It's also included in the component set. Because Helper is shared across all components, it allows us to centralise and share functionality between Controllers and Renderers. It also makes it easier to keep the logic in Controllers and Renderers minimal. We must relocate this logic to Helper whenever we need to invoke one controller function from another controller function. Any other JavaScript in the component bundle can call helper functions. When a component runs, Lightning FRAMEWORK creates a Controller and a Renderer instance for each component, but only creates one copy of the Helper and sends the reference to the Helper into every Controller and Renderer instance.
• Renderer: The client-side controller is the renderer. It's a JavaScript resource that defines all of the component's actions and functions. When an event occurs, it may cause actions to be taken, such as changing data or calling rerender() on impacted components. The rerender() function allows components to update themselves based on other components' updates since they were last rendered. Before adding custom rerendering logic, we usually wish to expand default rerendering by invoking superRerender() from the renderer() function. The rerendering is chained to the components in the body attribute when superRerender() is called.
• Style: The component's styles are stored in CSS Styles. Click the STYLE button in the Developer Console sidebar to add CSS to a component bundle.

Four ESSENTIAL design ideas were used to create the Lightning Experience UI, which SLDS embodies. They are as follows :

• Clarity: Eliminate ambiguity with clarity. Allow individuals to confidently perceive, comprehend, and act.
• Efficiency: Make workflows more efficient by streamlining and optimising them. Anticipate needs intelligently to help individuals perform better, smarter, and faster.
• Consistency: Applying the same SOLUTION to the same SITUATION creates familiarity and strengthens intuition.
• Beauty: Through DELIBERATE and elegant craftsmanship, show RESPECT for people's time and attention.

Salesforce Lightning Experience is a user interface that is modern, fast, and intelligent, and it is built on established Salesforce1 Mobile APP technology. To construct modern corporate APPLICATIONS, it INTEGRATES the Lightning Designing System (LDS), Lightning App Builder, and Lightning Components. Salesforce Lightning Experience is a next-generation productive user interface for Salesforce.com's sales and supports staff. Salesforce.com has introduced Salesforce1 for mobile applications, as well as two user interfaces for desktop versions of Salesforce traditional and lightning Salesforce.

Lightning Experience (or LEX for short) introduces a completely new client-side architecture, DEPARTING from the server-side rendering given by its predecessors (Salesforce Classic) and Visualforce. Visualforce UIs can still be used with Lightning Experience for backwards compatibility, but they won't have the same amount of extensibility or visual appeal as custom UIs DESIGNED with the Lightning framework.

Salesforce Lightning Design System (SLDS) gives you the tools to construct apps that follow Lightning Experience's CONCEPTS, design language, and best practices. 

The following are some of the advantages that make SLDS so beneficial:

• When enhancing existing functionality or integrating with external systems, gives a unified experience and streamlined workflows.
• Padding and MARGINS are not over-enforced by default.
• It is updated on a regular basis. As long as you're using the most recent version of SLDS, your PAGES will be Lightning Experience compliant.
• The CSS framework includes accessibility.
• It is compatible with various CSS frameworks, such as Bootstrap.
• Visualforce pages that match the look and feel of the Salesforce mobile app can be created with the Lightning Design System (SLDS). To use SLDS, you'll need to make a few changes to your code and remember a few things. Visualforce programming that uses SLDS, for the most part, works without a hitch.
• Our action, custom, DOCTYPE, standard, and utility icons are available in PNG and SVG (individual and sprite map) FORMATS in the Lightning Design System (SLDS).

The Salesforce LIGHTNING Design System (SLDS) allows you to CREATE Lightning Experience-style applications WITHOUT WRITING a single line of CSS. SLDS is a CSS framework that allows you to USE the icons, colour palettes, and fonts that our designers use to create Lightning Experience.

Lightning Data Service (LDS) is used to CREATE, delete, update, and load records in our component without using Apex code. Lightning Data Service is in charge of field-level security and sharing regulations. Lightning Data Service enhances efficiency and user interface consistency while simplifying access to Salesforce data. At its most basic level, Lightning Data Service can be thought of as the Lightning components' version of the Visualforce standard controller. While this statement is exaggerated, it serves to highlight a point. Use Lightning Data Service to access and alter Salesforce data in your components wherever possible.

The Lightning Data Service makes data access easier than utilising a server-side Apex controller. Read-only access can be declared explicitly in the markup of your component. Your component's JavaScript controller has nearly the same amount of code for data modification, and you can get rid of the Apex entirely. All of your data access code is condensed inside your component, reducing complexity dramatically. Aside from the CODING, Lightning Data Service has other advantages. It is based on highly efficient local STORAGE that is SHARED by all components that make use of it. Lightning Data Service records are cached and shared between components.

There are four types of Salesforce Lightning Events. They are as follows:

• System Events: The lightning framework fires system events when a component is initialised, rendered, or an attribute value is changed, AMONG other things. The following are the various sorts of Lightning-supported system events:
  • aura:valueInit: When the component markup is started or loaded but the component page is not yet rendered, this event runs a logic. This is the first TIME a system event is triggered.
  • aura:valueRender: When the component page is fully drawn or re-rendered, it runs a logic.
  • aura:noAccess: When the requested resource has no ACCESS authorization, this event runs a logic.
  • aura:locationChange: When the URL hash part of the URL has been updated, this event runs a logic.
  • aura:systemError: When an error occurs during the execution of a server-side (apex controller) activity, this event runs a logic.
  • aura:valueChange: When the value of an aura property is updated, this event runs a logic.
  • aura:valueDestroy: Runs a logic when a component is destroyed and we want to do some custom cleanup at the same time.
• Lightning Application Events from Library: These events are offered by Salesforce Library and can be utilised frequently depending on your needs. However, some of these library events may not be supported simultaneously in a Salesforce app, Lightning Experience, or standalone app. As a result, it's best to use $A.get() to figure out where your component is running, whether it's a Salesforce app with Lightning Experience or a standalone app.
• Application Events: Application Events assist in the exchange of values between two separate events (WITHOUT a parent-child relationship). It WORKS in the same way as a broadcast message, in that any device with the receiver turned on can receive the broadcast message transmitted by a single device. It means that any component having an event handler statement can receive the fired event in the case of Application Events.
• Component Events: To send values from a child component to its parent, component events are required. The event fired by the child components (sender) will be handled by the parent component (receiver).

We can mix up the Aura and LWC components. The ultimate parent component is Aura. Auras contain both LWC and Aura components, whereas Lightning WEB Components only have their own component.
If Aura and LWC components are ENCLOSED within a parent, they can interact in a variety of ways:

• Using application and component events to interact directly with the CHILD component.
• Receive DATA and interact with child component methods and attributes provided through public APIs using JS CustomEvent objects.
• Lightning Data Service (LDS) allows both the Aura components and LWC to receive and transfer data. There is currently no communication mechanism between Aura and Lightning web components that are not in the same hierarchy.

The distinction between the Lightning Web Components and the Aura Components is only visible to those working behind the SCENES. However, Salesforce and the community recommend that developers use LWCs when building SPAs for the following reasons:

• Easy to Learn: LWC takes the form and fills it up using the browser's native web standards. This means that no additional distraction layer, such as Aura Framework or another framework, is required; all we need to BUILD is regular JavaScript.
• Higher PERFORMANCE: Because performance is vital to deliverability, LWC is LIKELY to render faster than the aura components in the absence of an abstraction layer.
• Sites LOAD Faster: LWC is a lightweight framework that loads built components quickly.
• Less Proprietary, More Standards: Because LWC has built-in browser security features from Web Components Standards, out-of-the-box modification is becoming less common.
• Components with no/little UI can be written in LWC, and those components can be reused in other components, making them more efficient than static resources.
• Easy to Learn for Developers: There is no need to learn any additional framework in order to construct LWC. As a result, the developers have an easier time.
• Security, Testing, and Browser Compatibility are all Improved: Script, CSS, and DOM isolation are better with LWC, and event scope is limited. We have more uniformity in the design of the components with each of these. In addition, LWC provides two-way data binding, which allows us to coordinate how data moves between different components.

Following are the benefits of using the Aura components programming model :

• Components that come pre-assembled: Comes with a pre-installed collection of components to get you started designing apps right away. You won't have to waste time OPTIMISING your apps for various DEVICES because the components will do it for you.
• An ecosystem with a Variety of Components: Make business-ready components available through the Salesforce app, Lightning Experience, and COMMUNITIES. Users of the Salesforce app can access your components through the navigation menu. Drag-and-drop components on a Lightning PAGE in the Lightning App Builder or use Experience Builder to customise Lightning Experiences or Communities. The AppExchange has more components for your organisation. You can also publish and share your components with other users.
• Fast Development: It enables teams to work more quickly by providing out-of-the-box components that work on both desktop and mobile platforms. Using components to BUILD an app allows for parallel design, which improves overall development efficiency. Components are encapsulated, and their internals are kept private, but their public shape is visible to component users. This strong separation allows component authors to modify core implementation details while shielding component users from them.
• Cross-browser compatibility and device awareness: Apps are responsive and support the most recent browser technology, including HTML5, CSS3, and touch events.

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