[no-input-rename] Add option to allow input renames for directives

[AndreasHae]

We have directives that accept inputs (specifically, validators for template-driven forms). We prefix each input with the name of the directive to make it more clear which directive it belongs to, like this:

class SomeDirective {
  @Input('someDirective-name') name: string;
}

It would be nice to have an option to allow this while still having the rule enforced in components.

[abaran30]

Hey @AndreasHae . You can do this already with the allowedNames option.

Example, in your .eslintrc.json file under the ts section:

      "rules": {
        "@angular-eslint/no-input-rename": [
          "error",
          {
            "allowedNames": ["someDirective-name"]
          }
        ]
      }

[AndreasHae]

Hi @abaran30, thanks for your suggestion but that doesn't work for our use-case. If you have a small project with a limited amount of validators, this might work, but in a project our size, we can't add every one of the dozens of input directives to the eslint config explicitly. Devs will get annoyed having to add a new exception to the rule every time they add a property and instead just disable the rule altogether.

What I have in mind is to have a more generic option that allows directives to prefix their inputs with their respective selector, or an option to disable it entirely for directives. I think this kind of prefixing is rather common in Angular projects (correct me if I'm wrong) so having this option may benefit a lot of projects.

[JamesHenry]

I think this kind of prefixing is rather common in Angular projects

I have personally never seen it on dozens of Angular projects... What makes you think this is common practice?

We will definitely want to extend this rule, however, to take the new hostDirectives API in Angular 15 into account.

Based on this video: https://www.youtube.com/watch?v=EJJwyyjsRGs aliasing of host directive inputs is going to become more and more common and certainly doesn't deserve to be flagged as a bad practice.

I'm going to create a separate issue for this, as I would class this as a bug in the v15 release

UPDATE: #1230 resolved in #1231

[JamesHenry]

And just to be clear @AndreasHae I am not saying you are wrong, I am just saying my anecdotal experience doesn't match, and I'm wondering what led you to the conclusion

[AndreasHae]

@JamesHenry you're right, the specific example I gave I have also just seen in one project, sorry for the misunderstanding. I think that's because not many projects have directives with multiple inputs, which is the only use-case I would see for this naming convention.

I suppose what's more common is having an input in the directive and giving it a name that's more semantically correct within the input, while preserving the directive name on the outside. Let's say you have a directive:

@Directive({ selector: 'my-directive' })
class MyDirective {
  @Input('my-directive') value: string;
}

where maybe the value name makes the code within the directive more readable, but at the same time it preserves the ability to use it like this:

<p [my-directive]="someValue"></p>

That would be another use case where I wouldn't want my input rename to be flagged.