Explore topic-wise InterviewSolutions in .

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

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.

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.

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.

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.

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.

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

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.

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.

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.