tabris-js
tabris-js copied to clipboard
Discussion: Properties vs. Attributes
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.
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.
I would be in favor of using Attributes everywhere to reduce confusion. IMO the behavior from the "Con" example is expected.
I think what ever compromise needs to be taken is ok as long as we can get ride of one of two.