Event Handling

[Gozala]

As of this writing events handling is done via decoder.flow library. Meaning you can register a listener on the element as follows:

DOMinion.createElement(
  "button",
  [
    DOMinion.on(
      "click",
      Decoder.record({ type: Decoder.String, button: Decoder.Integer })
    )
  ],
  []
)

Then DOMinion library will take care of including AddEventListiner op into generated changelist that can be transferred over to the main thread.

Problems

• In current implementation RemoveEventListener also serializes event decoder and includes that in a changelist. That seems wasteful. It would make more a lot more sense to not include decoder in a RemoveEventListener op, which can be done either by simply allowing single listener per event type or by registering listeners by id and removing by that id.
• Same decoders are likely to be used across different elements, but library does no attempt to allow reuse instead same decoders will be serialized and transferred each time. It seem like registering listeners by id and then adding / removing them might be a better way to go. It also would make it easier to remove / add them on the main thread side as there there will be a need to identify which decoder is being added / removed. On the flip side global registry has it's own issue, namely diff(a, b) needs some way to assess if certain event listener existed in tree a and there for can be referred by id or if it needs to be registered first. It also becomes unclear where do we store all event listeners on to make diffing them efficient.

[aronallen]

I did something very similar using the Cycle JS architecture. Event binding uses a different channel. Workers allow you to create several MessageChannels. The Cycle architecture encourages you to declare listeners and vdom separately. I didn’t have this fancy transferable binary format. But I did end up with an API where you explicitly declare which event properties to transfer.