-
Notifications
You must be signed in to change notification settings - Fork 13.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(angular): setting props on a signal works #28882
Conversation
@liamdebeasi is this PR ready for review? |
Not yet. This requires a breaking change that I want to run by the team first. |
I'll close for now. |
This reverts commit 729529f.
@brandyscarney Any hope Angular signals might be supported in future versions of Ionic? |
The branch is merged into main recently and its name was 8.0, so I guess it will be in there? ^^ |
I did not close this PR. It was automatically closed when the |
@brandyscarney does someone has this in their mind, now where liam left? |
A new PR has been reopened! I recommend subscribing to it for more updates. |
Issue number: resolves #28876
What is the current behavior?
When assigning
componentProps
as inputs to an Angular component, we doObject.assign
. When using the newer Angular Signals API for inputs the value of an input is a function:The developer accesses the value of
myInput
in a template by doingmyInput()
sincemyInput
is a function.If a developer passes
componentProps: { myInput: 'bar' }
then the value ofmyInput
is set to this string value, overriding the function. As a result, callingmyInput()
results in an error becausemyInput
is a string not a function.What is the new behavior?
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?
As part of this
NavParams
has been removed as it is incompatible with thesetInput
API. The oldObject.assign
worked to allow devs to get all of thecomponentProp
key value pairs viaNavParams
even if they are not defined asInputs
. UsingsetInput
will now throw an error, so developers need to create an@Input
for each parameter. This means thatNavParams
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
Dev build:
7.6.2-dev.11706205501.196a5433