Event messaging

Event management in web applications involves coordinating interactions and communication between different components. Two common approaches are event aggregation and directed messaging.

Event aggregation uses an open eventing model with event subscribers and dispatchers. Components can subscribe to events of interest and handle them when dispatched. This allows loose coupling between event producers and consumers.

Directed messaging involves sending a message directly to target elements, specified using CSS selectors. This is a more targeted approach compared to publication. The messaging can be implemented imperatively in JavaScript code or declaratively using messaging intents defined in markup.

Both event aggregation and directed messaging have their place depending on the application architecture and communication needs between components. Event aggregation promotes decoupling while directed messaging enables targeted messaging. The choice depends on the specific application requirements and constraints.

Event aggregation

Event aggregation utilizes a publish-subscribe pattern for event notifications. Components can subscribe to events they are interested in. When an event is published or raised, all subscribed components are notified and can handle the event as needed.

This decouples the publishers of events from the subscribers. The publishers don’t need to know specifically which components will receive the events. Similarly, subscribers don’t need to know exactly which components are publishing events. This loose coupling enables more modular and flexible event handling in the application.

The key steps are:

  • Components subscribe to events, specifying callback functions to handle each event.
  • Other components in the application publish or raise events when something notable occurs.
  • The event aggregation system notifies all subscribed callbacks when a given event is published.
  • Subscribers handle the event in their callback functions.

This aggregator-based publish-subscribe model provides a flexible way to disseminate events across an application. Components can communicate effectively without tight coupling.

// subscribing to a event
crs.binding.events.emitter.on('my-event', callback);

// publish an event
crs.binding.events.emitter.emit('my-event', args);

It’s critical to remove the event listener when an element is being disposed of or when the event is no longer needed. Failure to properly clean up can lead to null reference exceptions, as the event emitter may attempt to execute a function that is no longer accessible.

// unsubscribe from event
crs.binding.events.emitter.remove('my-event', callback);

We can define markup that emits events.
There are simple examples where you just define the event key but you can also define properties to be used in the args.

// simple example
<button click.emit="my-event">Click Me</button>

You can also define a more complex version, take special note of the markup.

<button 
  click.emit="my_event(title='hello world', $event, contacts=${contacts})" />

The args argument on the call back will have three properties

1. title – ‘hello world’
2. event – PointerEvent
3. contacts – property (“contacts”) on the binding context

Directed messaging

You can send a message to a component or components using the postMessage method on the crs.binding.events.emitter object.

  1. query – css selector that defines what elements to send the message too
  2. args – dictionary that will be sent as argument to the element.
  3. scope – optional, the element used for the querySelectorAll, defaults to document.
crs.binding.events.emitter.postMessage('#myElement', objToSend);

The receiving components must implement a public “onMessage” method.
This method has a single “args” parameter that contains all the information about the message.

onMessage(args) {
    console.log(args);
}

You can also post messages by defining it in the markup.
The markup we include a message key so that we can define intent in the onMessage method.

<button click.post="got-contacts['message-target'](title='hello world')" />

Some notes about the above example.

1. got-contacts is the event key. In the args parameter you will find this value in the “key” property.

2. [css selectors] – this is a comma separated list of strings starting and ending in a single quotation mark that defines what the elements are that you want to send the message too.

For example [‘#single’, ‘.plural’]

3. The arguments that make up the args object is defined between the open and close round brackets. this is a comma separated list that uses an assignment expression for each property defined.

property=’value’ or
property=value or
property=${context_path}

$event is a exception to the rule as it will automatically be assigned to a “event” property.