feat(angular): setting props on a signal works (#29453)

Issue number: resolves #28876

---------

<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->

<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->

## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->

When assigning `componentProps` as inputs to an Angular component, we do
`Object.assign`. When using the newer Angular Signals API for inputs the
value of an input is a function:

```js
myInput = input<string>('foo') // this is a function
```

The developer accesses the value of `myInput` in a template by doing
`myInput()` since `myInput` is a function.

If a developer passes `componentProps: { myInput: 'bar' }` then the
value of `myInput` is set to this string value, overriding the function.
As a result, calling `myInput()` results in an error because `myInput`
is a string not a function.

## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->

- Angular 14.1 introduced `setInput` which lets us hand off setting
inputs to Angular. This will set input values properly even when using a
Signals-based input.

## Does this introduce a breaking change?

- [x] Yes
- [ ] No

<!--
  If this introduces a breaking change:
1. Describe the impact and migration path for existing applications
below.
  2. Update the BREAKING.md file with the breaking change.
3. Add "BREAKING CHANGE: [...]" to the commit description when merging.
See
https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer
for more information.
-->


As part of this `NavParams` has been deprecated as it is incompatible
with the `setInput` API. The old `Object.assign` worked to allow devs to
get all of the `componentProp` key value pairs via `NavParams` even if
they are not defined as `Inputs`. Using `setInput` will now throw an
error, so developers need to create an `@Input` for each parameter. This
means that `NavParams` has no purpose and can safely be retired in favor
of Angular's Input API. Not removing NavParms would make it difficult
for us to support new Angular APIs such as this Signals-based input API.

## Other information

<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->

Dev build: `8.1.1-dev.11715021973.16675b67`

You will need to update the Ionic config to opt-in to the new option:
```ts
useSetInputAPI: true,
```

---------

Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
This commit is contained in:
Sean Perkins
2024-05-06 18:12:32 -04:00
committed by GitHub
parent 0124f3b0b3
commit 4640e046eb
10 changed files with 76 additions and 28 deletions

View File

@ -19,7 +19,11 @@
* ```
*/
export class NavParams {
constructor(public data: { [key: string]: any } = {}) {}
constructor(public data: { [key: string]: any } = {}) {
console.warn(
`[Ionic Warning]: NavParams has been deprecated in favor of using Angular's input API. Developers should migrate to either the @Input decorator or the Signals-based input API.`
);
}
/**
* Get the value of a nav-parameter for the current view

View File

@ -20,12 +20,15 @@ import {
import { NavParams } from '../directives/navigation/nav-params';
import { ConfigToken } from './config';
// TODO(FW-2827): types
@Injectable()
export class AngularDelegate {
private zone = inject(NgZone);
private applicationRef = inject(ApplicationRef);
private config = inject(ConfigToken);
create(
environmentInjector: EnvironmentInjector,
@ -37,7 +40,8 @@ export class AngularDelegate {
injector,
this.applicationRef,
this.zone,
elementReferenceKey
elementReferenceKey,
this.config.useSetInputAPI ?? false
);
}
}
@ -51,7 +55,8 @@ export class AngularFrameworkDelegate implements FrameworkDelegate {
private injector: Injector,
private applicationRef: ApplicationRef,
private zone: NgZone,
private elementReferenceKey?: string
private elementReferenceKey?: string,
private enableSignalsSupport?: boolean
) {}
attachViewToDom(container: any, component: any, params?: any, cssClasses?: string[]): Promise<any> {
@ -84,7 +89,8 @@ export class AngularFrameworkDelegate implements FrameworkDelegate {
component,
componentProps,
cssClasses,
this.elementReferenceKey
this.elementReferenceKey,
this.enableSignalsSupport
);
resolve(el);
});
@ -121,7 +127,8 @@ export const attachView = (
component: any,
params: any,
cssClasses: string[] | undefined,
elementReferenceKey: string | undefined
elementReferenceKey: string | undefined,
enableSignalsSupport: boolean | undefined
): any => {
/**
* Wraps the injector with a custom injector that
@ -164,7 +171,38 @@ export const attachView = (
);
}
Object.assign(instance, params);
/**
* Angular 14.1 added support for setInput
* so we need to fall back to Object.assign
* for Angular 14.0.
*/
if (enableSignalsSupport === true && componentRef.setInput !== undefined) {
const { modal, popover, ...otherParams } = params;
/**
* Any key/value pairs set in componentProps
* must be set as inputs on the component instance.
*/
for (const key in otherParams) {
componentRef.setInput(key, otherParams[key]);
}
/**
* Using setInput will cause an error when
* setting modal/popover on a component that
* does not define them as an input. For backwards
* compatibility purposes we fall back to using
* Object.assign for these properties.
*/
if (modal !== undefined) {
Object.assign(instance, { modal });
}
if (popover !== undefined) {
Object.assign(instance, { popover });
}
} else {
Object.assign(instance, params);
}
}
if (cssClasses) {
for (const cssClass of cssClasses) {