Skip to content

fix(forms): typed argument for FormBuilder group #26985

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

Closed
wants to merge 1 commit into from

Conversation

cexbrayat
Copy link
Member

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

The refactored group method of FormBuilder introduced by #24599 allows two types of options but the signature doesn't show it.

What is the new behavior?

It adds a stricter type to the refactored group method.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

cc @kara

Sorry, something went wrong.

Copy link
Contributor

@IgorMinar IgorMinar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kara can you take a look too please? Thanks

validators = legacyOrOpts.validators != null ? legacyOrOpts.validators : null;
asyncValidators =
legacyOrOpts.asyncValidators != null ? legacyOrOpts.asyncValidators : null;
updateOn = legacyOrOpts.updateOn != null ? legacyOrOpts.updateOn : undefined;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need all the ternary operator checks? Couldn't we use object destructuring instead? It seems that we are doing a lot of work no obvious reason.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To support the legacy options of shape

{
  asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null;
  validator?: ValidatorFn | ValidatorFn[] | null;
}

as well as AbstractControlOptions with similar but slightly differently named properties (notice the ending s)

{
  asyncValidators?: AsyncValidatorFn | AsyncValidatorFn[] | null;
  validators?: ValidatorFn | ValidatorFn[] | null;
  updateOn?: 'change' | 'blur' | 'submit';
}

FormGroup {
group(
controlsConfig: {[key: string]: any},
legacyOrOpts: AbstractControlOptions|{[key: string]: any}|null = null): FormGroup {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm now realizing that this param name is very confusing. I think we should just call it options and document that it has two shapes one of which is deprecated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me

@@ -205,7 +205,7 @@ export declare class FormBuilder {
control(formState: any, validatorOrOpts?: ValidatorFn | ValidatorFn[] | AbstractControlOptions | null, asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null): FormControl;
group(controlsConfig: {
[key: string]: any;
}, legacyOrOpts?: {
}, legacyOrOpts?: AbstractControlOptions | {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this. Change. At minimum from docs perspective it makes the api cleaner.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, in terms of types, there isn't really a difference, but I do think this is helpful documentation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@IgorMinar Should legacyOrOpts be replaced with options here, too?

@IgorMinar IgorMinar requested a review from kara November 8, 2018 09:19
@LayZeeDK
Copy link
Contributor

LayZeeDK commented Nov 12, 2018

@kara Note that type declarations were previously made less strict because of internal Google tests.

Copy link
Contributor

@kara kara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (once Igor's comments are addressed)

FormGroup {
group(
controlsConfig: {[key: string]: any},
legacyOrOpts: AbstractControlOptions|{[key: string]: any}|null = null): FormGroup {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me

@kara kara added the action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews label Nov 21, 2018
@cexbrayat
Copy link
Member Author

@kara Thank you for your review. I renamed legacyOrOpts to options as requested by @IgorMinar and amended the commit.

Copy link
Contributor

@skreborn skreborn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just casual nitpicking following up on the legacyOrOpts -> options change.

updateOn = legacyOrOpts.updateOn != null ? legacyOrOpts.updateOn : undefined;
if (options != null) {
if (isAbstractControlOptions(options)) {
// `legacyOrOpts` are `AbstractControlOptions`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

legacyOrOpts should also be replaced in the comment here since it was renamed to options.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, thanks for catching that. I fixed.

asyncValidators = options.asyncValidators != null ? options.asyncValidators : null;
updateOn = options.updateOn != null ? options.updateOn : undefined;
} else {
// `legacyOrOpts` are legacy form group options
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

@@ -205,7 +205,7 @@ export declare class FormBuilder {
control(formState: any, validatorOrOpts?: ValidatorFn | ValidatorFn[] | AbstractControlOptions | null, asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null): FormControl;
group(controlsConfig: {
[key: string]: any;
}, legacyOrOpts?: {
}, legacyOrOpts?: AbstractControlOptions | {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@IgorMinar Should legacyOrOpts be replaced with options here, too?

@LayZeeDK
Copy link
Contributor

Please note my comment and make sure that you don't recreate the issue that broke your internal Google tests, @kara and @IgorMinar
#26985 (comment)

This is the reason types were made less strict and correct.

@kara
Copy link
Contributor

kara commented Nov 21, 2018

@LayZeeDK This PR does not actually make any meaningful type changes because AbstractControlOptions is a subtype of {[key:string]: any} type and does not replace it in the signature. It's mostly being added for documentation purposes.

@kara
Copy link
Contributor

kara commented Nov 21, 2018

presubmit

Copy link
Contributor

@kara kara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kara kara assigned IgorMinar and unassigned cexbrayat Nov 21, 2018
@kara kara added action: review The PR is still awaiting reviews from at least one requested reviewer target: major This PR is targeted for the next major release and removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews labels Nov 21, 2018
@kara
Copy link
Contributor

kara commented Nov 21, 2018

@IgorMinar Can you take another look?

@LayZeeDK
Copy link
Contributor

LayZeeDK commented Nov 22, 2018

So Angular 7.1.0 landed. This will be in which version now? 7.2.0? 7.1.x?

Copy link
Contributor

@IgorMinar IgorMinar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm. Thanks for being patient!

@IgorMinar IgorMinar added the action: merge The PR is ready for merge by the caretaker label Dec 7, 2018
@IgorMinar IgorMinar removed the action: review The PR is still awaiting reviews from at least one requested reviewer label Dec 7, 2018
@alxhub alxhub closed this in b0c7561 Dec 7, 2018
ngfelixl pushed a commit to ngfelixl/angular that referenced this pull request Jan 28, 2019
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: forms cla: yes target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants