Salesforce Lightning Interview Questions

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.

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.

We should use the force:hasRecordId interface to retrieve the record’s id from the record detail page.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

Yes, one Lightning component can be included within another Lightning.

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

No, there is no restriction to the number of components that can be used in an application.

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.

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.

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.

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.

A Lightning page is a custom layout that you may use to create pages for the Salesforce mobile app or Lightning Experience. Lightning pages are a cross between Visualforce pages and page layouts. Lightning pages, like page layouts, allow you to add custom items to a page. Instead of being fields or Visualforce components, these elements are Lightning components, which provide far more freedom. A Lightning page's structure changes depending on the device it's being viewed on. When you create a page, the template you choose determines how it appears on different devices. The template for the Lightning page divides the page into regions.

Lightning pages are made up of Lightning components, which are small, reusable, and adjustable pieces that you can drag and drop into page regions in the Lightning App Builder. A Lightning page can be used to construct an app page that you can add to the navigation bar of a Lightning app, making it visible in both Lightning Experience and the Salesforce mobile apps. An app page allows users to quickly access the most important objects and items in the app.

Lightning Out is a feature that allows Lightning Apps to be extended. It operates as a connector, allowing Lightning Components to be accessed from any external web container. This means you may utilise your Lightning Components on an external site (such as SharePoint or SAP), in a hybrid app built with the Mobile SDK, or even on Heroku or in a Visualforce Page. You may embed Lightning Components in an app across domains and manage interactions between the component and the app directly in the DOM using the Lightning Out JavaScript libraries. Your Lightning Components become substantially more effective with Lightning Out. You can utilise Lightning Components not only in other Lightning Components or Lightning Apps, but you can also expose them in almost any web container, on or off the App Cloud.

For component event propagation, the framework offers capture and bubble phases. These phases are similar to DOM handling patterns in that they allow interested components to engage with an event and maybe impact how future handlers behave.

The source component is the component that fires an event. The framework enables you to manage the event in stages. These phases provide you with the freedom to decide how to handle the event in your application.

The phases are as follows:

• Capture: The event is caught and passed down to the source component from the application root. A component in the containment hierarchy that receives the captured event can handle the event. From the application root down to the source component that triggered the event, event handlers are called in succession. Any registered handler in this stage can prevent the event from propagating, at which point neither this phase nor the bubble phase will call any additional handlers.
• Bubble: The event can be handled by the component that triggered it. The event then propagates up to the application root from the source component. A component in the containment hierarchy that gets the bubbled event can handle the event.
  The event handlers are called in the order that they were triggered, starting with the source component that fired the event and ending with the application root.
  In this phase, any registered handler can stop the event from propagating, at which point no more handlers are called.

For the propagation of application events, the framework offers the capture, bubble, and default phases. The capture and bubble phases are similar to DOM handling patterns in that they allow interested components to engage with an event and perhaps impact later handler behaviour. The framework's initial handling behaviour is preserved in the default phase. The source component is the component that fires an event. The framework enables you to manage the event in stages. These phases provide you with the freedom to decide how to handle the event in your application.

The phases are as follows:

• Capture: This phase is the same as that of the component event.
• Bubble: This phase is the same as that of the component event.
• Default: From the root node through its subtree, event handlers are called in a non-deterministic order. The default phase does not follow the same component hierarchy propagation principles as the capture and bubble phases. Application events that affect components in separate sub-trees of your app can be handled using the default phase.
  The root node defaults to the application root if the event propagation was not stopped in a prior phase. The root node is set to the component whose handler invoked the event.stopPropagation() if it was halted in a previous phase.

The following table lists the differences between component events and application events :

Salesforce Classic: Salesforce Classic is simply a term used to differentiate between the new and old user interfaces. It's essentially the same stage that we've been using for a long time. With the passage of time, the expectation to learn and adapt grows, and we can more easily discern the gaps between the customer's requirements and the services that they are receiving. It is critical to stay up with advancements, enhancements, and customer requirements during this particularly delicate phase of time innovation. It's also critical to update the user interface to make it easier to use and to keep it up to date with the latest technology.

Following are the differences between Salesforce Lightning and Salesforce Classic:

• User Experience Improvements: The user interface is one of the most significant differences between Salesforce Classic and Salesforce Lightning. The latter provides a far superior user interface to its users, including features such as drag-and-drop functionality that may be accomplished without the use of any coding. Instead of engaging a Salesforce developer to construct or change a Salesforce page, an admin can quickly rearrange the page components to their preference. In addition, Lightning helps to reduce the requirement for Visualforce for each activity. Any code that is produced during development must be tested before being deployed. In the event that a bug is missed, the code is sent back to the developer to be fixed, and the process begins again. These types of time-consuming activities can be avoided with Salesforce Lightning.
• Enhanced Security: Salesforce Lightning provides a higher level of protection. LockerService, for example, is a feature that allows Lightning components to interact with each other by separating them. This contributes to the platform's protection against harmful data. In Classic mode, there is no such feature.
  Permissions work differently in Salesforce Lightning as well. Users cannot change their assurance levels in-session, for example, from standard to high. They'll have to log out of the Lightning platform and log back in user authentication with a higher level of certainty.
• Einstein (Wave) Analytics: While an improved and upgraded user interface and security are compelling arguments, Salesforce Lightning also gives consumers access to Einstein (Wave) Analytics reports, which the Classic does not. Salesforce Classic reports use common reporting types to create graphs, charts, and lists. These dashboards show to be a terrific solution for capturing a view of crucial indicators when the data is refreshed.
• Progressive platform: Lightning was criticized in its early days due to its transition and compatibility concerns with objects, custom code, and apps. But those days are behind, and the platform has developed to accommodate any custom metadata items, making it much easier for businesses to migrate their existing apps and workflows without having to start from scratch.

Visualforce: Visualforce is a framework that allows developers to create complex, creative user interfaces that run natively on the Lightning platform. The Visualforce framework provides a tag-based markup language, comparable to HTML, as well as a collection of server-side "common controllers" that make doing fundamental database operations like queries and saves a breeze. Each Visualforce tag corresponds to a coarse or fine-grained user interface component, such as a segment of a page, a related list, or a field, in the Visualforce markup language. Developers can attach their own logic with an Apex controller class to control the behaviour of Visualforce components, or they can utilise the same logic that is used in regular Salesforce pages to govern the behaviour of Visualforce components.

The majority of the work is done on the server with Visualforce components. Rather than using the concept of a page as its core unit, Lightning is built from the ground up. Client-side centricity makes Lightning Components more dynamic and mobile friendly.

Following are the different types of lightning pages available in Salesforce Lightning :

• App Page: The Salesforce mobile app and Lightning Experience both enable app pages. We can create a home page for a third-party app using an app page, which we can integrate straight into the Salesforce mobile app and Lightning Experience navigation menus. Our users will then have access to an app home page where they can access the most important objects and items fast. To improve the functionality of an app page, we can add global actions. A user can enter call data, create and update records, send email, and start a task using global actions from your app page. When a user opens the Salesforce mobile app and navigates to a Lightning page, the page's activities display in the action bar. Actions display in the highlights panel at the top of the page in Lightning Experience.
• Home Page: Home pages are used to create custom pages with features relevant to specific categories of users, and assign the pages to various apps or app-and-user-profile combinations. Only the Lightning Experience supports custom home pages.
• Record Page: We can construct a customised version of an object's record page with a record page, adapting it to your users' needs. Lightning Experience and the Salesforce mobile app both enable custom record pages.

The metadata associated with a lightning page is represented by FlexiPage. The lightning page depicts an adaptive screen made up of areas that include the lightning components. There are 25 components on the lightning page. The Flexi page is saved as an XML file and deployed using a deployment tool or metadata API. In the API, lightning pages are referred to as Flexipages.

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

You can freeze user accounts to prevent them from working in your business while you undertake the steps to deactivate them. So, until you figure out how to remove this user from the Role hierarchy, you can update the owner of the entries he created/from any location where this user is employed. For this, we can use the FREEZE button on the user record.  If we click the FREEZE button, the user will no longer be able to log in to the application. Changing user accounts in the state does not free up existing user licences for use in your organisation. To release the licence, we must deactivate the user.

First and foremost, It is impossible for a Controller Extension to exist on its own. It will be applied to either a standard or a custom controller.  So, keeping the end goal in mind, certain techniques, for example, must be dead in User Mode and sure in System Mode. In this case, using a standard controller with a custom extension is a no-brainer. Wherever the victim is, the normal Controller provides all of the Force.com platform's pre-existing options. However, after we use the normal Controller, all of the Sharing rules, as well as a user's permissions, are revered. So, if this is what we frequently require, we should always choose this type of solution.

Profiles confirm the scope of a user's access in a Salesforce org. Because the first portion of the question is so important, Yes. A single profile is issued to a large number of users. A comparable profile will be issued to the entire team. The admin will create a single profile called Sales Profile, which will have access to Leads, Opportunities, Campaigns, Contacts, and other corporate items. This signifies that a similar profile has been assigned to a number of people. If the team leader or manager needs access to additional records or objects, distribution permission sets are created specifically for those users.

First, choose an object that is a parent object (Master) and a child object (Kid) (Detail). Let's pretend that we've decided that Obj1 will be the Master object and Obj2 will be the Detail object for the time being. First, let's define a Master-Detail relationship.Every child should have a parent. This means that each record in Obj2 must be linked to a parent record in Obj1. In addition, one child will have only one parent. One parent, on the other hand, will have several children. Let us consider that there are already existing records in Obj2. According to the Master-Detail relationship, we must ensure that each record in Obj2 is linked to a record in Obj1. And, in our current condition of affairs, Obj1 and Obj2 are not linked. As a result, we must first create a simple search relation between these two things in order to construct a relationship between them. As a result, we have a tendency to follow the instructions outlined below.

• We usually create a search box within the child Object Obj2 and inform Obj1 as a parent.
• Replace the price from Obj1 in the search field of all records in Obj2 (Related field)
• We then have a tendency to change the sphere search to a Master-Detail relationship.

In Salesforce, a Many-to-Many Relationship is also known as a Junction object. The steps to make it are as follows. 

• Create each object that has to be linked together.
• Create one custom object, also known as a Junction object, that should have Associate in Nursing automotive vehicle number as a unique identifier.
• For each item, create a pair of Master relationships.
• Make this a connected list on each object.

Conclusion

• Top Product Based Companies
• Salesforce Developer Salary
• Mulesoft Interview Questions
• Technical Interview Questions