some notes on the template-driven approach to forms in Angular 4 applications

1. This is the alternative to reactive forms.
2. <form action="/action_page.php" method="post"
      enctype="application/x-www-form-urlencoded"> is an old school example of a form tag. None of these inline settings will be present in a form tag at a template-driven form.
3. import { FormsModules } from '@angular/forms'; needs to go at the top of the module wrapping a component that will use a template-driven form and the module needs to spec FormsModules at imports.
4. Each element inside a form must be registered. Give the tags name attribute settings and put ngModel inline at any one element, perhaps with no banana box around it.
5. <form (ngSubmit)="onWhatever(f)" #f>
   ...is an example of a form tag that would trigger the onWhatever event when a button within it that was of type="submit" was clicked. On the TypeScript side you could loop in this...
   import { ElementRef } from '@angular/core';
   ...and then have some sort of something like this...
   onWhatever(myObject: ElementRef): void {
   ...however the ElementRef here may prove frustrating to work with. A suggested revamp of this is:
   <form (ngSubmit)="onWhatever(f)" #f="ngForm">
   ...and...
   import { NgForm } from '@angular/forms';
   ...and, yes...
   onWhatever(myObject: NgForm): void {
   ...allowing one to inspect myObject.value to see key/value pairs for the form fields designated. The name attributes hydrate the keys.
6. myObject.controls will have an object wherein each of the parameters holds a FormControl for each registered element. A FormControl will have more details, like dirty, etc.
7. @ViewChild('f') myObject: NgForm; as a variable in a component would be another way to have at the local reference if you didn't want to pass it in ngSubmit
8. putting required inline at an input tag will allow for some validation in the template-driven paradigm and putting email beside it furthermore validates for an email address ...This ends up changing the true or false state of the valid setting of the given FormControl and also the valid setting overall at the form, big picture. Classes like ng-dirty, ng-touched, and ng-valid get conditionally applies to form controls and, as you might guess, ng-invalid shows up when ng-valid does not. You can have a [disabled] on the form button based on if the whole of the form is valid, and a bunch of other similar tricks based on this stuff.
9. Putting a local reference like #foo="ngModel" inline at an input tag allows for help blocks like so to appear when one screws up what one puts in the form field:
   <span class="help-block">Yikes!</span>
   ...and herein help-block is a Bootstrap class for this sort of thing.
10. At an input changing ngModel to [ngModel]="whatever" will allow for one-way data binding and set a default value based on whatever is in the whatever variable as defined back at the TypeScript side of things. Banana box two-way databinding with something like [(ngModel)]="whatever" would allow whatever to be displayed elsewhere on the form as a magic string and it would get updated real time as the user types in the input with the two-way data binding.