Now that you’ve got the main foundations down to build out a frontend application, it’s time to prove to yourself that you own those skills! You’re going to be building a checklist application called
- Solidify and demonstrate your understanding of:
- localStorage to persist data
- Iterate through/filter DOM elements using for loops
- Understand the difference between the data model and how the data is displayed on the DOM
Solo Project Expectations
This project is an important step in demonstrating you are ready to start Module 2. To ensure we can accurately assess that, it’s important you meet the expectations:
- You are the only one who should type code - no copy and pasting code
- For any code that you didn’t write entirely by yourself (mentor or rock supported)- you should be able delete it and re-write it yourself
- You shouldn’t be looking at any other Check Yo Self codebase at any time for any reason. If you have an opportunity and are tempted, do the right thing for YOUR learning and don’t do it!
- Any peer-to-peer collaboration should be discussions about ideas, not coding together.
Set Up & Submission
- Create a private repository and add your assigned instructor as a collaborator. You cannot deploy private repositories to GitHub Pages, that’s ok.
- Create a project board
By EOD on Kick Off Day: DM your assigned instructor with two links: Project Board & Repo
todo-list.jsfile that contains a
ToDoListmethods must include, but are not limited to:
updateToDo(should update the todo’s title and urgency)
updateTask(should update a task’s content and if it has been completed)
task.jsfile that contains a Task class. We aren’t giving you any requirements about what methods or properties should be on it.
- A to-do list has an id, title, tasks, and urgent property.
- The id property should be a unique identifier
- title is a string
- urgent is a boolean value
- tasks should be an array of objects
- Each task in the array should be an object (you’ll need a way to identify these objects, track whether the task has been completed, and store the task’s text…)
- See above for the required methods of the
Each todo list on the page should be created as an instance of the
Iteration 0: Beginning User Flow
Viewing the List of To-Dos
When visiting the application, the user should:
- See a list of all existing to-dos, including the title, list of tasks to be checked off, and state of urgency.
- To-dos should appear in descending chronological order (with the most recently created todo at the top left).
- If there are no to-dos yet, then there should be an indication to the user to create a todo list, displayed in the empty section.
Adding a New Checklist
On the left side of the page, a user should see:
- Two inputs for entering the title and adding a new task to the list.
- Two buttons including a
Make Task Listbutton for committing the checklist and a
Clear Allbutton to clear the title and checklist.
- Lastly, there should be a
Filter by Urgencybutton.
When a user adds a new
- The task is added to the bottom of the checklist in between the
- Each task on the checklist should also be able to be removed by clicking the respective “delete” button.
- It should not add a task to the checklist if the input is empty.
- Tasks on the checklist of the form do not need to persist.
When a user clicks
Make Task List:
- A new card with the provided title and tasks should appear in the todo list.
- The text fields and checklist in the form should be cleared and ready to accept a new todo.
Make Task Listbutton should be disabled if either the title input or checklist is empty.
- The page should not reload.
- The todo card should be persisted. It should still be present upon reloading the page.
- The todo should be added to
saveToStoragemethod defined in the
When a user clicks
- Both the title input and list of tasks should be cleared.
Clear Allbutton should be disabled if both the title input and checklist are empty.
Iteration 1: Completing The MVP (Minimum Viable Product)
Checking Off A Task
After a user has completed a task on their checklist, they should be able to check it off.
- There should be a visual cue so that the user knows what they have completed and what is still left to do.
- Tasks that are checked off should persist upon reloading the page.
- The update of the data model should occur in the
updateTaskmethod that is defined in the
Deleting an Existing ToDo Card
After creating a todo card, the user should be able to remove it once they have completed their checklist.
- Each todo card on the todo list should have a button to remove it from both the data model and the DOM.
- The “Delete” button should only be enabled if all of the tasks on the checklist have been checked off.
- Upon clicking the “Delete” button, the appropriate todo list should be removed from the DOM.
- The update of the data model should happen in the
deleteFromStoragemethod that is defined in the
Marking a ToDo Card Urgent
A user should be able to mark their todo cards urgent so that they know which they need to complete first.
- When the user clicks on the
Urgentbutton, the button should stay in the active state.
- Todo cards that are marked as urgent should persist upon reloading the page.
- This update of the data model should occur in the
updateToDomethod that is defined in the
Iteration 2: Specifying what Content is Viewed
Filtering and Searching by Text
We’d like our users to be able to easily find their to-dos, so let’s provide them a search bar to filter through their list.
- At the top of the application, include a text field labeled
- As a user types in the search box, the list of to-dos on the DOM should filter in real time to only display todo cards whose title include the user’s text. The page should not reload.
- Clearing the search box should restore all todo cards on the list.
- There is no need to make persisting changes to the data model to achieve this functionality.
Viewing Urgent ToDo Cards
Let’s also allow our user be able to view their urgent todo cards only.
- The user should only see the urgent todo cards when they click on the
Filter by Urgencybutton. (consequently, the button should be highlighted)
- Clicking on the
Filter by Urgencybutton again, the button should no longer be highlighted, and all of the user’s to-dos should be displayed.
- When viewing urgent to-dos, the search field should only search through the urgent to-dos.
- If there are no urgent to-dos yet, then there should be an indication displayed in the empty todo section notifying the user to mark some to-dos urgent.
- These changes do not need to persist in between sessions.
Iteration 3 (Extensions): Improving on the Experience
Editing Our Tasks
A user would likely want to edit the title of a todo or update their task later on.
- When a user clicks the title or any of the tasks on the checklist of a todo card, that text should become an editable text field, pre-populated with the existing todo title or task.
- The user should be able to “commit” their changes by pressing “Enter/Return” and by clicking outside of the text field.
- This change should be saved in localStorage using the
updateTodomethod for the title and
updateTaskmethod for the task defined in the
Improving The Search Functionality
Our user might want to be able to search their cards not only by their title, but by their tasks as well.
- The user should have a drop down next to the search bar to select if they want to filter their list by
- Searching by the
Titlewill be the original functionality where it filters the todo cards by their title based on the user’s text.
- Searching by the
Taskswill filter the todo cards by their tasks based on the user’s text.
- Searching by the
Allwill filter the todo cards by both their title and tasks based on the user’s text.
Adding More Tasks To Each Card
The user might also might to add more tasks to their checklist after they have created a todo card.
- Add an input to the bottom of each card so that the user can add more tasks later.
- Each task added should appear at the bottom of the list unchecked.
- The user should not be able to add blank tasks if the input is empty.
What is a Masonry Layout?
This type of layout is known as a Masonry layout. This layout refers to when items of uneven size are laid out in a way where there are no uneven gaps. Due to this scenario, this is NOT good scenario for using
grid. This is because we can’t define where each card is going to be in the layout. There are a number of ways to solve this solution. Here are a couple of links to check out to achieve this goal:
- Place submissions in the appropriate tab of the Submission Sheet
Here are the links to the icon SVG files.
Desktop layout adding a task:
Desktop layout filtering by urgency:
Color, font, and icon spec:
- 4: Application meets all of the expectations from Iteration 3.
- 3: Application meets all of the expectations of Iteration 2.
- 2: Application meets all of the expectations of Iteration 1 and one of the 2 parts of Iteration 2.
- 1: Application meets all of the expectations of Iteration 0.
- 4: A PR template was used. A code review was requested and completed by a mentor, and all team members can speak to how the feedback in code review was implemented (and point to the commit(s) that implemented the feedback). AND: Developer is ready to clearly present the evolution of this app during the eval - from architecture decisions made in the planning process, to wins and challenges throughout.
- 3: Developer is able to clearly answer questions regarding the evolution of this app during the eval - from architecture decisions made in the planning process, to wins and challenges throughout. AND: A project board is used and kept update throughout the project. Branches are used. Most commits are formatted correctly. The README is formatted well and contains:
- Overview of project and goals
- Overview of technologies used, challenges, and wins, any other reflections
- Screenshots of comp and your app
- 2: Developer is able to answer questions regarding the evolution of the app, but may need some prompts to clearly articulate or provide enough context. More than a few commits are formatted incorrectly. The README is formatted well but may be lacking in detail.
- 1: Developer struggles to answer questions regarding the evolution of the app. OR: Commit and PR history does not tell a story of the application OR a README has not been created/has minimal information.
- All loops are refactored into the proper array prototype iteration methods (not using arrow functions)
- Uses logical operators instead of if/else statements where applicable
- When ‘Filtering and Searching by Text’ and ‘Viewing Urgent ToDo Cards’, to-dos that do not need to be shown on the DOM should be completely removed from the DOM, instead of only being hidden from view
- DRY and SRP practices are demonstrated in codebase and students can speak to implementation decisions
- All functions are less than 10 lines
- There are no nested if/else statements
- There are no global variables aside from query selectors and an array for your to-dos
- Uses event delegation correctly on dynamic elements for deleting, checking tasks off, and marking a to-do urgent
- 2: Application correctly implements data model for the
ToDoListclass including all required methods. No unused variables or functions are present in the codebase.
- 1: Crafts JS according to the Turing JS Style Guide