W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Custom element design with ES6 classes and Element constructors

From: Yehuda Katz <wycats@gmail.com>
Date: Thu, 15 Jan 2015 17:48:36 +0000
Message-ID: <CAMFeDTVz-N9vELZK_OXDFwbP_D9CwgPS9QFSCgU_CTqifjiLxg@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>, Erik Arvidsson <arv@google.com>
Cc: Dmitry Lomov <dslomov@chromium.org>, Domenic Denicola <d@domenic.me>, WebApps WG <public-webapps@w3.org>
It's not clear to me that:

import HTMLElement from "web/element";

class MyButton extends HTMLElement {
  readyCallback() {}
}

is that much more usable than

import HTMLElement, { ready } from "web/element";

class MyButton extends HTMLElement {
  [ready]() {}
}

In other words, in a modules world, you're already importing the class, and
adding on a symbol isn't too bad.

We're already doing some crude namespacing with *Callback. I'd expect that
as soon as the first iteration of Custom Elements is out, people will copy
the *Callback style in user code.

We can always work around it with more obscure and more verbose names
(since libraries will slurp up the good names) but that damages the
ergonomic argument.

On Thu, Jan 15, 2015, 9:32 AM Dimitri Glazkov <dglazkov@google.com> wrote:

>
>> I'm sympathetic to this but I think it is fine that DOM continues to
>> define new string based property names. Anytime we add a new property
>> to an existing class we run into this issue and I don't think we want
>> to give up on the superior usability of string based property names.
>>
>
> I agree, FWIW.
>
> :DG<
>
>
Received on Thursday, 15 January 2015 17:49:06 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC