Lightning Web Components Interview Questions- Part 5

36. What is the lightning/graphql module, and how is it different from the older lightning/uiGraphQLApi?

lightning/graphql is a newer LWC module for working with Salesforce’s GraphQL API, and it supersedes lightning/uiGraphQLApi. Its most notable addition is support for dynamic queries — instead of a fully static query string, you can build part of the query at runtime using JavaScript string interpolation (${variableName}) inside the gql tagged template literal, and the variable’s value is resolved and inserted into the query when it runs. This makes a single component’s query genuinely reusable across different objects or filter conditions, rather than needing a hardcoded query per use case.

import { gql } from 'lightning/graphql';

const query = gql`
  query getRecords {
    uiapi {
      query {
        ${this.objectName} {
          edges {
            node {
              Id
              Name { value }
            }
          }
        }
      }
    }
  }
`;

37. How do GraphQL mutations work in LWC as of Spring ’26?

Before Spring ’26, the GraphQL wire adapter in LWC was read-only — you could query data, but any create, update, or delete still had to go through Apex or lightning/uiRecordApi. Spring ’26 added an executeMutation function, imported from lightning/graphql, which lets you perform create/update/delete operations imperatively, directly from your JavaScript, using the same gql template literal syntax as queries.

import { executeMutation, gql } from 'lightning/graphql';

const UPDATE_ACCOUNT = gql`
  mutation UpdateAccount($input: AccountUpdateInput!) {
    uiapi {
      AccountUpdate(input: $input) {
        Record {
          Id
          Name { value }
        }
      }
    }
  }
`;

async function updateAccount(accountId, newName) {
    await executeMutation({
        query: UPDATE_ACCOUNT,
        variables: { input: { Id: accountId, Name: newName } }
    });
}

This matters practically because it cuts out an entire layer of Apex for straightforward CRUD operations — fewer controller classes, fewer test classes, and a component that can own its full data lifecycle (read and write) through one GraphQL surface instead of mixing GraphQL reads with Apex writes.

38. What is TypeScript support in LWC, and is it production-ready?

As of Spring ’26, TypeScript support for LWC is still in developer preview — not generally available. That’s an important nuance for an interview: candidates should know it exists, but also know not to overstate its maturity.

The most concrete addition is the @salesforce/lightning-types npm package, which provides official TypeScript type definitions for base components (like lightning-input or lightning-button). This replaces the custom type-definition files many teams previously wrote by hand. Salesforce DX’s MCP server also includes a tool that helps convert existing JavaScript-based LWC to TypeScript, which is meant to accelerate migration for larger codebases rather than requiring a full manual rewrite.

import type { LightningInput } from '@salesforce/lightning-types';

handleChange(event: CustomEvent) {
    const input = event.target as LightningInput;
    console.log(input.value, input.validity.valid);
}

39. What is Local Dev (Beta), and how does it change the LWC development workflow?

Local Dev is a local, single-component preview environment. As of Winter ’26, it supports access to platform modules directly during local preview — including Lightning Data Service wire adapters, @salesforce scoped modules, and Apex controllers. Previously, a lot of local component preview tooling couldn’t reach these platform-connected pieces, which meant developers had to deploy to a sandbox just to see how a component behaved against real data or Apex logic. Local Dev closes that gap, at least for single-component iteration.

40. What are complex template expressions in LWC, and what do they unlock?

Historically, LWC templates only allowed simple property references or getters — no inline logic beyond that. A beta feature expands what a template expression can contain, allowing more complex JavaScript expressions directly in the template rather than requiring every computed value to be pushed into a getter in the JavaScript class. This is a quality-of-life change more than an architectural one, but it reduces boilerplate for components with a lot of small derived display values.

41. Can Lightning Web Components be used as local actions in screen flows now?

Yes — as of Winter ’26, LWC can be used for local actions in screen flows. Local actions run entirely client-side (in the browser), which means they can access browser-native functionality using JavaScript without a server round-trip. Because a local action doesn’t need to render a visible UI element in the flow itself, components built for this purpose should use a blank HTML template — the component does its work invisibly as part of the flow’s execution.

42. What is SLDS 2.0, and does it break existing LWC styling?

SLDS 2.0 became generally available as of Winter ’26. It introduces updated component designs, styling hooks, and utilities, along with a beta dark mode option for custom themes (currently limited to the Starter edition). For LWC specifically, the practical concern is the design token variable syntax: the older --lwc- camelCase prefix syntax used in SLDS 1 doesn’t carry over the same way in SLDS 2, so components relying on that older syntax should migrate to the equivalent global styling hook rather than assuming it will keep working unchanged. Salesforce also improved the SLDS linter with additional validation rules and quick fixes specifically to help with this transition.

43. How does Lightning Out 2.0’s authentication model compare to the original Lightning Out (Beta)?

This is covered in depth in Part 3 of this series, but as a quick recap for anyone reading this part standalone: the original Lightning Out (Beta) used session-ID-based authentication passed to the external host page, which was fragile and offered weaker isolation. Lightning Out 2.0, generally available since Winter ’26, instead uses OAuth 2.0 combined with the UI Bridge API — the external app requests authorization, receives a token, and exchanges it for a short-lived, purpose-specific Frontdoor URL used to render the embedded component inside an isolated iframe with its own shadow DOM.

44. What is Lightning Web Security, and why does it matter for a 2026 interview specifically?

Also covered in depth in Part 2, but worth restating here because it’s one of the two most authentication/security-relevant topics on this list: Lightning Web Security (LWS) replaced Lightning Locker as Salesforce’s client-side security architecture, became the default for new orgs in Winter ’23, and reached full general availability for both LWC and Aura components in Summer ’23. It uses a JavaScript sandbox with runtime “distortions” instead of Locker’s secure wrapper objects, which allows custom elements and third-party web components that Locker used to block, while still preventing unsafe cross-namespace access.

45. If an interview focuses heavily on security and authentication, what should a candidate prioritize from this list?

Out of everything covered in this part, two topics carry the most weight for a security- or architecture-focused round: Lightning Web Security (client-side sandboxing and its replacement of Locker) and Lightning Out 2.0’s OAuth-based authentication model (replacing the old session-ID approach for embedding components externally). Being able to explain not just what changed, but why the new approach is more secure — shorter-lived, more narrowly scoped credentials, and stronger isolation boundaries — tends to distinguish a candidate who has actually kept up with the platform from one reciting older material.