Props, Events, LMS, or State Manager?

LWC has several ways to move information between components. That does not make them interchangeable.

Using Lightning Message Service to notify a direct child hides a relationship the template already knows. Passing data through eight components that never use it asks properties to do too much.

The communication mechanism should describe the relationship.

Start with ownership

My default remains: properties down, events up.

A parent owns data and passes the required part to a child:

<c-order-summary
  order={order}
  currency-code={currencyCode}>
</c-order-summary>

Treat received objects as read-only. Prefer narrow properties over one enormous config bag.

A public method is different. It is a command to a specific child: focus an input, reset a form, open a panel, or run validation.

@api
focusSearch() {
  this.template.querySelector('lightning-input')?.focus();
}

A method says “do this now”. A property says “this is the current input”.

Events carry occurrences back up:

this.dispatchEvent(
  new CustomEvent('quantitychange', {
    detail: { lineId: this.lineId, quantity: this.quantity }
  })
);

Name the occurrence, not the parent's reaction. quantitychange is better than updateordertotal.

Salesforce's event guidance follows the same direction: public APIs down the containment hierarchy, events up, and LMS when components are not directly related.

Use LMS for real distance

Lightning Message Service fits independently composed page regions, utility items, Aura, Visualforce, and workspace surfaces that share context without DOM ownership.

publish(this.messageContext, RECORD_SELECTED, {
  recordId: this.recordId,
  source: 'alarm-list'
});

Keep message payloads small and stable. Use application scope only when the message genuinely must cross the whole app; subscription scope changes who can react.

LMS is not a universal event bus for every click.

Use state when several components own one experience

A state manager earns its place when a related subtree needs shared reactive state, derived values, and coordinated actions: a cart, multi-panel editor, or workspace with filters, selection, and results.

Properties and events can model that, but deep prop drilling and event relaying can obscure the actual application.

Salesforce's state-management comparison keeps properties and events as the simple default and positions state managers for larger component groups.

Keep the state layer about state: mutable values, computed values, and actions. Components should still own DOM interaction.

The distinction from LMS is simple. A message says something happened across a composition boundary. A state manager says this is the current coherent state of one application.

Do not use either merely because several components read the same record. LDS already provides caching and update notifications. Add shared state when the application needs coordination beyond reading server data.

Let the relationship choose

Ask whether the components have a direct owner-child relationship, whether the value is an input, occurrence, command, or persistent state, and whether it must cross a page boundary.

The answers usually point to one mechanism.

If they point to all of them, revisit the component boundaries.

Communication code should make the architecture easier to see, not hide it.