Week 24, March 26

What We’re Seeing So Far #

• This is not, primarily, a content project—if you are burning your time here, we want you to refocus on the function !

• Differentiating between assets and content—you might think of an illustration or icon as an asset. This also not primarily an asset project, but leave some time (towards the end) for these.

• People should be in code! Focusing again, on the core functionality of it—don’t overindex on how it looks, right now—in fact, maybe don’t write any styles this week (nor any Figma).

• Model the data you will need—starting with local data (“hardcoded,” below) before moving to an API!

• Don’t check any API keys into your repositories! They shouldn’t be public. If you have an API that needs these, talk to us.

• As you get into the technical aspects of your MVP, ruthlessly trim your scope! As we said last week, “all things equal, a thoroughly working project is worth more than any particular taste/design.”

Working With Data #

This is similar to what we did with Are.na—but now working with a JSON file within your project. You could use this as a model for an “API” of your own data:

local-json

• Remember JSON (JavaScript Object Notation)?

  • Before we asked Are.na for data, but you can also include it yourself
  • You can always write/edit your own JSON files by hand, though the syntax is pretty easy to mess up!
  • Instead you could start your data from Google Sheets, and use an extension to export or convert it from CSV
  • There is also a better add-on, but New School IT doesn’t want us to have nice things—use a personal account to try this out!

• Just like with our Are.na projects, we can generate DOM from this data!

  • IRL, you’d probably have some kind of templating framework or library—but you can use vanilla JS for repetitive/data-derived DOM
  • We’ll again use a forEach loop to go through our array of data
  • For now, we can use the same template literals/strings, in our JS file
  • Using if/else conditional logic to apply a class
  • This still uses the fetch API to get the data—but now from a local file!

Keeping Track of State #

And an example of saving state. This is a little more advanced, but it shows some ways you might retain a user’s preferences/selections within your project (within what our free GitHub hosting allows):

forms-params-storage

• Briefly, static vs. dynamic websites (in a build/hosting context)

  • We have been writing static sites—meaning that only you can change your pages, in code
  • GitHub Pages (our hosting) does not allow server-side languages (PHP, Ruby, Go, Next.JS, etc.) nor databases (My SQL, Postgres, etc.)
  • These are how most sites are made dynamic—constructing pages, storing information, responding to user requests, allowing sign-in
  • But we can approximate/suggest some dynamic behavior with JS!

• Then onto form, input, and select elements (commenting out the form-state.js to start)

  • <form> / <input> / <select> / button are semantic indicators of interactivity
  • The type= attribute is used for different (user-agent) controls
  • required makes them… required
  • <label> elements are connected by for=, id=, name= attributes
  • You can (and should) style them from these defaults

• Onto search (aka: query strings) and URL params (for parameters)

  • By default, forms add their query string to the URL on submit
  • This is a way for your request to the server to be more specific
  • We’re going to use these to track our state—what the user has done
  • Using URLs also makes these shareable—you could bookmark/QR to different states
  • Let’s comment form-state.js back in and go through
  • preventDefault stops the form from submitting/refreshing
  • Instead, here we update the current URL on the input event (meaning any change to the form)

• Finally web storage!

  • This API persists data across reloads/browser sessions—but it is still limited to a single device
  • Cookies (cross domain, visible to server) vs. sessionStorage/ localStorage—are all just ways to keep track of things
  • These are visible/editable in a DevTools panel: Application Storage Local Storage