Repository files navigation

Before you continue, try the demo:https://dwyl.github.io/javascript-todo-list-tutorial/

Add a few items to the list. Double-click/tap the item to edit it.Check-off your todos and navigate the footer to filter for Active/Completed.Try and "break" it! Refresh the page and notice how your todo itemsare "still there" (they were saved tolocalStorage!).Once you have had a "play" with the demo, come back andbuild it!!

Thepurpose of thisTodo Listmini projectis topractice your "VanillaJS" skills andconsolidate your understanding of The Elm Architecture (TEA)by creating a real worlduseable App followingstrictDocumentation and Test Driven Development.

This willshow you that it's not onlypossibleto write docs and testsfirst,you will seefirst hand thatcode ismore concise,well-documented and thuseasier to maintainand you will get your work donemuch faster.

These arefoundational skills that willpayimmediate returns on the time invested,and willcontinue toreturn "interest"for as long as you write (and people use your) software!

It'simpossible to "over-state" howvital writing tests firstis to both yourpersonal effectiveness andlong-term sanity.Thankfully, by the end of this chapter, you will see howeasy it is.

Build a fully functional "Todo List" Application!
Along the way we will cover:

• Building an App using a pre-made CSS Styles/Framework!
• The Document Object Model (DOM) + JSDOM
• Browser Routing/Navigation
• Local Storage for Offline Support
• Keyboard event listeners for rapid todo list creation and editing!

We will be abstracting all "architecture" related ("generic") codeinto a "mini frontend framework" called "elmish".(elmish is inspired by Elm but only meant for educational purposes!)

The journey to creatingelmish is captured inelmish.mdand fully documented code is inelmish.js.This means our Todo List App can be as conciseand "declarative" as possible.

If you areunfamiliar with Todo lists, simply put:they are a way of keeping a list of the tasks that need to be done.
see:https://en.wikipedia.org/wiki/Time_management#Setting_priorities_and_goals

Todo Lists or "Checklists" are thebest way of tracking tasks.
Atul Gawande wrote asuperb book on this subject:
https://www.amazon.com/Checklist-Manifesto-How-Things-Right/dp/0312430000
Or if you don't have time to read,watch:https://www.youtube.com/results?search_query=checklist+manifesto

If you have not come across TodoMVC before,it's a website that showcases various "frontend" frameworksusing a common user interface (UI): a Todo List Application.

Wehighly recommend checking out the following links:

• Website:https://todomvc.com
• GitHub project:https://github.com/tastejs/todomvc

For our purposes we will simply be re-using theTodoMVCCSSto make our TEA Todo Listlook good(not have to "worry" about styles so we canfocus on functionality).All the JavaScript code will be written "from scratch"to ensure that everything is clear.

This tutorial is for anyone/everyone who wantsto develop their "core" JavaScript skills (without using a framework/library)while building a "real world" (fully functional) Todo List Application.

As always, if you get "stuck",please open an issue:https://github.com/dwyl/javascript-todo-list-tutorial/issuesby opening a question you helpeveryone learn more effectively!

Most beginners with basic JavaScript and HTML knowledgeshould be able to follow this example without any prior experience.The code is commented and the most "complex" function is an event listener.With that said, if you feel "stuck" at any point,please consult the recommend reading (and Google)and if you cannot find an answer,please open an issue!

• Test Driven Developement:https://github.com/dwyl/learn-tdd
• Tape-specific syntax:https://github.com/dwyl/learn-tape
• Elm Architecture:https://github.com/dwyl/learn-elm-architecture-in-javascript

Start by cloning this repository to yourlocalhostso that you can follow the example/tutorial offline:

git clone https://github.com/dwyl/javascript-todo-list-tutorial.git

Install thedevDependencies so you can run the tests:

cd javascript-todo-list-tutorial&& npm install

Now you haveeverything you need to build a Todo List from scratch!

In order tosimplify the code for our Todo List App,weabstracted much of the "generic" codeinto a "front-end micro framework" calledElm(ish).The functions & functionality ofElm(ish) should befamiliar to youso youshould be able to build the Todo List using theElm(ish)helper functions e.g:mount,div,input androute.

You canopt toeither:

a) read theElm(ish) docs/tutorialelmish.mdbefore building the Todo List App -this will give you both TDD practiceand a deeper understanding of building a micro framework.i.e. "prospective learning"

b) refer theElm(ish) docs/tutorialelmish.mdwhile building the Todo List App when you "need to know"how one of the helper functions works. i.e. "contextual learning"

c)onlyconsult theElm(ish) docs/tutorialelmish.mdif you are "stuck"while building the Todo List App.i.e. "debug learning"

The choice is yours; there is no "right" way to learn.

Before diving intobuilding the Todo List App,we need to consider how we are going totest it.By ensuring that we followTDD from thestart of an App,we will have"no surprises"andavoid having to "correct" any"bad habits".

We will be usingTape andJSDOM for testingboth our functions and the final application.If you arenew to either of these tools,please see:github.com/dwyl/learn-tapeandfront-end-with-tape.md

We will be usingJSDOC for documentation.Please seeour tutorial if this is new to you.

Create anew directory e.g:/todo-appSo that you can build the Todo List from scratch!

In your editor/terminal create the following files:

• test/todo-app.test.js
• lib/todo-app.js
• index.html

These file names should be self-explanatory, but if unclear,todo-app.test.js is where we will write the tests for ourTodo List App.todo-app.js is where all the JSDOCs and functionsfor our Todo List App will be written.

In order to run our test(s), we need some "setup" codethat "requires" the libraries/files so we canexecute the functions.

In thetest/todo-app.test.js file, type the following code:

consttest=require('tape');// https://github.com/dwyl/learn-tapeconstfs=require('fs');// to read html files (see below)constpath=require('path');// so we can open files cross-platformconsthtml=fs.readFileSync(path.resolve(__dirname,'../index.html'));require('jsdom-global')(html);// https://github.com/rstacruz/jsdom-globalconstapp=require('../lib/todo-app.js');// functions to testconstid='test-app';// all tests use 'test-app' as root element

Most of this code should befamiliar to youif you have followed previous tutorials.If anything isunclear please revisithttps://github.com/dwyl/learn-tapeandfront-end-with-tape.md

If you attempt to run the test file:node test/todo-app.test.jsyou should see no output.
(this is expected as we haven't written any tests yet!)

Themodel for our Todo List App isboringly simple.All we need is anObject with atodos key which has an Array of Objects as it's value:

{todos:[{id:1,title:"Learn Elm Architecture",done:true},{id:2,title:"Build Todo List App",done:false},{id:3,title:"Win the Internet!",done:false}]}

todos is anArray ofObjects and each Todo (Array) itemhas 3 keys:

• id: the index in the list.
• title: the title/description of the todo item.
• done: aboolean indicating if the item is complete or still "todo".

The TodoMVC Specification requires us to display acounterof the items in the Todo list:https://github.com/tastejs/todomvc/blob/main/app-spec.md#counter

In order to display thecount of items in the Todo list,wecould store 3 values in the model:

• total_items - the total number of items, in this case 3.
• completed_items - the number of completed items. in this case 1.
• incomplete_items - the number of items still to be done; 2.

Each time anew item is added to the listwe would need to updateboth thetotal_itemsand theincomplete_itemsvalues in themodel.And each time anitem gets checked off as "done",we would need to updateboth theincomplete_itemsand thecompleted_items.This isunnecessary effort we can avoid.We can simplycompute these values based on the data in thetodos Arrayand display them for the user without storing any additional data.

Instead ofstoring any additional data for acounter in the model(the count of active and completed Todo items),we willcompute the count and display the count at "runtime".We don'tneed to store any additional data in themodel.This may use a few CPU cycles computing thecounteach time the view is rendered but that's "OK"!Even on anancient Android devicethis will only take a millisecond to compute andwon't "slow down" the app or affect UX.

See below for how the three counts are computed.

e.g: in the model above there are 3 todo items in thetodos Array;2 items which are "active" (done=false)and 1 which is "done" (done=true).

Given that themodel is "just data"(it hasno "methods" becauseElm(ish) is"Functional"not"Object Oriented"),there is nofunctionality to test.We are merely going to test for the "shape" of the data.

In thetest/todo-app.test.js file, append following test code:

test('todo `model` (Object) has desired keys',function(t){constkeys=Object.keys(app.model);t.deepEqual(keys,['todos','hash'],"`todos` and `hash` keys are present.");t.true(Array.isArray(app.model.todos),"model.todos is an Array")t.end();});

If yourun this test in your terminal:

node test/todo-app.test.js

You should seeboth assertionsfail:

Write theminimum code required topass this test intodo-app.js.e.g:

/** * initial_model is a simple JavaScript Object with two keys and no methods. * it is used both as the "initial" model when mounting the Todo List App * and as the "reset" state when all todos are deleted at once. */varinitial_model={todos:[],// empty array which we will fill shortlyhash:"#/"// the hash in the url (for routing)}/* module.exports is needed to run the functions using Node.js for testing! *//* istanbul ignore next */if(typeofmodule!=='undefined'&&module.exports){module.exports={model:initial_model}}

Once you save thetodo-app.js file and re-run the tests.

node test/todo-app.test.js

Youshould expect to see both assertionspassing:

We're off to agreat start! Let's tackle some actualfunctionality next!

Theupdate function is the"brain"of the App.

TheJSDOC for ourupdate function is:

/** * `update` transforms the `model` based on the `action`. *@param {String} action - the desired action to perform on the model. *@param {Object} model - the App's data ("state"). *@return {Object} new_model - the transformed model. */

As with theupdate in ourcounter examplethe function body is aswitch statementthat "decides" how to handle a request based on theaction(also known as the "message").

Given that weknow that ourupdate function "skeleton"will be aswitch statement(because that is the "TEA" pattern)a good test tostart with is thedefault case.

Append the following test code intest/todo-app.test.js:

test('todo `update` default case should return model unmodified',function(t){constmodel=JSON.parse(JSON.stringify(app.model));constunmodified_model=app.update('UNKNOWN_ACTION',model);t.deepEqual(model,unmodified_model,"model returned unmodified");t.end();});

If yourun this test in your terminal:

node test/todo-app.test.js

You should see the assertionfail:

Write theminimum code necessary to pass the test.

Yes, we could just write:

functionupdate(action,model){returnmodel;}

And thatwould make the testpass.

But, in light of the fact that weknow theupdatefunction body will contain aswitch statement,make the test pass by returning themodelunmodified in thedefault case.

e.g:

/** * `update` transforms the `model` based on the `action`. *@param {String} action - the desired action to perform on the model. *@param {Object} model - the App's (current) model (or "state"). *@return {Object} new_model - the transformed model. */functionupdate(action,model){switch(action){// action (String) determines which casedefault:// if action unrecognised or undefined,returnmodel;// return model unmodified}// default? https://softwareengineering.stackexchange.com/a/201786/211301}

When you re-run the test(s) in your terminal:

node test/todo-app.test.js

You should see this assertion pass:

Now that we have apassing testfor thedefault case in ourupdate function,we can move on tothinking about the first (and most fundamental) pieceoffunctionality in the Todo List App: Adding an item to the list.

This is both thefirst "feature" a "user" will encounter andby far the mostused feature of a Todo List.
(bydefinition people add more items to their list than they finish,to finish everything we would have tolive forever!)

Adding a new todo item's text shouldappend the todo itemObject to themodel.todos Array.
Such that themodel is transformed (data is added) in the following way:

BEFORE:

{todos:[],hash:"#/"}

AFTER:

{todos:[{id:1,"Add Todo List Item",done:false}],hash:"#/"}

While considering the "Acceptance Criteria"for adding an item to the Todo List,wenotice that ourupdateJSDOCand corresponding function "signature" (defined above) as:

/** * `update` transforms the `model` based on the `action`. *@param {String} action - the desired action to perform on the model. *@param {Object} model - the App's (current) model (or "state"). *@return {Object} updated_model - the transformed model. */functionupdate(action,model){switch(action){// action (String) determines which casedefault:// if action unrecognised or undefined,returnmodel;// return model unmodified}// default? https://softwareengineering.stackexchange.com/a/201786/211301}

does not have aparameter for passing in the Todo List item Text (title),i.e. how do we add "data" to themodel...?

That's "Oh kay"! (don't panic!)
If wetry to think about implementation up-front,we wouldinvariably be "over-thinking" thingsand get "stuck" in the"analysis paralysis"of"waterfall"

As you areabout to see, we caneasily change the function signature,in thenext testwithout affecting our exiting (passing) test!

As youpractice "DDD" & "TDD" you will begin toappreciateand evenembrace themental agility that comes fromnot "over-thinking" things.

Whenever you encounter a "New Requirement"(or realise that you didn'tfully consider theoriginal requirements),you know that yoursuite of tests has"got yourback".
You can "refactor" a function'simplementation to your heart's content,safe in the knowledge that all yourexisting tests still pass.i.e. therest of the app "still works"exactly as expected.

We don't want to "mess with" either of the other two (existing) parameters,bothaction andmodel have clearly defined purposes,but weneed a way to pass "data" into theupdate function!

With that in mind, let'samend theupdateJSDOC commentand function signature to:

/** * `update` transforms the `model` based on the `action`. *@param {String} action - the desired action to perform on the model. *@param {Object} model - the App's (current) model (or "state"). *@param {String} data - data we want to "apply" to the item. e.g: item Title. *@return {Object} updated_model - the transformed model. */functionupdate(action,model,data){switch(action){// action (String) determines which casedefault:// if action unrecognised or undefined,returnmodel;// return model unmodified}// default? https://softwareengineering.stackexchange.com/a/201786/211301}

Without makingany other changes, re-run the tests:

node test/todo-app.test.js

Everything should still pass:

Congratulations! You justextended a function (signature)without affecting anyexisting tests.

Append the following test code to yourtest/todo-app.test.js file:

test('`ADD` a new todo item to model.todos Array via `update`',function(t){constmodel=JSON.parse(JSON.stringify(app.model));// initial statet.equal(model.todos.length,0,"initial model.todos.length is 0");constupdated_model=app.update('ADD',model,"Add Todo List Item");constexpected={id:1,title:"Add Todo List Item",done:false};t.equal(updated_model.todos.length,1,"updated_model.todos.length is 1");t.deepEqual(updated_model.todos[0],expected,"Todo list item added.");t.end();});

If yourun this test in your terminal:

node test/todo-app.test.js

You should see the assertionfail:

With the above test as your "guide",write thebare minimum code necessary to make all assertions pass.

Sample implementation:

/** * `update` transforms the `model` based on the `action`. *@param {String} action - the desired action to perform on the model. *@param {Object} model - the App's (current) model (or "state"). *@param {String} data - the data we want to "apply" to the item. *@return {Object} updated_model - the transformed model. */functionupdate(action,model,data){varnew_model=JSON.parse(JSON.stringify(model))// "clone" the modelswitch(action){// and an action (String) runs a switchcase'ADD':new_model.todos.push({id:model.todos.length+1,title:data,done:false});break;default:// if action unrecognised or undefined,returnmodel;// return model unmodified}// see: https://softwareengineering.stackexchange.com/a/201786/211301returnnew_model;}

thecase 'ADD' is therelevant code.

Wasyour implementationsimilar...?
If you were able to make itsimpler,please share!

Once you have the test(s)passing e.g:

Let's move on to thenext functionality!

Checking off a todo item involves changing the value of thedone propertyfromfalse totrue. e.g:

FROM:

{todos:[{id:1,"Toggle a todo list item",done:false}]}

TO:

{todos:[{id:1,"Toggle a todo list item",done:true}]}

Given that we have already defined ourupdate function above,we can dive straight into writing atest:

Append the following test code to yourtest/todo-app.test.js file:

test('`TOGGLE` a todo item from done=false to done=true',function(t){constmodel=JSON.parse(JSON.stringify(app.model));// initial stateconstmodel_with_todo=app.update('ADD',model,"Toggle a todo list item");constitem=model_with_todo.todos[0];constmodel_todo_done=app.update('TOGGLE',model_with_todo,item.id);constexpected={id:1,title:"Toggle a todo list item",done:true};t.deepEqual(model_todo_done.todos[0],expected,"Todo list item Toggled.");t.end();});

execute the test:

node test/todo-app.test.js

You should see somethingsimilar to the following:

With the above test as your "guide",write theminimum code necessary to make the test pass.(ensure that you continue to make a "copy" of themodelrather than "mutate" it)

Once you make itpass you should see:

Try to make the test pass alone (or with your pairing partner).If you get "stuck" see:todo-app.js

Yes, youguessed it!Choosing to name theaction as "TOGGLE"isprecisely because we don'tneedto have aseparate functionto "undo" an item if it has been "checked off".

Append the following test code to yourtest/todo-app.test.js file:

test('`TOGGLE` (undo) a todo item from done=true to done=false',function(t){constmodel=JSON.parse(JSON.stringify(app.model));// initial stateconstmodel_with_todo=app.update('ADD',model,"Toggle a todo list item");constitem=model_with_todo.todos[0];constmodel_todo_done=app.update('TOGGLE',model_with_todo,item.id);constexpected={id:1,title:"Toggle a todo list item",done:true};t.deepEqual(model_todo_done.todos[0],expected,"Toggled done=false >> true");// add another item before "undoing" the original one:constmodel_second_item=app.update('ADD',model_todo_done,"Another todo");t.equal(model_second_item.todos.length,2,"there are TWO todo items");// Toggle the original item such that: done=true >> done=falseconstmodel_todo_undone=app.update('TOGGLE',model_second_item,item.id);constundone={id:1,title:"Toggle a todo list item",done:false};t.deepEqual(model_todo_undone.todos[0],undone,"Todo item Toggled > undone!");t.end();});

You should notneed to modify any of the code in theupdate function.The above test should justpass based on the code you wrote above.If it doesnot, thenrevise your implementationof theTOGGLE case inupdate untilall tests pass:

It won't have "escaped" you thatso far we have not writtenany codethat auser can actuallyinteract with.

So far we havesuccessfully added twocase blocks in theswitch statementof ourupdate function. We now have the twobasic functions requiredto bothADD a new todo list item to themodel.todos Arrayand check-off a todo list item as "done" using theTOGGLE action.This is "enough" functionality to startusing the todo list (ourselves)andUX-testing it withprospective "users".

If you followed through the "Elm(ish)" tutorialelmish.mdyou will have seen that we created asampleview in the last fewteststo "exercise" the DOM element creation functions.This means that wealready know how to build aview for our Todo List App!We "just" need toadapt theview we made inElm(ish) to displaythe data in ourmodel.

Let's return to the samplemodel from above:

{todos:[{id:1,title:"Learn Elm Architecture",done:true},{id:2,title:"Build Todo List App",done:false},{id:3,title:"Win the Internet!",done:false}],hash:'#/'// the "route" to display}

The model containsthree items in thetodos Array.
The first is complete (done=true)whereas the second and third items are still "todo" (done=false).

This is what thismodel looks like in the "VanillaJS"TodoMVC:

Ourquest in the next "pomodoro" is to re-create thisusing the DOM functions we created inElm(ish)!

For now,ignore the<footer> (below the Todo List)andjust focus on rendering thelist itself.

In your web browser, openDeveloperToolsandinspect the HTML for the Todo list:https://todomvc.com/examples/vanillajs/

This is the HTML copied directly from the browser:

<sectionclass="main"style="display: block;"><inputclass="toggle-all"type="checkbox"><labelfor="toggle-all">Mark all as complete</label><ulclass="todo-list"><lidata-id="1533501855500"class="completed"><divclass="view"><inputclass="toggle"type="checkbox"><label>Learn Elm Architecture</label><buttonclass="destroy"></button></div></li><lidata-id="1533501861171"class=""><divclass="view"><inputclass="toggle"type="checkbox"><label>Build Todo List App</label><buttonclass="destroy"></button></div></li><lidata-id="1533501867123"class=""><divclass="view"><inputclass="toggle"type="checkbox"><label>Win the Internet!</label><buttonclass="destroy"></button></div></li></ul></section>

Note: there is "redundant" markup in this HTML in the form of a<div>inside the<li>, for now we are just replicating the HTML "faithfully",we can "prune" it later.

From this HTMl we can write our"Technical Acceptance Criteria":

• Todo List items should be displayed as list items<li>in anunordered list<ul>.
• Each Todo List item<li> should contain a<div>with aclass="view" which "wraps":
  • <input type="checkbox"> - the "checkbox"that people can "Toggle" to change the "state"of the Todo item from "active" to "done"(which updates the modelFrom:model.todos[id].done=falseTo:model.todos[id].done=true)
  • <label> - the text content ("title") of the todo list item
  • <button> - the button the personcan click/tap todelete a Todo item.

Given themodel (above),

• There is a<ul> with 3<li> (list items)rendered in theview.
• Thefirst<li> has an<input type="checkbox">which ischecked (done=true)
• Theremaining<li>'s have<input type="checkbox">that areunchecked (done=false)

Let's "tackle" thefirst assertionfirst:

It'salways a good idea to "break apart" a test into smaller testsbecause it means we will write smaller(and thusmore maintainable) "composable" functions.With that in mind, let's add the followingtest totest/todo-app.test.js:

test.only('render_item HTML for a single Todo Item',function(t){constmodel={todos:[{id:1,title:"Learn Elm Architecture",done:true},],hash:'#/'// the "route" to display};// render the ONE todo list item:document.getElementById(id).appendChild(app.render_item(model.todos[0]))constdone=document.querySelectorAll('.completed')[0].textContent;t.equal(done,'Learn Elm Architecture','Done: Learn "TEA"');constchecked=document.querySelectorAll('input')[0].checked;t.equal(checked,true,'Done: '+model.todos[0].title+" is done=true");elmish.empty(document.getElementById(id));// clear DOM ready for next testt.end();});

After saving thetest/todo-app.test.js file, if you attempt to run it:

node test/todo-app.test.js

you will see something like this:

Given the test above, I added the following code to mytodo-app.js file:

/* if require is available, it means we are in Node.js Land i.e. testing! *//* istanbul ignore next */if(typeofrequire!=='undefined'&&this.window!==this){var{ a, button, div, empty, footer, input, h1, header, label, li, mount,    route, section, span, strong, text, ul}=require('./elmish.js');}/** * `render_item` creates an DOM "tree" with a single Todo List Item * using the "elmish" DOM functions (`li`, `div`, `input`, `label` and `button`) * returns an `<li>` HTML element with a nested `<div>` which in turn has the: *   `<input type=checkbox>` which lets users to "Toggle" the status of the item *   `<label>` which displays the Todo item text (`title`) in a `<text>` node *   `<button>` lets people "delete" a todo item. * see: https://github.com/dwyl/learn-elm-architecture-in-javascript/issues/52 *@param  {Object} item the todo item object *@return {Object} <li> DOM Tree which is nested in the <ul>. *@example * // returns <li> DOM element with <div>, <input>. <label> & <button> nested * var DOM = render_item({id: 1, title: "Build Todo List App", done: false}); */functionrender_item(item){return(li(["data-id="+item.id,"id="+item.id,item.done ?"class=completed" :""],[div(["class=view"],[input(["class=toggle","type=checkbox",(item.done ?"checked=true" :"")],[]),label([],[text(item.title)]),button(["class=destroy"])])// </div>])// </li>)}

Add therender_item to themodule.exports at the end of the file:

if(typeofmodule!=='undefined'&&module.exports){module.exports={model:initial_model,update:update,render_item:render_item,// export so that we can unit test}}

This will make the test pass:

Now that we have arender_item functionthat renders asingle<li> (todo list item),we can create another function whichuses therender_item in a "loop",to createseveral<li> nested in a<ul>.

Append the following test code to yourtest/todo-app.test.js file:

test('render "main" view using (elmish) HTML DOM functions',function(t){constmodel={todos:[{id:1,title:"Learn Elm Architecture",done:true},{id:2,title:"Build Todo List App",done:false},{id:3,title:"Win the Internet!",done:false}],hash:'#/'// the "route" to display};// render the "main" view and append it to the DOM inside the `test-app` node:document.getElementById(id).appendChild(app.render_main(model));// test that the title text in the model.todos was rendered to <label> nodes:document.querySelectorAll('.view').forEach(function(item,index){t.equal(item.textContent,model.todos[index].title,"index #"+index+" <label> text: "+item.textContent)})constinputs=document.querySelectorAll('input');// todo items are 1,2,3[true,false,false].forEach(function(state,index){t.equal(inputs[index+1].checked,state,"Todo #"+index+" is done="+state)})elmish.empty(document.getElementById(id));// clear DOM ready for next testt.end();});

If you attempt to run this test:

node test/todo-app.test.js

you will see something like this:

Given your knowledge of implementing therender_item function above,and your skills with JavaScript loops, create yourrender_main function,to make the tests pass.

If you get "stuck" there is areference implementation in:todo-app.js

All our tests passand we have100% test coverage:

This means we are writing the "bare minimum" code necessaryto meet all acceptance criteria (requirements),which isbothfaster andmore maintainable!
Onwards!

Referring again to therendered HTMLonhttps://todomvc.com/examples/vanillajs as our "guide":

"copy-pasted" of therendered HTML from the Dev Tools:

<footerclass="footer"style="display: block;"><spanclass="todo-count"><strong>2</strong> items left</span><ulclass="filters"><li><ahref="#/"class="selected">All</a></li><li><ahref="#/active">Active</a></li><li><ahref="#/completed">Completed</a></li></ul><buttonclass="clear-completed"style="display: block;">    Clear completed</button></footer>

These are the criteria (checklist) as described inissues/53:

• render_footer returns a<footer> DOM element which can be rendered directly to thedocument ornested in another DOM element.
• <footer> contains:
  • <span> which contains
    • atext node with:"{count} item(s) left".pseudocode:{model.todos.filter( (i) => { i.done==false })}item{model.todos.length > 1 ? 's' : '' } left
  • <ul> containing 3<li> with the following links (<a>):
    • ShowAll:<a href="#/">All</a>
      • class="selected" should only appear on the selected menu/navigation item.this should be "driven" by themodel.hash property.
    • ShowActive: <a href="#/active">Active</a>
    • ShowCompleted:<a href="#/completed">Completed</a>
  • <button>willClear allCompleted items.sample code:
    new_model.todos = model.todos.filter(function(item) { return item.done === false })

"armed" with the acceptance criteriachecklistand the"informative prior"(theexperience we havealready gained)from building the previous view functionsrender_item andrender_mainweestimate withreasonable confidencethat it will take us25 minutes (one "pomodoro)to:

• Craft theJSDOC commentdocumenting therender_footer functionso that all future developers willeasily understand what the function does.
• Write a (unit)test covering the acceptance criteria (test first!)
• Write the (bare minimum) code topass the test assertions.

Note On Time Estimates: if it takeslonger than25 mins "budget",don't panic or feel like you have "failed",it's not a "problem" ...it's just "more data" (knowledge/experience)that you can incorporate into improvingfuture estimates!over time you will getreally good at estimating,this is just astarting point

Here is a sample comment which documents therender_footer function:

/** * `render_footer` renders the `<footer>` of the Todo List App * which contains count of items to (still) to be done and a `<ul>` "menu" * with links to filter which todo items appear in the list view. *@param {Object} model - the App's (current) model (or "state"). *@return {Object} <section> DOM Tree which containing the <footer> element. *@example * // returns <footer> DOM element with other DOM elements nested: * var DOM = render_footer(model); */

Write yourown JSDOC or add these lines to yourtodo-app.js file.

Here is a sample test you can add to yourtest/todo-app.test.js file:(if you feel confident in your TDD skills,you couldtry to write your own test/assertions...)

test.only('render_footer view using (elmish) HTML DOM functions',function(t){constmodel={todos:[{id:1,title:"Learn Elm Architecture",done:true},{id:2,title:"Build Todo List App",done:false},{id:3,title:"Win the Internet!",done:false}],hash:'#/'// the "route" to display};// render_footer view and append it to the DOM inside the `test-app` node:document.getElementById(id).appendChild(app.render_footer(model));// todo-count should display 2 items left (still to be done):constleft=document.getElementById('count').innerHTML;t.equal(left,"<strong>2</strong> items left","Todos remaining: "+left);// count number of footer <li> items:t.equal(document.querySelectorAll('li').length,3,"3 <li> in <footer>");// check footer link text and href:constlink_text=['All','Active','Completed'];consthrefs=['#/','#/active','#/completed'];document.querySelectorAll('a').forEach(function(a,index){// check link text:t.equal(a.textContent,link_text[index],"<footer> link #"+index+" is: "+a.textContent+" === "+link_text[index]);// check hrefs:t.equal(a.href.replace('about:blank',''),hrefs[index],"<footer> link #"+index+" href is: "+hrefs[index]);});// check for "Clear completed" button in footer:constclear=document.querySelectorAll('.clear-completed')[0].textContent;t.equal(clear,'Clear completed','<button> in <footer> "Clear completed"');elmish.empty(document.getElementById(id));// clear DOM ready for next testt.end();});

Run this test:

node test/todo-app.test.js

you will see something like this:

Given the docs and test above, attempt to write therender_footer function.

Note: for now we arenot "concerned"with what happens when the "Clear completed"<buton> is clicked/tapped.We will "cover" that below. For now, focus on rendering the DOM.

If you get "stuck" trying to make the tests pass, first keep trying!
Then "ask a friend" and finally, consult thereference implementation in:todo-app.js

For good measure, we add asecond test to check our "pluarisation":

test('render_footer 1 item left (pluarisation test)',function(t){constmodel={todos:[{id:1,title:"Be excellent to each other!",done:false}],hash:'#/'// the "route" to display};// render_footer view and append it to the DOM inside the `test-app` node:document.getElementById(id).appendChild(app.render_footer(model));// todo-count should display "1 item left" (still to be done):constleft=document.getElementById('count').innerHTML;t.equal(left,"<strong>1</strong> item left","Todos remaining: "+left);elmish.empty(document.getElementById(id));// clear DOM ready for next testt.end();});

This testshould pass without any further code needing to be written.

Once you have written the code to pass the tests,you should see something like this:

Now that we have the individual ("lower order") functionsrender_main#51,render_item#52,andrender_footer#53for rendering thesections of the todo app,we can write theview function to render theentire app!

With themain andfooter "partial" views built,the overallview is quite simple:

To save on repetition, and illustrate just howsimpletheview is,this is the "HTML" with the<section class"main"> and<footer>partials replaced by invocationsto the respective functionsrender_main andrender_footer:

<sectionclass="todoapp"><headerclass="header"><h1>todos</h1><inputclass="new-todo"placeholder="What needs to be done?"autofocus=""></header>  render_main(model)  render_footer(model)</section>

Theview displays:

• <section> inside which the app is rendered.
• <h1> containing the title text "todos".
• <input>has placeholder text"What needs to be done?"
• <ul> list of todo itemshaszero items by default (based on theinitial_model)
• <footer> count is Zero when the app is firstrendered with no todos in themodel.

Here is a sample JSDOC comment you can add to yourtodo-app.js file:

/** * `view` renders the entire Todo List App * which contains count of items to (still) to be done and a `<ul>` "menu" * with links to filter which todo items appear in the list view. *@param {Object} model - the App's (current) model (or "state"). *@return {Object} <section> DOM Tree which containing all other DOM elements. *@example * // returns <section> DOM element with other DOM els nested: * var DOM = view(model); */

These should be pretty familiar to you by now.If you feel comfortable extending it with more detail, go for it!

A sample test for theview functionyou can add to yourtest/todo-app.test.js file:(if you feel confident in your TDD skills,you couldtry to write your own test/assertions...)

test.only('view renders the whole todo app using "partials"',function(t){// render the view and append it to the DOM inside the `test-app` node:document.getElementById(id).appendChild(app.view(app.model));// initial_modelt.equal(document.querySelectorAll('h1')[0].textContent,"todos","<h1>todos");// placeholder:constplaceholder=document.getElementById('new-todo').getAttribute("placeholder");t.equal(placeholder,"What needs to be done?","paceholder set on <input>");// todo-count should display "0 items left" (based on initial_model):constleft=document.getElementById('count').innerHTML;t.equal(left,"<strong>0</strong> items left","Todos remaining: "+left);elmish.empty(document.getElementById(id));// clear DOM ready for next testt.end();});

Run this test:

node test/todo-app.test.js

you will see something like this ("Red"):

You should have the knowledge & skillto write theview function and make the test pass.

If you get "stuck" trying to make the tests pass, first keep trying!
Then "ask a friend" and finally, consult thereference implementation in:todo-app.js

When you runnpm test you should see something like this:

So far we have made alot of progress with our Todo List Appquest,however if we were tostop working on thisnow we would havenothing to show a "user".Users can'tinteract with functions,even those withgreat test coverage!

What weneed is to start putting all the pieces togetherinto a functioning app!

Open yourindex.html fileand ensure that the following lines are in the<body>:

<body><divid="app"></div><!-- CSS Styles are 100% optional. but they make it look *much* nicer --><linkrel="stylesheet"href="todomvc-common-base.css"><linkrel="stylesheet"href="todomvc-app.css"><scriptsrc="elmish.js"></script><scriptsrc="todo-app.js"></script><script>varmodel={todos:[{id:1,title:"Learn Elm Architecture",done:true},{id:2,title:"Build Todo List App",done:false},{id:3,title:"Win the Internet!",done:false}],hash:'#/'// the "route" to display};mount(model,update,view,'app');</script><!-- Below this point is all related to the Tests for the App --><divid="test-app"></div><!-- Create a test-app div to mount the app --></body>

For a complete "snapshot" of theindex.html file here,see:index.html

If you run the project with commandnpm startand navigate to:http://127.0.0.1:8000/

You should see:

So theviewlooks like a TodoMVC Todo List(mostly thanks to the imported CSS),however we still cannotinteract with the app.

Next we're going to move to "wiring-up" thefunctionalityto construct the UX.

With all the "foundation" well defined and tested,we canconfidently move on to building out thefeaturespeopleusing the app will interact with!

Take a look at this list of test output:https://github.com/tastejs/todomvc/tree/main/tests#example-output

TodoMVC  1. No Todos    ✓ should hide #main and #footer (201ms)  2. New Todo    ✓ should allow me to add todo items (548ms)    ✓ should clear text input field when an item is added (306ms)    ✓ should trim text input (569ms)    ✓ should show #main and #footer when items added (405ms)  3. Mark all as completed    ✓ should allow me to mark all items as completed (1040ms)    ✓ should allow me to clear the completion state of all items (1014ms)    ✓ complete all checkbox should update state when items are completed (1413ms)  4. Item    ✓ should allow me to mark items as complete (843ms)    ✓ should allow me to un-mark items as complete (978ms)    ✓ should allow me to edit an item (1155ms)    ✓ should show the remove button on hover  5. Editing    ✓ should hide other controls when editing (718ms)    ✓ should save edits on enter (1093ms)    ✓ should save edits on blur (1256ms)    ✓ should trim entered text (1163ms)    ✓ should remove the item if an empty text string was entered (1033ms)    ✓ should cancel edits on escape (1115ms)  6. Counter    ✓ should display the current number of todo items (462ms)  7. Clear completed button    ✓ should display the number of completed items (873ms)    ✓ should remove completed items when clicked (898ms)    ✓ should be hidden when there are no items that are completed (893ms)  8. Persistence    ✓ should persist its data (3832ms)  9. Routing    ✓ should allow me to display active items (871ms)    ✓ should allow me to display completed items (960ms)    ✓ should allow me to display all items (1192ms)    ✓ should highlight the currently applied filter (1095ms)27 passing (1m)

We are going to write each one of these tests and then

Add the following test to yourtest/todo-app.test.js file:

test.only('1. No Todos, should hide #footer and #main',function(t){// render the view and append it to the DOM inside the `test-app` node:document.getElementById(id).appendChild(app.view({todos:[]}));// No Todosconstmain_display=window.getComputedStyle(document.getElementById('main'));t.equal('none',main_display._values.display,"No Todos, hide #main");constmain_footer=window.getComputedStyle(document.getElementById('footer'));t.equal('none',main_footer._values.display,"No Todos, hide #footer");elmish.empty(document.getElementById(id));// clear DOM ready for next testt.end();});

Run the test with:

node test/todo-app.js

You should see the following output:

Simply replace the instances of"style=display: block;" in the view codewith a reference to a "computed style" e.g:

// Requirement #1 - No Todos, should hide #footer and #mainvardisplay="style=display:"+(model.todos.length>0 ?+"block" :"none");

You should see:

Testing it in your web browser you should see the desired result:

If you get stuck trying to make the test pass, see:todo-app.js

Recommended reading on CSSvisibility:hidden vs.display:nonethe difference isimportant for UI:https://stackoverflow.com/questions/133051/what-is-the-difference-between-visibilityhidden-and-displaynone

The second batch of tests involves adding a new todo item to the list:

2. New Todo  ✓ should allow me to add todo items (548ms)  ✓ should clear text input field when an item is added (306ms)  ✓ should trim text input (569ms)  ✓ should show #main and #footer when items added (405ms)

Let's create a test with these 4 assertions.

Add the following code/test to yourtest/todo-app.test.js file:

// Testing localStorage requires "polyfil" because:// https://github.com/jsdom/jsdom/issues/1137 ¯\_(ツ)_/¯// globals are usually bad! but a "necessary evil" here.global.localStorage=global.localStorage ?global.localStorage :{getItem:function(key){constvalue=this[key];returntypeofvalue==='undefined' ?null :value;},setItem:function(key,value){this[key]=value;},removeItem:function(key){deletethis[key]}}localStorage.removeItem('elmish_store');test('2. New Todo, should allow me to add todo items',function(t){elmish.empty(document.getElementById(id));// render the view and append it to the DOM inside the `test-app` node:elmish.mount({todos:[]},app.update,app.view,id,app.subscriptions);constnew_todo=document.getElementById('new-todo');// "type" content in the <input>:consttodo_text='Make Everything Awesome!     ';// deliberate whitespace!new_todo.value=todo_text;// trigger the [Enter] keyboard key to ADD the new todo:new_todo.dispatchEvent(newKeyboardEvent('keyup',{'keyCode':13}));constitems=document.querySelectorAll('.view');t.equal(items.length,1,"should allow me to add todo items");// check if the new todo was added to the DOM:constactual=document.getElementById('1').textContent;t.equal(todo_text.trim(),actual,"should trim text input")// subscription keyCode trigger "branch" test (should NOT fire the signal):constclone=document.getElementById(id).cloneNode(true);new_todo.dispatchEvent(newKeyboardEvent('keyup',{'keyCode':42}));t.deepEqual(document.getElementById(id),clone,"#"+id+" no change");// check that the <input> was reset after the new item was addedt.equal(new_todo.value,'',"should clear text input field when an item is added")constmain_display=window.getComputedStyle(document.getElementById('main'));t.equal('block',main_display._values.display,"should show #main and #footer when items added");constmain_footer=window.getComputedStyle(document.getElementById('footer'));t.equal('block',main_footer._values.display,"item added, show #footer");elmish.empty(document.getElementById(id));// clear DOM ready for next testlocalStorage.removeItem('elmish_store');// clear "localStorage" for next testt.end();});

Run the test with:

node test/todo-app.js

You should see the following output:

So far in the Todo List Appwe have not implemented anysubscriptions,however, in order to "listen" for the[Enter] key "event"(to add a Todo List item), we need to dive into event listeners.

Thankfully, we touched upon this while buildingElm(ish),if you need a recap, see:elmish.md#subscriptions-for-event-listeners

Try to make the "2. New Todo" batch of testspassby creating (and exporting) asubscriptions functionin yourlib/todo-app.js file.

If you get "stuck", checkout the sample code:todo-app.js > subscriptions

Once you see the tests passing:

Let's add someinteraction!

The third batch of tests involves "Toggling" all todos as "done=true":

3. Mark all as completed  ✓ should allow me to mark all items as completed  ✓ should allow me to clear the completion state of all items  ✓ complete all checkbox should update state when items are completed

Luckily, given that we know how to use aboolean value,thesethree assertions can be "solved" withminimal code.Let's create a test with these 3 assertions.

Add the following code/test to yourtest/todo-app.test.js file:

test.only('3. Mark all as completed ("TOGGLE_ALL")',function(t){elmish.empty(document.getElementById(id));localStorage.removeItem('elmish_'+id);constmodel={todos:[{id:0,title:"Learn Elm Architecture",done:true},{id:1,title:"Build Todo List App",done:false},{id:2,title:"Win the Internet!",done:false}],hash:'#/'// the "route" to display};// render the view and append it to the DOM inside the `test-app` node:elmish.mount(model,app.update,app.view,id,app.subscriptions);// confirm that the ONLY the first todo item is done=true:constitems=document.querySelectorAll('.view');document.querySelectorAll('.toggle').forEach(function(item,index){t.equal(item.checked,model.todos[index].done,"Todo #"+index+" is done="+item.checked+" text: "+items[index].textContent)})// click the toggle-all checkbox to trigger TOGGLE_ALL: >> truedocument.getElementById('toggle-all').click();// click toggle-all checkboxdocument.querySelectorAll('.toggle').forEach(function(item,index){t.equal(item.checked,true,"TOGGLE each Todo #"+index+" is done="+item.checked+" text: "+items[index].textContent)});t.equal(document.getElementById('toggle-all').checked,true,"should allow me to mark all items as completed")// click the toggle-all checkbox to TOGGLE_ALL (again!) true >> falsedocument.getElementById('toggle-all').click();// click toggle-all checkboxdocument.querySelectorAll('.toggle').forEach(function(item,index){t.equal(item.checked,false,"TOGGLE_ALL Todo #"+index+" is done="+item.checked+" text: "+items[index].textContent)})t.equal(document.getElementById('toggle-all').checked,false,"should allow me to clear the completion state of all items")// *manually* "click" each todo item:document.querySelectorAll('.toggle').forEach(function(item,index){item.click();// this should "toggle" the todo checkbox to done=truet.equal(item.checked,true,".toggle.click() (each) Todo #"+index+" which is done="+item.checked+" text: "+items[index].textContent)});// the toggle-all checkbox should be "checked" as all todos are done=true!t.equal(document.getElementById('toggle-all').checked,true,"complete all checkbox should update state when items are completed")elmish.empty(document.getElementById(id));// clear DOM ready for next testlocalStorage.removeItem('elmish_store');t.end();});

Yes, it's a "big" test with several assertions.We prefer to keep them "clustered" together because they testthe functionality as a "block".Some people prefer to split the assertions out into individual unit tests,our advice to the "practical developer" is: be pragmatic!If you are testing the functionality and the test is legible,there's no "harm" in having several assertions.

If you attempt to run the test file:

node test/todo-app.test.js

You will see something like this:

While there mayappear to be "many" assertions in this test,in reality there are only two bits of functionality.

Firstly, we need a newcasein theupdateswitch statement:TOGGLE_ALL.
andsecond we need to add a couple of lines to ourTOGGLEblock tocheck ifall todos aredone=true ordone=false.In the case whereall todos aredone=true we should reflectthis in the "state" of thetoggle-all checkbox.Theeasiest way of representing this in themodel iswith a new property, e.g:model.all_done=truewhenall todos aredone=true.

The only other thing we need to update is therender_mainfunction to includesignal('TOGGLE_ALL') in the attributes array.

Try and make this test pass by yourself before consulting thesample code:lib/todo-app.js

4. Item  ✓ should allow me to mark items as complete (843ms)  ✓ should allow me to un-mark items as complete (978ms)  ✓ should allow me to edit an item (1155ms)  ✓ should show the remove button on hover

Of these requirements, we already have the first two "covered"because we implemented theTOGGLE feature (above).

We can add another "proxy" test just for "completeness":

test.only('4. Item: should allow me to mark items as complete',function(t){elmish.empty(document.getElementById(id));localStorage.removeItem('elmish_'+id);constmodel={todos:[{id:0,title:"Make something people want.",done:false}],hash:'#/'// the "route" to display};// render the view and append it to the DOM inside the `test-app` node:elmish.mount(model,app.update,app.view,id,app.subscriptions);constitem=document.getElementById('0')t.equal(item.textContent,model.todos[0].title,'Item contained in model.');// confirm that the todo item is NOT done (done=false):t.equal(document.querySelectorAll('.toggle')[0].checked,false,'Item starts out "active" (done=false)');// click the checkbox to toggle it to done=truedocument.querySelectorAll('.toggle')[0].click()t.equal(document.querySelectorAll('.toggle')[0].checked,true,'Item should allow me to mark items as complete');// click the checkbox to toggle it to done=false "undo"document.querySelectorAll('.toggle')[0].click()t.equal(document.querySelectorAll('.toggle')[0].checked,false,'Item should allow me to un-mark items as complete');t.end();});

You should not need to write any additional codein order to make this test pass; just run it and move on.

should show the remove button on hover

• should show the<button>on hover (over the item) ... thankfully the TodoMVC CSShandles this for us, we just need ourviewto render the<button>
• Clicking/tapping the<button>sends thesignal('DELETE', todo.id, model)
• TheDELETE update case receives thetodo.idand removes it from themodel.todos Array.

Append the following test code to yourtest/todo-app.test.js file:

test.only('4.1 DELETE item by clicking <button>',function(t){elmish.empty(document.getElementById(id));localStorage.removeItem('elmish_'+id);constmodel={todos:[{id:0,title:"Make something people want.",done:false}],hash:'#/'// the "route" to display};// render the view and append it to the DOM inside the `test-app` node:elmish.mount(model,app.update,app.view,id,app.subscriptions);// const todo_count = ;t.equal(document.querySelectorAll('.destroy').length,1,"one destroy button")constitem=document.getElementById('0')t.equal(item.textContent,model.todos[0].title,'Item contained in DOM.');// DELETE the item by clicking on the <button>:constbutton=item.querySelectorAll('button.destroy')[0];button.click()// confirm that there is no loger a <button>t.equal(document.querySelectorAll('button.destroy').length,0,'there is no loger a <button> as the only item was DELETEd')t.equal(document.getElementById('0'),null,'todo item successfully DELETEd');t.end();});

If you run the testsnode test/todo-app.test.jsyou should now see:

The first two assertions areoptional andshould (always)pass given that they rely on functionality defined previously.The second two will only pass once youmake them pass!

Thefirst step is to add an invocation ofsignal('DELETE' ...)to therender_item view rendering function.Specifically thebutton line:

button(["class=destroy"])

Add thesignal function invocation:

button(["class=destroy",signal('DELETE',item.id)])

simply adding this function invocation as an Array element will set itas anonclick attribute for the<button>therefore when theuser clicks the button it will"trigger" thesignal function with the appropriate arguments.There is no "magic" just code we tested/wrote earlier.

Second we need to add acase statementto theupdate function.You should attempt to "solve" this yourself.There is no "right" answer, there are at least5 ways of solving this, as always, you should write the codethat you feel is mostreadable.

If you get "stuck" or want to confirm your understandingof the implementation of theDELETE functionality,check the code intodo-app.js >updatefunction.

Rather bizarrely the edit functionality is mentionedboth in the Item and Editing sections.

should allow me to edit an item

This is kindameaningless as an assertion.What does "edit an item" actuallymean?
(we have expanded the acceptance criteria below...)

Editing a Todo List item is (by far)the most "advanced" functionality in the TodoMVC appbecause it involves multiple steps and "dynamic UI".

Don't panic! Just because something has "more steps" than we have seen before,doesn't mean we should be "overwhelmed" by its' complexity.We just need to "break it down" into "bitesize chunks"!

Note: the most "difficult" part of implementing the "edit an item"functionality is having a "mental picture" of the UXso that we can write thetests firstand isolate the required functions (update actions) from the keyboard/mouseinteractions. i.e. breaking down the steps into distinct "units".

First let's review the TodoMVC "Editing" test assertions:

5. Editing  ✓ should hide other controls when editing (718ms)  ✓ should save edits on enter (1093ms)  ✓ should save edits on blur (1256ms)  ✓ should trim entered text (1163ms)  ✓ should remove the item if an empty text string was entered (1033ms)  ✓ should cancel edits on escape (1115ms)

Further reading of the TodoMVC Spec:https://github.com/tastejs/todomvc/blob/main/app-spec.md#itemreveals the following acceptance criteria:

• Double-click on Item<label>title</label>to begin editing (that item)
• Render an<input>if in "editingmode"(see screenshot and markup below)
  • Addclass="editing" to<li> when editing
  • Remove (don't add)class="editing" from<li>when no longer editing.
• Set theitem.id as theid of the<input>so that we know which item is being edited.
• Addcase inkeyup Event Listenerfor[Enter] keyup (seesubscriptions above)if we are in "editingmode",get the text value from the<input>instead of<input>so that weupdate theexisting Todo Item title (text).
• When[Enter] is pressed while in "editingmode","dispatch" theSAVE action:signal('SAVE')
  • If the<input> isblank,delete the todo item.

Byinspecting the DOM for the VanillaJS TodoMVC example:https://todomvc.com/examples/vanillajs
we can see thattwo things change in the DOM when in "editingmode":

• <li> the CSSclass="editing" is addedto the todo list item beingedited.
• <input> is inserted into the DOMinside the<li>so the item title can be edited.

Here is thesample HTML in "editingmode"(copy-pasted) from the VanillaJS TodoMVC implementationthe<li> is being edited (as per screenshot above):

<ulclass="todo-list"><lidata-id="1533987109280"class="completed"><divclass="view"><inputclass="toggle"type="checkbox"checked=""><label>hello world</label><buttonclass="destroy"></button></div></li><lidata-id="1534013859716"class="editing"><divclass="view"><inputclass="toggle"type="checkbox"><label>totes editing this todo item</label><buttonclass="destroy"></button></div><inputclass="edit"></li></ul>

From the HTML/DOM we can see that "editing" a Todo item isdeceptively simplefrom a markup perspective, wejust need to knowwhich item we are editingand render the appropriate tags/classes.

There arethree steps to Editing a Todo List item:

1. Trigger the "double-click" event listener/handler1.1. Receiving thesingal('EDIT', item.id)activates "editingmode".
2. Edit the todo list item'stitle property
3. Save the updated itemtitle:singal('SAVE', item.id)

For thesethree steps there are twoupdate actions:EDIT andSAVEwhich will require two newcase statements in theupdate function.

Note: there is a "fourth" step which is "Cancelling" an edit,which we will cover insection 5.5 below, but for now we areonly considering the "happy path" which results in a successful edit.

In order to edit an item therender_item functionwill require3 modifications:

1. Add thesignal('EDIT', item.id) as anonclick attribute to<label>so that when a<label> is (double-)clickedthemodel.editing property is set by theupdate function (see below).
2. Apply the"class=editing" to the list item which is being edited.
3. Display the<input>with the Todo list item title as it'svalue property.

For the above modifications (requirements) we can write asingle testwith four assertions. Append the following code totest/todo-app.test.js:

test.only('5. Editing: > Render an item in "editing mode"',function(t){elmish.empty(document.getElementById(id));localStorage.removeItem('elmish_'+id);constmodel={todos:[{id:0,title:"Make something people want.",done:false},{id:1,title:"Bootstrap for as long as you can",done:false},{id:2,title:"Let's solve our own problem",done:false}],hash:'#/',// the "route" to displayediting:2// edit the 3rd todo list item (which has id == 2)};// render the ONE todo list item in "editing mode" based on model.editing:document.getElementById(id).appendChild(app.render_item(model.todos[2],model,mock_signal),);// test that signal (in case of the test mock_signal) is onclick attribute:t.equal(document.querySelectorAll('.view > label')[0].onclick.toString(),mock_signal().toString(),"mock_signal is onclick attribute of label");// test that the <li> and <input> was rendered:t.equal(document.querySelectorAll('.editing').length,1,"<li class='editing'> element is visible");t.equal(document.querySelectorAll('.edit').length,1,"<input class='edit'> element is visible");t.equal(document.querySelectorAll('.edit')[0].value,model.todos[2].title,"<input class='edit'> has value: "+model.todos[2].title);t.end();});

There is quite a lot to "unpack" here, but the main gist is thatbased on themodel.editing key being set to2, ourrender_item function,will add theediting CSS class to the<li> element and render an<input> with CSS classedit.The TodoMVC style sheet (todomvc-app.css) will take care of displayingthe input correctly.

Setting theonclick attribute of the<label> elementto whatever is passed in as the third argument ofredner_itemi.e. thesignal will mean that a specific action will be dispatched/triggeredwhen the<label> element is clicked.

SPOILER ALERT: If you want totry to make the "Edit Mode"Testassertionspass without reading the "solution",do it now before proceeding to the reading theimplementation section.

Given that there are 4 assertions that need to passand we know there are 3 changes that need to be madeto therender_item function,rather than leaving you (the reader) wondering "where do I start?!",here is the code that makes the tests pass:

Before:

functionrender_item(item,model,signal){return(li(["data-id="+item.id,"id="+item.id,item.done ?"class=completed" :""],[div(["class=view"],[input([item.done ?"checked=true" :"","class=toggle","type=checkbox",typeofsignal==='function' ?signal('TOGGLE',item.id) :''],[]),// <input> does not have any nested elementslabel([],[text(item.title)]),button(["class=destroy",typeofsignal==='function' ?signal('DELETE',item.id) :''])])// </div>])// </li>)}

After:

functionrender_item(item,model,signal){return(li(["data-id="+item.id,"id="+item.id,item.done ?"class=completed" :"",model&&model.editing&&model.editing===item.id ?"class=editing" :""],[div(["class=view"],[input([item.done ?"checked=true" :"","class=toggle","type=checkbox",typeofsignal==='function' ?signal('TOGGLE',item.id) :''],[]),// <input> does not have any nested elementslabel([typeofsignal==='function' ?signal('EDIT',item.id) :''],[text(item.title)]),button(["class=destroy",typeofsignal==='function' ?signal('DELETE',item.id) :''])]),// </div>].concat(model&&model.editing&&model.editing===item.id ?[// editing?input(["class=edit","id="+item.id,"value="+item.title,"autofocus"])] :[]))// </li>)}

Let's walk through the three code changes made:

1. Adding"class=editing" to the<li> based onmodel.editingis the simplest code modification, similar to the conditional attributeclass=completed on the previous line.

model&&model.editing&&model.editing===item.id ?"class=editing" :""

We include the check formodel && model.editing because if either of thesetwo areundefined there's no need to keep checking.Only if themodel.editing matches theitem.id(the todo list item being rendered) do we render the"class=editing".Only one todo list itemtitle will be edited at once,so this will only match (at most)one item in themodel.todos array.

2. Setting thesignal('EDIT', item.id)

Why do we need thetypeof signal (type-checking)...?

label([typeofsignal==='function' ?signal('EDIT',item.id) :''],[text(item.title)]),

Whycan't we just write this:

label([signal('EDIT',item.id)],[text(item.title)]),

Given thatsignal is the final argument to therender_item function,it is considered anoptional argument.If for any reason therender_item function is invokedwithout thesingalparameter, then attempting toinvokesignal('EDIT', item.id)will result in aReferenceError: signal is not defined which will"crash" the appfatally.

If you are theonly person who is going to write code that will invokerender_item, you don't need to "worry" about thetypeof signalbecause there is "no need" for type-checking thesignal;surely you won'tforget to invoke it with a validsignal ...however wealways approach our JavaScript code a"defensive programming"perspectivebecause weknow fromexperiencethat banking on the"happy path"in JS codeis like driving without a seatbelt;you might be "fine" most of the time, but when something "bad" happens,you will go flying through the windscreen and have areally bad day!

If you want toavoid having to domanual "type-checking",useElm, it does all this for youtransparently.

3. Append the<input>to the<li> if in "editingmode":

].concat(model&&model.editing&&model.editing===item.id ?[// editing?input(["class=edit","id="+item.id,"value="+item.title,"autofocus"])] :[]))// </li>

Thereason we use.concat is to allow us tooptionally render the element ornothing thenappend it to theArray of child elements nested in the<li>.

Analternative to using.concat() could be an emptydiv node:

model&&model.editing&&model.editing===item.id ?// editing?input(["class=edit","id="+item.id,"value="+item.title,"autofocus"])  :div()// empty element.

This is because attempting to return anything other than a DOM elementwill result in the following error:

TypeError:Argument1ofNode.appendChilddoesnotimplementinterfaceNode

We are not "fans" of having "empty" elements in the DOM, it's "sloppy".
Hence theconcat() approach which results in "clean" DOM.

At this point our test assertions all pass:

node test/todo-app.test.js

But we are building avisual application and are notseeing anything ...

Let's take abrief detour tovisualise the progress we have made.

Open theindex.html fileand alter the contents of the<script> tag:

<script>varmodel={todos:[{id:0,title:"Make something people want.",done:false},{id:1,title:"Bootstrap for as long as you can",done:false},{id:2,title:"Let's solve our own problem",done:false}],hash:'#/',// the "route" to displayediting:2// edit the 3rd todo list item (which has id == 2)};mount(model,update,view,'app',subscriptions);</script>

Then in your terminal, start the live-server:

npm start

In your browser, vist:http://127.0.0.1:8000/
You should see that thethird todo list item is in "editingmode":

Nothing will happen (yet) if you attempt to "save" any changes.Let's work on thecase (handler) forsignal('EDIT', item.id)which will handle the "double-click" event and setmodel.editing.

The TodoMVCspec for itemhttps://github.com/tastejs/todomvc/blob/main/app-spec.md#itemincludes the line:

Double-clicking the<label> activates editing mode, by toggling the .editing class on its<li>

Note: the sample TodoMVC Browser Tests:https://github.com/tastejs/todomvc/tree/main/tests#example-outputdoesnot include a test-case fordouble-clicking.We are going to add one below for "extra credit".

Since Double-clicking/tapping is theonly way to edit a todo item,we feel that it deserves a test.

When we don't know how to do something, a good place to start is to searchfor the keywords we want, e.g: "JavaScript detect double-click event"for which the top result is the following StackOverflow Q/A:https://stackoverflow.com/questions/5497073/how-to-differentiate-single-click-event-and-double-click-event

Reading though all the answers, we determine that the most relevant (to us)is:https://stackoverflow.com/a/16033129/1148249 (which uses "vanilla" JS):

Note: when you find a StackOverflow question/answerhelpful,upvote to show your appreciation!

<divonclick="doubleclick(this, function(){alert('single')}, function(){alert('double')})">click me</div><script>functiondoubleclick(el,onsingle,ondouble){if(el.getAttribute("data-dblclick")==null){el.setAttribute("data-dblclick",1);setTimeout(function(){if(el.getAttribute("data-dblclick")==1){onsingle();}el.removeAttribute("data-dblclick");},300);}else{el.removeAttribute("data-dblclick");ondouble();}}</script>

Given that we are using the Elm Architecture to manage the DOM,we don't want a function thatalters the DOM.So we are going toborrow thelogic from this example butsimplify it.Since we are not mutating the DOM by settingdata-dblclick attributes,we won't need to remove the attribute using asetTimeout,

In keeping with our TDD approach,ourfirst step when adding thecase expressionfor'EDIT' in theupdate function is to write atest.

Append following test code to yourtest/todo-app.test.js file:

test.only('5.2 Double-click an item <label> to edit it',function(t){elmish.empty(document.getElementById(id));localStorage.removeItem('todos-elmish_'+id);constmodel={todos:[{id:0,title:"Make something people want.",done:false},{id:1,title:"Let's solve our own problem",done:false}],hash:'#/'// the "route" to display};// render the view and append it to the DOM inside the `test-app` node:elmish.mount(model,app.update,app.view,id,app.subscriptions);constlabel=document.querySelectorAll('.view > label')[1]// "double-click" i.e. click the <label> twice in quick succession:label.click();label.click();// confirm that we are now in editing mode:t.equal(document.querySelectorAll('.editing').length,1,"<li class='editing'> element is visible");t.equal(document.querySelectorAll('.edit')[0].value,model.todos[1].title,"<input class='edit'> has value: "+model.todos[1].title);t.end();});

If you attempt to run this test:node test/todo-app.test.jsyou will see output similar to the following:

Let's write the code necessary to make the test assertionspass!If you want to try this yourself based on the StackOverflow answer (above),go for it! (don't scroll down to the "answer" till you have tried...)

Given our "research" (above) of how to implement a "double-click" handler,we can write the'EDIT' case as the following:

case'EDIT':// this code is inspired by: https://stackoverflow.com/a/16033129/1148249// simplified as we are not altering the DOM!if(new_model.clicked&&new_model.clicked===data&&Date.now()-300<new_model.click_time){// DOUBLE-CLICK < 300msnew_model.editing=data;console.log('DOUBLE-CLICK',"item.id=",data,"| model.editing=",model.editing,"| diff Date.now() - new_model.click_time: ",Date.now(),"-",new_model.click_time,"=",Date.now()-new_model.click_time);}else{// first clicknew_model.clicked=data;// so we can check if same item clicked twice!new_model.click_time=Date.now();// timer to detect double-click 300msnew_model.editing=false;// resetconsole.log('FIRST CLICK! data:',data);}break;

If you ignore/remove theconsole.log lines (which we are using for now!),the code is only a few lines long:

case'EDIT':// this code is inspired by: https://stackoverflow.com/a/16033129/1148249// simplified as we are not altering the DOM!if(new_model.clicked&&new_model.clicked===data&&Date.now()-300<new_model.click_time){// DOUBLE-CLICK < 300msnew_model.editing=data;}else{// first clicknew_model.clicked=data;// so we can check if same item clicked twice!new_model.click_time=Date.now();// timer to detect double-click 300msnew_model.editing=false;// reset}break;

The main "purpose" of this code is todetect if a<label> was clickedtwice in the space of 300 milliseconds and apply theitem.id tothemodel.editing property so that we know which<li> to render in"editing mode".

Run the test and watch itpass:node test/todo-app.test.js

In this case the time between the two clicks was 31 milliseconds,so they will count as a "double-click"!

If a<label> is clicked slowly, themodel.editing willnot be set,and we willnot enter "editing mode".Let's add a quick test for the scenariowhere two clicks are more than 300ms apart.

Append following test code to yourtest/todo-app.test.js file:

test.only('5.2.2 Slow clicks do not count as double-click > no edit!',function(t){elmish.empty(document.getElementById(id));localStorage.removeItem('todos-elmish_'+id);constmodel={todos:[{id:0,title:"Make something people want.",done:false},{id:1,title:"Let's solve our own problem",done:false}],hash:'#/'// the "route" to display};// render the view and append it to the DOM inside the `test-app` node:elmish.mount(model,app.update,app.view,id,app.subscriptions);constlabel=document.querySelectorAll('.view > label')[1]// "double-click" i.e. click the <label> twice in quick succession:label.click();setTimeout(function(){label.click();// confirm that we are now in editing mode:t.equal(document.querySelectorAll('.editing').length,0,"<li class='editing'> element is NOT visible");t.end();},301)});

There is no need to write any code to make this test pass,this is merely an additional test toconfirm that our check for thetime between clicks works; clicks spaced more than 300ms will not countas "double-click".