Re: [DOMCore] Making event initializing easier

On Wed, Mar 9, 2011 at 06:58, Alex Russell <slightlyoff@google.com> wrote:
> On Fri, Mar 4, 2011 at 2:25 AM, Anne van Kesteren <annevk@opera.com> wrote:
>> If we indeed introduce objects into our APIs and I start to think that would
>> make sense I think the simplest approach that could possibly work here is to
>> overload initEvent(). In addition to its three argument version it would get
>> a version that accepts just one argument, an object. From this object
>> property values are queried to set values on the event. E.g.
>>
>>  var e = document.createEvent("CustomEvent")
>>  e.initEvent({"type":"custom", "details":{"hello":"world"}})
>>  document.dispatchEvent(e)
>
> I'd prefer something even more direct, moving away from "create*"
> methods entirely and using "new" instead. E.g.:
>
> var e = new CustomEvent({ type: "custom", details: { hello: "world" }});
> someNode.dispatch(e);

Yeah, making DOM interfaces constructable is something that is a clear
win from JS.

With ES.next having support for destructuring assignment I believe we
will see more objects-as-named-parameter patterns in library code so
making the DOM follow suite is a win.

I would actually take this one (or two) steps further. The CustomEvent
interface is pretty useless in JS. Event objects are not sealed in JS
so adding custom meta data is trivial.

var event = new Event("type");
event.myDetails = {now: new Date};
eventTarget.dispatchEvent(event);

we could even make new Event add all properties from the property bag.

var event = new Event("type", {myDetails: {now: new Date}});
eventTarget.dispatchEvent(event);

This brings me to my second step. The above looks pretty much like an
ad-hoc "class". Why not go the distance and make this actually work.

function MyEvent(type) {
  Event.call(this, type);
}
MyEvent.prototype = {
  __proto__: Event.prototype,  // I'm too lazy to use Object.create
  get prop() { ... },
  method: function() { ... }
});

eventTarget.dispatchEvent(new MyEvent('type'));

erik


> Regards
>
>> These are the reasons why I prefer this design over settable attributes or a
>> constructor-based approach:
>>
>>  * It is a very minimal change from the existing model. The existing model
>> is not great, but it is what we have and deviating away from it far for a
>> feature mostly used for debugging is not worth it. Even if not just used for
>> debugging the above is not much more complex than what libraries offer.
>>  * With settable attributes it becomes a little messier to also unset
>> several flags at the same time. You would always want to unset the "trusted
>> flag" for instance. (An alternative would be to not allow initializing
>> already dispatched events (possibly scoped to trusted events), but that is
>> not what implementations do.) Depending on the outcome of the other thread
>> we might also want to reset the "stop propagation flag", "stop immediate
>> propagation flag", and "canceled flag" here. Having these as side effect of
>> initEvent() makes sense. Having them as side effect of setting the offsetX
>> or type attribute makes a lot less sense.
>>  * In order for the constructor-based approach to work well you would want
>> this kind of object-approach as well. Otherwise you have the same issues
>> with having to remember all the arguments and making extensibility
>> difficult. It seems therefore better to first experiment on a somewhat
>> smaller scale (just initEvent(object)) than introducing constructors all
>> over.
>>
>> Interested to hear what you all think!
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>>
>>
>
>

Received on Wednesday, 9 March 2011 18:30:25 UTC