Skip to content

docs(angular): document boolean input changes in the v10 migration guide - #4744

Open
thetaPC wants to merge 2 commits into
major-10.0from
FW-7637
Open

thetaPC wants to merge 2 commits into
major-10.0from
FW-7637

Conversation

@thetaPC

@thetaPC thetaPC commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Issue URL: ionic-team/ionic-framework#31442

What is the current behavior?

The v10 migration guide has no Angular section. Boolean inputs on Ionic components are getting an input transform in v10, and nothing documents it.

What is the new behavior?

Adds Getting Started > Angular > Boolean Inputs to the v10 migration guide, covering:

  • The new shorthand, <ion-item button>, which previously failed to compile
  • The break: declaring the transform turns on type checking Angular did not do before, so [button]="items.length" now fails with TS2322 and needs coercing
  • null and undefined pass through instead of coercing to false, the opposite of Angular's own booleanAttribute, because components like ion-item and sheet ion-modal treat "not set" as a third state

Does this introduce a breaking change?

  • Yes
  • No

Other information

N/A

@vercel

vercel Bot commented Sep 18, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
ionic-docs Ready Ready Preview Sep 21, 2026 9:54pm UTC

Request Review

@ShaneK ShaneK left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! I checked the behavior claims against the v10 source and both the ion-item and ion-modal examples hold up. One correction inline on the coercion paragraph, which came across from the framework PR.

Comment thread docs/updating/10-0.mdx
+ <ion-item [button]="items.length > 0"></ion-item>
```

Coercion also moves from Stencil to Angular, which changes the result for numbers. `0` and `NaN` previously became `false` and now become `true`, matching Angular's own `booleanAttribute`. Without `strictTemplates` there is no compile error to catch the binding above, so an empty list now disables the item rather than enabling it. Coercing the expression fixes both the type error and the runtime change.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Coercion also moves from Stencil to Angular, which changes the result for numbers. `0` and `NaN` previously became `false` and now become `true`, matching Angular's own `booleanAttribute`. Without `strictTemplates` there is no compile error to catch the binding above, so an empty list now disables the item rather than enabling it. Coercing the expression fixes both the type error and the runtime change.
Coercion also moves from Stencil to Angular, which changes the result for numbers. `0` and `NaN` previously became `false` and now become `true`, matching Angular's own `booleanAttribute`. Without `strictTemplates` there is no compile error to catch the binding above, so an empty list now renders the item as tappable rather than plain. Coercing the expression fixes both the type error and the runtime change.

This is the same correction as the one on the framework PR, since the paragraph came across with it. The example binds button rather than disabled.

Comment thread docs/updating/10-0.mdx
<ion-item [button]="true"></ion-item>
```

Declaring the transform also turns on type checking for these inputs, which Angular did not do before. The generated component wrappers declare no class fields, so Angular had nothing to check a binding against and accepted any value. A binding that passes something outside `boolean | string | null | undefined` now fails to compile. The common case is a truthiness binding on a number:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This holds under strictTemplates, though the caveat doesn't turn up until the coercion paragraph further down, where it's attached to a different point. Could it go here instead? Someone without strictTemplates reads this, expects a compile error, gets none, and never reaches the part that actually affects them.

This branch was successfully deployed

1 active deployment
Preview 91f31b43 Deployed Sep 21, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants