fac-11/jaam-todo-list

Marmalade ( the todo app )

Our task for this week was to create a todo-style web app, which in keeping with the jam theme we called Marmalade.

Marmalade needed to have a simple functionality which allowed its users to roughly jot down short notes and reminders for themselves which are then appended to the site as a <li>. These reminders can then be marked as completed or deleted using interactive elements such as <input type="checkbox"> and <button>.

Introduction

The task this week was to utilise best-practice TDD or test-driven development to make this app.

We decided to spend the first hour dividing up the work, and trying to understand what was being asked of us. After last week we were keen to have more communication between us as a four - making sure that we all understood the different elements of the code we would be writing, and that we changed pairs more often.

We also wrote some initial code, like HTML and CSS templates, so that we all had a solid base to work from before splitting off to our seperate feature branches in pairs. We made a few initial tests in our test.js file - one testing that the Tape testing framework was functioning as it should, and one checking that the argument we were passing in todos was an array of objects as it should be. At this point we split off into pairs.

(il)logical.js

The experience we had with TDD felt pretty frustrating and counter-intuitive at first. The initial logic.js file seemed fairly simple to write when we first looked at it. What was most challenging was trying to write the tests for every granular aspect of our functions. It felt pedantic and tedious checking for things like

Does one really equal one??

or

Is the argument that is DEFINITELY an array really an array?

We all learnt that for any function you can write, there are at least two or three different tests you can write to compliment it (or to needlessly complicate matters and confuse yourself depending on how you look at it). The fairly simple layout of logic.js was offset by the time-consuming task of writing test.js.

dom.js

Once the crux of the logic.js file was completed, we moved on to the dom.js file, which was how we linked the javascript to the HTML. This was also pretty challenging. Working from somebody else's template really highlighted the need for clear, (self)-explanatory code, and how something that seems pretty obvious for somebody writing the code can seem completely confusing for someone adding to it/coming to it at a later date.

It was not until this stage that the advantages of writing code using a test-driven methodology became apparent. Because we had written these tests thoroughly checking every aspect of our functions, we were able to have a little more faith in these functions when our dom.js file wasn't linking things properly.

If something wasn't working as expected, we could go back to the tests to double check their accuracy. So long as these were pure functions we were working from, we could be sure that this foundation was working. This made our debugging process a lot faster.

jaam-todo-list's Issues

Is the 'preventDefault' for markTodo in L32 of DOM.js needed?

On commenting the line out it doesn't seem to affect the functioning of the site
This is the line

Address mobile usability

Perhaps insert meta viewport in html in order to prevent scaling on mobile:
<meta name="viewport" content="width=device-width, initial-scale=1.0">

Currently becomes v small in mobile devices

User Story #1: enter tasks

As a disorganised person,
I want to enter tasks I need to do into a web page so that I don't forget them

Create readme

Create gh-pages

For users to access the site 👍

Feature: Create deleteTodo function

Using TDD

The styling is beautiful

good job

Code review time is for code review

It's only an hour so it's really important to review the other projects, not keep working on your own:

I know it's tempting but it's only an hour a week and code review is a super important skill to learn

Pushed node_modules

Easy mistake to make.

Just remember to initialise your repo with a node gitignore.

Avoid @import in CSS

Generally using a <link> tag in your HTML will be much more performant that @import in your CSS. There's (a lot) more info here: http://www.stevesouders.com/blog/2009/04/09/dont-use-import/

Consider containing relevant variables within individual tests for readability?

User Story #2: view tasks

As a disorganised person,
I want to view the tasks I have added in a list so that I can plan my day

Commented explanations before each test is super helpful for reading

👍
(this can be deleted)

Feature: Create addTodo function

Using TDD

Great job with the tests!

If you'd commented out the sort todos function and added an /* istanbul ignore next */ before the final if (module !== statement you'd be 100% with all branches.

Sweeet! 👍

Feature: Create markTodo function

Using TDD

Question: What is the purpose of testing the test suite?

We're unsure on whether you need to test a test - can you explain your thought process?

User Story #4: thumb-friendly tasks

As a disorganised person,
I want to the to-dos to be large enough so that I don't hit the wrong one with my thumb

Accessible form

Bit of a dodge issue to raise given that you're using our html but still 🙊

All inputs should have labels with a for attribute or be wrapped around an input:

<label for="form-title">Description</label>
<input id="form-title" type="message" name="description" value="" placeholder="Got something to do?!">

or

<label>Description
<input id="form-title" type="message" name="description" value="" placeholder="Got something to do?!">
</label>

Is the 'colors' array unused in the dom.js file?

L9 & L10 in DOM.js

On a mobile screen list items look small

Please, consider making font size responsive

Checkbox loses focus

Every time one of the todo checkboxes is checked it loses focus:

Not great for accessibility. It's happening because the whole set of todos is being re-rendered every time there's a change. Pretty difficult (fun) issue to solve. This might help.

No sound for added UX & accessibility

Convenient dings would be great...

User Story #3: mark tasks

As a disorganised person,
I want to mark tasks as complete so that I can focus on the tasks I have left

Keep console.logs away from production

Logs are very useful for debugging but shouldn't really be in production:

Feature: Create new todo

See:

addTodoForm.addEventListener('submit', function(event) {
Inside this function you need to create a new state with a new to-do.

Feature: Create sortTodos function

Using TDD. This should be treated as a sprint goal once the other functions are working.

Perhaps 'marked0' should be the 'actual' in L156-L182

Perhaps the 'marked0' should be the 'actual' and the output function may not need to be assigned a variable:
var actual = logic.markTodo(markedO, 0);

Rather this variable can become the actual:

var markedO = [{
  | id: 0,
  | description: 'add chilli',
  | done: false,
  | },
  | {
  | id: 1,
  | description: 'onion',
  | done: true,
  | }
  | ]

Review the code here #L156-L182

Feature: Create createTodoNode

This is Part 2. We need to complete this function. It take one argument, this is a to-do element.

This function returns a DOM node. This node is a list item.

If we build this function correctly the render function will take care of inserting all the to-do nodes onto the page!