You have all the pieces: money helpers, validation, rendering, events, a form, storage, modules and classes. This lesson puts them together into the finished Pocket, and, more importantly, shows the shape that holds a small app together so it stays easy to change.
\nEvery interactive app has data that changes. In Pocket that is the list of expenses and the category filter the user picked. Put all of it in one object, the state:
\nconst state = {\n expenses: loadExpenses(),\n filter: \"all\",\n};Then make one function the only way to change it. It applies the change, saves, and re-renders:
\nfunction update(changes) {\n Object.assign(state, changes);\n saveExpenses(state.expenses);\n render();\n}Object.assign(state, changes) copies the properties of changes onto state, so update({ filter: "food" }) changes only the filter. Every event handler now ends the same way: work out the new values, then call update. You never need to remember to save or redraw, because it is impossible not to.
render reads the state and draws the whole interface. Anything that can be computed from the state is computed here, not stored: the visible list depends on the filter, and the total depends on the visible list.
function render() {\n const visible =\n state.filter === \"all\"\n ? state.expenses\n : state.expenses.filter((e) => e.category === state.filter);\n\n list.replaceChildren();\n if (visible.length === 0) {\n const empty = document.createElement(\"li\");\n empty.className = \"empty\";\n empty.textContent = \"No expenses yet. Add your first one above.\";\n list.append(empty);\n }\n for (const expense of visible) {\n list.append(renderItem(expense));\n }\n totalEl.textContent = `Total: ${formatMoney(totalCents(visible))}`;\n}\n\nfunction renderItem(expense) {\n const li = document.createElement(\"li\");\n li.dataset.id = expense.id;\n const text = document.createElement(\"span\");\n text.textContent = `${expense.label}: ${formatMoney(expense.amount)} (${expense.category})`;\n const button = document.createElement(\"button\");\n button.type = \"button\";\n button.className = \"delete\";\n button.textContent = \"Delete\";\n button.setAttribute(\"aria-label\", `Delete ${expense.label}`);\n li.append(text, button);\n return li;\n}Because render always starts from the state, the filter, the list and the total can never contradict each other. Switching the filter to “food” does not hide some <li> elements and recalculate a number; it simply draws a different picture of the same state.
Two details worth copying. The empty state turns a blank list into guidance. And the delete button’s aria-label tells screen-reader users which expense it deletes, since ten buttons all called “Delete” are useless to someone who cannot see the row.
With the state, update and render in place, each feature is a few lines:
form.addEventListener(\"submit\", (event) => {\n event.preventDefault();\n const result = readExpenseForm(form); // { values } or { errors }\n if (result.errors) {\n showErrors(form, result.errors);\n return;\n }\n update({ expenses: addExpense(state.expenses, { id: nextId(), ...result.values }) });\n form.reset();\n form.elements.label.focus();\n});\n\nlist.addEventListener(\"click\", (event) => {\n const button = event.target.closest(\".delete\");\n if (!button) return;\n const id = button.closest(\"li\").dataset.id;\n update({ expenses: state.expenses.filter((e) => e.id !== id) });\n});\n\nfilterSelect.addEventListener(\"change\", () => {\n update({ filter: filterSelect.value });\n});\n\nrender();readExpenseForm and showErrors are the form code from section 4, moved into small named functions: one reads, trims, converts and validates, returning either clean values or an errors object; the other writes the messages and sets aria-invalid. Giving each a name turns the submit handler into a summary you can read in five seconds.
Notice what the handlers do not contain: no DOM building, no saving, no totals. They read the event, call pure functions such as addExpense from section 3, and hand the result to update. The rules live in expenses.js, where you can test them without a browser; the handlers are glue.
“Adding an expense works” is where testing starts, not where it ends. Before calling Pocket finished, run through this list by hand:
\nabc, 0 or -5 each show a clear message and add nothing.<b>hi</b> shows as text, and a very long label does not break the layout.Every item comes from a lesson in this course, and each catches a real class of bugs that users would otherwise find for you.
\n\nThe exercise below hands you a nearly finished Pocket with the filter and delete still to wire up. After that, one short lesson on where to go from here.
\n","toc":[{"id":"sec-1","text":"The shape: one state, one way to change it","level":2},{"id":"sec-2","text":"Render derives everything","level":2},{"id":"sec-3","text":"Handlers translate events into updates","level":2},{"id":"sec-4","text":"A definition of done","level":2}],"takeaways":["Keep all changing data in one place and change it through one function that saves and re-renders, so the page, the data and storage never disagree.","Derive everything you can, such as the visible list and the totals, from the state at render time instead of storing it separately.","Pure functions hold the rules; handlers stay short and only translate events into state changes.","An app is done when it handles the empty state, bad input, a reload and keyboard-only use, not just the happy path."],"further":[{"title":"Document.createElement() (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement"},{"title":"HTMLElement: change event (MDN)","url":"https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event"}],"quiz":[{"q":"Pocket shows expenses filtered to “food” with a total at the bottom. Where should the filtered list come from?
","options":[{"text":"A second array,foodExpenses, updated whenever an expense is added or deleted.","why":"Two arrays that must be kept in step will eventually disagree, for example after a delete that only updates one."},{"text":"Reading the <li> elements currently on the page.","why":"The page is a picture of the data. Reading data back out of it couples your logic to markup and breaks easily."},{"text":"Computed inside render from state.expenses and state.filter every time.","why":"Correct. Derived data that is recomputed from the single source of truth can never go stale."}],"answer":2},{"q":"Every handler in Pocket ends with the same three steps. Which order is right?
","options":[{"text":"Update the state, save it, render from it.","why":"Correct. The state changes first; saving and rendering both read from the new state, so both reflect the same data."},{"text":"Render, then update the state, then save.","why":"Rendering before the state changes draws the old data, so the screen is always one step behind."},{"text":"Save, then update the state, then render.","why":"Saving before updating stores the old data, so a reload loses the latest change."}],"answer":0},{"q":"Which of these is part of a reasonable definition of done for Pocket, beyond “adding an expense works”?
","options":[{"text":"Every function is written as a class method.","why":"Classes are a tool, not a goal. Plain functions are often the better choice for pure logic."},{"text":"The app has at least one animation.","why":"Polish is nice, but it says nothing about whether the app works for real use."},{"text":"The code uses noif statements.","why":"Conditions are essential to real programs. Avoiding them is not a quality measure."},{"text":"The list shows a helpful message when there are no expenses, and the data survives a reload.","why":"Correct. Empty states and persistence are part of what users experience, so they belong in “done”."}],"answer":3}],"exercise":{"kind":"web","mode":"dom","starter":{"html":"Pocket is almost done: the state, update, render, storage and the add form all work. Wire up the last three pieces:
visibleExpenses() returns only the expenses whose category matches state.filter, or all of them when the filter is "all". render already uses it for the list and the total.#filter select changes, update the filter.#expense-list that deletes the expense whose Delete button was clicked.Change data only through update(...), so every change is saved and re-rendered.
visibleExpenses is one if and one filter: state.expenses.filter((e) => e.category === state.filter).","filterSelect.addEventListener("change", () => update({ filter: filterSelect.value }));","For delete: const button = event.target.closest(".delete"); if (!button) return; then read button.closest("li").dataset.id and call update({ expenses: state.expenses.filter((e) => e.id !== id) })."],"explanation":"All three features are small because the structure does the heavy lifting. The filter is not stored anywhere except state.filter; the visible list and its total are derived from it at render time, so they can never disagree. The filter and delete handlers only work out new values and call update, which applies them, saves to storage and re-renders, so the saved data is always what the user sees. Delegation means the delete listener keeps working through every re-render and for newly added expenses. Because idCounter starts after the highest saved id, new expenses never reuse an id that is already stored.