Webbo3 Level 2 · JavaScript Development · Day 5 of 20

Project 1: Make It Work

Your first solo build. A problem statement, not a tutorial, and a Friday where you have to defend what you wrote.

There is no tutorial today. You are given a problem and a standard, and the gap between them is the work. This is deliberate: copying a tutorial teaches you to copy tutorials, and the first time you face a blank file with nobody to copy is the first time you find out whether you can actually do this. Better that it happens here, on a Friday, with your instructor in the room.

The brief

That is the entire brief, and it is meant to feel slightly too open. Decide the rest yourself: what a task looks like, what happens to a completed one, what the empty state says. Those decisions are the part being assessed.

What it must do

The one rule about how you build it

Keep your data in an array and render the page from it. Do not treat the DOM as your store of truth: do not read the list back off the page to find out what tasks exist. One array of task objects, one render() function that draws it, and every action changes the array and calls render() again.

// the shape the whole project hangs off
let tasks = [
  { id: 1, text: 'Finish Day 4 exercise', done: true  },
  { id: 2, text: 'Push project to GitHub', done: false }
];

let filter = 'all';        // 'all' | 'active' | 'completed'
let search = '';

function visibleTasks() {
  return tasks
    .filter((t) => filter === 'all'
                || (filter === 'active' && !t.done)
                || (filter === 'completed' && t.done))
    .filter((t) => t.text.toLowerCase().includes(search.toLowerCase()));
}

console.log('all:', visibleTasks().length);
filter = 'active';
console.log('active:', visibleTasks().map((t) => t.text));
search = 'github';
console.log('active + search "github":', visibleTasks().map((t) => t.text));

Notice visibleTasks() does not touch the page at all. It answers one question: given the current filter and search, which tasks should be on screen? Your render() then draws whatever it returns. Separating "what is true" from "what is drawn" is the single most useful structural idea in this project, and it is what React will do for you automatically in Level 3.

// in render(): stamp the id onto the element
`<li data-id="${task.id}" class="${task.done ? 'done' : ''}"> ... </li>`

// in the delegated listener: read it back
const id = Number(event.target.closest('li').dataset.id);
const task = tasks.find((t) => t.id === id);

Number() there is not decoration. Everything in dataset is a string, so t.id === id compares a number to a string and is always false. That is Day 1 coming back to bite, and it will cost somebody in your cohort an hour today.

What to hand in

1. A public GitHub repository with real commit messages. Not one commit called "final". At least six, each describing what changed.
2. A README with: what it does, a screenshot, how to run it, and one honest paragraph on what you would improve with more time.
3. The project folder structured the way you learned last month: index.html at the root, css/, js/.
4. A deployed link if you can manage it. GitHub Pages is free and takes ten minutes. Not required today, required from Day 18.

The Friday evaluation

You do not submit and go home. You demonstrate, and you answer questions. Fifteen minutes each.

The kind of question you will be asked

• Show me where the task actually gets deleted. Why does that work for a row you added thirty seconds ago?
• You used === here and == nowhere. What would break if you swapped them?
• Your search runs on every keystroke. What happens with two thousand tasks?
• If I typed <b>hello</b> as a task, what appears on screen, and why?
• Walk me through what happens, in order, between my click and the row disappearing.

The marking rubric

Questions you will have today

Next week: JavaScript that talks to the outside world. Modules, asynchronous code, HTTP and real APIs, ending in your first group build.