feat(common): introduce ngAttr directive - #13958

@DzmitryShylovich you've forgotten to commit unit tests :-)

Before doing more work on this I would like to hear a bit more about real-life scenarios, though.

Before doing more work on this I would like to hear a bit more about real-life scenarios, though.

I have doubts too, this is why I didn't add tests :)

What happens if you have:

<div [foo]="exp1" [ngAttr="{ foo: exp2 }">

There is no easy way to detect that.

I would also like to see real world scenarios. Please update or close this PR

@mhevery

I would also like to see real world scenarios

Take a look at #13940 (comment)

@DzmitryShylovich @mhevery I've updated the original issue with my thoughts on the ngAttr: #13940 (comment)

tl;dr; is that IMO it is not adding enough benefit to "pay" for itself. Having said this I would prefer that @mhevery decides here.

My experience tells me that more things means more bugs and supporting voes. So I vote against this as well. Going to close the PR for now.

I am working on a form generator that takes a JSON configuration, built by consumer of library, and automatically builds out a form in Angular Material. I would like to allow user to pass custom attributes to each form field to suit there needs e.g. aria labels, flex-layout directives, etc... [ngAttr]="config.attrs" would be very useful. I am currently try to use elementRefs and viewChild but I am having some trouble getting it to behave as expected.

A feature like this seems more useful for code that builds code, but if the performance will take a big hit then I need to find another solution. My library is available here, and corresponding code is in the DynamicFormModule. I'll update if I find a good workaround.

Update
I got the custom attributes to show up in DOM by accessing a @ViewChild inside of an ngAfterViewInit and using Renderer2.setAttribute , but the flex-layout directives don't seem to have any effect. It seems like afterViewInit is happening after flex-layout does it's thing. Even if this did work, I am forced to use NativeElement when using this method, which warned against in documentation. Maybe the Ivy update will address these issues, maybe it won't.

I just wanted to make sure I voiced this as it is a good use case for the feature. Especially as users become better versed with angular and start building more generative code.

@DzmitryShylovich would you be amicable to me pulling your attrs code into a module in an open source library? If so, I would like to stick with the ngAttrs naming convention. This way if it ever it ever is implemented in @angular/core, consumers of the library can easily convert to the native method. I can add some testing as well.

+1 to @nayfin, for basically the same reason. Also building JSON configurable form from reusable base components.

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