Repository navigation
[Proposal] Normalize inputs (@Input()) #21143
Description
I'm submitting a...
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
Problem
-
There isn't type check on
@Inputso I tend to expect any type -
sometimes you want to give a flexible API to user by using input like
@Input() in: string | string[] | Foo[]but internally you just want to manage
Foo[].
Edit: 1) seems to be possible since v5
Solution
Introduce normalizer function to use on @Input() decorator.
type NormalizerFn = (v: any) => any;
Input(name: string);
Input(normalizer: NormalizerFn);
Input(name: string, normalizer: NormalizerFn);The normalizer function should be pure. Here is an example :
const asBoolean = v => v === true;
usage
@Input(NotNull)
v: string
@Input('value', asBoolean)
w: booleanWe could provide the most commons one and a compose() utility so we can compose multiple normalizer into a new one.
I've done a POC showing it all here : https://stackblitz.com/edit/angular-input-with-normalizer?file=app%2Fapp.component.ts
So this POC is just reducing the boilerplate of create a setter to do the job but I think this should be taken care of by Angular itself prior to set the input on the component.
Benefits
- Remove the need of all those setter/getter which are tedious and introduce a cleaner and flexible way to do it.
- Enforce OnPush strategy, changing an input from 2 values that get normalized to the same final value won't trigger CD anymore.
- Probably harmonize the way we handle certain type like boolean (see Feature Request: Unify the toBoolean behavior for boolean attributes #19929)
Problem
I'm not sure if the compiler can pick up a function definition inside metas and run it elsewhere. I'm hoping for someone with the knowledge to step in and give us a brief explanation before I start digging on the subject.
I don't think this introduce breaking change but not sure.
Activity
lazarljubenovic commentedon Dec 22, 2017
I'd love to see this.
A good starting point for the built-in normalizers would be
coercionfrom the CDK. Since these are pure functions, they are trivial to tree-shake with today's tooling, so IMO they could belong to@angular/commonwith no problem.angular-robot commentedon Jun 5, 2021
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
angular-robot commentedon Jun 26, 2021
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
alxhub commentedon Jul 17, 2021
Type-checking
@Inputs like this is supported in Ivy, and now TypeScript has split types forget/setaccessor pairs so this is even easier.angular-automatic-lock-bot commentedon Aug 17, 2021
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.