feat: (Angular) Signal-based Ionic components for Angular

[ntorrey]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

While still in development, Angular's new signal APIs provide developers with improved DX and performance (eg. zoneless applications). It would be great if Ionic components would employ these new signal APIs under the hood to allow for zoneless change detection. See link below for the API.

Describe the Use Case

It would allow for increased performance, and would be required for a developer to be able to use Ionic components in a zoneless Angular application.

Describe Preferred Solution

No response

Describe Alternatives

No response

Related Code

No response

Additional Information

Angular Signal Component API:
angular/angular#49682

[sean-perkins]

Hello @ntorrey thanks for this feature request.

Can you share what advantages or specific features you think would benefit from a signal-based implementation?

Many of Ionic's "angular" components are just thin component wrappers setting props from the host to the web component and binding event listeners. There are a few exclusions, but we try to avoid any framework-specific component implementations, if possible. The render performance where signals would be applicable is owned by Stencil's own virtual dom implementation and has a similar form of reactivity and performance.

Thanks!

[ntorrey]

@sean-perkins
I confess my ignorance in the inner workings of Ionic components. My concern is simply that Ionic components will still "work" in a (future) zoneless Angular application where change detection will only run when either:

1. A signal in the template changes or
2. An observable with the async pipe in a template (user$ | async) is updated.

Maybe this won't be an issue, but just wanted to make sure.

[sean-perkins]

@ntorrey signals are supported with Ionic components and will continue to be so in the future state of Angular with zoneless applications. There may be specific areas where Ionic may not work and I would encourage you to continue to help us by reporting those issues like you have done with #28876. That specific bug report we are tracking against v8 (#28882) due to incompatibilities with our existing NavParams API and setInput. We are favoring Angular's setInput API and removing the legacy NavParams.

We rely heavily on this amazing community to report those areas, since they often are the ones that get a first hands-on with building real scenarios with them. Our team will review Angular's big changes mainly over majors or if there is a very high demand feature that lands in a minor.

I don't believe I have seen any commitments from the Angular team on zoneless being the default in the near-ish future, but I can capture some investigation work so our team is aware and we can validate core behavior based on the current state (opt-in flag).

Do you have any other questions or concerns? If not, I think we can close out this feature request and handle bug reports case-by-case 🙂

[ntorrey]

@sean-perkins
Thank you for the response! Feel free to close the feature request. Just wanted to create awareness around this issue in case it were necessary.

[ionitron-bot]

Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Ionic, please create a new issue and ensure the template is fully filled out.