Aurelia should support boolean values for attributes.

[AshleyGrant]

I should be able to tell Aurelia that an attribute's value should be treated as a boolean. This should work for both simple custom attributes as well as attributes on custom elements.

Usage:

<foo bar="false"></foo>

Custom Element VM:

export class Foo {
  @bindable({ isBoolean: true }) bar;
}

If the custom attribute or custom element tells Aurelia that it expects its value to be a boolean, the Aurelia will coerce the value to a boolean before setting the VM property and calling any changed callbacks.

[EisenbergEffect]

I'm thinking this will merge with our support for typed bindables. A typed bindable would look like this:

@bindable.boolean bar;

This would ensure that the property value was always a boolean type, using a value converter under the hood. These value converters could have a property set on them which indicates if they should reflectToAttribute. If that is set, when the property is updated it will update the DOM. All primitive converters would update the DOM (boolean, int, float and string). Additionally, we can allow for boolean properties to add/remove the attribute instead of updating the value. That could be done like this potentially:

@bindable.boolean({addRemove: true}) bar;

[kevmeister68]

I was going to raise a similar issue but found this. When you declare a bindable attribute on your custom element, you don't know whether someone is going to directly assign a literal value to it, or bind to it, and therefore the value of the underlying property could end up as a literal string, or as whatever type is bound to it.

I think I would prefer to see the @bindable( ) decorator being extended so the options object allows an implicit "value converter" being able to be defined by the user, plus a precanned set of Aurelia-supplied converters.

Otherwise, it seems to me that if someone wants their own coercion function, they may have to build their own decorator, which falls into the category of sledgehammer cracking walnut.

[EisenbergEffect]

Yes, the options object would be extended to enable providing a value converter. However, we could also provide a nice syntax, as above, for the common primitive types. That syntax would essentially just create the options object and configure the value converter automatically.

[fopsdev]

like this feature.
just in case -> float numbers can be formatted differently depending on the used culture
i'm just telling that because i see developers running into this issue again and again :)

[ajayvikas]

Is this planned for final release or thereafter?

[EisenbergEffect]

It's planned for a point release. Don't we are stopping with 1.0. We just need to cut an official release rather than let it go on forever. After that, we turn right back around to implement some new features. This is one that is near the top of the list.

[jods4]

Would love to have this, especially the add/remove part, so that you can do <data-field required /> and have a boolean required attribute in code-behind. I would go as far as say that for bindable.boolean it should be the (overidable) default.

[thomas-darling]

Yep, we really need this too, and looking very much forward to it - both the type support, the reflectToAttribute option, and the add/remove behavior for boolean attributes.

We would also really like to see the @bindable decorator leverage TypeScript metadata, if available, to automatically determine the type - that way, this will just work:

@bindable
public foo: boolean;

[jdanyow]

@thomas-darling here's the add/remove behavior for boolean attributes: https://gist.run/?id=744ae2416278d35b5a7d450f3cc118f5

[thomas-darling]

@jdanyow Thanks, didn't think of using a binding behavior for that - might come in handy!

I think there's more to it that that, though. Let's take the disabled attribute on input elements as an example - that is a boolean attribute with no value - it's the fact that it is present on the element that makes it true.

From the spec:

A number of attributes are boolean attributes. The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.

NOTE: The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

https://www.w3.org/TR/html5/infrastructure.html#boolean-attributes

I'd also say it should be @bindable that controls whether the attribute uses the add/remove behavior. Think of a custom input element, which comes with styles for when the element is disabled - in this case, the CSS distributed with that element might apply different styles depending on the presence of the disabled attribute. It would be highly error prone if we had to remember to add a binding behavior to every disabled attribute, in order to make that styling work.

So, I'd say this property, which we know is boolean

class Foo
{
    @bindable
    public disabled: boolean;
}

Should be true for:

<foo disabled></foo>
<foo disabled=""></foo>
<foo disabled="disabled"></foo>
<foo disabled.bind="true"></foo>

And false for:

<foo></foo>
<foo disabled.bind="false"></foo>

And if reflectToAttribute is enabled for that @bindable, I'd say it should actually default to the add/remove behavior for boolean properties.

So, while the element in my markup might be written as:

<foo disabled.bind="true">I'm disabled</foo>
<foo disabled.bind="false">I'm enabled</foo>

The element in the DOM should be:

<foo disabled>I'm disabled</foo>
<foo>I'm enabled</foo>

That way CSS like this will always work as expected:

foo[disabled] { color: gray }

Makes sense?

[atsu85]

@thomas-darling,

<foo disabled.bind(true)></foo>

I guess You are not proposing alternative syntax, but meant
<foo disabled.bind="true"></foo>
instead?