alpha.39: classes added to the original element removed by host class property

[adamdbradley]

In the below code, the yellow css class added to the original element is being removed by the directive's host: { 'class': 'item' } property.

@Directive({
  selector: 'my-item',
  host: {
    'class': 'item'
  }
})
export class MyItem {}


@Component({
  selector: 'my-app'
})
@View({
  template: `
  <my-item class="yellow">
    My Item
  </my-item>
  `,
  directives: [MyItem]
})
export class App {}

alpha.39 does remove the "yellow" css class from the element:
http://plnkr.co/edit/uWtEnSvK7GMSj3i3MCeG?p=preview

alpha.37 does not remove the "yellow" css class from the element:
http://plnkr.co/edit/ug3KaOTAjYOECLeLW0mQ?p=preview

[naomiblack]

This is important but not blocking. @adamdbradley says they have another way around this.

[mhevery]

@adamdbradley and @tbosch discussed this today. I believe that @tbosch said that this is the correct behavior. @tbosch can you verify?

[pkozlowski-opensource]

@tbosch I would be surprised if the new behaviour would be a correct one. I remember that we used to have logic in the compiler where classes set by host were merged with ones already present on a host element. IMO it made sense.

What would be rationale for changing this merging behaviour?

[tbosch]

My initial thought was that treating class here as a special case seems wrong / not intuitive to users. However, other alternatives seem not right either: E.g. using:

host: { 'class.my-class': true

would clearly show that this is a special case, however, no one would use false as value...

So I am adding the previous behavior back. I.e. host attribtues class and style get merged with the attributes on the element.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}