-
Notifications
You must be signed in to change notification settings - Fork 232
Add support for [attr.name.if]="boolean" syntax #1058
Comments
BTW if anyone has better syntax alternatives, suggest them! |
|
I think the best way would be to make it a breaking change to be (a) in line with e.g. <button [attr.shiny]="false"></button>
<!-- <button></button> -->
<button [attr.shiny]="null"></button>
<!-- <button></button> -->
<button [attr.shiny]="myObject"></button>
<!-- <button></button> -->
<!-- Maybe a warn?: [attr.shiny] can only handle Boolean values. myObject is an object, therefore the attribute 'shiny' is not set. -->
<button [attr.shiny]="true"></button>
<!-- <button shiny></button> --> We could also opt-in with: <button [attr.bool.shiny]="isShiny"></button>
<!-- <button shiny="true"></button> -->
<!-- <button shiny="false"></button> -->
<button [attr.bool.shiny]="myObject"></button>
<!-- !!! throws a compile time error: myObject is not a Boolean. You can only use a Boolean value with [attr.bool.<foo>] !!! --> As a bonus you could extend (in the future) the attribute binding with e.g. toJSON 😅 <button [attr.json.data-hero]='myObject'></button>
<!-- <button data-hero='{"name": "Batman", "realName": "Bruce Wayne"}'></button> --> BTW, is it not possible to check at compile time if it is a Boolean or an object (I have no idea which code you are generating and if Dart allows this)? So this (just brainstorming): <button [attr.shiny]="myObject"></button>
<!-- <button></button> -->
<!-- Maybe a warn?: [attr.shiny] can only handle Boolean values. myObject is an object, therefore the attribute 'shiny' is not set. --> ... generates something like this: try {
if (attrShinyValue) {
// logic to add the attribute to the HTML element
}
} catch (e) {
// ups, not a Boolean
// inform the user with a warn/error message
} |
Honestly I don't see any of the proposals carry it's weight. |
Yeah, just a suggestion because they talked about it. Just gave my two cents. If I would start from scratch (developing my Angular) I would in line it with the rest and because not everything has to be groundbreaking, but sometimes only to make the product a little more coherent. |
We've decided we are not adding any more (intentional) breaking changes to the framework before 6.0.0, so if we do add this it needs to be incremental (i.e. non-breaking).
There is, though. Users have not found a way to add/remove a value-less attribute. We could argue that isn't useful, but at least someone thinks it is, and they can't write the code today. |
Not sure what you mean by that. Currently Angular creates Have you checked if If this doesn't work, then there is of course work necessary. |
Yes, they want to omit the |
I see. In this case I'd prefer
or if possible even better just
It could also be I don't know about the amount of work which approach causes, but I think boolean attributes are special enough (but probably rather rare) so that their own prefix would be justified. |
I'll let @TedSander and @nshahan weigh in because its their team's request. |
We see this code pattern a good amount of time: It is weird to use an API where you ask the user to use null instead of false. False is more natural value. Will also be better for non-nullablity. Seems like we could do better. It was so bad teams were trying to add Inputs/unperformant code just to get around writing this syntactic sugar in their template. I would think it would be an easy nice to use syntactic sugar that could be added pretty easily. If it is hard to do in the compiler we don't NEED it, but if it is easier I think it has been shown by other frameworks and the code we see inside that it is useful. |
@TedSander what about the DOM result I don't see much value in I have no strong opinion either way. I'm just curious about this topic because I was involved a bit in the discussion back then with Angular TS (and I think I also argued for |
I see this as convenient when you want have styles that target the presence of an attribute on an element in the dom. my-component {
[my-attribute] {
// some special styles
} It gets confusing when you have to deal with the attribute being present, not present, present but "true", and present but "false". It would be easier if "true" and "false" were always represented as present or not present in the dom. I think it would be nice to have syntactic sugar that would allow you to have an input binding between a dart bool and the presence of an attribute on the element. That way, if you wrote At the same time if you set the value of the input to |
@zoechi raised="" vs raised doesn't matter. Most HTML APIs have the behavior that any value on the attribute means it is true. This still autofocuses for example: Mostly we get to work around this because we deal with the JS property instead of the html attribute in angular, but we still need to deal with it for some HTML specific APIs like CSS as Nick mentioned, and other HTML like things. |
We're moving forward here, non-breaking:
(This is some-what similar to It would have been nice to just do
We can always revisit making this implicit in a future major release or behind a flag. |
This was quite easy, so its making it in for 5.0.0 final! |
Closed in #1439. |
Similar to
[class.name]="boolean"
, which adds a class'name'
ifboolean
istrue
, and removes class'name'
_ifboolean
isfalse
(or I thinknull
?).For example:
Would output
<button shiny></button>
ifisShiny == true
, and remove the'shiny'
attribute ifisShiny != true
. The reason for this new feature, versus re-using the existing[attr.shiny]
syntax, is that it strictly coerces the values to strings, and writes them in the template:... outputs
<button shiny="true"></button>
.We talked about trying to check, and if the value is a
bool
use the new behavior, but that is (a) breaking, and (b) not definitive (it's possible for the value to beObject
orbool
and require runtime checks). It's probably not worth it.The text was updated successfully, but these errors were encountered: