can we remove the awkward id argument?

[neonstalwart]

can we remove the awkward id argument?

[Raynos]

@neonstalwart the motivation for the id is namespacing.

It allows the application to have multiple delegator instances which means you can nest applications in applications. The reason the id is needed is because dom-delegator has a global event listener on document.body so it cant handle all events, it must only handle events with its own id.

Removing the id breaks recursive modularity.

That said a PR on event-sinks to make the id optional is fine.

Having the notion that a Sink has an id is also useful. It means you can serialize a sink to id:key and know it came from EventSinks(id, [key]).sinks[key]

[neonstalwart]

what about using a weakmap to map the delegator instance to the events for this delegator on a node? addEvent(delegator, target, type, handler) i.e. use the target as a key to get a hash and then use the type as a key to get another weakmap which will let you use the delegator as a key to get the handler.

wouldn't that eliminate the need for the id to be passed around everywhere?

[Raynos]

@neonstalwart the problem with that interface is that you now have to pass an instanceof delegator into the render(state) function.

The reason that I had this id is so that you can call addEvent(myAppNamespace, ...) in render.js and call EventSink(myAppNamespace).on(eventName, ...) in input.js

This way the two files (rendering) and (handling user input) are completely seperate and do not have references to each other. Other then a shared id.

My implementation actually embeds the shared id on the sink so you never see the id in the rendering function. Although you still see the id in the input handling code.

[neonstalwart]

ok, i might still think on this for a while because even though i see the need for the id, it feels awkward to need to provide it when you use some of these APIs without dom-delegator but i'll close this for now.