To help separate some of the data and logic from the Vue component, create a new Typescript class for the form data called
The form request is part of the API and needs to be placed in
Fields on the request object should be public and nullable and default to null on object creation so that Vue can read/write the data.
With the new class in place, we have a clear contract of what data can be sent to the API endpoint.
In an ideal world, all of the Typescript classes for the request objects and API endpoints would be generated by something like OpenAPI or Swagger and the definitions of the endpoints defined in the server side code.
OpenAPI and Swagger is not part of the scope of this challenge.
When your request object is submitted - it should not send through any data other than the form fields.
Update the endpoint¶
For our request object to work, we will need to update the endpoint we use in the
Update the submit method to only accept objects of type
Add a reset button that sets all values back to the default (
To accomplish this, add a
reset method to the request object that sets all the properties to
Extend the form¶
Add a text area
message after the last form input for a contact message. Text area inputs work the same way as normal text inputs
and the same steps can be repeated from when the phone input was added.
The textarea is a required input - it must use the same Bootstrap classes as the other form inputs to stay consistent.
You will need to add the new field to your request object and bind the new input in your
In the real world, most if not all of the validation would be performed server side, this would mean there is a single source of truth on what is and is not valid in a project.
To keep things simple, we will continue to use frontend validation going forward.
We need to refactor our validation as it is still on the form component. We need to move the logic to the new
Create a new method on the
request object that returns a
boolean to indicate whether the validation has passed or failed.