{"id":903,"date":"2024-02-22T10:39:19","date_gmt":"2024-02-22T16:39:19","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=903"},"modified":"2024-02-22T14:25:03","modified_gmt":"2024-02-22T20:25:03","slug":"building-a-todo-app-from-scratch-step-3-basic-javascript-functionality","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/building-a-todo-app-from-scratch-step-3-basic-javascript-functionality\/","title":{"rendered":"Building a TODO App from Scratch \u2014 Step 3 \u2014 Basic JavaScript Functionality"},"content":{"rendered":"\n

We left off with a wireframe-y looking HTML-ized version of our design. Personally, I’m a little tempted to get some CSS on there, but let’s hold off and do the very basic JavaScript functionality first. That will make it, ya know, actually functional, and having some of the interactive stuff in place might inform some of our styling choices anyway.<\/p>\n\n\n

\n
\n

Article Series<\/h3>\n <\/header>\n
\n
    \n
  1. \n Building a TODO App from Scratch \u2014 Step 1 \u2014 Planning & Design<\/a>\n <\/li>\n
  2. \n Building a TODO App from Scratch \u2014 Step 2 \u2014 HTML<\/a>\n <\/li>\n
  3. \n Building a TODO App from Scratch \u2014 Step 3 \u2014 Basic JavaScript Functionality<\/a>\n <\/li>\n
  4. \n Building a TODO App from Scratch \u2014 Step 4 \u2014 Styling & Interactive Choices<\/a>\n <\/li>\n
  5. \n Building a TODO App from Scratch \u2014 Step 5 \u2014 Extra Functionality<\/a>\n <\/li>\n <\/ol>\n <\/div>\n<\/div>\n\n\n\n

    Where is the data going to go?<\/h2>\n\n\n\n

    There are more ways and places to save data on the web than you can shake a stick at. Much like we slowed down at the beginning and did some design thinking at first, we might do well do do a little data thinking and consider the experience we’re trying to build.<\/p>\n\n\n\n

    For example, we might want to offer our TODO app for multiple users who log in to the website. If that’s the case, we’ll need to store the data in such a way that each user has their own set of to-dos associated with them. That would be fun! In that case we’d have to think about security and ensuring correct auth around data access. Maybe a bit much for a first crack though, so let’s table that for now.<\/p>\n\n\n\n

    Circling back to the front-end, it would be nice to get our data there ultimately as JSON. JSON is just so browser-friendly, as JavaScript can read it and loop over it and do stuff with it so easily. Not to mention built-in APIs<\/a>. <\/p>\n\n\n\n

    That doesn’t mean we have to store data<\/em> as JSON, but it’s not a terrible idea. We could use a more traditional database like MySQL, but then we’d need some kind of tool to help us return our data as JSON, like any decent ORM should be able to help with. SQLlite might be even better<\/a>.<\/p>\n\n\n\n

    Or if we went with Postgres, it supports a better native json<\/code> field type, and built-in utility functions like ROW_TO_JSON()<\/code>. <\/p>\n\n\n\n

    Still, just keeping the data as JSON sounds appealing. I’m not a huge data expert, but as I understand it there are JSON-first databases like MongoDB<\/a> or CouchDB<\/a> that might make perfect sense here. I’ve used Firebase a number of times before and their data storage<\/a> is very JSON-like. <\/p>\n\n\n

    \n
    \"\"
    There are a million data storage options, and every data storage company wants your data. Just the way it is, kid.<\/figcaption><\/figure>\n<\/div>\n\n\n

    Overwhelmed? Sorry. Let’s make like Liz Lemon and not overthink it<\/a>. Let’s assume we’re going to use JSON data, and dunk that data as a string in localStorage<\/code>. While this isn’t exactly a database, we can still nicely format our data, make it extensible, and pretend like we’re interfacing with a fancier database system. <\/p>\n\n\n\n

    What we’re giving up with localStorage<\/code> is a user being able to access their data from anywhere. If they so much as open our TODO app in another browser, their data isn’t there. Let alone open the site on their phone or the like. Or do something blasphemous like clear their browser data. So it’s rudimentary, but it’s still “real” enough data storage for now. <\/p>\n\n\n\n

    What is the data going to look like?<\/h2>\n\n\n\n

    JSON can be an {}<\/code> Object or []<\/code> Array. I’m thinking Array here, because arrays have this natural sense of order. We talked about being able to re-arrange to-do items at some point, and the position in the array could be all we need for that. <\/p>\n\n\n\n

    As best I know, as of ES2020, I believe Objects maintain order when you iterate over them in all the various ways. But I don’t think there is any reasonable way to change that order easily, without creating a brand new Object and re-inserting things in the newly desired order. Or, we’d have to keep an order<\/code> value for each item, then update that as needed and always iterate based on that value. Sounds like too much work.<\/p>\n\n\n\n

    So…<\/p>\n\n\n

    [\n  { \/* to-do item *\/<\/span> },\n  { \/* to-do item *\/<\/span> }\n]<\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
    If we were<\/em> supporting a multi-user system, perhaps all the data would be an object with each user ID being a key and the data being an array like above. One way or another, one use per Array.<\/p>\n\n\n\n
    Now what does each item look like? Based on our design, we really only need a few things:<\/p>\n\n\n\n
      \n
    1. Title (text of the to-do)<\/li>\n\n\n\n
    2. Complete (whether it is done or not)<\/li>\n<\/ol>\n\n\n\n
      We could decide that we don’t need “complete” because we’ll just delete it. But any to-do app worth it’s salt will be able to show you a list of completed items, and you can always delete them from there. <\/p>\n\n\n\n
      We talked about using the array order for the visual order of the to-dos. I think I’m fine with that for now, knowing we can always add ordering properties if we really feel like it. In fact, we can add whatever. We could add dates like a “created at”, “modified at”, “due date”, or “completed at” if we felt it would be useful. We could add tags. We could add a description. But these kind of things should be design and UX driven, as we well know by now. Don’t just go adding data speculatively, that tends to not end well.<\/p>\n\n\n\n
      When it comes to updating\/deleting existing to-dos, we’re going to need a way to update just that item in the data. That’s why I brought up the array order again, because theoretically we could know which item we’re dealing with by the DOM order, then match that to the array order to find the right item. But something about that feels janky to me. I’d rather have a more solid-feeling one-to-one connection between the UI and the data. Maybe it’s just me, but it feels better. So let’s add a unique identifier to each todo.<\/p>\n\n\n\n
      So our now-list-of-three will look like this in the data:<\/p>\n\n\n
      [\n  {\n     title: \"Walk the dog\"<\/span>, \/\/ string<\/span>\n     completed: false<\/span>,      \/\/ boolean<\/span>\n     id: \"something-unique\"<\/span> \/\/ string<\/span>\n  },\n  {\n    \/\/ more! <\/span>\n  }\n]<\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
      Seems workable and extensible to me! <\/p>\n\n\n\n
      Writing data<\/h2>\n\n\n\n
      There is one way to add a new item on our site: submitting the form. So if we get ahold of that form in JavaScript and watch for the submit<\/code> event, we’re in business.<\/p>\n\n\n
      const<\/span> form = document<\/span>.querySelector(\"#todo-form\"<\/span>);\n\nform.addEventListener(\"submit\"<\/span>, (event) => {\n  event.preventDefault();\n\n  \/\/ Add to-do to data and render UI<\/span>\n\n  form.reset();\n});<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Two little tricks there. <\/p>\n\n\n\n
        \n
      1. The preventDefault<\/code> is because we’re handling the submission in JavaScript so we’re preventing the browser from trying to perform the default action of going to a new page. <\/li>\n\n\n\n
      2. The reset<\/code> bit is a nice little built-in UI for resetting the fields, so we don’t have to manually clear them ourselves. After we add a to-do, we don’t want that same text just sitting there in the input, it should go back to blank.<\/li>\n<\/ol>\n\n\n\n
        We talked about all our data being one big JSON-able Array. So:<\/p>\n\n\n
        let<\/span> TODOs = [];<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        Then we can push<\/code> into that array with the new data. We know the complete<\/code> value will be false (we just added it!) and the title will be from the input. <\/p>\n\n\n
        TODOs<\/span>.push<\/span>({\n  title<\/span>: event.target[0<\/span>].value,\n  complete: false,\n  id: self.crypto.randomUUID<\/span>()\n});<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        That last bit is the browser giving us a unique identifier for free! We could used the package<\/a> for them, but we just don’t need to anymore. UUID’s are cool. There is a practically-zero chance of ever getting a duplicate ever<\/em>. Wikipedia<\/a>:<\/p>\n\n\n\n
        \n
        … only after generating 1 billion UUIDs every second for approximately 100 years would the probability of creating a single duplicate reach 50%.<\/p>\n<\/blockquote>\n\n\n\n
        We’ve decided we’re just going to keep the data in localStorage<\/code> for now, so after we’ve updated our TODOs Array, let’s dump it there. <\/p>\n\n\n
        localStorage[\"data\"<\/span>] = JSON<\/span>.stringify(TODOs);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        Uh, that was easy.<\/p>\n\n\n\n
        Now that we’ve added the data, we know we’ll need to re-render the UI. But we’ll make a function for that in the next section, as obviously we’ll need to render the UI when we read the data when the page loads as well. <\/p>\n\n\n\n
        Reading data<\/h2>\n\n\n\n
        Getting the data out of localStorage<\/code> is just as easy as writing to it: localStorage[\"data\"]<\/code>. That’ll have our JSON data in it. Probably. If we’ve written to it before. Just to be sure, let’s check before we parse out the data. <\/p>\n\n\n
        let<\/span> TODOs = [];\n\nif<\/span> (localStorage[\"data\"<\/span>] !== null<\/span> && localStorage[\"data\"<\/span>] !== undefined<\/span>) {\n  TODOs = JSON<\/span>.parse(localStorage[\"data\"<\/span>]);\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        Just doing that once when the page is loaded will ensure our TODOs<\/code> variable is loaded with what we got. <\/p>\n\n\n\n
        Now we need to render the UI. We already figured out we need to do this in several situations:<\/p>\n\n\n\n
          \n
        1. When the page loads<\/li>\n\n\n\n
        2. When we add a new to-do<\/li>\n\n\n\n
        3. When we complete a to-do<\/li>\n<\/ol>\n\n\n\n
          So let’s write it as a function so we can call it in all those situations. <\/p>\n\n\n
          const<\/span> list = document<\/span>.querySelector(\"#todo-list\"<\/span>);\n\nfunction<\/span> buildUI<\/span>(<\/span>) <\/span>{\n  let<\/span> HTML = ``<\/span>;\n  TODOs.forEach((todo<\/span>) =><\/span> {\n    HTML += `\n      <li id=\"${todo.id}<\/span>\">\n       ${todo.title}<\/span>\n       <button aria-label=\"Complete\" class=\"button-complete\">\n         <svg class=\"svg-check\"><path d=\"...\" \/><\/svg>\n       <\/button>\n      <\/li>`<\/span>;\n  });\n  list.innerHTML = HTML;\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          We knows TODOs<\/code> is an Array, so we loop over it, creating one big string of HTML with all the <li><\/code>s we’ll populate the <ol><\/code> with. (We’ll monkey with that SVG later.)<\/p>\n\n\n\n
          The downsides of a Template Literal is that you don’t get syntax highlighting usually. It’s not going to be linted or checked like your other HTML. Still, I like how simple the Template Literal is here, let’s keep it.<\/p>\n\n\n\n
          Completing a to-do<\/h2>\n\n\n\n
          In the HTML for each of our to-dos, remember we have a <button><\/code> designed for clicking to complete a to-do. But they don’t have click event handlers on them yet. We could put an onclick<\/code> handler as an attribute right on them. That’s not the world’s worst idea, since they would automatically have interactivity applied to them the second they hit the DOM. <\/p>\n\n\n\n
          Just go another way though: event delegation. We can just watch for clicks on the whole document, and if the event originated on that kind of button, then we can do our work. <\/p>\n\n\n
          document<\/span>.documentElement.addEventListener(\"click\"<\/span>, (event) => {\n  if<\/span> (event.target.classList.contains(\"button-complete\"<\/span>)) {\n    \/\/ Click happened on a Complete button<\/span>\n  }\n});<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          There is a little gotcha here though! We have an <svg><\/code> in our button, and it’s possible\/likely the user clicks directly on that, so event.target<\/code> will be that and not the <button><\/code>. So a smidge of CSS will help us:<\/p>\n\n\n
          .svg-check<\/span> {\n  display<\/span>: block; \/* prevent weird line-height issue *\/<\/span>\n  pointer-events<\/span>: none; \/* stop click events from being target *\/<\/span>\n}<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          Now we need to do the actual work. We can figure out exactly which to-do this is by the unique ID that we gave the <li><\/code> element. That will match the ID in our data. So we look through our data and find that ID, mark it as complete, and put the data back. <\/p>\n\n\n
          document<\/span>.documentElement.addEventListener(\"click\"<\/span>, (event) => {\n  if<\/span> (event.target.classList.contains(\"button-complete\"<\/span>)) {\n    TODOs = TODOs.filter((todo<\/span>) =><\/span> todo.id !== event.target.parentElement.id);\n    localStorage[\"data\"<\/span>] = JSON<\/span>.stringify(TODOs);\n    buildUI();\n  }\n});<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          That filter<\/code> function is instantly<\/em> removing the to-do with a matching ID from the data. Ultimately our plan is to update the complete<\/code> value in our data, so that we can show a list of completed to-dos. But we’ve done a lot today already, so let’s revisit that when we do more with JavaScript. We’ve still got editing to do and such.<\/p>\n\n\n\n
          This is a little akwardness of the localStorage<\/code> setup we have. Every time we touch our data, we rewrite the entire set of data each time. When you’re working with a “real” database, don’t download the entire database and replace the entire database when small changes are made, that would just be silly. But our data is so small\/light here, even if there were a few hundred to-dos, it’s not that big of a deal. But certainly a real database is a cleaner and more scalable approach. We could have also architected things differently, making each to-do a unique key in localStorage<\/code>, but that didn’t have the Array characteristic we wanted, and just feels kinda sloppy to me. <\/p>\n\n\n\n
          See that we’re calling our buildUI()<\/code> function after making the data change as well, ensuring our UI is in sync with our data. <\/p>\n\n\n\n
          So Far<\/h2>\n\n\n\n
          I feel like the native JavaScript Template Literal is a good fit here. That’s the string within backticks (`<\/code>). This allows us to write multi-line strings and interpolate variables inside. This is a place where there is lots of choice though! We could have used a native HTML <template><\/code> here, and perhaps we will in the future. We could have used a Handlebars template<\/a> or the like. If you’re used to using a JavaScript framework, this is essentially a component and essentially the heart of whatever framework it is. Like the JSX of React.<\/p>\n\n\n\n
    (Astute readers will note that JSON doesn’t actually have comments, unless we fix it somehow<\/a>.)<\/p>\n\n\n\n