ng-enabled

[cricardol]

Should this attribute be created in a future release?

[mhevery]

what is the rationalization?

On Fri, Aug 10, 2012 at 7:01 AM, cric [email protected] wrote:

Should this attribute be created in a future release?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1252.

[andershessellund]

You need to use ng-disabled - there is no HTML attribute called enabled.

[adz]

It should be added for completeness...

Why have both ng-show and ng-hide when you can just use ng-hide?

It sometimes reads better, just like the show/hide variants, by avoiding double negatives:
<button ng-enabled='loaded && product.available'/>

Vs:
<button ng-disabled='!(loaded && product.available)'/>

[pierredewilde]

+1

[graphnode]

+1

I have a function in this attribute. It confused the hell of me that I need to return true to disable the button.

[perrygovier]

+1

[rzschech]

+1

[wokier]

as @adz said, like ng-show and ng-hide

[shangxiao]

+1 as it makes for better readability - an ng-enabled would eliminate double negatives

[bevacqua]

+1 👍

[mmastrac]

+1 as well. I spent a few minutes today wondering why my ng-enabled="blah" directive wasn't working before I realized that there wasn't one.

[devmondo]

👍

[pencilcheck]

+1 Come on guys, you can make it

[basarat]

+1 for intuitiveness, lower barrier to entry

[glyphobet]

+1 double negatives are harder to think about and easier to screw up

[kdekooter]

+1 if you have ng-hide and ng-show you should also have ng-enabled

[stanonyime]

+1

[zdennis]

+1

[mariusschulz]

+1

[kanetz]

+1

[crw-riviere]

+1 =]

[pfraces]

+1

[danmichaelo]

Being new to angular and having just read about ng-show and ng-hide, I sort-of expected there to be ng-enabled to pair with ng-disabled too 👍

[ajhekman]

+1

[ejdyksen]

+1...this is a simple thing that makes a huge difference in code readability.

[ericfledderman-zz]

+1

[pencilcheck]

Come on AngularJS developers, it might take only a few secs to commit but now you are stalling us for a year?

[petebacondarwin]

I have added it to a milestone after we get RC3 out the door, for discussion. Perhaps someone would like to make a tested, CLA-signed PR with decent commit messages?

[IgorMinar]

I think the whole precedence discussion about a possible but unlikely scenario of having the conflicting directives on the same element is a distraction.

The real question is do we want this in Angular core or not. Either way we go, we should have a reason for it and I'm sorry but many +1 are not enough force the decision. Consistency and predictability are more important.

ngDisabled and other directives that bind to boolean attributes exist only because in certain versions of IE we can't bind directly to disabled (or other boolean) attributes because IE will not store the value of the disabled attribute in the DOM. So if template contains <input disabled="{{someCondition}}">, the parsed DOM be the same as if the template was just <input disabled>. This is why ngDisabled exists - it allows the template to not be messed up in IE. If it weren't for IE, we wouldn't have ngDisabled.

So what's up with ngEnabled? Q: Would it be convenient to have it? A: Sometimes. Q: Would it be consistent with the rest of the system? A: No.

If we wanted to make it consistent with the rest of the system, we'd have to created ngReadWrite (as an opposite for ngReadOnly), ngUnselected (as an opposite for ngSelected), ngUnchecked (for ngChecked) and the list goes on and on and becomes more ridiculous the more exotic the boolean attributes get. As you can see this would cause an api explosion and would not add much value for anyone.

Q: What about ngShow/ngHide? A: they should not exist. We should just bind to the hidden attribute and if anything have the ngHidden directive for IE. That's the direction we'll go in Angular2. It's too late to change it in Angular1.

So what if someone wants ngEnabled really really badly? Just write a new module and share it via bower or npm. You can start off with this code: http://plnkr.co/edit/zzBMyd5REGcVEjUzkovQ?p=preview

Now why on earth was this labeled as "PRs plz" is not clear to me. I think it was done by an accident by someone on the team and I apologize for that.

I'm sorry to disappoint many people on this thread, but we need to keep Angular focused and consistent. If someone can be done via a non-core module then it should be done that way. Otherwise we'll end up with a bloated code base that contains random features that overall make no sense.

[btford]

I made a npm module/bower component here –> https://github.com/btford/angular-enabled

[zdennis]

@bford, you are the man!

@IgorMinar, thank you for your thoughtful reply and the additional context that went into your decision.

[armw4]

+5

[mdr]

If we wanted to make it consistent with the rest of the system, we'd have to created ngReadWrite (as an opposite for ngReadOnly), ngUnselected (as an opposite for ngSelected), ngUnchecked (for ngChecked) and the list goes on and on and becomes more ridiculous the more exotic the boolean attributes get. As you can see this would cause an api explosion and would not add much value for anyone.

"We can't add X, even though dozens are asking for it, because we wouldn't want to add Y and Z, which no-one is asking for."

[stevebroshar]

From the perspective of interface design, logic should be named using positive terms. As @graphnode says above it is confusing that the value true disables something. True (positive) should be associated with something positive (enabled).

Some argue that ngDisabled is named such since it controls the disabled HTML attribute and therefore an ngEnabled makes no sense ... since there is no enabled HTML attribute. And that's a fair point. The question becomes: is ngDisabled a low level helper for the disabled attribute? Or is it a higher level feature -- the way to control whether something is enabled?

I suggest that it should be the latter. First, adding abstraction to a system leads to better code. Second, as a programmer with limited HTML experience I would rather rely on a library such as NG than to learn about the details of HTML. I'd be happy if I never knew that HTML had a disabled attribute.

FWIW I do not think that ngEnabled should be added for completeness -- since both ngHide and ngShow exist. Therefore, there is no need for something like ngUnchecked. Besides, that's negative. ngChecked is the right choice.

[kdekooter]

👍 what @stevebroshar says! Abstract away from freaky lower level details.

[martijn80]

Symfony2 has a project tag DX, which stands for Developer Experience.

The option to support ng-support would really qualify to improve the angularjs developer experience.

[blakekl]

I have to agree with @IgorMinar and @stevebroshar. I understand why Igor doesn't want to add it and his arguments are very valid, however I think steve broshar's counter is the correct way to go. Unless it's impossible to implement it this way and support IE. Negative logic statements are just bad, even if HTML surfaces it that way.

[jamesdaily]

@blakekl: I don't view it as negative logic or positive logic, but rather a way to deviate from the default. By default, form fields are enabled (interactive, usable, clickable, etc), and write-able; check boxes by default are un-checked; dropdown options are by default unselected (and default to the top row by UI convention).

The HTML boolean attributes only serve to override the default behavior, and do not take any stance on positivity or negativity. There's nothing negative or positive about a read-only field, it's just read-only.

You may decide that "enabled" is positive and "disabled" is negative, but that's only true in the context of your particular application.

[ivan-saorin]

@jamesdaily +1 perfect!

It is funny to see how much philosophy is hidden behind an ng-enabled attribute. It is also funny to see how customers (developers using angular for real applications) requesting an enhancement are dismissed basing the reasoning on not sustainable arguments.
If the attribute would be useful: it, guess what, will be useful. And that regardless of any html related negative logic you may put behind that.

So for the sake of maintaining this comment page under 1GB in space you shall really listen to the requests and insert the new attribute. Or at least remove the ng-show one, as at that point would be unnecessary if not confusing.

[mstdokumaci]

this is a perfect example of how developers can become arrogant stubborns.

[SanderElias]

@mstdokumaci : Code of conduct
I just hope you understand that this way of communicating is deemed unacceptable here?

[blakekl]

@jamesdaily I use the terms 'positive' and 'negative' loosely, mostly based on my experience that using what I called 'negative' frequently results in code that reads with double negatives. Positive is simply the opposite. Sorry if the terminology was confusing. I didn't mean it to be.

I frequently see form submit buttons with something like: ng-disabled="!isValid();" which seems to cause confusion on our team.

[SanderElias]

@blakekl, I see your point, but then again you can simply do: ng-disabled="isInvalid()" right? And if you really want, it's easy enough to write your own xxDisabled directive That's just a single way to resolve the issue!

[wspringer]

+1 on having it baked in

[nithinankam]

please put in ng-enabled

[ilaipi]

+1024

[sap9433]

My dear ng-enabled , I miss you so much ...

[moniuch]

An argument that ng-enabled should not exist because there's no such attribute as "enabled" is irrelevant when compared to the fact that there's no attribute show or hide, but even though we do have two counterparts in angular. If we spoke about ng-attr-enabled - then I would agree. But to me ng-enabled would be just a helper, just like ng-disabled and - as many have stated before - stand for readability which I bet all developers of angularjs fight and advocate for.

[dokuboyejo]

+2048
For me, < buuton ng-enabled="con"> reads better than < buuton ng-disabled="!con">

[wspringer]

Perhaps we should just have an ng-enabled fork of Angular JS. It’s almost worth it.

-- 
Wilfred Springer
+31 612 981 670
http://nxt.flotsam.nl/

On 11 Aug 2015 at 08:07:03, dokuboyejo ([email protected]) wrote:

+2048
For me, < buuton ng-enabled="con"> reads better than < buuton ng-disabled="!con">

—
Reply to this email directly or view it on GitHub.

[ivan-saorin]

@dokuboyejo It's so obvious It hurts!! ;)

[Maxwe11]

👍

[praveen912]

+1

[petebacondarwin]

We have provided this feature in an external module, thanks to Angular core member @btford : https://github.com/btford/angular-enabled