Typed Task Manager

Build a to-do app using interfaces for tasks and a discriminated union for task status.

InterfacesUnion TypesType Narrowing

Overview

A task manager is the natural first TypeScript project because the whole idea behind it — a list of things, each with a handful of fields — is exactly what interfaces exist to describe. Where a plain JavaScript to-do app just trusts that every object in the array happens to have a `text` and a `completed` flag, this version has the compiler check that guarantee for you, on every single line that touches a task.

The core idea this project teaches is type narrowing: a task's `status` field is not a loose string, it is a union of exactly three literal values (`'todo'`, `'in-progress'`, `'done'`). Once a variable is typed that way, TypeScript can follow a `switch` statement branch by branch and know exactly which of the three values you are handling in each case — and it will refuse to compile if you ever forget one.

What You'll Build

A `Task` interface and a `TaskStatus` union type that together describe every task's exact shape.
A form that adds new, fully-typed tasks to an in-memory `Task[]` array.
A `renderTasks()` function that rebuilds the list from that typed array on every change.
A status button that cycles each task through `todo` -> `in-progress` -> `done` using a narrowing `switch`.
A delete button, wired through the same typed, delegated click handler as the status button.

Prerequisites

Solid JavaScript — DOM basics, `addEventListener`, arrays (`push`, `filter`, `find`, `forEach`), and plain objects.
This is your first TypeScript project, so you should already know the basic type annotation syntax: `let x: number`, `function f(x: string): void`.
What an `interface` is at a glance — a named description of an object's shape, checked at compile time only (it produces no runtime code at all).
That TypeScript needs a build step: a `.ts` file is compiled ("transpiled") to plain `.js` by the `tsc` command before a browser can run it, and every type annotation is stripped out in that process.

Project Structure

This project uses three files: `index.html` for the page shell, `styles.css` for the visual styling, and `script.ts` — a real TypeScript file — for all of the behavior. In a real project you would run `tsc script.ts` (or a bundler configured for TypeScript) to produce a `script.js` that `index.html` actually loads; every code block from here on shows the `.ts` source exactly as you would write it in an editor with type-checking turned on.

Just like a plain JavaScript version, the `tasks` array is the single source of truth and the visible `<ul>` is always rebuilt from it. What TypeScript adds on top is a guarantee: every object that ever enters that array is checked against the `Task` interface at compile time, so a typo like `status: 'Done'` (capitalized) or a missing `id` field is caught before the code ever runs, not discovered later by a user staring at a broken row.

<!-- Root container for the whole task manager -->
<div class="task-app">
  <h1>Typed Task Manager</h1>

  <!-- A <form>, not just a lone button, so pressing Enter submits too -->
  <form id="task-form">
    <input
      type="text"
      id="task-input"
      placeholder="What needs to get done?"
      autocomplete="off"
    />
    <button type="submit">Add</button>
  </form>

  <!-- Starts empty on purpose; renderTasks() fills this in from tasks[] -->
  <ul id="task-list"></ul>
</div>

* {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

body {
  font-family: Arial, Helvetica, sans-serif;
  background: #1a1d23;
  color: #e8e8e8;
  display: flex;
  justify-content: center;
  padding: 40px 16px;
}

.task-app {
  width: 100%;
  max-width: 460px;
  background: #23262e;
  border-radius: 10px;
  padding: 24px;
}

.task-app h1 {
  margin-bottom: 16px;
  font-size: 1.5rem;
}

#task-form {
  display: flex;
  gap: 8px;
  margin-bottom: 16px;
}

#task-input {
  flex: 1;
  padding: 10px 12px;
  border-radius: 6px;
  border: 1px solid #3a3f4b;
  background: #1a1d23;
  color: #e8e8e8;
  font-size: 1rem;
}

#task-form button {
  padding: 10px 16px;
  border: none;
  border-radius: 6px;
  background: #4f8cff;
  color: white;
  cursor: pointer;
  font-weight: bold;
}

#task-list {
  list-style: none;
}

.task-item {
  display: flex;
  align-items: center;
  gap: 10px;
  padding: 10px 4px;
  border-bottom: 1px solid #3a3f4b;
}

.task-item span {
  flex: 1;
}

.status-todo .status-btn { background: #3a3f4b; }
.status-in-progress .status-btn { background: #c99a2e; }
.status-done .status-btn { background: #2e9e5b; }
.status-done span { text-decoration: line-through; opacity: 0.6; }

.status-btn, .delete-btn {
  border: none;
  border-radius: 6px;
  color: white;
  padding: 6px 10px;
  cursor: pointer;
  font-size: 0.85rem;
}

.delete-btn {
  background: transparent;
  color: #ff6b6b;
}

Step 1: Define the Task Interface and Status Union

Everything else in this project is built on two type declarations: a `TaskStatus` union that lists the only three valid statuses a task can have, and a `Task` interface that reuses that union for its `status` field instead of the wider (and much less useful) `string`.

// A union of string literals — TypeScript will only allow these three exact
// strings, catching typos like "Todo" or "done " at compile time instead of
// silently creating a task nothing in the UI can ever match
type TaskStatus = 'todo' | 'in-progress' | 'done';

// An interface describes the *shape* every task object must have. Using a
// named interface (rather than scattering loose variables) means every
// function that touches a task gets full autocomplete and compile-time
// checking on task.id, task.text, and task.status
interface Task {
  id: number;
  text: string;
  status: TaskStatus; // reuses the union above instead of "string", so an invalid status is a type error right at the object literal
}

A `type` alias and an `interface` can often describe the same shape, but `TaskStatus` has to be a `type` — a union of literals isn't something an `interface` can express — while `Task` is deliberately an `interface`, since it is a plain object shape and interfaces are the conventional choice for that in TypeScript.

Step 2: Select Elements and Type the State

`document.getElementById` returns the generic type `HTMLElement | null`, because TypeScript has no way to know at compile time whether an element with that id actually exists, or what kind of element it is. A type assertion (`as HTMLFormElement`) tells the compiler what you already know from reading the HTML, so later lines can use `.elements`, `.value`, and other properties specific to that element type.

// Type assertions narrow "HTMLElement | null" down to the specific element
// type each variable actually holds, unlocking properties like .value that
// only exist on HTMLInputElement, not on the generic HTMLElement
const taskForm = document.getElementById('task-form') as HTMLFormElement;
const taskInput = document.getElementById('task-input') as HTMLInputElement;
const taskList = document.getElementById('task-list') as HTMLUListElement;

// Annotating this explicitly as Task[] (rather than letting TypeScript infer
// the near-useless "never[]" from an empty array literal) means push()ing
// anything that isn't a full, valid Task is a compile error immediately
let tasks: Task[] = [];

// Hands out a unique id to each new task without needing a database
let nextId = 1;

Step 3: Render Tasks from Typed State

`renderTasks` takes no arguments and returns nothing — annotating it `: void` documents that its entire job is a side effect (rewriting the DOM), not computing a value. Because `tasks` is typed as `Task[]`, the `task` parameter inside `forEach` is automatically known to be a `Task`, with every field autocompleting.

function renderTasks(): void { // ": void" documents "this does something, it doesn't return anything"
  taskList.innerHTML = '';

  tasks.forEach(function (task: Task) { // TypeScript infers this type from Task[] automatically; written out here for clarity
    const li = document.createElement('li');
    li.className = 'task-item status-' + task.status; // task.status can only ever be one of the three TaskStatus literals
    li.dataset.id = String(task.id);

    const span = document.createElement('span');
    span.textContent = task.text;

    const statusBtn = document.createElement('button');
    statusBtn.type = 'button';
    statusBtn.className = 'status-btn';
    statusBtn.textContent = statusLabel(task.status); // defined in Step 5 — turns the union value into readable text

    const deleteBtn = document.createElement('button');
    deleteBtn.type = 'button';
    deleteBtn.className = 'delete-btn';
    deleteBtn.textContent = 'Delete';

    li.appendChild(span);
    li.appendChild(statusBtn);
    li.appendChild(deleteBtn);
    taskList.appendChild(li);
  });
}

Step 4: Add a New Task

Annotating the new task object literal as `Task` means TypeScript checks it against the interface right where it is created — forgetting the `status` field, or misspelling one of its literal values, fails to compile instead of quietly producing a task the rest of the app can't handle.

taskForm.addEventListener('submit', function (event: SubmitEvent): void {
  event.preventDefault(); // Stop the browser's default full-page reload on form submit

  const text = taskInput.value.trim();
  if (text === '') {
    return; // Silently ignore empty submissions
  }

  // The ": Task" annotation checks this object literal against the interface
  // right here — every field is required, and status can only be one of the
  // three TaskStatus literals
  const newTask: Task = {
    id: nextId++,
    text: text,
    status: 'todo', // every new task always starts in the same literal member of TaskStatus
  };

  tasks.push(newTask); // tasks is Task[], so pushing anything else here would be a compile error
  taskInput.value = '';
  renderTasks();
});

What Happens in the tasks Array

Click Run to see what this code prints.

Step 5: Narrow on Status to Update and Delete Tasks

`nextStatus` is where type narrowing actually pays off: because its parameter is typed `TaskStatus` (not `string`), a `switch` over it can be checked for exhaustiveness. The `default` branch assigns whatever is left to a variable typed `never` — if `TaskStatus` ever grew a fourth member and this switch weren't updated to handle it, that assignment would fail to compile, catching the gap immediately instead of at runtime.

// Cycles a task forward through its lifecycle. Typing both the parameter
// and return value as TaskStatus (not string) is what makes the switch below
// exhaustiveness-checkable by the compiler
function nextStatus(current: TaskStatus): TaskStatus {
  switch (current) {
    case 'todo':
      return 'in-progress';
    case 'in-progress':
      return 'done';
    case 'done':
      return 'todo';
    default:
      // If TypeScript ever lets a value reach here, TaskStatus grew a member
      // this switch doesn't handle — assigning it to "never" turns that gap
      // into a compile-time error instead of a silent runtime bug
      const _exhaustive: never = current;
      return _exhaustive;
  }
}

// A second, simpler narrowing switch — no default case is needed here
// because TypeScript already knows the three cases below cover every
// possible TaskStatus value, so the function is provably total
function statusLabel(status: TaskStatus): string {
  switch (status) {
    case 'todo':
      return 'To Do';
    case 'in-progress':
      return 'In Progress';
    case 'done':
      return 'Done';
  }
}

Step 6: Wire Everything Together

A single delegated click listener on `taskList` handles both the status button and the delete button. `event.target` is typed `EventTarget | null` by default, which has no `.closest()` method, so it is asserted to `HTMLElement` first — the same trick used for the DOM lookups in Step 2, just applied to an event instead of an id.

taskList.addEventListener('click', function (event: MouseEvent): void {
  const target = event.target as HTMLElement; // narrow EventTarget | null down to something with .closest() and .classList
  const li = target.closest('.task-item') as HTMLLIElement | null;
  if (!li || !li.dataset.id) return; // click landed outside any task row

  const id = Number(li.dataset.id);
  const task = tasks.find(function (t: Task): boolean { return t.id === id; });
  if (!task) return; // task is "Task | undefined" until this guard narrows it to just "Task" below

  if (target.classList.contains('delete-btn')) {
    tasks = tasks.filter(function (t: Task): boolean { return t.id !== id; });
  } else if (target.classList.contains('status-btn')) {
    task.status = nextStatus(task.status); // reuses the narrowing switch from Step 5
  } else {
    return; // click was on the row but not on either button
  }

  renderTasks();
});

// Draw the initial (empty) list as soon as the script runs
renderTasks();

Complete Code

Here is the complete project — the HTML shell, the CSS, and the fully assembled `script.ts` in the order you would put them in real files. Remember that this `.ts` file has to be run through `tsc` (or a TypeScript-aware bundler) before a browser can execute it; the interactive demo right after this section runs the type-erased JavaScript output, which is why its inline script has no type annotations at all — types are a compile-time-only tool, and there is nothing left of them once transpilation strips them out.

<div class="task-app">
  <h1>Typed Task Manager</h1>

  <form id="task-form">
    <input type="text" id="task-input" placeholder="What needs to get done?" autocomplete="off" />
    <button type="submit">Add</button>
  </form>

  <ul id="task-list"></ul>
</div>

* { box-sizing: border-box; margin: 0; padding: 0; }

body {
  font-family: Arial, Helvetica, sans-serif;
  background: #1a1d23;
  color: #e8e8e8;
  display: flex;
  justify-content: center;
  padding: 40px 16px;
}

.task-app {
  width: 100%;
  max-width: 460px;
  background: #23262e;
  border-radius: 10px;
  padding: 24px;
}

.task-app h1 { margin-bottom: 16px; font-size: 1.5rem; }

#task-form { display: flex; gap: 8px; margin-bottom: 16px; }

#task-input {
  flex: 1;
  padding: 10px 12px;
  border-radius: 6px;
  border: 1px solid #3a3f4b;
  background: #1a1d23;
  color: #e8e8e8;
  font-size: 1rem;
}

#task-form button {
  padding: 10px 16px;
  border: none;
  border-radius: 6px;
  background: #4f8cff;
  color: white;
  cursor: pointer;
  font-weight: bold;
}

#task-list { list-style: none; }

.task-item {
  display: flex;
  align-items: center;
  gap: 10px;
  padding: 10px 4px;
  border-bottom: 1px solid #3a3f4b;
}

.task-item span { flex: 1; }

.status-todo .status-btn { background: #3a3f4b; }
.status-in-progress .status-btn { background: #c99a2e; }
.status-done .status-btn { background: #2e9e5b; }
.status-done span { text-decoration: line-through; opacity: 0.6; }

.status-btn, .delete-btn {
  border: none;
  border-radius: 6px;
  color: white;
  padding: 6px 10px;
  cursor: pointer;
  font-size: 0.85rem;
}

.delete-btn { background: transparent; color: #ff6b6b; }

type TaskStatus = 'todo' | 'in-progress' | 'done';

interface Task {
  id: number;
  text: string;
  status: TaskStatus;
}

const taskForm = document.getElementById('task-form') as HTMLFormElement;
const taskInput = document.getElementById('task-input') as HTMLInputElement;
const taskList = document.getElementById('task-list') as HTMLUListElement;

let tasks: Task[] = [];
let nextId = 1;

function statusLabel(status: TaskStatus): string {
  switch (status) {
    case 'todo':
      return 'To Do';
    case 'in-progress':
      return 'In Progress';
    case 'done':
      return 'Done';
  }
}

function nextStatus(current: TaskStatus): TaskStatus {
  switch (current) {
    case 'todo':
      return 'in-progress';
    case 'in-progress':
      return 'done';
    case 'done':
      return 'todo';
    default:
      const _exhaustive: never = current;
      return _exhaustive;
  }
}

function renderTasks(): void {
  taskList.innerHTML = '';

  tasks.forEach(function (task: Task) {
    const li = document.createElement('li');
    li.className = 'task-item status-' + task.status;
    li.dataset.id = String(task.id);

    const span = document.createElement('span');
    span.textContent = task.text;

    const statusBtn = document.createElement('button');
    statusBtn.type = 'button';
    statusBtn.className = 'status-btn';
    statusBtn.textContent = statusLabel(task.status);

    const deleteBtn = document.createElement('button');
    deleteBtn.type = 'button';
    deleteBtn.className = 'delete-btn';
    deleteBtn.textContent = 'Delete';

    li.appendChild(span);
    li.appendChild(statusBtn);
    li.appendChild(deleteBtn);
    taskList.appendChild(li);
  });
}

taskForm.addEventListener('submit', function (event: SubmitEvent): void {
  event.preventDefault();

  const text = taskInput.value.trim();
  if (text === '') {
    return;
  }

  const newTask: Task = {
    id: nextId++,
    text: text,
    status: 'todo',
  };

  tasks.push(newTask);
  taskInput.value = '';
  renderTasks();
});

taskList.addEventListener('click', function (event: MouseEvent): void {
  const target = event.target as HTMLElement;
  const li = target.closest('.task-item') as HTMLLIElement | null;
  if (!li || !li.dataset.id) return;

  const id = Number(li.dataset.id);
  const task = tasks.find(function (t: Task): boolean { return t.id === id; });
  if (!task) return;

  if (target.classList.contains('delete-btn')) {
    tasks = tasks.filter(function (t: Task): boolean { return t.id !== id; });
  } else if (target.classList.contains('status-btn')) {
    task.status = nextStatus(task.status);
  } else {
    return;
  }

  renderTasks();
});

renderTasks();

Sample Run

Sample Interaction

Click Run to see what this code prints.

Extend This Project

Persist `tasks` to `localStorage`, parsing the saved JSON back with `JSON.parse(saved) as Task[]` on load.
Add a `dueDate?: string` optional field to `Task`, and render it only for tasks where it is set.
Build a `countByStatus(tasks: Task[]): Record<TaskStatus, number>` summary using `Record` to guarantee all three statuses are always present.
Write a real type guard, `function isOverdue(task: Task): boolean`, and use it with `.filter()` to show only overdue tasks.
Add a priority field typed as a second union (`'low' | 'medium' | 'high'`) and sort the rendered list by it.

Summary

You built a task manager where an `interface` and a literal union type describe every task's exact shape, and a `switch` statement narrows that union case by case, with the compiler checking that every case is actually handled. This pattern — model the valid states as a union, then narrow on it with `switch` or `if` — is the foundation the rest of the TypeScript course builds on, especially the discriminated unions used in the Form Validator project.