Form validation in Svelte - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output when submitting a form with empty required fields?

Consider this Svelte form with two required inputs. What happens when the user submits the form without filling any fields?

Svelte

<script>
  let name = '';
  let email = '';
  let error = '';
  function handleSubmit() {
    if (!name || !email) {
      error = 'Please fill all required fields.';
    } else {
      error = '';
    }
  }
</script>
<form on:submit|preventDefault={handleSubmit} aria-label="User form">
  <label for="name">Name:</label>
  <input id="name" type="text" bind:value={name} aria-required="true" />
  <label for="email">Email:</label>
  <input id="email" type="email" bind:value={email} aria-required="true" />
  <button type="submit">Submit</button>
  {#if error}
    <p role="alert" style="color: red;">{error}</p>
  {/if}
</form>

A The form shows the error message 'Please fill all required fields.' below the button.

B The browser shows a native tooltip error for the first empty required input.

C The form submits successfully and clears the inputs.

D Nothing happens; the form silently fails without feedback.

💡 Hint

Look at the handleSubmit function and the error variable usage.

The handleSubmit function checks if name or email is empty. If so, it sets the error message, which is shown below the button. The form does not submit because of preventDefault.

📝 Syntax

intermediate

Which option correctly validates an email input in Svelte?

Which code snippet correctly updates an emailError message when the email input is invalid?

Svelte

<script>
  let email = '';
  let emailError = '';
  function validateEmail() {
    // validation logic here
  }
</script>
<input type="email" bind:value={email} on:input={validateEmail} aria-describedby="email-error" />
<p id="email-error" role="alert" style="color: red;">{emailError}</p>

A

function validateEmail() {
  emailError = email.match(/^[^@]+@[^@]+\.[^@]+$/) ? '' : 'Invalid email address';
}

B

function validateEmail() {
  emailError = email.includes('@') ? '' : 'Invalid email address';
}

C

function validateEmail() {
  if (!email.includes('@')) {
    emailError = 'Invalid email address';
  } else {
    emailError = '';
  }
}

D

function validateEmail() {
  emailError = email.length > 5 ? '' : 'Invalid email address';
}

💡 Hint

Check which option uses a proper email pattern to validate.

Option A uses a regular expression to check the email format correctly. Option A only checks for '@' presence, which is insufficient. Option A does not clear the error if valid. Option A checks length, which is not reliable.

❓ state_output

advanced

What is the value of formValid after input changes?

Given this Svelte code, what is the value of formValid after the user types '[e-mail]' in the email input and 'John' in the name input?

Svelte

<script>
  import { derived, writable } from 'svelte/store';
  const name = writable('');
  const email = writable('');
  const formValid = derived(
    [name, email],
    ([$name, $email]) => $name.trim().length > 0 && /^[^@]+@[^@]+\.[^@]+$/.test($email)
  );
</script>
<input type="text" bind:value={$name} aria-label="Name input" />
<input type="email" bind:value={$email} aria-label="Email input" />

A false

B undefined

C null

D true

💡 Hint

Check the derived store logic and the input values.

The formValid store returns true only if name is not empty and email matches the regex. Both inputs meet these conditions, so formValid is true.

🔧 Debug

advanced

Why does this Svelte form not show validation errors on submit?

Review this Svelte form code. The form submits even when inputs are empty, and no error message appears. What is the cause?

Svelte

<script>
  let username = '';
  let error = '';
  function submitForm(event) {
    event.preventDefault();
    if (!username) {
      error = 'Username required';
    }
  }
</script>
<form on:submit={submitForm} aria-label="Username form">
  <input type="text" bind:value={username} aria-required="true" />
  <button type="submit">Submit</button>
  {#if error}
    <p role="alert" style="color: red;">{error}</p>
  {/if}
</form>

A The error variable is not reactive, so it never updates.

B The form submits because the submit event is not prevented, so the page reloads before error shows.

C The input is missing a name attribute, so validation fails silently.

D The error message is outside the form, so it is not displayed.

💡 Hint

Check the form submission event handling.

The submitForm function does not call event.preventDefault(), so the form submits normally and reloads the page before the error message can show.

🧠 Conceptual

expert

Which approach best ensures accessible form validation feedback in Svelte?

Choose the best practice for showing validation errors that screen readers announce immediately after user input changes.

A Use <code>aria-hidden="true"</code> on error messages to avoid distraction.

B Use <code>role="alert"</code> on the error message and update it only on form submit.

C Use <code>aria-live="assertive"</code> on the error message container and update error text reactively.

D Show errors only as placeholder text in inputs without ARIA roles.

💡 Hint

Think about how screen readers detect live changes.

Using aria-live="assertive" ensures screen readers announce error messages immediately when they appear. role="alert" also works but updating only on submit delays feedback. Placeholder text is not accessible feedback. Hiding errors prevents screen readers from reading them.

Practice

1. What is the main purpose of form validation in a Svelte application?

easy

A. To check user input before sending data

B. To style the form elements

C. To load data from the server

D. To create new components

Solution

1. Step 1: Understand form validation role

   Form validation ensures user input is correct before submission.

2. Step 2: Identify the correct purpose

   Checking input prevents errors and improves user experience.

3. Final Answer:

   To check user input before sending data -> Option A

4. Quick Check:

   Form validation = check input [OK]

Hint: Validation means checking input before sending [OK]

Common Mistakes:

• Confusing validation with styling
• Thinking validation loads data
• Mixing validation with component creation

2. Which Svelte syntax correctly binds an input's value for validation?

easy

A.

B.

C.

D.

Solution

1. Step 1: Recall Svelte binding syntax

   Svelte uses bind:value={variable} to bind input values.

2. Step 2: Identify correct syntax

   <input bind:value={name} /> uses correct curly braces and binding keyword.

3. Final Answer:

   <input bind:value={name} /> -> Option B

4. Quick Check:

   bind:value with braces = correct [OK]

Hint: Use bind:value with curly braces for binding [OK]

Common Mistakes:

• Omitting curly braces
• Using colon instead of equals
• Using value= instead of bind:value=

3. What will be the output when submitting this Svelte form if the input is empty?

<script>
  let email = '';
  let error = '';
  function validate() {
    if (!email) {
      error = 'Email is required';
    } else {
      error = '';
    }
  }
</script>

<form on:submit|preventDefault={validate}>
  <input bind:value={email} type="email" />
  <button type="submit">Submit</button>
  <p>{error}</p>
</form>

medium

A. Error message 'Email is required' is shown

B. Form submits with no error message

C. Syntax error prevents form rendering

D. Form reloads the page

Solution

1. Step 1: Analyze validation function

   If email is empty, error is set to 'Email is required'.

2. Step 2: Check form submission behavior

   Submit event is prevented from default, so page does not reload, and error message shows.

3. Final Answer:

   Error message 'Email is required' is shown -> Option A

4. Quick Check:

   Empty input triggers error message [OK]

Hint: Empty input triggers error message display [OK]

Common Mistakes:

• Ignoring preventDefault causing page reload
• Expecting form to submit without error
• Confusing syntax error with logic error

4. Identify the error in this Svelte form validation code:

<script>
  let password = '';
  let error = '';
  function check() {
    if(password.length < 6) {
      error = 'Password too short';
    }
  }
</script>

<form on:submit={check}>
  <input bind:value={password} type="password" />
  <button type="submit">Login</button>
  <p>{error}</p>
</form>

medium

A. Incorrect binding syntax for password

B. Error message variable not declared

C. Missing preventDefault on submit event

D. Password length check uses wrong operator

Solution

1. Step 1: Review submit event handling

   The form's submit event calls check but does not prevent default, so page reloads.

2. Step 2: Identify missing preventDefault

   Without preventDefault, error message disappears on reload, breaking validation UX.

3. Final Answer:

   Missing preventDefault on submit event -> Option C

4. Quick Check:

   Submit needs preventDefault to stop reload [OK]

Hint: Always use preventDefault on form submit to keep validation visible [OK]

Common Mistakes:

• Forgetting preventDefault causes page reload
• Thinking binding syntax is wrong when it is correct
• Assuming error variable is missing

5. How can you improve accessibility when showing validation errors in a Svelte form?

hard

A. Remove labels to reduce clutter

B. Use only color changes to show errors

C. Hide error messages visually but keep them in the DOM

D. Add aria-live="polite" to error message container

Solution

1. Step 1: Understand accessibility for errors

   Screen readers need to be notified of error changes dynamically.

2. Step 2: Use aria-live attribute

   Adding aria-live="polite" tells assistive tech to announce updates politely.

3. Final Answer:

   Add aria-live="polite" to error message container -> Option D

4. Quick Check:

   aria-live improves screen reader announcements [OK]

Hint: Use aria-live for dynamic error announcements [OK]

Common Mistakes:

• Relying only on color changes (not accessible)
• Hiding errors visually removes info from users
• Removing labels harms form clarity