attributesBindings does not set id in 1.13

[Serabe]

The following code does not work in 1.13 but does in 1.12:

export default Ember.Component.extend({
  attributeBindings: [
    'tagId:id', // Not working
    'hi:my-attr', // working
  ],
  tagId: 'my-id',
  hi: 'hola',
});

[Serabe]

For reference, thank to @SaladFork, attributeBindings in:

• Ember 1.12
• Ember 1.13

[Serabe]

On the other hand, if the component gets called like {{my-component id="whatever"}} the element gets the whatever id.

[Serabe]

The problem seems to be in this line. I need to do something like this:

{{my-component object=object}}

with the my-components id attribute depending on a (computed) property of object (the CP does not depend on any other attribue). I tried setting directly the elementId in didInitAttrs, but it seems it was too late to change it.

didInitAttrs() {
  this.elementId = this.get('object.idForComponent');
}

On the other hand, doing that in init works as expected.

What is the official and supported way to do this?

[pixelhandler]

attributeBindings are a feature of Ember.View (deprecated) and not are not documented whether or not the same feature will be supported on Ember.Component.

This does appear to be a (regression) bug for v1.13.x as this did work in v1.12. I someone will need to confirm whether an undocumented use of attributeBindings even in 1.12 should still work in 1.13.

[stefanpenner]

So just a headsup, we don't support id's changing after initial render. Although I believe we do support bindings used to populate it on initial render.

Someone should likely verify my above statements.

It may be the case, that timings changed preventing the ID from being set at the right time. (that is my guess)

[rwjblue]

attributeBindings is a supported and public API for Ember.Component. The issue here is that the id attribute is set to the elementId (essentially hard coded) and does not look for it in attributeBindings. We specifically make {{foo-bar id="asdfadsf"}} work by grabbing id out of attrs here.

We could likely fix that in our handling of attributeBindings. Essentially moving this above here.

Working on a test + PR...