Event Handling
- Dominant language
- JavaScript
- Stars
- 19
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
As of this writing events handling is done via [decoder.flow](http://github.com/gozala/decoder.flow) library. Meaning you can register a listener on the element as follows:
```js
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.
Contributor guide
No contributing guide indexed for this repository
Research direction
The issue names DOMinion.createElement, DOMinion.on, generated changelists, AddEventListiner, RemoveEventListener, and diff(a, b), but no files or tests. Start by tracing those entry points and compare how add and remove operations carry event decoders. Done means an agreed listener identity and storage design that avoids unnecessary decoder serialization and supports diffing across trees.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100