You already know how to manufacture the <li> of a task. What you still do not have is a way of working: right now you paint once at startup and then patch each element by hand inside the click handler. That works with three actions and becomes unmanageable with fifteen, because every action has to remember to update the <li>, the summary, the hours counter, the workload panel and whatever comes next. The alternative is a change of mindset: instead of describing what has to be modified, you write a function that describes how the screen should look given a state, and you call it again every time the state changes. In this lesson you will build that cycle, learn to group the board into columns, to escape data if you use text templates, and to solve the problem that appears as soon as you redraw everything: that focus, scrolling and whatever the user was typing get lost along the way.

1. From a single node to the complete list: render(state)
2. The cycle state → render → event → new state → render
3. Templates with template literals and escapeHtml
4. Three ways of producing HTML, compared
5. <template> for the cards
6. Grouping the board by status with Object.groupBy
7. Empty states, counters and summary
8. The problem of redrawing everything
9. Partial updating: keys and node reuse
10. reconcile(list, data)
11. Sorting and filtering in the view without touching the model
12. Nómada Tasks: view/board-view.js
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

Compare the two ways of thinking:

The render function takes the state and produces the screen. Nothing else. It does not know what has changed and does not care: it draws what is there now.

The advantage is not writing less code: it is that the screen cannot get out of sync with the state. In the imperative version there is always a case where somebody forgets to update one of the five things and the interface shows a lie. In the declarative one, that is impossible by construction.

This is the architecture of almost any modern interface application, and now you are going to write it by hand:

The rules of the cycle, which are worth respecting with discipline:

• One single direction. The state feeds the screen; the screen is never the source of truth. If you need to know which tasks are done, you ask the Board, you do not count elements with the class task--done.
• Handlers do not touch the DOM. They modify the state (through the model) and call render(). Just that one.
• render is (almost) pure. Given the same state, it produces the same screen. Its only side effect is writing to the DOM.
• The model still does not know a screen exists. Task and Board do not change a single line in this lesson.

There is a way of building HTML that turns out to be very readable: the template literals from 01-05, with the structure written as it is and the data interpolated.

It reads beautifully. And exactly as written, it is a vulnerability. In 06-07 Marta will be able to write the title of a task; if she writes <img src=x onerror="…">, that code will run in your page.

The only way of using this approach safely is to escape every interpolated piece of data, with no exceptions:

Details that make this function correct and not a false sense of security:

• & is escaped first in the order of the regular expression, because if it were escaped afterwards it would turn the already generated < into <. Using replace with a replacement function avoids the problem at the root, because each character is processed exactly once.
• The quotes are escaped too. Without them, a piece of data interpolated inside an attribute (data-id="${value}") could close the attribute and inject others. It is a real vector.
• String(value) protects against null, undefined and numbers.

And a warning not to forget: escaping works for text content and quoted attributes. It is not enough if you interpolate inside a <script>, inside a style, or in an href/src attribute (where a javascript: is still dangerous). For those cases, do not interpolate: use nodes.

With the function, the template ends up like this:

It works, it is safe… and it depends on nobody ever forgetting an esc(). A single slip reopens the hole. That fragility is the decisive argument against this approach, and the reason the alternatives in the next section are preferable.

Operational conclusion for Nómada Tasks: <template> for the card's fixed structure, buildElement for the dynamic parts, and template literals only for constant markup with no data. It is the balance between readability and safety, and it eliminates the entire class of escaping errors.

We pick up the template from 06-05 and give it its final shape, with the columns included:

And the function that fills it in. Notice that it now updates an existing <li> if you pass one, and only clones when there is none: that dual capability is what will make the reconciliation of section 10 possible.

A single function serves both for creating and for updating. That is exactly what a render that runs many times needs.

The Taller Nómada board has three columns: pending, in progress and done. Grouping is one line, with what you learned in 04-05:

Two warnings about Object.groupBy:

• It only creates the keys that appear. If no task is done, byStatus.done is undefined, not an empty array. Use ?? [] always.
• The object it returns has the null prototype, so it has no hasOwnProperty and no toString. To check keys, Object.hasOwn(byStatus, 'done') or simply the ??.

With that, drawing the three columns is straightforward:

With the canonical backlog, the result is:

And 25 + 20 = 45 h open, out of 48 h in total. The canonical numbers, now spread across columns.

The minimal CSS so they look like columns:

A detail that separates a finished interface from a prototype: what you see when there is nothing. An empty column with no message looks like a loading error.

You have already solved it above with $('.column__empty', column).hidden = inStatus.length > 0, but it is worth telling three different situations apart, because the right message is not the same:

And the global summary, which reuses the model's method:

That element carries role="status" in the HTML (06-01), so a screen reader announces the new summary every time it changes, without stealing focus.

And now the bad news. replaceChildren(...) destroys all the nodes and creates others. That has four visible consequences:

1. Focus is lost. If Marta had tabbed her way to the "Mark done" button of the third task and presses Enter, the render leaves her with focus on document.body. Her next Tab takes her to the top of the page.
2. Scrolling is lost inside containers with their own scrollbar.
3. Browser state is lost: selected text, open <details>, the cursor position inside an <input> that happened to be in the list.
4. CSS transitions are restarted, because the elements are new.

There are two strategies for solving it.

Strategy A: save and restore. Before redrawing, note what was focused; afterwards, look it up again by its stable key and give it back its focus.

It works and it is simple, but it is a patch: the more things there are to preserve, the more fragile it becomes.

Strategy B: do not destroy what has not changed. This is the good one, and it is what frameworks do. Instead of emptying and recreating, you compare the list of current nodes with the new data and reuse every node that is still valid, updating only its content.

To reuse a node you have to be able to identify it. Position will not do: if the first task disappears, all the others shift and the second one's node would come to represent the third, with focus and animations in the wrong place.

What does work is a stable key: an identifier that belongs to the data, not to its position. In Nómada Tasks you have had it since 06-02: data-id.

Here is the implementation, and it is shorter than it looks:

A line-by-line explanation of what it does and why:

• Step 1: it builds a Map of key → node with what is on screen. It is exactly the pattern of indexing by id from 04-05, applied to nodes instead of objects.
• Step 2: it walks the data in the order they should end up in. For each one, if a node with that key already existed it reuses it (paint(item, previous) updates it instead of cloning), and if not, it creates a new one. Then it places it in its position with insertBefore, which —remember 06-05— moves the node if it was already in the tree.
• Step 3: what is left in the Map are nodes whose key no longer appears in the data. They are removed.

The result: the nodes of the tasks that are still there are never destroyed. They keep their focus, their transitions and any browser state.

Check it: put focus on the "Start" button of the third task, press Enter and observe that focus is still there after the render, with the button already changed to "Mark done". With replaceChildren it would have disappeared.

The limits of this implementation. It is deliberately simple and is not a complete reconciliation algorithm: it does not detect moves optimally (it may move more nodes than strictly necessary) and it only works with direct children that have a key. For a task list it is more than enough. For a large interface, with nested trees and components, doing this by hand becomes unfeasible, and that is where frameworks come in: React, Vue and Angular solve this exact problem —and that is why all of them ask you for a key in lists, which is literally this data-id. You will see it in Why Frameworks Exist, and you will arrive at that lesson knowing what problem they solve, which is the only way of really understanding them.

Filtering and sorting are presentation decisions. The Board must not find out: if Lucía filters by her name, the board still has six tasks and 45 h open; the only thing that changes is what is shown.

Three important points:

• board.tasks already returns a copy ([...this.#tasks], the encapsulation of 05-03), so the .sort(), which mutates, does not touch the model's internal array. If the getter returned the real array, this sort would reorder the model: a subtle, unpleasant bug.
• The priority comparator uses || as a tie-breaker: if two tasks have the same priority, they are ordered by id. Without a tie-breaker, the order among equals would depend on the algorithm and could change between renders, producing visual jumps.
• localeCompare(text, 'en') sorts accented characters correctly, something the string < operator does not do.

The complete module, which brings everything above together:

And the entry point, which by now is pure wiring:

The whole cycle from section 2, in twenty lines: the delegated handler touches the model and calls render(); render() draws what is there. When the carpentry task is marked as done, the card moves from the "Not started" column to "Completed" without being destroyed, the counters go from 3 tasks · 25 h to 2 tasks · 20 h and from 1 task · 3 h to 2 tasks · 8 h, the summary drops from 45 to 40 h open and from 1 overdue to 0, and focus stays exactly where it was.

• Interpolating unescaped data into a text template. One forgotten ${} is enough to open an XSS. If you choose this approach, escape always; if you can, use <template> or nodes and eliminate the whole class of errors.
• Using the array index as the key. data-id="${index}" looks like it works until an element in the middle is deleted: from then on every node represents the wrong item. The key must belong to the data.
• Forgetting ?? [] with Object.groupBy. It only creates the keys that appear; a column with no tasks gives undefined and the following .map throws a TypeError.
• Sorting the model's array. sort mutates. It works here because board.tasks returns a copy; if some getter returned the internal array, you would be reordering the model from the view. When in doubt, [...list].sort(...).
• Redrawing inside a fast event loop. A complete render() for every keystroke in a search field is wasted work. The solution is the debounce you will see in 06-07.
• Putting handlers inside render. If render registers handlers, every call adds another one and you end up with the action running five times. Handlers are registered once, by delegation, outside the render.
• Redrawing and losing focus without realizing. It is a serious, silent accessibility failure: mouse users never notice it. Always test it with the Tab key.
• Tip: keep render() free of hidden effects. Let it only read the state and write to the DOM. If it makes requests, changes the model or triggers actions, it stops being predictable and debugging becomes very hard.
• Tip: keep the view state in a single object. Having filters, sort and today in a single #state makes answering "why does it look like this?" trivial: you print the object and you know.

Add to the HTML an <input type="search" id="search"> with its <label> and wire it up so that typing filters the tasks by title. It must use state.filters.text, must not touch the model, and must show in the summary how many are being seen. Check with the Tab key that focus does not leave the search field while typing, and explain why reconciliation is essential here.

Add a <select id="sort"> with the options priority, due date and hours, and make the cards reorder when it changes. Then check, with the DevTools, that reordering moves the nodes instead of recreating them: set a data-mark on an <li> from the console, reorder, and verify that the mark is still there.

Add a data-action="delete" button to the card and a removeTask(id) method to Board. Check that after deleting a task from the middle, the remaining cards keep their nodes (they are not recreated) and that focus moves to the equivalent button of the next task. Explain what would have happened if reconcile used position instead of data-id.

Exercise 1

Reconciliation is essential here for a very concrete reason: the input event fires on every keystroke, so every letter causes a render(). If that render did a replaceChildren, it would destroy and recreate every card twenty times while Marta types "screen printing". It would not lose the <input>'s focus —that is outside the reconciled container—, but it would waste an enormous amount of work, restart the CSS transitions on every key and produce a perfectly visible flicker. With reconcile, each keystroke only removes the cards that stop matching and brings back the ones that match again.

Typing "carpent", the summary shows 6 tasks · 5 open · 45 of 48 h · 1 overdue · effort 124 · showing 1: the model's numbers do not change, only the count of what is shown. It is exactly the separation we were after.

Exercise 2

Check that the nodes move and are not recreated:

If the mark survives, it means reconcile reused the node and only relocated it with insertBefore. With replaceChildren the mark would have disappeared, because the <li> would be a different object. This witness-attribute trick is, incidentally, an excellent debugging technique for verifying any node-reuse strategy.

Note: change is the right event for a <select>; input works too, but change better expresses the intention of "an option has been chosen".

Exercise 3

If reconcile identified the nodes by position, deleting the task in the middle would cause the following: the node occupying position 2 would be filled with the data of the task that was previously in position 3, the one in 3 with the data from 4, and so on to the end; the last node would be removed. Visually the result would be correct, but every node would have changed its data: focus, which was on the card in position 3, would end up on a card that now shows a different task; any CSS transition under way would be applied to the wrong element; and any browser state tied to a node (an expanded <details>, for instance) would be attributed to the wrong task.

With data-id as the key, each task's node stays its own whatever happens: only the node whose key disappears from the data is removed. This is exactly why React, Vue and Angular insist so much on the key prop for lists, and seeing it from the inside is going to save you a lot of time when you get to Module 10.

You have gone from manipulating individual nodes to having an architecture. The axis is the render(state) function, which describes how the screen should look given a state, and the cycle state → render → event → new state → render, with its rules: one single direction, handlers do not touch the DOM (they change the state and call render), and the model still does not know a screen exists. The advantage is not writing less, but that the interface cannot get out of sync with the data, which is the kind of error hardest to chase down in an imperative application.

You know the three ways of producing HTML and the criterion for choosing. Template literals are the most readable and the most dangerous: they demand escaping every piece of data with an escapeHtml function that translates & < > " ', and one slip is enough to open an XSS. Building with nodes is safe by definition. And <template> with content.cloneNode(true) combines the readability of having the structure in the HTML with the safety of filling it in through textContent, which is the option adopted in the project. On top of it you have written paintCard(task, existing), a function that creates or updates depending on whether you pass it a previous node: the property that makes everything else possible.

You know how to group the board into columns with Object.groupBy, with the reminder that it only creates the keys present and that ?? [] is needed; how to draw counters per column (3 tasks and 25 h not started, 2 and 20 h under way, 1 and 3 h completed, adding up to the usual 45 h open); and how to take care of empty states with different messages depending on whether it is an empty column, a filter with no results or a brand-new board. And, above all, you know what happens when you redraw everything with replaceChildren: focus, scrolling, selection and browser state are lost, an accessibility failure that mouse users never perceive. The answer lies in stable keys: reconcile(container, data, key, paint) indexes the existing nodes in a Map by their data-id, reuses the ones still alive by updating their content, relocates them with insertBefore and removes the leftovers. The surviving nodes keep their identity, and with it their focus and their transitions. Filtering and sorting, finally, are view decisions: they live in its state, they operate on the copy returned by board.tasks and they never alter the model.

That twenty-line reconcile is also a lesson about the craft: doing it well for a flat list with a key is manageable; doing it for nested trees of components, with arbitrary order and partial updates, is the work that React, Vue and Angular do. You will arrive at Module 10 knowing exactly what problem they solve and why they all ask you for a key.

One last piece remains, and it is the one that turns the board into a real tool. Marta can move tasks around and filter them, but she cannot create any: the backlog is still the one in data/backlog.js. Adding a task means a form, and a form brings a world of its own: accessible fields with their labels, values that always arrive as text, native browser validation versus validation in JavaScript, business rules that must go on living in the model, error messages a screen reader can announce, and focus put where it belongs when something fails. All of that is Handling and Validating Forms, the last lesson of the module.