Unit Project: Accessible Task Board

Unit Project: Accessible Task Board | JavaScript Course | SovranCode

COMPLETE LESSON · ABOUT 65 MIN OF ACTIVE PRACTICE

Learn Unit Project: Accessible Task Board step by step

Follow the lesson in order: understand the model, trace worked examples, run a controlled experiment, debug a faulty assumption, build independently, and verify your reasoning.

LESSON MAP

What you will understand and apply

Render the entire view from one state model
Support keyboard submission and delegated actions
Validate restored storage and test focus after removal
Build an accessible task board with create, complete, remove, filter, status, focus recovery, and validated local persistence.

DEEP EXPLANATION

Build the complete mental model

Build the mental model

Write a compact product specification first: a learner can add a non-empty task, toggle completion, remove it, filter the visible list, reload safely, and use every action with a keyboard. Define empty, success, and invalid-storage behavior. These acceptance criteria become both an implementation sequence and a manual test script. Before writing more syntax, name the values involved in Unit Project: Accessible Task Board, who creates them, and which result or effect the program promises. Trace the smallest example by hand and identify any browser or runtime API separately from the language feature. A useful mental model should predict a changed input, not merely describe the demonstration after it runs.

Use the API deliberately

Keep tasks and filter in one state value. Event handlers produce the next state, persistence stores a versioned public snapshot, and render derives visible DOM. Create elements and set textContent for titles. Use delegated actions from the list and data attributes as behavior hooks, but keep button text understandable without those attributes. During implementation, keep the state rule in a focused function or event boundary with explicit inputs. Choose names that reveal the domain, keep calculation separate from document, console, storage, or network effects, and prefer the narrowest API that expresses the problem. Compare this design with one reasonable alternative and explain why the selected construct makes ownership or control flow clearer.

Handle boundaries and tradeoffs

Test with keyboard-only navigation, a long title, duplicate titles, an empty list, the last item being removed, corrupted storage, and 200% zoom. When a focused task is removed, move focus to a logical neighboring control or the add field. Announce concise changes while leaving the visible list as the durable record. Verification for Unit Project: Accessible Task Board must cover an ordinary case, an empty or missing case, invalid input, and the most important threshold. Predict each result before running it, then locate the first value that violates the contract when reality differs. Record the corrected case as a repeatable check and explain which product behavior should occur instead of allowing undefined, NaN, stale data, or silent failure to spread.

WORKED EXAMPLES

Read the decision before the syntax

Example 1: Project foundation

Trace this Unit Project: Accessible Task Board example from validated input to returned value or visible effect before editing it.

const state = { tasks: [], filter: "all" };
function addTask(title) {
  const clean = title.trim();
  if (!clean) return false;
  state.tasks = [...state.tasks, { id: crypto.randomUUID(), title: clean, done: false }];
  return true;
}
function visibleTasks() {
  return state.tasks.filter(task => state.filter === "all" || (state.filter === "done") === task.done);
}
console.log(addTask("Practice DOM"), visibleTasks());

Example 2: Second worked example

This variation changes the shape of the problem so you can compare the underlying state contract instead of copying one solution.

function readTasks(storage, key) {
  try {
    const parsed = JSON.parse(storage.getItem(key) ?? "[]");
    if (!Array.isArray(parsed)) return [];
    return parsed.filter(task => task && typeof task.id === "string" && typeof task.title === "string" && typeof task.done === "boolean");
  } catch {
    return [];
  }
}

How to trace this lesson

Write down the exact inputs used by Unit Project: Accessible Task Board.
Predict each returned value and observable effect before running the example.
Mark the first boundary where invalid or missing data could enter.
Verify the ordinary, empty, invalid, and threshold cases independently.

Common mistakes and corrections

Using the DOM text as the source of truth creates duplicated state that filtering and persistence can easily desynchronize.: Make the state rule explicit and cover it with a focused example.
Changing several parts of the example before explaining the original result.: Make one change at a time and compare it with a written prediction.
Testing only the demonstration's happy path.: Add missing, invalid, empty, and boundary inputs that exercise the stated contract.

PRACTICE LADDER

Move from recognition to independent work

1
Render the entire view from one state model
2
Support keyboard submission and delegated actions
3
Validate restored storage and test focus after removal
4
Build an accessible task board with create, complete, remove, filter, status, focus recovery, and validated local persistence.

Complete these in order. The final step should work without copying the lesson example; use the runner and lab below to test it.

Core rule

Applied boundary

RUNNABLE EXAMPLE

Change one assumption at a time

Predict the output, run the example, then change one input and one boundary in the Unit Project: Accessible Task Board example. Explain every changed result before continuing.

const state = { tasks: [], filter: "all" };
function addTask(title) {
  const clean = title.trim();
  if (!clean) return false;
  state.tasks = [...state.tasks, { id: crypto.randomUUID(), title: clean, done: false }];
  return true;
}
function visibleTasks() {
  return state.tasks.filter(task => state.filter === "all" || (state.filter === "done") === task.done);
}
console.log(addTask("Practice DOM"), visibleTasks());

const state = { tasks: [], filter: "all" };
function addTask(title) {
  const clean = title.trim();
  if (!clean) return false;
  state.tasks = [...state.tasks, { id: crypto.randomUUID(), title: clean, done: false }];
  return true;
}
function visibleTasks() {
  return state.tasks.filter(task => state.filter === "all" || (state.filter === "done") === task.done);
}
console.log(addTask("Practice DOM"), visibleTasks());

Press Run to execute your code.

DEBUGGING CHALLENGE

Locate the first incorrect value

Predict the failure and write your repair before revealing the explanation.

list.addEventListener("click", () => state.tasks.pop());

Reveal repair and explanation

list.addEventListener("click", event => {
  if (!(event.target instanceof Element)) return;
  const button = event.target.closest("button[data-remove]");
  if (!button) return;
  state.tasks = state.tasks.filter(task => task.id !== button.dataset.remove);
  render();
});

The repaired handler delegates by stable identity and then re-renders from the updated state.

INDEPENDENT LAB

Build without copying the example

Build an accessible task board with create, complete, remove, filter, status, focus recovery, and validated local persistence.

const root = document.querySelector('main');
// Build an accessible task board with create, complete, remove, filter, status, focus recovery, and validated local persistence.

const root = document.querySelector('main');
// Build an accessible task board with create, complete, remove, filter, status, focus recovery, and validated local persistence.

Press Run to execute your code.

Self-review checklist Render the entire view from one state model Support keyboard submission and delegated actions Validate restored storage and test focus after removalWhat did you predict, observe, and change?

KNOWLEDGE CHECK

Explain the rule, not only the syntax

1. Where should the task board's source of truth live? One explicit JavaScript state model Several unrelated DOM text nodes CSS generated content

2. Which evidence best demonstrates mastery of Unit Project: Accessible Task Board? A prediction, boundary tests, and an explained result A copied snippet with no changes One successful happy-path run

Loading saved work…

Code and answers save automatically. Guest work stays on this device; signed-in work syncs to your account. The runner is isolated, blocks network access, and stops long-running console programs.

1. JavaScript Foundations

2. Functions and Collections

3. Objects and Structured Data

4. Browser Interfaces

5. Async and Reliable Applications

6. Application Engineering