I've recreated this diagram inspired by Philippe Ozil's article about LWC Inter-Component Communication Patterns. 🙏
🔗 LINK: https://lnkd.in/g8VdKJ5H
Some thoughts, trying to go beyond what is in the article:
👉 passing objects via @api results in read-only proxies sent to children - this might affect data flows and debugging and we will have to copy/clone them before making changes.
👉 Lightning Message Service's default sends messages only within the active tab - for utility bar + primary tab we need scope APPLICATION_SCOPE in subscribe()
👉 LMS or Pub/Sub leaves the dependency between LWCs implicit, thus making harder to refactor or trace data flows and might increase complexity.
👉 Pub/Sub requires manual unregistration of listeners in disconnectedCallback() to avoid memory leaks - LMS will require unregistering only if using createMessageContext() or if references are kept.
👉 Public methods don't trigger auto-rerender - careful if calling a method before the child has rendered - you may have to check the sequence of connected and rendered callback events.
👉 Custom events might require deeper awareness of DOM event phases if needing interception/capture.
👉 LMS and Pub/Sub are fire-and-forget, no queueing or guaranteed delivery - subscriber might not be yet rendered or connected when the message is published - you might need ack messages or state checks.
Other pertinent links:
🔗 Step Up Your LWC Skills – Part 1
https://lnkd.in/gjw5KK9s
🔗 Define the Scope of the Message Service
https://lnkd.in/g6x_RMQx
🔗 Lightning Message Service Limitations
https://lnkd.in/g3gmcfPS
🔗 lightning/messageService https://lnkd.in/g8Vfg8rT
Thanks to Sarabjeet Pal who pointed out we now have State Managers as another communication alternative between parent and child LWCs! 🙏
🔗 https://lnkd.in/gEMwBvu3
