Pub/Sub Client-side
Pub/Sub patterns on the client-side
We can also implement a pub/sub mechanism in the client-side and in the backend, as well, to keep our state manegement and components context awareness consistent, leveraging a web platform native API: window.postMessage().
I have dedicated an entire section to describe native APIs, and how to make the best out of them to simplify development and maintenance efforts and reduce 3rd party dependencies, and make sure a frontend implementation is cross-browser and platform compatible. But I feel the postMessage API deserves a mention together with event-driven design.
Communicating state changes via events: State management
State management is complex to implement even for one application built with a single technology, and it’s exponentially more complex when an app is composed of independent micro parts.
Over the years, maintainers and communities have come up with custom state management solutions, that aligned with the development patterns they were promoting. It is my humble opinion that most of them have been somewhat overengineered and difficult to implement and maintain, resulting in extreme misuse and overuse.
Some modern state management libraries, like Pinia for Vue are doing a great job in simplifying and streamlining state management, and have become more intuitive and maintainable, but they tend to be bound to a specific framework, and not be useful for horizontal frontend composition with multiple technologies -or a technology different than the one they were built for.
The most effective way to manage state in a horizontal frontend composition scenario, is to leverage web platform native APIs. When composing horizontally with technologies that require a shell, it is also advised to have a specific team in charge of that orchestration shell, and state management design and execution, including the documentation and maintenance of an API and a global layer to communicate and persist state changes.