Solution

State

We will need two state variables: tasks and newTask.

tasks: Since there's a list of tasks that can be modified, we will need it to be part of the component's state. If you are going to re-order the list of tasks, we need to specify a key for each item. This allows Svelte to track the reordering of the items and reorder the DOM elements accordingly, instead of updating the DOM elements blindly. We cannot use the text of the task as the key because they are not guaranteed to be unique. Usually, the most foolproof method is to generate a unique ID for each task. Libraries like uuid come to mind, but in this case, a simple incrementing counter will do. Since we want ids to be globally unique, it is initialized in the module script, outside of the component script.

newTask: this is the state that represents the text in our input field for creating a new task. When the user clicks on the submit button, we will use the value of this state variable to add a new task to the tasks array.

Adding tasks

New tasks should be added to the end of the tasks array. We can construct a new task object based on the newTask value. To update the tasks array, we can either modify it directly or create a new array and assign it to the tasks variable. Since Svelte tracks changes through assignment statements, if we call tasks.push() to modify the array directly, we need to add another assignment to hint to Svelte that the tasks variable has changed. This could be as simple as assigning tasks to itself: tasks = tasks.

After adding a new task using the newTask value, we should clear the input for the next task by setting newTask to an empty string ''.

Deleting tasks

Having a unique id for each task object simplifies things here because we can search through the existing list and remove the task corresponding to the id to be removed. Upon finding the index of the task object to be removed, you can use Array.prototype.splice to remove the element at that index.

Accessibility

• All form <input>s should be labelled either via <label>s or aria-label attributes. Since the original markup doesn't contain a <label>, we can add aria-label to the <input>.
• Screen reader users won't be aware that a new task has been added. An aria-live region can be added to inform them about the newly-added task. There is unlikely to be enough time to do this during an interview, but you will get bonus points for mentioning it. Read more about ARIA live regions on MDN.

Test cases

• Add tasks
  • Add a new task.
  • Add multiple tasks.
  • Add tasks with potentially malicious content like HTML (e.g. <script>, <style> or <link>) and ensure there's no XSS.
  • Check that <input> is cleared after a task is added.
• Delete tasks
  • Delete an existing task.
  • Delete multiple tasks.
  • Delete newly-added tasks.