User Interface practice questions

Standard component events via aura:registerEvent

Why it fails: Component events only bubble up parent-child hierarchies in Aura.

Standard window.postMessage API

Why it fails: window.postMessage is not recommended or standard for LWC intra-page communication.

Imperative Apex method calls

Why it fails: Apex methods are for server communication, not local component messaging.

method

Why it fails: Using the `method` attribute on an `aura:handler` tag fails because `method` defines an action that a parent component can invoke directly on a child component via component-level action binding, rather than listening for an asynchronously fired component event. It is tempting because developers frequently confuse top-down imperative calls with bottom-up event handling when managing component communication. The `method` attribute *would* be the correct choice if the requirement specified that the parent needed to trigger logic directly inside the child component, instead of handling an event dispatched upward by the child.

controller

Why it fails: The `controller` attribute defines the client-side JavaScript file associated with a component rather than specifying the event to be intercepted. While developers frequently link components to their controllers to manage logic, this attribute does not facilitate event registration or listener binding within the `aura:handler` tag. Instead, the `event` attribute is mandatory to identify the specific event type being handled, whereas the `action` attribute designates the callback function executed when that event is fired.

Call the wire adapter imperatively inside a JavaScript function.

Why it fails: Calling a wire adapter imperatively is technically impossible because wire adapters are exclusively designed for the reactive `@wire` service to stream data automatically, not for manual invocation. Developers are often tempted by this approach because imperative calls are correctly used when data fetching must be triggered by a specific user action, such as clicking a button, rather than reacting reactively to property changes.

Use standard hidden HTML inputs to store state.

Why it fails: Storing state in standard hidden HTML inputs fails because Salesforce wire adapters rely on reactive JavaScript properties to automatically re-provision data when parameters change, whereas hidden DOM elements do not trigger the necessary component re-rendering lifecycle or reactive tracking mechanisms. Developers migrating from traditional server-rendered architectures might be tempted to use hidden inputs because they are useful for persisting form state across postbacks in classic HTML form submissions or legacy Visualforce pages where DOM manipulation is the standard method for retaining user input values.

Reload the entire browser page using window.location.reload().

Why it fails: Reloading the browser destroys the entire component state and aborts asynchronous transactions rather than triggering a targeted reactivity cycle in the Lightning Data Service wire adapter. Developers transitioning from traditional server-rendered architectures might initially consider a full-page refresh because they are accustomed to rebuilding page state from scratch following URL or parameter changes. In legacy web applications, this approach resets the execution context, whereas modern reactive frameworks require reactive property bindings to provision new parameters to `@wire` without losing component state.

<apex:repeat>

Why it fails: Iterating over a collection is indeed its primary function, making it tempting when developers need to output multiple records. However, this component merely evaluates its body for each item in the collection without generating native tabular structure, meaning HTML table tags like `<table>`, `<tr>`, and `<td>` must be manually written alongside it. The question specifically requires displaying records in a table, a layout natively handled by another component that automatically renders semantic HTML grid structures.

apex:iterator

Why it fails: Iterating over a collection via `<apex:iterator>` processes generic items without automatically generating tabular HTML structures like table rows and columns, failing the prompt's requirement to display records explicitly in a table. It is tempting because developers frequently use it to loop through lists and output custom markup block by block. It would be the correct choice when rendering non-tabular layouts such as custom lists, card grids, or unordered lists where standard table semantics are unnecessary.

apex:outputPanel

Why it fails: `apex:outputPanel` is designed to group elements together for AJAX partial page refreshes or conditional rendering, rather than processing lists of data into a tabular structure. Developers often find this tag tempting when wrapping dynamic content areas that need to be rerendered via controller actions. However, because it lacks row-iteration capabilities and semantic table generation, it fails to display collections in a structured grid format, making a dedicated iterator or table component necessary for handling lists of records.

init event

Why it fails: Fires before rendering occurs.

afterDOMInsert

Why it fails: Not a valid Aura event.

render event

Why it fails: Fires during the render phase, not necessarily after DOM insertion.

Setting style attributes directly via JavaScript on child elements.

Why it fails: Manipulating the DOM imperatively via JavaScript violates shadow DOM encapsulation boundaries and bypasses the declarative CSS styling hook mechanism requested in the scenario. This approach appears attractive because it provides direct, dynamic control over element properties using standard browser APIs, making it the correct choice when you need to calculate runtime dimensions, apply transient animation states, or programmatically update inline styles based on complex user interactions that cannot be predicted at compile time.

Using global CSS stylesheets

Why it fails: Global CSS stylesheets fail in this scenario because the shadow DOM encapsulates component styles, preventing external global rules from crossing the boundary to target internal elements of a child component. This approach is tempting because developers routinely use global stylesheets in traditional web development to apply site-wide design systems or consistent branding. Such stylesheets would be the correct choice when styling light DOM elements or legacy web pages where encapsulation barriers do not restrict CSS cascade rules.

Using the >>> combinator selector

Why it fails: While this deep combinator appears tempting because it traditionally allowed CSS selectors to pierce shadow boundaries and style inner elements directly, it fails here because Salesforce deprecated and removed support for shadow-piercing combinators in Lightning Web Components to enforce strict encapsulation. It would only be relevant in older web standard frameworks or legacy shadow DOM implementations that still permit unrestricted cross-boundary style bleeding, whereas modern Lightning Web Components strictly mandate custom CSS properties, known as styling hooks, for parent-to-child styling.

@RemoteAction

Why it fails: `@RemoteAction` is tempting because it exposes Apex methods to JavaScript, making it a familiar choice for developers migrating legacy Visualforce pages that rely on JavaScript remoting. However, it fails in this scenario because it is specifically designed for Visualforce controllers rather than the Lightning Data Service wire protocol required by Lightning Web Components. To successfully provision data to the `@wire` service, the Apex method must instead be annotated with `@AuraEnabled(cacheable=true)`.

@InvocableMethod

Why it fails: Targeting invocable methods makes this option tempting because it exposes Apex logic to Salesforce platform features, making it the correct choice when invoking Apex actions declaratively from Flow or Process Builder. However, it fails in this scenario because it is designed for action execution rather than reactive data provisioning, whereas the `@wire` service specifically requires a method annotated with `@AuraEnabled(cacheable=true)` to stream reactive data properties into Lightning Web Components.

@AuraEnabled

Why it fails: Although `@AuraEnabled` is essential for exposing Apex methods to Lightning Web Components, adding it alone is insufficient for `@wire` integration because the method also requires the `cacheable=true` parameter. Developers frequently select this annotation because it successfully enables standard imperative Apex calls and property binding within components, making it tempting to assume it provides full compatibility with the reactive wire service without enabling caching.

apex:pageBlock

Why it fails: Rendering section-level styling containers and standard UI structure does not handle partial DOM re-rendering, meaning any associated action method execution still triggers a traditional full page submit and reload cycle. It is tempting because it frequently appears alongside command components inside standard Salesforce layout designs to group fields and buttons visually. It represents the correct choice when developers need to structure form layouts into distinct visual sections with built-in styling, collapsible headers, and tabbed interfaces on a standard Visualforce page.

apex:form

Why it fails: Using `<apex:form>` fails to satisfy this scenario because it submits the entire form via a standard full page postback rather than performing a partial page update via AJAX. Developers often gravitate towards `<apex:form>` because it is strictly required to enclose any input fields, buttons, or commands that submit user input to the controller. It represents the correct choice whenever a developer needs to capture user input and execute a standard server-side submission that refreshes the entire view.

apex:actionFunction

Why it fails: While `<apex:actionFunction>` can trigger controller actions asynchronously via AJAX without a full page reload, it fails this specific scenario because it is designed to bind JavaScript functions to controller methods rather than directly wrapping a user-interface button component. Developers typically select this component when they need to invoke Apex logic directly from custom client-side JavaScript scripts or event handlers, rather than declaratively enclosing a markup region for targeted partial page rendering.

lightning:button

Why it fails: `lightning:button` is an Aura component rather than a Lightning Web Component, meaning it cannot be used directly inside an LWC HTML template. Developers migrating older Aura codebases or confusing the namespace prefixes often reach for this tag, as it is the standard button primitive within the Aura framework. It would be the correct choice if you were building an Aura component and needed to render a clickable standard button adhering to the Salesforce Lightning Design System.

apex:commandButton

Why it fails: Visualforce leverages `apex:commandButton` to submit form data and invoke server-side controller actions within a traditional page-centric architecture. Developers transitioning to Lightning Web Components often reach for this familiar tag out of habit when seeking standard button functionality. However, this component belongs exclusively to the Visualforce framework and cannot be interpreted or rendered within modern web component boundaries. Building an LWC requires utilising the native `lightning-button` base component to ensure proper integration with the Lightning design system and component lifecycle.

ui:button

Why it fails: `ui:button` belongs to the obsolete Aura component framework rather than modern Lightning Web Components, meaning it cannot be used within an LWC template. It is tempting because developers migrating older Aura codebases frequently encounter `ui:button` when searching for standard UI controls. It would be the correct choice if you were building an Aura component and needed to leverage Aura-specific interface bindings and event models, but it has no place in a contemporary LWC architecture where `lightning:button` must be utilised instead.

slds-col

Why it fails: Applying `slds-col` sets an individual item's sizing within a Salesforce Lightning Design System grid, but it cannot manage layout wrapping for a container. Developers often reach for it when defining column widths for individual children inside a grid. It would be the correct choice when assigning specific proportions—such as `slds-size_1-of-2`—to a child element once the parent container has already been designated to wrap its contents using a layout modifier.

slds-nowrap

Why it fails: `slds-nowrap` fails this scenario because it explicitly forces flex items to stay on a single line, preventing any automatic wrapping onto multiple rows as required by the prompt. This class is tempting because developers often need to control flex wrapping, and `slds-nowrap` would be the correct choice when designing horizontal navigation bars, button toolbars, or tab strips where content must clip or overflow horizontally rather than breaking onto subsequent lines.

slds-grid

Why it fails: Applies a standard flexbox layout along a single line, causing child elements to shrink and fit within one row rather than wrapping automatically. It is tempting because it establishes the foundational horizontal layout context required for flexible containers. This class provides the base flex container framework and would be the correct choice when designing a single-row navigation bar or button toolbar where content must remain strictly on one line without multi-row wrapping.

1 MB

Why it fails: Allocating 1 MB is incorrect because it vastly overestimates the strict heap limit enforced on Visualforce controller states. This figure represents the maximum allowable file size for a single attachment or document uploaded to Salesforce, or the individual heap limit for certain asynchronous Apex executions. Developers often confuse governor limits across different execution contexts, making this larger memory threshold seem plausible when attempting to cache extensive collections of records within page state variables, whereas the actual limit for a Visualforce view state is capped at a much smaller 135 KB.

64 KB

Why it fails: The maximum allowable view state limit for a Visualforce page is strictly restricted to 170 KB rather than 64 KB, meaning this lower threshold would immediately trigger a limit exception during complex page operations. Developers might naturally confuse this value with the 64 KB heap size allocation assigned to synchronous Apex trigger context limits or email service attachments, where 64 KB represents a standard boundary for server-side processing payloads rather than client-facing state maintenance.

512 KB

Why it fails: The maximum allowable view state limit for a Visualforce page is strictly capped at 170 KB, making this 512 KB threshold excessive and incorrect. Developers often fall into the trap of confusing this limit with the maximum heap size allocated for asynchronous Apex transactions or the general file attachment limits, where 512 KB represents a common sizing benchmark. In valid Salesforce contexts, 512 KB aligns with specific governor limits such as the maximum email message size or certain static resource storage capacities, but it has no relevance to the strict byte constraints enforced on Visualforce view states.

private

Why it fails: Declaring a field as `private` restricts its visibility to the current Apex class, which is tempting because developers naturally associate access modifiers with data security and hiding information from external layers. However, this modifier only enforces encapsulation rules at the code level and has no effect on the Visualforce view state mechanism. Even private variables are automatically serialised and included in the encrypted view state payload sent to the client. To explicitly exclude a variable from the view state to reduce payload size, the `transient` keyword must be used instead.

static

Why it fails: Marking a field as `static` binds its value to the class itself rather than a specific instance, meaning it retains state across multiple requests and bypasses normal view state serialization entirely, which sounds like an easy way to shrink the payload. However, this is tempting because developers often misuse it for memory management, yet it causes data leakage by sharing the exact same field value across every concurrent user session interacting with the controller, completely failing the requirement to securely isolate sensitive per-user data.

final

Why it fails: Declaring a variable as final establishes a constant whose value cannot be reassigned after initialization, which is useful for defining immutability or preventing accidental modification of configuration values within business logic. However, this modifier does not interact with the Visualforce serialization process, meaning the platform still includes the annotated variable in the view state regardless of its immutability. To exclude sensitive data from the view state and optimise page performance, developers must use the transient keyword instead.

ui:spinner

Why it fails: `ui:spinner` belongs to the legacy Aura framework rather than the Lightning Web Components (LWC) programming model. Developers familiar with Aura often mistake it for a native LWC component because of its naming convention. However, LWC requires the `lightning-spinner` component to render progress indicators. While `ui:spinner` functions within Aura applications to provide visual feedback during asynchronous processes, it lacks the necessary integration with the LWC shadow DOM and custom element standards required for modern Salesforce development.

apex:spinner

Why it fails: `apex:spinner` belongs to the legacy Visualforce framework rather than the Lightning Web Components (LWC) programming model. It functions by rendering server-side components within a page-centric architecture, whereas LWC requires client-side base components like `lightning-spinner`. Developers familiar with migrating legacy Visualforce pages to modern Lightning interfaces often mistake this tag for a native LWC element. It remains valid exclusively when building traditional Visualforce pages that require an asynchronous loading indicator during controller execution.

lightning-progress

Why it fails: `lightning-progress` renders a progress bar or step-based pathway to track completion through a sequence of stages, which makes it tempting when developers search for a visual indicator of ongoing activity. However, it fails this scenario because it requires a predefined path or numeric percentage rather than providing an indeterminate loading animation. This component is the correct choice when you need to guide users through a multi-step wizard or display the exact completion status of a linear business process.

Database.QueryLocator

Why it fails: Used in batch apex, not directly as a Visualforce pagination property.

ApexPages.Paginator

Why it fails: Not a valid class.

lightning__AppPage

Why it fails: `lightning__AppPage` fails this scenario because it exposes components specifically for standard or custom Lightning application pages rather than enabling them to launch as modal or panel overlays triggered from a record page's action menu. Developers often select this target mistakenly when building custom utility bar items or dashboard-like components that reside directly within the flexible layout of an app home page. It would be the correct choice if the component needed to be added directly to the canvas of a Lightning Application using the Lightning App Builder, rather than functioning as an interactive record-level action.

lightning__RecordPage

Why it fails: Enables the component as a standard tab/region on a record page.

lightning__Tab

Why it fails: Configuring a Lightning Web Component as a record page Quick Action requires the `lightning__RecordAction` target configuration rather than `lightning__Tab`. While `lightning__Tab` is tempting because it enables components to render as standalone pages within the Salesforce navigation bar or custom utility items, it fails this scenario because it does not expose the component to the contextual overlay framework required for record-level modal actions.

<apex:script>

Why it fails: Visualforce provides the `<apex:script>` component specifically to embed JavaScript code directly within a page. This tag satisfies the stem requirement by functioning as a wrapper that automatically manages standard HTML script rendering, allowing developers to include custom client-side logic safely. Unlike standard HTML `<script>` tags, using the Salesforce-specific component ensures proper integration with the Visualforce component tree and facilitates the secure referencing of controller variables through expressions where necessary.

<apex:code>

Why it fails: `<apex:code>` is designed to render syntax-highlighted code snippets within a page rather than executing client-side scripts. It is tempting because developers often look for tags containing the word "code" when attempting to embed logic. This tag would be the correct choice if the requirement was merely to display a readable, formatted block of source code for users to view, but it fails here because it lacks any capability to run JavaScript functionality.

<apex:javascript>

Why it fails: Not a valid tag.

Global un-scoped CSS stylesheets loaded in every page

Why it fails: Global un-scoped CSS stylesheets loaded in every page disrupt the Shadow DOM encapsulation model inherent to Lightning Web Components, causing unintended style leaks across components. Developers often reach for global stylesheets because they are familiar from traditional web development for applying uniform brand themes or typography across an entire application. In standard web development outside Salesforce, relying on a shared global stylesheet provides a centralised mechanism for site-wide design tokens, whereas modern web components require isolated styling to maintain modularity and prevent cascading side effects.

Inline style tags in HTML templates

Why it fails: Hardcoding inline style tags inside HTML templates violates Lightning Web Component encapsulation rules and prevents the platform from applying scoped styling mechanisms securely. Developers are often tempted to use inline styles for rapid prototyping or when needing to dynamically inject calculated pixel values for specific HTML elements at runtime. While native web development permits inline styles for quick overrides, Salesforce architecture requires standard stylesheet files bundled within the component directory to maintain strict Content Security Policy enforcement and maintainable design systems.

Bootstrap CSS framework via static resource

Why it fails: Using the Bootstrap CSS framework via a static resource violates Salesforce styling encapsulation boundaries by applying global DOM styles that conflict with the Shadow DOM architecture of Lightning Web Components. Developers are often tempted to use Bootstrap because it provides a robust, pre-built library of responsive UI components and rapid layout grids for standard web development. This approach would be the correct choice when building traditional server-rendered web pages or standalone applications that rely on global stylesheets rather than encapsulated component frameworks.

A CSS stylesheet (.css)

Why it fails: A CSS stylesheet is tempting because developers routinely write custom styles to alter component appearance, making it a natural inclusion when structuring a bundle. However, it fails this scenario because component styling is entirely optional in the Salesforce build process; a functional Lightning Web Component requires only an HTML template and a configuration XML file to define its UI and metadata. A stylesheet is only needed when specific design overrides or layout rules must be applied beyond the standard Lightning Design System defaults.

An Apex controller class

Why it fails: An Apex controller class is unnecessary because a Lightning Web Component functions entirely client-side using native JavaScript and HTML files, meaning server-side data access is optional rather than a mandatory configuration file or metadata element for component creation. Developers are often tempted to include an Apex controller because it is the standard mechanism for querying and manipulating Salesforce data when building robust components. It becomes the correct choice only when the component specifically requires server-side business logic, database transactions, or access to data unavailable via UI API endpoints.

An Aura dependency bundle (.auradoc)

Why it fails: An `.auradoc` file is used solely for documenting Aura components in the legacy Aura framework, meaning it has no functional role in defining or configuring modern Lightning Web Components. Developers familiar with the older Aura architecture might erroneously look to `.auradoc` bundles because documentation and metadata files are standard requirements for component creation in that programming model, whereas Lightning Web Components strictly require an HTML template, JavaScript controller, and an `.js-meta.xml` configuration file instead.

Communication across components in different browser tabs.

Why it fails: Lightning Message Service is explicitly restricted to communicating within a single browser window or tab, preventing it from broadcasting messages across separate browser tabs or windows. However, this option seems plausible because developers frequently need to synchronise state and UI events between multiple concurrent browser sessions for the same user. In a scenario requiring cross-tab communication—such as updating a shopping cart or dashboard across different tabs—HTML5 Web Storage events or the Broadcast Channel API must be utilised instead.

Executing asynchronous server-side database updates automatically.

Why it fails: Lightning Message Service is strictly designed for front-end publish-subscribe communication across the DOM, operating purely within the client context between Visualforce pages, Aura components, and Lightning Web Components. It lacks any capability to execute server-side database transactions or run asynchronous Apex logic. This choice is tempting because developers frequently need to coordinate UI state changes following database operations, which would typically be handled by pairing Aura/LWC controller methods with Queueable Apex or `@future` methods for background server-side processing.

Store sObjects in public static variables.

Why it fails: Storing sObjects in public static variables fails to optimise view state because static variables persist across the request lifecycle but are intentionally excluded from the standard view state serialization mechanism, meaning they do not reduce the payload sent to the client and often cause data synchronisation issues during multi-step controller actions. Developers are frequently tempted to use this approach because static variables provide a convenient way to share data across controller extensions or apex methods without re-querying the database, which is the correct pattern for caching transient utility data or sharing configuration constants that do not require state preservation across postbacks.

Store large lists of static data in controller member variables.

Why it fails: Storing large static datasets in controller member variables serialises and transmits that entire collection within the encrypted view state string on every postback, directly inflating the page payload and degrading performance. Developers often consider member variables because they provide a straightforward way to retain state across server requests for dynamic user inputs. This approach works effectively for small, frequently modified collections bound directly to interactive form components, but fails when applied to large, unchanging datasets that should instead be queried on demand or cached using transient properties.