Week 25

Session recording

Project progress review

We’ll start today again by checking in on your projects—which should be into code. Same groups again:

1. Bhroovi, Kirsten, Kritika, Rodrigo, Shaurya, Vera, Wenny

2. Alexis, Angelica, Emily, JC, Rebecca, Sachi

3. Cristina, Dhruvil, Hana, Sabrina, Vicky, Zil

4. Hannah, Hao, Lucy, Sarah, Shaoran, Xinyi

And a similar structure as last week:

• We’ll each see the other half of you, from last time—a few minutes each
• Recap your project for us and any show us changes/updates to your roadmap
• Then we’d love to see your progress into code! We should be past Figma here
  
  
• You know the drill: you will do the same thing when we aren’t at your table!
• Share where things have evolved from last week, how your plan has changed
• Focus your discussion with your classmates on your technical challenges/hurdles—they might have insight into solutions or approaches

Reconvene!

We’ll add our overall thoughts again here!

Saving state

Now for 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—only you can change your pages, in code
  • GitHub Pages (our hosting) does not allow server-side languages (PHP, Ruby, Go, etc.) nor databases (MySQL, Postgres, etc.)
  • These are how most sites are dynamic—constructing pages, storing information
  • But we can approximate/suggest this kind of dynamic behavior with JS

• Then forms and inputs (comment out the form-state.js to start)

  • <form> / <input> / 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 the submit event
  • This is a way for your request to the server to be more specific
  • We’re going to use these to track our state
  • URLs makes these shareable—you could bookmark/QR to different states
  • Comment form-state.js back in and go through
  • preventDefault stops the form from submitting/refreshing
  • Instead, we update the URL on the input event (any change to the form)

• Finally web storage

  • Persists across reloads/browser sessions—but still limited to one device
  • Cookies (cross domain, visible to server) vs. sessionStorage/localStorage
  • Visible/editable in Inspector (Application > Storage > Local Storage)

For next week

• Pull down our repo from today to see how it works—again, with the lens of how you might use it in your project:

  forms-params-storage

• Onwards to your next project milestone, which we think should be “topping out” your code. Again this will depend on your own roadmap—but know that if you aren’t “topped out” for next week, you are running behind!

  As always, update us with your progress:

  Assignment submission