LWC Interview Questions

• LWC is a modern framework to build UI in Salesforce.
• Built using standard web technologies (HTML, JS, CSS).
• Runs natively in the browser for better performance.

• LWC uses modern web standards, while Aura uses a Salesforce-specific framework.
• LWC is faster and lighter than Aura.
• LWC supports native browser features like Shadow DOM.

• Faster performance and better browser rendering.
• Code is cleaner and more reusable.
• Easier for web developers to adopt (uses standard JS).

• LWC supports all modern browsers: Chrome, Edge, Safari, Firefox.
• Works on both desktop and mobile browsers.
• Internet Explorer is not supported.

• LWC is built on Web Components, a W3C browser standard.
• Uses Custom Elements, Shadow DOM, HTML templates.
• Ensures future-proof and reusable components.

• Shadow DOM isolates component styling and structure.
• Prevents styles from leaking in or out.
• LWC uses Shadow DOM to ensure UI encapsulation and security.

• Yes, you can embed LWC into Aura components.
• Use <c:yourLWCComponent /> in the Aura markup.
• Ensure the LWC is exposed via @api.

• Yes, core LWC engine is available on GitHub.
• Salesforce open-sourced it to support wider developer use.
• Developers can explore, contribute, and build outside Salesforce.

• It uses less code and less memory compared to Aura.
• Loads and runs faster in the browser.
• Relies on native browser features, not heavy libraries.

• No built-in support for two-way data binding.
• Can't use aura:method, aura:attribute, or events from Aura.
• Limited global eventing — use Pub-Sub or Message Service.

• .js – JavaScript logic file.
• .html – HTML template for UI.
• .js-meta.xml – Configuration file (exposes the component in Salesforce).

• It defines where and how the component can be used.
• Controls visibility in App Builder, Utility Bar, Community, etc.
• Includes tags like <isExposed>, <targets>, and <targetConfigs>.

• No — each component must have its own folder.
• Folder name must match the component name.
• Salesforce uses folder structure to identify components.

• Set <isExposed>true</isExposed> in .js-meta.xml.
• Add a target like <target>lightning__AppPage</target>.
• Deploy the component and use it in App Builder.

• Use the <targets> tag to specify allowed pages.
• Example: only allow on Record Pages using <target>lightning__RecordPage</target>.
• Omitting other targets restricts usage to only selected ones.

• Defines where the component can be placed (App Page, Record Page, etc.).
• Controls where the component shows up in the App Builder UI.
• Helps with granular control over component usage.

• Add <target>lightning__RecordPage</target> in .js-meta.xml.
• Set <isExposed>true</isExposed>.
• Then it appears as a custom component in Record Page setup.
  • To restrict it to a specific object, use:
    
                   <targetConfigs>

                <targetConfig targets="lightning__RecordPage">

                        <objects>

               <object>Account</object>

                         </objects>

               </targetConfig>

           </targetConfigs>

•  Makes the component visible in tools like App Builder.
•  Without isExposed, the component is not available for drag-drop.
•  Must be set to true for public/external usage.

• Yes, in the .js-meta.xml file using <apiVersion> tag.
• You can increase to use newer features or avoid deprecated ones.
• Use the same version as your org's default when possible.

• Use VS Code + Salesforce Extensions (SFDX) for push/pull.
• Or deploy via Change Sets, Metadata API, or Unlocked Packages.
• Deploy all three files (.js, .html, .xml) inside the lwc/ folder.

• Use standard HTML5 inside the .html file.
• Bind data using {property} syntax.
• Use <template> blocks for conditions and loops.

• LWC automatically scopes CSS to the component using Shadow DOM.
• Styles do not affect other components.
• You style elements normally inside a .css file with the same name.

• SLDS (Salesforce Lightning Design System) is included by default.
• Use class names like slds-button, slds-card in your HTML.
• Helps maintain Salesforce look and feel.

• Yes, use loadStyle() from lightning/platformResourceLoader.
• Upload the stylesheet as a Static Resource.
• Load it inside connectedCallback() or similar lifecycle hook.

• CSS is scoped locally, cannot affect parent/sibling DOM elements.
• Global overrides require workarounds like :host.
• Inline styles are allowed, but @import and global styles are limited.

•  Yes, use style attribute like standard HTML.
• Example: <div style="color: red;">Hello</div>.
• Or use dynamic binding: <div style={dynamicStyle}></div>.

• Use CSS Static Resources for shared styles.
• Load them using loadStyle() in each component.
• LWC doesn’t support global CSS files natively.

• A base component that provides consistent styling and layout.
• Wraps content in a styled box with header and body.
• Commonly used in App Builder and record pages.

• Yes, but carefully — avoid breaking design consistency.
• Use custom classes + !important if needed (not recommended).
• Prefer extending SLDS classes instead of overriding them.

• Use class={dynamicClass} in HTML.
• Build the class in JS based on logic.
• Example: this.dynamicClass = this.error ? 'slds-text-color_error' : 'slds-text-color_success';

• Declare variables inside the class; they are reactive by default.
• Used to update the UI automatically when their values change.
• Bind to HTML using {propertyName} syntax.

• Makes object or array properties reactive (mainly for nested updates).
• Not needed for simple data types like string or number.
• Used to track changes inside complex data structures.

• Marks a property/method as public, accessible from the parent component.
• Used for data binding or calling child methods.
• Enables communication between components.

• Public: Decorated with @api, accessible from parent.
• Private: Declared without decorator, used only internally.
• Use @api for shared data, keep internal data private.

• Bind the method to an event like onclick in HTML.
• Method must be defined in the JS file.
• Used for handling user interactions (e.g., button clicks).

• Modules are reusable JS units; imports bring them into your component.
• You import from lwc, other components, or utility files.
• Example: import { LightningElement } from 'lwc';

• Every LWC JS file must export a class.
• The class should extend LightningElement.
• It’s the main logic container for the component.

• Add event handler like onclick={handleClick} in HTML.
• Define the method in JS using event.target if needed.
• Used for inputs, buttons, and other interactive elements.

• Use {} to bind JS variables in the template.
• For input fields, use value={property} and onchange.
• Keeps the UI and JS in sync.

• Declarative (@wire) is automatic and easy but limited.
• Imperative gives full control (useful for dynamic behavior).
• Use declarative for display, imperative for action-based logic.

• LWC supports one-way data binding.
• Data goes from JS to HTML, not the other way.
• You update JS manually when the user changes something.

• Use {property} in HTML.
• If the JS variable changes, the UI updates.
• UI changes won’t update JS unless you handle it.

• Use onchange or oninput in HTML.
• Get value using event.target.value.
• Update your JS variable inside the handler.

• Makes nested object/array changes visible in UI.
• Not needed for simple variables like strings or numbers.
• Used for objects like this.account.name.

• No direct two-way binding.
• You manually sync input and variable using event.
• Use value={x} + onchange={handleChange}.

• Use value={name} in <input>.
• Add onchange={handleChange} to update JS.
• Keeps UI and JS in sync manually.

• Use {} to show JS data in HTML.
• Example: <p>{message}</p>.
• Works with variables and getters.

• Calculates a value in JS and shows in HTML.
• Used like a variable: {fullName}.
• Helps format or combine values.

• Use <template for:each={items}>.
• Loop through the array in HTML.
• Add key={item.id} for performance.

• Yes — use dot notation like {account.name}.
• For reactivity, use @track or reassign the object.
• Deep changes need special handling.

• By using public properties or methods in the child.
• The parent sets values using HTML attributes.
• Uses the @api decorator in the child component.

• Makes a property or method public in the child component.
• Allows the parent to pass data or call methods on the child.
• Enables parent-to-child communication.

• By using custom events.
• The child dispatches an event.
• The parent listens and handles it using an event handler.

• Events created by a component to send custom data.
• Used for child-to-parent communication.
• Created with new CustomEvent() in JavaScript.

• Use new CustomEvent('eventName', { detail: data }).
• Call this.dispatchEvent(event) inside the child.
• Example: this.dispatchEvent(new CustomEvent('notify'));

• In the parent's HTML, add on<eventname> to the child tag.
• Example: <c-child onnotify={handleNotify}></c-child>
• The handler method is defined in the parent’s JS file.

• Bubbling allows events to move up the DOM tree.
• Composed allows events to pass through Shadow DOM.
• Use { bubbles: true, composed: true } for full visibility.

•  Not directly.
• They can communicate via their parent using custom events.
• Or use Pub-Sub model for loose coupling.

• Pub-Sub (Publish-Subscribe) is used for sibling-to-sibling communication.
• One component fires an event, another one subscribes to it.
• Works well in non-nested components within the same page.

• It connects an Apex method or data service to your component.
• Automatically fetches data and re-renders the UI when data changes.
• Used for read-only, reactive data access.

• Import the Apex method using import getData from '@salesforce/apex/ClassName.method';
• Use @wire(getData) above a JS property or function.
• Example: @wire(getAccounts) accounts;

• Use an object with @wire(getData, { param1: '$value' }).
• Prefix $ means the parameter is reactive.
• The wire re-runs when the parameter value changes.

• The @wire function receives the error inside the error field.
• You can check if (error) and show a message.
• No need for try-catch — the error is handled by LWC.

• Use console.log(error) inside the @wire function.
• Use browser DevTools or debugger.
• Check Salesforce Debug Logs or Developer Console for server-side issues.

• Only works for Apex methods marked as @AuraEnabled(cacheable=true).
• Cannot be used for mutating data (create, update, delete).
• Limited error handling and no manual control over timing.

•  Yes, you can use multiple @wire for different methods.
• Each can bind to a different property or function.
• Keep them separate and manage their data individually.

• Import refreshApex from @salesforce/apex.
• Call refreshApex(wiredVariable) in your JS code.
• It re-invokes the Apex call and updates the UI.

• No — Apex methods must be annotated with @AuraEnabled.
• For wire, also add cacheable=true if it's a read-only method.
• Without annotation, LWC cannot access the method at all.

• Special methods that run at different stages of a component's life.
• Help you run code when the component loads, renders, or unloads.
• Common hooks: constructor(), connectedCallback(), renderedCallback(), disconnectedCallback().

• Runs first, before anything else (even before the component appears).
• Used to initialize variables (but not access the DOM).
• Avoid calling Apex or this.template here.

• Runs when the component is inserted into the DOM.
• Best place to call Apex methods, wire logic, or event listeners.
• It runs once per component insert.

• Called after the template and DOM are rendered.
• Use it for DOM access or layout-related JS.
• It can run multiple times, not just once.

• Runs when the component is removed from the DOM.
• Used to clean up resources, timers, or event listeners.
• Helps prevent memory leaks.

• Runs after every re-render, not just the first time.
• Can run multiple times if reactive data changes.
• Add conditions to avoid unwanted repeat logic.

• Yes, this is a recommended place to call Apex imperatively.
• Good for initial data fetches when component loads.
• Avoid calling Apex in constructor() or renderedCallback().

• Avoid heavy or repeated logic — it runs many times.
• Don’t call Apex here (may cause infinite loop).
• Use it only for DOM-specific actions, not data fetching.

• Use a Boolean flag to check if logic has already run.
• Example: if (!this.hasRendered) { this.hasRendered = true; /* run code */ }
• Prevents duplicate calls or loops in renderedCallback().

• It allows programmatic navigation to pages (record, list, VF, etc.).
• Powered by NavigationMixin from lightning/navigation.
• Used to create a seamless in-app user experience.

• Use NavigationMixin.Navigate() method.
• Set type: 'standard__recordPage' and pass recordId.
• Example: Navigate to a Contact or Account record.

• A mixin (helper) provided by Salesforce to enable navigation.
• Import it and wrap your component class using NavigationMixin().
• Gives access to the this[NavigationMixin.Navigate]() method.

• Use type: 'standard__objectPage' with actionName: 'new'.
• Specify the object API name (e.g., Account).
• It opens the standard New Record modal/page.

• Use type: 'standard__component'.
• Provide the component's componentName (namespace + name).
• Only works in Lightning Experience and with Aura components, not LWC directly.

• Use type: 'standard__webPage'.
• Set the VF page URL (with base path if needed).
• Can also include parameters like ?id=001....

• standard__recordPage – to view record details.
• standard__objectPage – to open list view or new record.
• standard__webPage – to open external/VF URL.

•  Yes, using type: 'standard__webPage'.
• Can open internal or external URLs.
• Example: Link to a help article or website.

• Use standard__navItemPage to switch Lightning tabs.
• Use appTarget: 'standard__App' to go to another app (limited use).
• Navigation works inside the same Lightning Experience shell.

• Can't navigate to another LWC directly (no direct component-to-component).
• Some types (like standard__component) work only with Aura.
• Not supported in Communities/Sites without adjustments.

• Lightning App Builder (Record, App, Home pages).
• Experience Cloud (Communities), Utility Bar, Tabs.
• Inside Aura components or as standalone LWC components.

• Yes, by using <c:yourLWCComponent> in Aura markup.
• The LWC must be exported as @api (public).
• Useful for combining old Aura with new LWC.

• Set <isExposed>true</isExposed> in the .js-meta.xml file.
• Add appropriate <targets> like lightning__RecordPage.
• The component appears in App Builder for drag-and-drop.

• Yes, but you must enable lightningCommunity__Page target in .js-meta.xml.
• Add the component to a Community/Experience Builder page.
• Some standard components may be limited in Guest access.

• Push the LWC component using sfdx force:source:push.
• Add the component to a page using App Builder.
• Or test in a custom tab, record page, or Aura wrapper.

• Add lightning__UtilityBar target in the .js-meta.xml file.
• Go to App Manager → Edit app → Add Utility Item.
• Select your LWC from the list and configure settings.

• Use a deployment tool (like VS Code, ANT, or Change Sets).
• Include all LWC files: .js, .html, .js-meta.xml.
• Deploy as part of a source folder under lwc/.

•  Not directly — LWC cannot be embedded inside Visualforce.
• Workaround: use Lightning Out with an Aura wrapper component.
• Then include that Aura component in the VF page.

• Test thoroughly in a sandbox or scratch org first.
• Use source control (Git) and sfdx project structure.
• Keep components modular and use naming conventions.

• Cannot deploy LWC components alone via Change Set — needs metadata enabled.
• Not supported in Classic or Visualforce directly.
• Guest user access needs special setup in Communities.