Repository navigation
Closed
Labels
P4A relatively minor issue that is not relevant to core functionsA relatively minor issue that is not relevant to core functionsarea: coreIssues related to the framework runtimeIssues related to the framework runtimecore: binding & interpolationIssue related to property/attribute binding or text interpolationIssue related to property/attribute binding or text interpolationfeatureLabel used to distinguish feature request from other issuesLabel used to distinguish feature request from other issuesfreq2: medium
Milestone
Description
I'm submitting a...
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
Current behavior
Warning: this issue may be pedantic.
Different directives are using different mechanism to convert string to boolean.
In NgModel, the conversion is:
const isDisabled = disabledValue === '' || (disabledValue && disabledValue !== 'false');While in RequiredValidator :
this._required = value != null && value !== false && `${value}` !== 'false';And in EmailValidator :
this._enabled = value === '' || value === true || value === 'true';So that the result is:
| Pattern | [disabled] |
[required] |
[email] |
|---|---|---|---|
<element attribute> |
true |
true |
true |
<element attribute="true"> |
true |
true |
true |
<element attribute="false"> |
false |
false |
false |
<element attribute="foo"> |
true |
true |
false |
<element [attribute]="true"> |
true |
true |
true |
<element [attribute]="false"> |
false |
false |
false |
<element [attribute]="null"> |
false |
false |
false |
<element [attribute]="0"> |
false |
true |
false |
<element [attribute]="1"> |
true |
true |
false |
<element [attribute]="{}"> |
true |
true |
false |
<element [attribute]="{toString:()=>'false'}"> |
true |
false |
false |
The object definition is inlined just for demonstration.
Expected behavior
Angular should provide a unified mechanism for string -> boolean transformation in boolean attributes.
Minimal reproduction of the problem with instructions
Likely not needed as a one-line code in console.
What is the motivation / use case for changing the behavior?
Angular should provide a guideline for how to covert string to boolean in boolean attributes.
Environment
Angular version: 5.0.0-rc.5
Browser:
- [x] Chrome (desktop) version XX
- [x] Chrome (Android) version XX
- [x] Chrome (iOS) version XX
- [x] Firefox version XX
- [x] Safari (desktop) version XX
- [x] Safari (iOS) version XX
- [x] IE version XX
- [x] Edge version XX
For Tooling issues:
- Node version: XX
- Platform:
Others:
Another question is that NgModel#disbaled is declared as boolean while still accepts string value (by design for empty string), is it expected? (Consider we'll have type-checking for inputs some day)
Reacted by Oleksandr Tytskyi, Lazar Ljubenović, Alan Agius, Yaroslav Admin, Rafael Santana, Robert Wysocki, Paul Gschwendtner, Jason Bedard and Emil Sundin
Metadata
Metadata
Assignees
Labels
P4A relatively minor issue that is not relevant to core functionsA relatively minor issue that is not relevant to core functionsarea: coreIssues related to the framework runtimeIssues related to the framework runtimecore: binding & interpolationIssue related to property/attribute binding or text interpolationIssue related to property/attribute binding or text interpolationfeatureLabel used to distinguish feature request from other issuesLabel used to distinguish feature request from other issuesfreq2: medium
Activity
dawidgarus commentedon Oct 25, 2017
Built-in mechanism to sanitize inputs would be nice, something like:
@Input('required', { sanitize: 'boolean' }) private required: boolean, so one could safely write<element required>and always have boolean value in property. Also setter/ngOnChange won't be called if the actual input value will change from one truthy (or falsy) value to another.trotyl commentedon Oct 25, 2017
Relates to #5761 & #14761, but this one is not asking for syntax sugar, just the logic for manually implementation.
trotyl commentedon Oct 25, 2017
@dawidgarus Your request is another form of #8968, you should follow it there.
LinboLen commentedon Oct 26, 2017
in my short-sighted opinions;
already have pipe. this feature looks like not standard.
<element attribute><element attribute="true">... is a sugar for binding string literal. convert it? why? how? only for ngmodel? none of them sounds possible.alan-agius4 commentedon Feb 9, 2018
I think something like this ideally; https://github.com/angular/material2/tree/17cc4a198f336e8ebefbb2710d8e80df2595db7e/src/cdk/coercion
trotyl commentedon Feb 9, 2018
@alan-agius4 That's what we choose at last, but it would throwing error for
Symboltype (an small edge case problem).angular-robot commentedon Jun 4, 2021
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
angular-robot commentedon Jun 24, 2021
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
angular-automatic-lock-bot commentedon Apr 28, 2022
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.