SF-PD2 User Interface Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use Lightning Message Service to publish a message the parent subscribes to, since LMS is required for any parent-child communication.

  Why it's wrong here

  Lightning Message Service is designed for communication across unrelated components, different DOM trees, or between LWC and Aura or Visualforce, not for direct parent-child interaction. Using it for a parent and its own child adds needless indirection and overhead. Standard @api properties and CustomEvent dispatch already cover parent-child needs, so LMS is not required and is the wrong tool in this scenario.

• ✗

  Store shared state on a window-level global variable so both parent and child can read and write it directly.

  Why it's wrong here

  Polluting the global window object bypasses the component lifecycle, breaks reactivity, and is not supported by the LWC framework, which discourages global state. Changes to a global variable do not trigger re-rendering, and this pattern invites memory leaks and cross-component interference. Salesforce provides @api, CustomEvent, and LMS for these needs, so a window global is an anti-pattern and never the correct answer.

• ✓

  Annotate a property with @api so the parent can set it declaratively in markup or imperatively via the component instance.

  Why this is correct

  @api is the decorator that makes a property or method part of the component's public API. A parent can set an @api property either declaratively as an attribute in the template or imperatively on the element reference in JavaScript. This is the documented mechanism for exposing data and behavior from a child to its parent, so it directly satisfies the reusable-component requirement.

• ✗

  Call the parent's method directly by querying the parent component with this.template.querySelector on the root element.

  Why it's wrong here

  A child cannot traverse upward to its parent using querySelector; the template query only searches the child's own rendered DOM. There is no supported API for a child to reach into the parent's methods. Even if a reference existed, this would create tight coupling and break encapsulation. The correct direction is parent-to-child for method calls and child-to-parent for events, so this option is invalid.

• ✓

  Dispatch a CustomEvent from the child and let the parent attach a handler with the on<eventname> attribute in its template.

  Why this is correct

  Dispatching a CustomEvent with composed and bubbles set appropriately, then listening in the parent's template using the on<eventname> pattern, is the standard LWC parent-child event mechanism. The parent receives the event and can read event.detail. This gives the child a clean, decoupled way to notify its parent, matching the requirement to fire an event the parent can handle.