feat(angular): support setting boolean props by attribute presence #31442
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| /* | ||
| * Duplicates `angular-component-lib/boolean-attribute.ts`, which the output | ||
| * target copies next to each generated proxies file and so is not reachable | ||
| * from here. `proxy.ts` duplicates `ProxyCmp` for the same reason. Refer to | ||
| * the TODO at the top of `proxy.ts`. | ||
| */ | ||
|
|
||
| /** | ||
| * Transforms a value to a boolean so that boolean properties can be set by attribute presence, | ||
|
Member
There was a problem hiding this comment. Did this end up confirmed? The original report was an editor warning rather than a build failure, and I'm not sure the new option silences it on its own. From the compiler side it doesn't. Writing |
||
| * e.g. `<ion-modal handle>` instead of `<ion-modal [handle]="true">`. | ||
| * | ||
| * Strings are coerced the same way Angular's `booleanAttribute` coerces them, so `''` (a bare | ||
| * attribute) becomes `true` and `'false'` becomes `false`. | ||
| * | ||
| * Unlike Angular's `booleanAttribute`, `null` and `undefined` are passed through rather than | ||
| * coerced to `false`. Components frequently treat them as a state distinct from `false`, and both | ||
| * reach inputs routinely from the `async` pipe before its first emission and from form control | ||
| * values: | ||
| * | ||
| * ```tsx | ||
|
Member
There was a problem hiding this comment. This is the only one of the three copies anyone will actually edit, and it's the shortest. It drops the notes the generated copy carries about why Angular's Meanwhile the tsx example and the |
||
| * // `undefined` means "decide based on the mode", which is not the same as `false` | ||
| * const showDetail = detail !== undefined ? detail : mode === 'ios'; | ||
| * | ||
| * // a strict comparison also behaves differently for `null` than it does for `false` | ||
| * const showHandle = handle !== false; | ||
| * ``` | ||
| * | ||
| * Declared as a function rather than an arrow constant because Angular has to resolve input | ||
| * transforms statically when compiling a library in partial compilation mode. | ||
| */ | ||
| export function nullableBooleanAttribute(value: boolean | string | null | undefined): boolean | null | undefined { | ||
| if (value === null || value === undefined) { | ||
| return value; | ||
| } | ||
| return typeof value === 'boolean' ? value : value !== 'false'; | ||
|
Member
There was a problem hiding this comment. Anything that isn't a boolean, Coercing only strings would keep the feature and the old behavior. The catch is that the two generated copies of this helper are byte-identical to what Mostly flagging it so it's a deliberate call rather than something we notice later, since changing it afterwards is its own behavior change. |
||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,43 @@ | ||
| /* eslint-disable */ | ||
| /* tslint:disable */ | ||
|
|
||
| /** | ||
| * Transforms a value to a boolean so that boolean properties can be set by attribute presence, | ||
| * e.g. `<my-component disabled>` instead of `<my-component [disabled]="true">`. | ||
| * | ||
| * Strings are coerced the same way Angular's `booleanAttribute` coerces them, so `''` (a bare | ||
| * attribute) becomes `true` and `'false'` becomes `false`. | ||
| * | ||
| * Unlike Angular's `booleanAttribute`, `null` and `undefined` are passed through rather than | ||
| * coerced to `false`. Components frequently treat them as a state distinct from `false`: | ||
| * | ||
| * ```tsx | ||
| * // `undefined` means "decide based on the mode", which is not the same as `false` | ||
| * const showDetail = detail !== undefined ? detail : mode === 'ios'; | ||
| * | ||
| * // a strict comparison also behaves differently for `null` than it does for `false` | ||
| * const showHandle = handle !== false; | ||
| * ``` | ||
| * | ||
| * Both values reach inputs routinely in Angular templates, from the `async` pipe before its | ||
| * first emission and from form control values, so coercing them would change the behavior of | ||
| * bindings that work today. | ||
| * | ||
| * This is implemented here rather than imported from `@angular/core` so that consumers on | ||
| * Angular versions without `booleanAttribute` are unaffected by this file being generated. | ||
| * | ||
| * The parameter type is what Angular derives `ngAcceptInputType_*` from, so it decides which | ||
| * template bindings compile. Widening it to `unknown` would let any expression through. | ||
| * | ||
| * Declared as a function rather than an arrow constant because Angular has to resolve input | ||
| * transforms statically when compiling a library in partial compilation mode. | ||
| * | ||
| * This lives in its own file, separate from `utils.ts`, so that it carries no runtime imports. | ||
| * That keeps it independently type-checkable without pulling `rxjs` in for `proxyOutputs`. | ||
| */ | ||
| export function nullableBooleanAttribute(value: boolean | string | null | undefined): boolean | null | undefined { | ||
| if (value === null || value === undefined) { | ||
| return value; | ||
| } | ||
| return typeof value === 'boolean' ? value : value !== 'false'; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
<ion-modal [handle]="42">failure in the description has a flip side I don't think we've accounted for. These inputs had no type at all before, so anything that compiled and isn'tboolean,anyor nullable now fails too. Something like[disabled]="items.length"is the common one, and it's the same on Angular 18 through 22.What gets emitted is
ngAcceptInputType_<prop>: boolean | string | null | undefined. Upstream chose the narrow type on purpose, the helper's own comment says widening it tounknownwould let any expression through, so this is intended rather than a slip. It does mean every boolean input in the library gets stricter in a minor though.Could we check the breaking change box, or scope the claim in the description? It probably wants a changelog note either way.