The primary APIs/tools for Web UI message passing on the frontend are Event and postMessage(). Events have phases, security features and various useful traits, postMessage passes objects in memory around.
Events can bubble, can be encapsulated in shadow DOM, they can be dispatched on the global self for tight coupling, like for shared state across applications, they can be dispatched on specific elements and bubble up to any element along the way to consume and manipulate further as desired, separating concerns after the point of dispatching. This is how DOM elements work already. Whenever some user does something the various respective events notify of state changes, whatever they are, and the listeners can do their thing. Whether it’s global for storage events, ui-activity like scrolling, handled or unhandled promise rejections and on and on or for specific more specialized elements like forms, or custom elements extending the generic HTMLElement and using custom events mixed and matched in whatever way makes sense.
More related to this approach:
- Knowledge: Events: Open Web Components
- 14 Events and application data flow · Web Components in Action
- JavaScript.info ~ Shadow DOM and events
- A playlist where the first 2 videos touch on state management: https://www.youtube.com/playlist?list=PLNM_ABHoF7B0qDu0GI09eCXimoL2AyMMq
A modern library that facilitates with lightweight API extensions for web UI’s is LitElement and the included lit-html handles state changes to views—making views a function of the state by applying a functional pattern to incoming state objects to templated views. Events are the native state communication system.
Top comments (0)