You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which @angular/* package(s) are relevant/related to the feature request?
core
Description
We now have two options:
Attribute - no change watching but no binding too. Limited to only compile time strings.
Input - signal based and can change over time.
What's missing is the in between. A way to pass an input but without change watching.
The idea came from inputs I can't or don't want to handle when they change. Currently using ngOnChanges first change check I throw an error if it gets changed after first time.
Proposed solution
A way to declare on time input. Something like: a = input.oneTime<string>() and will be just a string. If changed after first time will throw an error.
It will also make performance better (I think?) as no need for signal or tracking.
Alternatives considered
Check in ngOnChanges for first change and throw error. With signal inputs it's tougher as ngOnChanges is discouraged.
The text was updated successfully, but these errors were encountered:
Related to #14033 where we would, probably, also need the binding side of it (the reasoning being that one-value inputs should only be bound with either a static value or a one-time binding).
Which @angular/* package(s) are relevant/related to the feature request?
core
Description
We now have two options:
What's missing is the in between. A way to pass an input but without change watching.
The idea came from inputs I can't or don't want to handle when they change. Currently using ngOnChanges first change check I throw an error if it gets changed after first time.
Proposed solution
A way to declare on time input. Something like:
a = input.oneTime<string>()
and will be just a string. If changed after first time will throw an error.It will also make performance better (I think?) as no need for signal or tracking.
Alternatives considered
Check in ngOnChanges for first change and throw error. With signal inputs it's tougher as ngOnChanges is discouraged.
The text was updated successfully, but these errors were encountered: