Form Fields

Form components are individual elements that make up a form, such as text fields, checkboxes, radio buttons, select fields, text areas and buttons. They allow user input, selection and actions.

Marigold has a set of form components that you can use to build your form.

• Autocomplete
• Button
• Calendar
• Checkbox
• ComboBox
• DateField
• DatePicker
• Multiselect
• NumberField
• Radio
• SearchField
• Select
• Slider
• Switch
• TextArea
• TextField

Anatomy

An accessible form field includes a clear label associated with its corresponding form control (<input>, <select>, ...). Additional guidance is provided by a help text, which can give additional context or instructions or display a descriptive messages.

Marigold's form components allow to set these properties like shown below. All form components allow to set a label, description and errorMessages besides some additional control-specific props.

Usage

Form fields are essential for collecting user input, making selections, or triggering actions. They should be designed for clarity and accessibility to ensure a smooth user experience. Proper use of labels, help texts, and error messages ensures users understand each field's purpose and can interact with it correctly. Accessible form fields also improve usability for people using assistive technologies.

Label

Labels are essential for accessibility and clarity, ensuring that each form field is clearly defined. In most cases, a label should be provided for each form control to describe the expected input. They are used when fields require specific instructions (e.g., name, email, or password should have a clear label).

However, labels might not be necessary when the purpose of the input is obvious from context. For example, in search bars, the purpose of the input is clear. In these cases, it is still important to provide an aria-label attribute to ensure that users with assistive technologies can understand the input's purpose, maintaining accessibility for all users.

Placeholder

Placeholder text is a short hint displayed inside an input field before a user enters a value. To save space, placeholder text is often used instead of a label, as shown in the first example. This is problematic for the following reasons:

• Placeholder text disappears once a person starts filling in an input field, causing some to forget what the field was for
• Some might miss or skip fields with placeholder text, as it can look like the field has already been pre-filled.
• Placeholder text colour contrast is almost always inaccessible, as it’s very light by design. This means many will struggle to read the label.

Help Text

Help Text should be used to provide additional clarification or instructions when the label alone isn't enough to explain the input (e.g., complex or uncommon fields). It’s helpful for explaining specific formats or validation rules. However, it shouldn't be used when the input is straightforward and the label is clear, as it can clutter the form and overwhelm the user with unnecessary details.

Field States

Form components often exist in various states to indicate how they should behave or be interacted with. These states provide important context for users and ensure proper handling of inputs in different senarios. Below are the common field states used in forms.

Disabled State

Disabled input fields are non-interactive and signal that they are temporarily unavailable. They are typically used when the input is irrelevant based on prior user choices or when a prerequisite action is required. To avoid confusion, it's important to provide clear context or messaging explaining why the field is disabled, ensuring users understand when and how the input will become available.

Required State

Required fields must be completed before form submission.

Error State

Fields in an error state indicate that the entered value is invalid or incorrect. Error messages and visual feedback.

ReadOnly State

Read-only fields display data that users can view but not modify. They are commonly used for displaying information that is fixed or derived from other inputs. It's important to provide context or a clear explanation for why a field is read-only, so users understand its purpose and why it cannot be changed.

Validation

Form validation is a crucial aspect of web development, ensuring that user input meets the required criteria before it is processed. Validation helps maintain data accuracy, consistency, and security by guiding users to correct any errors in their inputs.

HTML forms enable developers to collect and submit user input on web pages, and they include built-in validation mechanisms through attributes like required and input types such as email or number. These attributes allow browsers to provide immediate feedback when inputs are invalid, improving the user experience.

Marigold's components seamlessly integrate with HTML forms, offering a developer-friendly solution for input data validation. It supports native attributes like required and validation based on input types. Additionally, Marigold's form elements allow custom validation functions to extend the browser's validation capabilities.

Built-in / Native Form Validation

The most straightforward way to validate user input is to use the built-in constraint validation. Marigold's form components work seamlessly with this API, allowing you to set constraints for each field. The browser will check these constraints on blur (user leaves the field) or when the form is submitted.

Marigold's form components utilize the same API as native HTML forms. Yet, the browser won't display error messages; instead, they will be styled to seamlessly blend with the overall design.

Here is an email subscription form. If you submit it without entering an email address or if the entered email address is invalid, an error will be displayed:

Custom Message

While browser-provided error messages are helpful, they might not be very descriptive. In such instances, you have the flexibility to override them by using a function with the errorMessages prop of the field. This allows you to display custom error messages tailored to better describe the occured error.

The example below customizes the default error messages for an unfilled required field. It's important to note that you only need to override the messages you want to; any unmodified aspects will fallback to the browser-provided messages.

Custom Validation

When the native validation options are insufficient or not ideal, it's also possible to entirely override them and implement a custom validation method by using the validate prop of a field. Ensure that the prop is assigned a function that returns one or more error messages. If there are multiple error messages, they should be provided as a string array.

The below example demonstrates a more sophisticated method for validating email addresses. The validation will always display the custom error messages. There is no separate message if the field is left empty.

Real-time Validation

By default, validation errors are shown to the user after the value is confirmed, for example, when they click away (on blur) or upon submitting the form. This prevents the user from being confused by irrelevant errors while they are still in the process of entering a value.

In specific situations though, choosing real-time validation proves beneficial, for example when enforcing certain password requirements. To enable real-time validation, control the field and configure the error and errorMessages props accordingly.

Here's an example where real-time validation is employed to check password requirements, immediately informing the user when a criteria is met.

Handling Server Errors

Server-side validation is essential alongside client-side validation to ensure robust and secure applications. While client-side validation offers immediate feedback and a smoother user experience, server-side validation is crucial for maintaining data integrity and security.

Marigold supports displaying server validation errors via the validationErrors prop on the <Form> component. The errors should be an object, where each field's nameis mapped to a string or array of strings representing error messages. The errors are immediately shown to the user upon setting the validationErrors and are cleared when the user modifies the field's value.

The subscription example now involves sending and receiving the provided email to and from the server. While most email subscriptions will be successful, attempting to use support@reservix.de serves as a negative example, triggering an error response from the server.

Related