docs: add sample usage of the FormArray API for reactive forms

[maequise]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

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?

Missing a more concrete sample on how to use the FormArray API

Issue Number: #53705

What is the new behavior?

Include a more concrete sample of how to use the FormArray API on the site into the guide of reactive forms

Does this PR introduce a breaking change?

• Yes
• No

Other information

[jessicajaniuk]

@maequise Looks like your commit message is causing the lint to fail. It's very close though. Run git commit --amend and change your commit message to docs: add sample usage of the FormArray API for reactive forms, and then force push. That'll fix it.

[jessicajaniuk]

@dylhunn Can you review the content here?

[github-actions]

Deployed adev-preview for 9a09d02 to: https://ng-dev-previews-fw--pr-angular-angular-54138-adev-prev-6sk3qzg2.web.app

Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt.

[sonukapoor]

Do we need this comment?

[maequise]

This comment is not revelant, I certainly forgot to remove it. If need I can remove it and make a new push.

[sonukapoor]

Yes, remove anything that is not relevant.

[sonukapoor]

Suggested change

	In a more concrete sample, we can imagine the following use case. You are application needs a basic form, with known information, but the user has the ability to add more or less sub-form.
	In a more concrete sample, we can imagine the following use case. Your application needs a basic form, with known information, but the user has the ability to add more or less sub-form.

[sonukapoor]

Suggested change

	Tip: If you watch the HTML template, you will notice that the access to the `FormArray` is not from the `FormGroup` directly with the **get()** method. We will define a getter method.
	Tip: If you watch the HTML template, you will notice that the access to the `FormArray` is not from the `FormGroup` but directly using the **get()** method. We will define a getter method.

[sonukapoor]

Suggested change

	With this method, when the user click on the button, it is adding a new `FormGroup` in the `FormArray`. When adding a new entry, the template will be updated.
	With this method, when the user clicks on the button, it is adding a new `FormGroup` in the `FormArray`. When adding a new entry, the template will be updated.

[sonukapoor]

Suggested change

	We can add entries to the `FormArray` but we should be able to remove a specific entry. The `FormArray` has the **removeAt()** method that permits to delete a specific index of the `FormArray`.
	We can now add entries to the `FormArray` but we should also be able to remove a specific entry. The `FormArray` has the **removeAt()** method that permits to delete a specific index of the `FormArray`.

[maequise]

@sonukapoor thank you for the review, I made the corrections (the last forced "push" was because I missed one edit)

[MarkTechson]

I really appreciate this work but this should really be a tutorial or code example, not necessarily an additional guide. I would also add here that we should consider revamping this guide and converting it to an issue that we should track and keep track of this work.

@twerske can you chime in on this?

[maequise]

I really appreciate this work but this should really be a tutorial or code example, not necessarily an additional guide. I would also add here that we should consider revamping this guide and converting it to an issue that we should track and keep track of this work.

@twerske can you chime in on this?

I was thinking earlier in the afternoon adding a tutorial on the suject.

[twerske]

I really appreciate this work but this should really be a tutorial or code example, not necessarily an additional guide. I would also add here that we should consider revamping this guide and converting it to an issue that we should track and keep track of this work.

@twerske can you chime in on this?

I agree. This should be a tutorial not a guide since it's a walk through of a code example.

[maequise]

As suggested, I made a tutorial for this part and removed the guide part.