Sibling Communication with Lightning Message Service

@api and CustomEvent both rely on a direct parent/child relationship — a parent passing data down, or a child's event bubbling up to a listening ancestor. Two components that are not nested — for instance, two independent components both placed directly on the same Lightning Record Page — have no such relationship to lean on.

Lightning Message Service solves this with a publish/subscribe model, built around a Lightning Message Channel — a piece of metadata that defines a named "channel" any component can publish to or subscribe from, regardless of where it sits in the page.

// Publishing (in one component)
import { LightningElement, wire } from 'lwc';
import { publish, MessageContext } from 'lightning/messageService';
import RECORD_SELECTED_CHANNEL from '@salesforce/messageChannel/RecordSelected__c';

export default class FilterPanel extends LightningElement {
    @wire(MessageContext) messageContext;

    handleFilterClick(recordId) {
        publish(this.messageContext, RECORD_SELECTED_CHANNEL, { recordId });
    }
}

// Subscribing (in a completely unrelated component)
import { subscribe, MessageContext } from 'lightning/messageService';
import RECORD_SELECTED_CHANNEL from '@salesforce/messageChannel/RecordSelected__c';

connectedCallback() {
    subscribe(this.messageContext, RECORD_SELECTED_CHANNEL, (message) => {
        this.selectedRecordId = message.recordId;
    });
}

@wire(MessageContext) (a first glimpse of the wire service, fully covered in Module 6) gives access to the messaging infrastructure this all runs on top of.

Real Lightning pages commonly have several independent components — a filter panel, a results list, a detail panel — that all need to coordinate without being nested inside each other. LMS is the standard, supported way to make that happen.