Order of values inconsistent in todo list application parts

[bzuu]

In part 1 of the todo list application the State record is defined as:

type State = {
    TodoList : string list
    NewTodo : string
}

then in part 2 the properties are suddenly flipped around:

type State = {
  NewTodo: string
  TodoList : Todo list
}

This is somewhat confusing and it breaks the init() function.

I'd be happy to submit a pull request with a fix, but not sure which part(s) you'd prefer to be rewritten/reordered. I guess rewriting part 1 would be easiest.

[Zaid-Ajaj]

Hi @bzuu, thanks for pointing this out! I too believe this should be consistent 💯 I will keep it mind the next time when I make the updates to the book soon

[BennieCopeland]

@bzuu The order of the fields doesn't matter, but it can be made consistent. It is the change from TodoList : string list to TodoList : Todo list that breaks the init() function, but this is part of the required steps in refactoring between the Todo part 1 version, and Todo part 2 version to add the Completed boolean flag. It's supposed to break the init() function because you are purposefully changing the Type to add a new feature. The updated version of init() could be explicitly added to part 2, or alternatively, this blurb from the Todo exercises page could be brought forward and reworded:

Currently each to-do's ID is an int, however .Net framework has a built-in module specifically for generating unique IDs: System.Guid.

The point of this exercise is to change the Todo type so the ID is of type Guid, then, using the IDE's errors, or even compiler errors, find all the places the change breaks the type-system and refactor them to make the application compile again.

as an exercise to trust the compiler.