Discussion: Properties vs. Attributes

[tbuschto]

Currently we have two interfaces that are somewhat similar:

Properties<Widget> is used by the widget constructor and the set method on widget and widgetCollection. It describes a plain object where the key-value pairs are property name and property value to be set on the widget: new MyWidget({foo: 'bar'}) or myWidget.set({foo: 'bar'}) is the same as myWidget.foo = 'bar'.

Attributes<Widget> is used by JSX elements, the new factory API, and - as for 3.7 - the apply method. It is a superset of Properties<Widget>, which in addition to properties also can include listeners to be registered for a event matching in name: <Widget onFoo={barListener}/> or Widget({onFoo: barListener}) is (almost) the same as widget.onFoo(barListener) or widget.onFoo.addListener(barListener).

Question:

Would it be a good idea to accept Attributes in places where Properties was used before? (Maybe even depreacate Properties.)

Pro

I have seen it several times that Properties and Attributes are confused with each other, e.g. on coding components such as:

class MyWidget extends Composite {
  constructor(attr: Attributes<MyWidget>) {
    super(attr);  // WRONG
  }
}

Making e.g. the constructor accept Attributes would eleminate this.

Con

Could cause even more confusion since, for example,

widget.set({onFoo: listener1}); 
widget.set({onFoo: listener2});

would in fact not register both listeners, but only listener2. That's how apply already works, and it's also in line with the really old HTML event attributes

Potential Compromise

Another option would be to only accept it via constructor, not set. That would make the asFactory method less necessary, as the the only difference would really be that new can be omitted.

[tbuschto]

It should also be noted that there are other miner differences between Properties and Attributes, and that in the future they may diverge even further when Attributes will for example accept observables.

[cpetrov]

I would be in favor of using Attributes everywhere to reduce confusion. IMO the behavior from the "Con" example is expected.

[mpost]

I think what ever compromise needs to be taken is ok as long as we can get ride of one of two.