elements schema: detect dangling attributes

In the ideal world we should be able to detect "dangling" attributes. In the <div foo> example we should report foo as "dangling" when:

foo is not a valid HTML attribute (how come should we identify valid attributes? From a spec / schema?)
there is no matching directive
it wasn’t consumed by a binding / event handler / var declaration / other ng-specific construct
it is not prefixed with data- (?)

In practice "dangling" attributes in templates are most probably attributes are introduced due to:

typos
forgetting to add a directive (in the directives for the @View annotation) that should match a given attribute

Grr, detection of dangling attributes would really help to catch cases of using directives in a template without listing a given directive in @View. Maybe as a first step we could throw for all attributes that:

were not matched by any directive
have - in their names
are not on elements with names containing -
are not data- (and / or x-?) prefixed

While not perfect it should be able to catch some common errors.

@pkozlowski-opensource

@pkozlowski-opensource what is stoping up from implementing this? I thought we had something already work.ng

@mhevery

@mhevery nothing particular stops us, apart that it needs work. Here are the items to take care of:

- need to have a way of knowing which attributes were "consumed" by a directive (selector + "static" property bindings)
- need to have a way of knowing what are legitimate attributes on both regular HTML elements (we can hand-code this in schema from HTML specs) and web components (this will require hand-written schema by devs)

So, it is definitively doable but require some work - we can put it in one of the releases, depending on other priorities.

implemented

I believe that this is still an issue. If I have an attribute fooo but meant to kick-off directive foo it will fail silently.

Re-opening as this is not implemented, see #12016 as an example.

But why Angular compiler can't detect that component has a title input and don't set HTML attribute in this case?

@th0r

This is part of the sticking point:

need to have a way of knowing what are legitimate attributes on both regular HTML elements (we can hand-code this in schema from HTML specs) and web components (this will require hand-written schema by devs)

The problem is that we would need a way to tell Angular what attributes we don't mind appearing. People do use "unknown" attributes in custom elements but also with 3rd party libraries that are working outside Angular.

The additional cost of providing an API to specify this compared to the benefit that compiler errors provide is not high. Especially considering how few comments and votes this issue has received.

Regarding your point @th0r - we cannot remove title attribute since it might be used for CSS styling etc.

I don't suggest to remove any attribute, I suggest to fix the most common case when component's input has the same name as some already existing html attribute and not set this attribute in this case. It can be easily done as I believe Angular compiler has all necessary information for this. If one really needs to set this html attribute, he can always do it via [attr.].

My concern is that more new arrtibutes may appear in html in the future which potentially may overlap with input names on your already existing components and it may break their behavior.

I don't suggest to remove any attribute, I suggest to fix the most common case when component's input has the same name as some already existing html attribute and not set this attribute in this case. It can be easily done as I believe Angular compiler has all necessary information for this. If one really needs to set this html attribute, he can always do it via [attr.].

So you are saying that if there is

<my-component title="static text">...</my-component>

where the component has title as an input:

@Component({selector: 'my-component', ...})
class MyComponent {
  @Input()
  title: string;
}

Then the rendered HTML should not contain the title attribute? Is this not equivalent to removing that attribute?

In any case I think that this use case is probably not the same as detecting dangling attributes as outlined in this issue, so perhaps it should be discussed separately?

@petebacondarwin

@petebacondarwin angular-eslint/angular-eslint#320

I think prefer for correct behaviour restrict input when name conflicted with native attribute.

What do you think about check it when running AOT (if we don't have eslint)?

Frankly speaking, I don't understand why Angular sets attributes for co-named inputs on component's host element at all. IMO it's very confusing and strange as most of them simply become [object Object].

In any case I think that this use case is probably not the same as detecting dangling attributes as outlined in this issue, so perhaps it should be discussed separately?

I posted it here because of this comment - it says that issue with title is blocked by this one which has been closed.

@th0r

I think that comment @th0r is not correct. That issue is not dependent upon this one.
I don't think it is wise for the Angular compiler to error here. There are many cases where you actually do want to have the attribute appear; moreover, if you do not want an attribute to appear then you simply use a square bracket binding to a string instead.
Rather I think the right approach to support developers it to vote for the issue on angular-eslint as mentioned by @splincode.

@petebacondarwin

@petebacondarwin could you provide a few examples when you need an attribute for corresponding input to be set on host component?

@th0r

I'm. not quite sure what you are asking for @th0r - but the Angular Material library has possible examples: the MatInput directive has a placeholder input, which can be set without creating a square bracket binding, https://material.angular.io/components/form-field/overview#floating-label.

OK, thanks, but that's a directive and I'm talking about components with custom tag selectors and I can't think of any usecase when you want their inputs to also be set as host attributes. Anyway, for such cases we could have an extra decorator for inputs e.g. @Attr which would tell Angular to also set corresponding attribute to the host element.

@th0r

Thanks for the additional viewpoint @th0r - This checking can be achieved through linting, without creating a breaking change to how the Angular compiler works, so we do not intend to implement this feature.

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.}

Navigation Menu

Repository navigation

elements schema: detect dangling attributes #3425

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

elements schema: detect dangling attributes #3425

Description

Activity

pkozlowski-opensource commented on Aug 11, 2015

mhevery commented on Aug 21, 2015

pkozlowski-opensource commented on Aug 21, 2015

mhevery commented on Jul 1, 2016

pkozlowski-opensource commented on Jul 1, 2016

pkozlowski-opensource commented on Sep 30, 2016

16 remaining items

th0r commented on Sep 3, 2021

petebacondarwin commented on Sep 3, 2021

th0r commented on Sep 4, 2021

th0r commented on Sep 4, 2021

petebacondarwin commented on Sep 4, 2021

splincode commented on Sep 4, 2021

th0r commented on Sep 4, 2021

petebacondarwin commented on Sep 4, 2021

th0r commented on Sep 4, 2021

petebacondarwin commented on Sep 4, 2021

th0r commented on Sep 5, 2021

petebacondarwin commented on Sep 8, 2021

angular-automatic-lock-bot commented on Oct 9, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions