Learning guide
This page is about JavaScript Todo App—Todo list with add, complete, delete in localStorage. Study the samples before you unzip anything.
Keep one tab on PHP.net or MDN. Our variable names are plain on purpose so you can map them to the manual quickly.
Read a section, predict what should happen, then run it. Logs and the browser network tab are part of the lesson.
If local setup is new to you, block an hour once for Apache/MySQL or Live Server, then reuse that stack for other guides.
Start from index.html when you open the reference tree. The optional package at the bottom matches this article.
Concepts you should understand
Authentication labs cover identity, sessions, and password hashing. Upload labs cover validation, storage layout, and metadata. AJAX labs cover HTTP verbs, JSON contracts, and separating view from API. Map each file in the reference section to one of these ideas.
Optional local lab setup
This lab runs entirely in the browser; focus on events, DOM APIs, and asynchronous flows. These steps describe a learning environment, not commercial software installation.
- Create a workspace folder for this JavaScript lab on your computer.
- Use VS Code Live Server or
npx serveto avoid browser file:// restrictions. - Open
index.html, then editassets/app.jsand observe reload behavior. - When a lesson pairs with PHP, run the API in localhost and point
fetchURLs accordingly. - Document assumptions (CORS, ports, JSON shape) in comments so future labs stay consistent.
Guided walkthrough
Begin by using the feature as a learner: submit empty forms, invalid emails, and edge cases.
Watch how the UI responds, then locate the PHP or JavaScript responsible for that message.
Trace variables from $_POST or fetch bodies down to SQL or DOM updates.
Rewrite one branch in your own words—rename fields, add comments, or log values with error_log or console.debug.
If behavior changes unexpectedly, you have found a learning moment about sessions, scope, or async timing.
For topics like JavaScript Todo App, compare your work against the annotated snippets below before peeking at the full reference tree. Spaced repetition (revisit the lesson days later) cements syntax into long-term memory better than a single rushed pass.
Annotated code samples
Each block is meant to be edited, not pasted blindly. Read the note under it, then try one small change.
Hydrating state from localStorage
const todos = JSON.parse(localStorage.getItem('gt_todos') || '[]');localStorage persists key/value data in the browser across reloads. Parsing JSON turns the stored string back into an array of task objects. Defaulting to [] avoids errors on first visit when nothing is saved yet.
Front-end code runs in an environment you do not control—users can modify JavaScript in DevTools. Treat browser validation and storage as convenience layers; authoritative rules belong on the server for anything security-related.
Persisting after each edit
function save(list) {
localStorage.setItem('gt_todos', JSON.stringify(list));
render();
}Stringifying before save keeps structure intact for later sessions. Calling render() immediately updates the DOM so the UI matches storage. For real apps you would sync to a server; here the goal is to practice client-side state flow.
Rename one function in your copy so you are sure you understand what it returns.
Appending a new task object
save([...todos, { text: value, done: false }]);The spread operator copies existing items immutably, which is easier to reason about than mutating a global array. Each task is a small object with text and done flags you can toggle in the UI. Immutability patterns prepare you for React-style state updates later.
Skim the sample once, then change a variable and reload to see what actually moves.
Security notes for students
Practice code deliberately simplifies reality. Before any production deployment, add HTTPS, rate limiting, logging, and professional review. Never reuse tutorial passwords in public systems. Remove sample accounts and disable verbose errors on live hosts.
Legal: Globaltuts.com is not responsible for security vulnerabilities if practice code is deployed on a live production server without proper sanitization. Read our practice project policy, Privacy Policy, and Disclaimer.