angular-docs-cn/aio/content/guide/forms.md

788 lines
28 KiB
Markdown
Raw Normal View History

# Forms
2017-03-31 19:57:13 -04:00
Forms are the mainstay of business applications.
2017-03-06 05:43:33 -05:00
You use forms to log in, submit a help request, place an order, book a flight,
schedule a meeting, and perform countless other data-entry tasks.
2017-03-06 05:43:33 -05:00
In developing a form, it's important to create a data-entry experience that guides the
user efficiently and effectively through the workflow.
2017-03-06 05:43:33 -05:00
Developing forms requires design skills (which are out of scope for this page), as well as framework support for
*two-way data binding, change tracking, validation, and error handling*,
which you'll learn about on this page.
2017-03-06 05:43:33 -05:00
This page shows you how to build a simple form from scratch. Along the way you'll learn how to:
2017-03-31 19:57:13 -04:00
* Build an Angular form with a component and template.
* Use `ngModel` to create two-way data bindings for reading and writing input-control values.
* Track state changes and the validity of form controls.
* Provide visual feedback using special CSS classes that track the state of the controls.
* Display validation errors to users and enable/disable form controls.
* Share information across HTML elements using template reference variables.
You can run the <live-example></live-example> in Stackblitz and download the code from there.
{@a template-driven}
2017-03-31 19:57:13 -04:00
## Template-driven forms
You can build forms by writing templates in the Angular [template syntax](guide/template-syntax) with
2017-03-06 05:43:33 -05:00
the form-specific directives and techniques described in this page.
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
You can also use a reactive (or model-driven) approach to build forms.
However, this page focuses on template-driven forms.
2017-04-10 11:51:13 -04:00
</div>
2017-03-06 05:43:33 -05:00
You can build almost any form with an Angular template&mdash;login forms, contact forms, and pretty much any business form.
You can lay out the controls creatively, bind them to data, specify validation rules and display validation errors,
conditionally enable or disable specific controls, trigger built-in visual feedback, and much more.
2017-03-06 05:43:33 -05:00
Angular makes the process easy by handling many of the repetitive, boilerplate tasks you'd
otherwise wrestle with yourself.
2017-03-06 05:43:33 -05:00
You'll learn to build a template-driven form that looks like this:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/hero-form-1.png" alt="Clean Form">
</figure>
2017-03-06 05:43:33 -05:00
The *Hero Employment Agency* uses this form to maintain personal information about heroes.
Every hero needs a job. It's the company mission to match the right hero with the right crisis.
Two of the three fields on this form are required. Required fields have a green bar on the left to make them easy to spot.
2017-03-06 05:43:33 -05:00
If you delete the hero name, the form displays a validation error in an attention-grabbing style:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/hero-form-2.png" alt="Invalid, Name Required">
</figure>
2017-03-06 05:43:33 -05:00
Note that the *Submit* button is disabled, and the "required" bar to the left of the input control changes from green to red.
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
You can customize the colors and location of the "required" bar with standard CSS.
2017-04-10 11:51:13 -04:00
</div>
2017-03-06 05:43:33 -05:00
You'll build this form in small steps:
1. Create the `Hero` model class.
1. Create the component that controls the form.
1. Create a template with the initial form layout.
2017-03-06 05:43:33 -05:00
1. Bind data properties to each form control using the `ngModel` two-way data-binding syntax.
1. Add a `name` attribute to each form-input control.
1. Add custom CSS to provide visual feedback.
2017-03-06 05:43:33 -05:00
1. Show and hide validation-error messages.
1. Handle form submission with *ngSubmit*.
1. Disable the forms *Submit* button until the form is valid.
2017-03-31 19:57:13 -04:00
## Setup
Create a new project named <code>angular-forms</code>:
<code-example language="sh" class="code-shell">
ng new angular-forms
</code-example>
## Create the Hero model class
2017-03-06 05:43:33 -05:00
As users enter form data, you'll capture their changes and update an instance of a model.
You can't lay out the form until you know what the model looks like.
A model can be as simple as a "property bag" that holds facts about a thing of application importance.
2017-03-06 05:43:33 -05:00
That describes well the `Hero` class with its three required fields (`id`, `name`, `power`)
and one optional field (`alterEgo`).
Using the Angular CLI, generate a new class named `Hero`:
<code-example language="sh" class="code-shell">
ng generate class Hero
</code-example>
With this content:
<code-example path="forms/src/app/hero.ts" title="src/app/hero.ts">
2017-03-31 19:57:13 -04:00
</code-example>
2017-03-31 19:57:13 -04:00
2017-03-06 05:43:33 -05:00
It's an anemic model with few requirements and no behavior. Perfect for the demo.
The TypeScript compiler generates a public field for each `public` constructor parameter and
2017-03-06 05:43:33 -05:00
automatically assigns the parameters value to that field when you create heroes.
2017-03-06 05:43:33 -05:00
The `alterEgo` is optional, so the constructor lets you omit it; note the question mark (?) in `alterEgo?`.
2017-03-06 05:43:33 -05:00
You can create a new hero like this:
<code-example path="forms/src/app/hero-form/hero-form.component.ts" linenums="false" region="SkyDog">
</code-example>
## Create a form component
An Angular form has two parts: an HTML-based _template_ and a component _class_
to handle data and user interactions programmatically.
2017-03-06 05:43:33 -05:00
Begin with the class because it states, in brief, what the hero editor can do.
Using the Angular CLI, generate a new component named `HeroForm`:
<code-example language="sh" class="code-shell">
ng generate component HeroForm
</code-example>
With this content:
<code-example path="forms/src/app/hero-form/hero-form.component.ts" linenums="false" title="src/app/hero-form/hero-form.component.ts (v1)" region="v1">
2017-03-31 19:57:13 -04:00
</code-example>
2017-03-31 19:57:13 -04:00
Theres nothing special about this component, nothing form-specific,
2017-03-06 05:43:33 -05:00
nothing to distinguish it from any component you've written before.
Understanding this component requires only the Angular concepts covered in previous pages.
2017-03-31 19:57:13 -04:00
* The code imports the Angular core library and the `Hero` model you just created.
* The `@Component` selector value of "hero-form" means you can drop this form in a parent template with a `<hero-form>` tag.
* The `templateUrl` property points to a separate file for the template HTML.
* You defined dummy data for `model` and `powers`, as befits a demo.
2017-03-06 05:43:33 -05:00
Down the road, you can inject a data service to get and save real data
or perhaps expose these properties as inputs and outputs
2017-03-31 19:57:13 -04:00
(see [Input and output properties](guide/template-syntax#inputs-outputs) on the
[Template Syntax](guide/template-syntax) page) for binding to a
2017-03-06 05:43:33 -05:00
parent component. This is not a concern now and these future changes won't affect the form.
2017-03-31 19:57:13 -04:00
* You added a `diagnostic` property to return a JSON representation of the model.
2017-03-06 05:43:33 -05:00
It'll help you see what you're doing during development; you've left yourself a cleanup note to discard it later.
## Revise *app.module.ts*
2017-03-06 05:43:33 -05:00
`app.module.ts` defines the application's root module. In it you identify the external modules you'll use in the application
and declare the components that belong to this module, such as the `HeroFormComponent`.
2017-03-06 05:43:33 -05:00
Because template-driven forms are in their own module, you need to add the `FormsModule` to the array of
`imports` for the application module before you can use forms.
Update it with the following:
2017-03-31 19:57:13 -04:00
<code-example path="forms/src/app/app.module.ts" title="src/app/app.module.ts">
</code-example>
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
There are two changes:
2017-03-31 19:57:13 -04:00
1. You import `FormsModule`.
2017-03-31 19:57:13 -04:00
1. You add the `FormsModule` to the list of `imports` defined in the `@NgModule` decorator. This gives the application
access to all of the template-driven forms features, including `ngModel`.
2017-04-10 11:51:13 -04:00
</div>
2017-04-10 11:51:13 -04:00
<div class="alert is-important">
If a component, directive, or pipe belongs to a module in the `imports` array, _don't_ re-declare it in the `declarations` array.
If you wrote it and it should belong to this module, _do_ declare it in the `declarations` array.
2017-04-10 11:51:13 -04:00
</div>
## Revise *app.component.html*
2017-03-06 05:43:33 -05:00
`AppComponent` is the application's root component. It will host the new `HeroFormComponent`.
Replace the contents of its template with the following:
<code-example path="forms/src/app/app.component.html" title="src/app/app.component.html">
</code-example>
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
There are only two changes.
The `template` is simply the new element tag identified by the component's `selector` property.
This displays the hero form when the application component is loaded.
Don't forget to remove the `name` field from the class body as well.
2017-04-10 11:51:13 -04:00
</div>
## Create an initial HTML form template
Update the template file with the following contents:
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="start" title="src/app/hero-form/hero-form.component.html">
</code-example>
2017-03-06 05:43:33 -05:00
The language is simply HTML5. You're presenting two of the `Hero` fields, `name` and `alterEgo`, and
opening them up for user input in input boxes.
The *Name* `<input>` control has the HTML5 `required` attribute;
the *Alter Ego* `<input>` control does not because `alterEgo` is optional.
2017-03-06 05:43:33 -05:00
You added a *Submit* button at the bottom with some classes on it for styling.
2017-03-06 05:43:33 -05:00
*You're not using Angular yet*. There are no bindings or extra directives, just layout.
<div class="l-sub-section">
In template driven forms, if you've imported `FormsModule`, you don't have to do anything
to the `<form>` tag in order to make use of `FormsModule`. Continue on to see how this works.
</div>
The `container`, `form-group`, `form-control`, and `btn` classes
2017-03-06 05:43:33 -05:00
come from [Twitter Bootstrap](http://getbootstrap.com/css/). These classes are purely cosmetic.
Bootstrap gives the form a little style.
2017-04-10 11:51:13 -04:00
<div class="callout is-important">
<header>
Angular forms don't require a style library
</header>
Angular makes no use of the `container`, `form-group`, `form-control`, and `btn` classes or
the styles of any external library. Angular apps can use any CSS library or none at all.
2017-04-10 11:51:13 -04:00
</div>
To add the stylesheet, open `styles.css` and add the following import line at the top:
2017-03-31 19:57:13 -04:00
<code-example path="forms/src/styles.1.css" linenums="false" title="src/styles.css">
</code-example>
## Add powers with _*ngFor_
2017-03-06 05:43:33 -05:00
The hero must choose one superpower from a fixed list of agency-approved powers.
You maintain that list internally (in `HeroFormComponent`).
2017-03-06 05:43:33 -05:00
You'll add a `select` to the
form and bind the options to the `powers` list using `ngFor`,
a technique seen previously in the [Displaying Data](guide/displaying-data) page.
Add the following HTML *immediately below* the *Alter Ego* group:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (powers)" region="powers">
</code-example>
This code repeats the `<option>` tag for each power in the list of powers.
The `pow` template input variable is a different power in each iteration;
2017-03-06 05:43:33 -05:00
you display its name using the interpolation syntax.
{@a ngModel}
2017-03-31 19:57:13 -04:00
## Two-way data binding with _ngModel_
Running the app right now would be disappointing.
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/hero-form-3.png" alt="Early form with no binding">
</figure>
2017-03-31 19:57:13 -04:00
2017-03-06 05:43:33 -05:00
You don't see hero data because you're not binding to the `Hero` yet.
You know how to do that from earlier pages.
[Displaying Data](guide/displaying-data) teaches property binding.
[User Input](guide/user-input) shows how to listen for DOM events with an
event binding and how to update a component property with the displayed value.
2017-03-06 05:43:33 -05:00
Now you need to display, listen, and extract at the same time.
2017-03-06 05:43:33 -05:00
You could use the techniques you already know, but
instead you'll use the new `[(ngModel)]` syntax, which
makes binding the form to the model easy.
Find the `<input>` tag for *Name* and update it like this:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModelName-1">
</code-example>
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
You added a diagnostic interpolation after the input tag
so you can see what you're doing.
You left yourself a note to throw it away when you're done.
2017-04-10 11:51:13 -04:00
</div>
Focus on the binding syntax: `[(ngModel)]="..."`.
You need one more addition to display the data. Declare
a template variable for the form. Update the `<form>` tag with
`#heroForm="ngForm"` as follows:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="template-variable">
</code-example>
The variable `heroForm` is now a reference to the `NgForm` directive that governs the form as a whole.
<div class="l-sub-section">
{@a ngForm}
### The _NgForm_ directive
What `NgForm` directive?
You didn't add an [NgForm](api/forms/NgForm) directive.
Angular did. Angular automatically creates and attaches an `NgForm` directive to the `<form>` tag.
The `NgForm` directive supplements the `form` element with additional features.
It holds the controls you created for the elements with an `ngModel` directive
and `name` attribute, and monitors their properties, including their validity.
It also has its own `valid` property which is true only *if every contained
control* is valid.
</div>
2017-03-06 05:43:33 -05:00
If you ran the app now and started typing in the *Name* input box,
adding and deleting characters, you'd see them appear and disappear
from the interpolated text.
2017-03-06 05:43:33 -05:00
At some point it might look like this:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/ng-model-in-action.png" alt="ngModel in action">
</figure>
The diagnostic is evidence that values really are flowing from the input box to the model and
back again.
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
That's *two-way data binding*.
For more information, see
[Two-way binding with NgModel](guide/template-syntax#ngModel) on the
the [Template Syntax](guide/template-syntax) page.
2017-04-10 11:51:13 -04:00
</div>
2017-03-06 05:43:33 -05:00
Notice that you also added a `name` attribute to the `<input>` tag and set it to "name",
which makes sense for the hero's name. Any unique value will do, but using a descriptive name is helpful.
Defining a `name` attribute is a requirement when using `[(ngModel)]` in combination with a form.
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
Internally, Angular creates `FormControl` instances and
registers them with an `NgForm` directive that Angular attached to the `<form>` tag.
Each `FormControl` is registered under the name you assigned to the `name` attribute.
Read more in the previous section, [The NgForm directive](guide/forms#ngForm).
2017-04-10 11:51:13 -04:00
</div>
2017-03-06 05:43:33 -05:00
Add similar `[(ngModel)]` bindings and `name` attributes to *Alter Ego* and *Hero Power*.
You'll ditch the input box binding message
and add a new binding (at the top) to the component's `diagnostic` property.
2017-03-06 05:43:33 -05:00
Then you can confirm that two-way data binding works *for the entire hero model*.
2017-03-06 05:43:33 -05:00
After revision, the core of the form should look like this:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModel-2">
</code-example>
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
* Each input element has an `id` property that is used by the `label` element's `for` attribute
to match the label to its input control.
* Each input element has a `name` property that is required by Angular forms to register the control with the form.
2017-04-10 11:51:13 -04:00
</div>
2017-03-06 05:43:33 -05:00
If you run the app now and change every hero model property, the form might display like this:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/ng-model-in-action-2.png" alt="ngModel in action">
</figure>
The diagnostic near the top of the form
2017-03-06 05:43:33 -05:00
confirms that all of your changes are reflected in the model.
2017-03-06 05:43:33 -05:00
*Delete* the `{{diagnostic}}` binding at the top as it has served its purpose.
## Track control state and validity with _ngModel_
2017-03-06 05:43:33 -05:00
Using `ngModel` in a form gives you more than just two-way data binding. It also tells
you if the user touched the control, if the value changed, or if the value became invalid.
The *NgModel* directive doesn't just track state; it updates the control with special Angular CSS classes that reflect the state.
2017-03-06 05:43:33 -05:00
You can leverage those class names to change the appearance of the control.
<table>
<tr>
<th>
State
</th>
<th>
Class if true
</th>
<th>
Class if false
</th>
</tr>
<tr>
<td>
2017-03-06 05:43:33 -05:00
The control has been visited.
</td>
<td>
<code>ng-touched</code>
</td>
<td>
<code>ng-untouched</code>
</td>
</tr>
<tr>
<td>
2017-03-06 05:43:33 -05:00
The control's value has changed.
</td>
<td>
<code>ng-dirty</code>
</td>
<td>
<code>ng-pristine</code>
</td>
</tr>
<tr>
<td>
2017-03-06 05:43:33 -05:00
The control's value is valid.
</td>
<td>
<code>ng-valid</code>
</td>
<td>
<code>ng-invalid</code>
</td>
</tr>
</table>
2017-03-31 19:57:13 -04:00
Temporarily add a [template reference variable](guide/template-syntax#ref-vars) named `spy`
to the _Name_ `<input>` tag and use it to display the input's CSS classes.
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="ngModelName-2">
</code-example>
2017-03-06 05:43:33 -05:00
Now run the app and look at the _Name_ input box.
Follow these steps *precisely*:
1. Look but don't touch.
1. Click inside the name box, then click outside it.
1. Add slashes to the end of the name.
1. Erase the name.
The actions and effects are as follows:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/control-state-transitions-anim.gif" alt="Control State Transition">
</figure>
2017-03-06 05:43:33 -05:00
You should see the following transitions and class names:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/ng-control-class-changes.png" alt="Control state transitions">
</figure>
2017-03-06 05:43:33 -05:00
The `ng-valid`/`ng-invalid` pair is the most interesting, because you want to send a
strong visual signal when the values are invalid. You also want to mark required fields.
To create such visual feedback, add definitions for the `ng-*` CSS classes.
2017-03-06 05:43:33 -05:00
*Delete* the `#spy` template reference variable and the `TODO` as they have served their purpose.
## Add custom CSS for visual feedback
2017-03-06 05:43:33 -05:00
You can mark required fields and invalid data at the same time with a colored bar
on the left of the input box:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/validity-required-indicator.png" alt="Invalid Form">
</figure>
2017-03-06 05:43:33 -05:00
You achieve this effect by adding these class definitions to a new `forms.css` file
that you add to the project as a sibling to `index.html`:
<code-example path="forms/src/assets/forms.css" title="src/assets/forms.css">
</code-example>
Update the `<head>` of `index.html` to include this style sheet:
<code-example path="forms/src/index.html" linenums="false" title="src/index.html (styles)" region="styles">
</code-example>
## Show and hide validation error messages
2017-03-06 05:43:33 -05:00
You can improve the form. The _Name_ input box is required and clearing it turns the bar red.
That says something is wrong but the user doesn't know *what* is wrong or what to do about it.
Leverage the control's state to reveal a helpful message.
2017-03-06 05:43:33 -05:00
When the user deletes the name, the form should look like this:
docs(aio): image sweep (#16609) * fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
2017-05-09 18:53:32 -04:00
<figure>
<img src="generated/images/guide/forms/name-required-error.png" alt="Name required">
</figure>
2017-03-06 05:43:33 -05:00
To achieve this effect, extend the `<input>` tag with the following:
2017-03-31 19:57:13 -04:00
* A [template reference variable](guide/template-syntax#ref-vars).
* The "*is required*" message in a nearby `<div>`, which you'll display only if the control is invalid.
2017-03-06 05:43:33 -05:00
Here's an example of an error message added to the _name_ input box:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="name-with-error-msg">
</code-example>
2017-03-06 05:43:33 -05:00
You need a template reference variable to access the input box's Angular control from within the template.
Here you created a variable called `name` and gave it the value "ngModel".
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
Why "ngModel"?
A directive's [exportAs](api/core/Directive) property
tells Angular how to link the reference variable to the directive.
You set `name` to `ngModel` because the `ngModel` directive's `exportAs` property happens to be "ngModel".
2017-04-10 11:51:13 -04:00
</div>
2017-03-06 05:43:33 -05:00
You control visibility of the name error message by binding properties of the `name`
control to the message `<div>` element's `hidden` property.
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (hidden-error-msg)" region="hidden-error-msg">
</code-example>
2017-03-06 05:43:33 -05:00
In this example, you hide the message when the control is valid or pristine;
"pristine" means the user hasn't changed the value since it was displayed in this form.
2017-03-06 05:43:33 -05:00
This user experience is the developer's choice. Some developers want the message to display at all times.
If you ignore the `pristine` state, you would hide the message only when the value is valid.
If you arrive in this component with a new (blank) hero or an invalid hero,
you'll see the error message immediately, before you've done anything.
2017-04-10 11:51:13 -04:00
Some developers want the message to display only when the user makes an invalid change.
Hiding the message while the control is "pristine" achieves that goal.
You'll see the significance of this choice when you add a new hero to the form.
2017-03-06 05:43:33 -05:00
The hero *Alter Ego* is optional so you can leave that be.
Hero *Power* selection is required.
2017-03-06 05:43:33 -05:00
You can add the same kind of error handling to the `<select>` if you want,
but it's not imperative because the selection box already constrains the
power to valid values.
2017-03-06 05:43:33 -05:00
Now you'll add a new hero in this form.
Place a *New Hero* button at the bottom of the form and bind its click event to a `newHero` component method.
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="new-hero-button-no-reset" title="src/app/hero-form/hero-form.component.html (New Hero button)">
</code-example>
<code-example path="forms/src/app/hero-form/hero-form.component.ts" region="new-hero" title="src/app/hero-form/hero-form.component.ts (New Hero method)" linenums="false">
</code-example>
Run the application again, click the *New Hero* button, and the form clears.
The *required* bars to the left of the input box are red, indicating invalid `name` and `power` properties.
That's understandable as these are required fields.
2017-03-06 05:43:33 -05:00
The error messages are hidden because the form is pristine; you haven't changed anything yet.
Enter a name and click *New Hero* again.
2017-03-06 05:43:33 -05:00
The app displays a _Name is required_ error message.
You don't want error messages when you create a new (empty) hero.
Why are you getting one now?
Inspecting the element in the browser tools reveals that the *name* input box is _no longer pristine_.
2017-03-06 05:43:33 -05:00
The form remembers that you entered a name before clicking *New Hero*.
Replacing the hero object *did not restore the pristine state* of the form controls.
2017-03-06 05:43:33 -05:00
You have to clear all of the flags imperatively, which you can do
by calling the form's `reset()` method after calling the `newHero()` method.
<code-example path="forms/src/app/hero-form/hero-form.component.html" region="new-hero-button-form-reset" title="src/app/hero-form/hero-form.component.html (Reset the form)">
</code-example>
2017-03-06 05:43:33 -05:00
Now clicking "New Hero" resets both the form and its control flags.
## Submit the form with _ngSubmit_
The user should be able to submit this form after filling it in.
2017-03-06 05:43:33 -05:00
The *Submit* button at the bottom of the form
does nothing on its own, but it will
trigger a form submit because of its type (`type="submit"`).
A "form submit" is useless at the moment.
To make it useful, bind the form's `ngSubmit` event property
to the hero form component's `onSubmit()` method:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (ngSubmit)" region="ngSubmit">
</code-example>
You'd already defined a template reference variable,
`#heroForm`, and initialized it with the value "ngForm".
Now, use that variable to access the form with the Submit button.
2017-03-31 19:57:13 -04:00
2017-03-06 05:43:33 -05:00
You'll bind the form's overall validity via
the `heroForm` variable to the button's `disabled` property
using an event binding. Here's the code:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (submit-button)" region="submit-button">
</code-example>
If you run the application now, you find that the button is enabled&mdash;although
2017-03-06 05:43:33 -05:00
it doesn't do anything useful yet.
2017-03-06 05:43:33 -05:00
Now if you delete the Name, you violate the "required" rule, which
is duly noted in the error message.
2017-03-06 05:43:33 -05:00
The *Submit* button is also disabled.
2017-03-06 05:43:33 -05:00
Not impressed? Think about it for a moment. What would you have to do to
wire the button's enable/disabled state to the form's validity without Angular's help?
2017-03-06 05:43:33 -05:00
For you, it was as simple as this:
1. Define a template reference variable on the (enhanced) form element.
2. Refer to that variable in a button many lines away.
## Toggle two form regions (extra credit)
Submitting the form isn't terribly dramatic at the moment.
2017-04-10 11:51:13 -04:00
<div class="l-sub-section">
An unsurprising observation for a demo. To be honest,
jazzing it up won't teach you anything new about forms.
But this is an opportunity to exercise some of your newly won
binding skills.
If you aren't interested, skip to this page's conclusion.
2017-04-10 11:51:13 -04:00
</div>
2017-03-06 05:43:33 -05:00
For a more strikingly visual effect,
hide the data entry area and display something else.
2017-03-06 05:43:33 -05:00
Wrap the form in a `<div>` and bind
its `hidden` property to the `HeroFormComponent.submitted` property.
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="edit-div">
</code-example>
The main form is visible from the start because the
2017-03-06 05:43:33 -05:00
`submitted` property is false until you submit the form,
as this fragment from the `HeroFormComponent` shows:
<code-example path="forms/src/app/hero-form/hero-form.component.ts" linenums="false" title="src/app/hero-form/hero-form.component.ts (submitted)" region="submitted">
</code-example>
2017-03-06 05:43:33 -05:00
When you click the *Submit* button, the `submitted` flag becomes true and the form disappears
as planned.
Now the app needs to show something else while the form is in the submitted state.
2017-03-06 05:43:33 -05:00
Add the following HTML below the `<div>` wrapper you just wrote:
<code-example path="forms/src/app/hero-form/hero-form.component.html" linenums="false" title="src/app/hero-form/hero-form.component.html (excerpt)" region="submitted">
</code-example>
2017-03-06 05:43:33 -05:00
There's the hero again, displayed read-only with interpolation bindings.
This `<div>` appears only while the component is in the submitted state.
2017-03-06 05:43:33 -05:00
The HTML includes an *Edit* button whose click event is bound to an expression
that clears the `submitted` flag.
2017-03-06 05:43:33 -05:00
When you click the *Edit* button, this block disappears and the editable form reappears.
## Summary
2017-03-06 05:43:33 -05:00
The Angular form discussed in this page takes advantage of the following
framework features to provide support for data modification, validation, and more:
2017-03-31 19:57:13 -04:00
* An Angular HTML form template.
* A form component class with a `@Component` decorator.
* Handling form submission by binding to the `NgForm.ngSubmit` event property.
* Template-reference variables such as `#heroForm` and `#name`.
* `[(ngModel)]` syntax for two-way data binding.
* The use of `name` attributes for validation and form-element change tracking.
* The reference variables `valid` property on input controls to check if a control is valid and show/hide error messages.
* Controlling the *Submit* button's enabled state by binding to `NgForm` validity.
* Custom CSS classes that provide visual feedback to users about invalid controls.
Heres the code for the final version of the application:
<code-tabs>
<code-pane title="hero-form/hero-form.component.ts" path="forms/src/app/hero-form/hero-form.component.ts" region="final">
</code-pane>
<code-pane title="hero-form/hero-form.component.html" path="forms/src/app/hero-form/hero-form.component.html" region="final">
</code-pane>
<code-pane title="hero.ts" path="forms/src/app/hero.ts">
</code-pane>
<code-pane title="app.module.ts" path="forms/src/app/app.module.ts">
</code-pane>
<code-pane title="app.component.html" path="forms/src/app/app.component.html">
</code-pane>
<code-pane title="app.component.ts" path="forms/src/app/app.component.ts">
</code-pane>
<code-pane title="main.ts" path="forms/src/main.ts">
</code-pane>
<code-pane title="forms.css" path="forms/src/assets/forms.css">
</code-pane>
</code-tabs>