---
tags: mstu5003, tinker
---

# Shared Tinkers: Summer 2021

## Tinker: Javascript II

### Supplemental Videos

Want to see one of our past instructors go through the Todo Tinker with line by line articulation and explanation?
- [Codepen Todo Line-By-Line](https://www.youtube.com/watch?v=ktqNLff0JT0)

Want to see Jin use the `Debugger` tool to analyze a Todo Application (similar to but not Codepen version) and go through it state-by-state?
- [Non-codepen Todo w/ Debugger State-By-State](https://www.youtube.com/watch?v=Bb6oIAlGJX0)

## Tinker: Javascript I

### Supplemental Videos

Since this one is more complex - here is a video series specifically discussing how this all breaks down.

#### Series I (More Recent)
- [JS Tinker Part I](https://www.youtube.com/watch?v=Cog0ONe0HoE&list=PLn93-yl6k7zVzwy1dz4nnDOxlWz-oYgsV&index=13)
- [JS Tinker Part II](https://www.youtube.com/watch?v=r0Xq9KNhkQM&list=PLn93-yl6k7zVzwy1dz4nnDOxlWz-oYgsV&index=14)
- [JS Tinker Part III](https://www.youtube.com/watch?v=2XHERpt_HlU&list=PLn93-yl6k7zVzwy1dz4nnDOxlWz-oYgsV&index=15)

#### Series II (Older but more broken down)
- [Tinker JS I - Prom Challenge](https://www.youtube.com/watch?v=Qc-bLsm1De8&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=26)
- [Tinker JS I - Part I](https://www.youtube.com/watch?v=5oVyGoBLbYE&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=27)
- [Tinker JS I - Part II](https://www.youtube.com/watch?v=iN-y8jFg60s&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=28)
- [Tinker JS I - Part III](https://www.youtube.com/watch?v=KelskXU8tWY&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=29)
- [Tinker JS I - Part IV - Select](https://www.youtube.com/watch?v=pCaygYSDtwM&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=30)
- [Tinker JS I - Part IV - Checkboxes](https://www.youtube.com/watch?v=w31FngMw_gE&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=31)
- [Tinker JS I - Part IV - Radios](https://www.youtube.com/watch?v=72DWMuK2Hf0&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=32)
- [Tinker JS I - Conclusion](https://www.youtube.com/watch?v=FOpDKw93LcI&list=PLn93-yl6k7zUkSFNI8MQqmIVn017z8vKO&index=33)

---

## Tinker: Javascript 0

- https://hackmd.io/U754O84DRGmoJ5e_KZhAow
- https://hackmd.io/@rd2705/SJen-vZKO/edit
- https://hackmd.io/mI0bL9xHRK-cVhL3JYzl9w
- https://hackmd.io/@YwsrjOkPRL6ZM3W5_dupQA/By6d4Yxtd
- https://hackmd.io/@fIGQ0hRxR9S_zxiMbM7uFQ/S1rfZNbtO
- https://hackmd.io/@d2n0MPMFSxSoTl18LbQZYw/BJuzXBbYu
- https://hackmd.io/@aOqX_rJrQeq-upgu6SyO5A/rJWaNKgF_

### Feedback

- Overall I'm really pleased with what I saw. Feels like many of you are making those connections between objects and our pages, and how we can start getting and manipulating them. Based on your work I feel pretty good about this week's topic as you'll go into it with a strong understanding of these fundamentals and can focus on the good stuff.
- TIP: `element` objects are common for us to work with when doing web-apps. Another common object (i.e. this week) is the `event` object. It's a tad special and is available to us when we do interactions, so be mindful of what makes `event` objects 1) different from element objects and 2) useful in their own right.
- I think most of you'all are understanding this idea of *objects* and how to manipulate them. You are generally using dot-notation correctly.
- Think of dot-notation as transliterating to the word "has" or "of" --- therefore, `object.property` can be read as `object` `has` `property` OR backwards, `property` `of` `object`. Using this, you can infer a lot of things.
- Example: If I give `x.color` you can infer that `x` is a reference to an object and `color` is a property of it. You can also infer that whatever kind of object `x` is (`x` is just a reference name for the kind of object it points to - could conceptually be a car, could be an animal) other similar objects have similar properties like `color`.
- With our work, we work most primarily with `element` objects. `let x = document.querySelector('div')` etc.
- TIP: When you look at the Elements tool in the devtools, we often say we're looking at the HTML. But that's not 100% correct. Our static code is HTML. What the elements tool shows is is more of a LIVE representation of the HTML. So yes, it's represented in HTML - but it changes dynamically. Doing something like `document.querySelector("#main").className = "sweet"` will dynamically SHOW in the elements tool where our original codepen code will always remain static and the same.
- While not wrong (meaning it IS 100% valid), I see many of you'all using other selector methods (i.e. methods = functions of objects) like `getElementById`, `getElementsByClassName`, `getElementsByTagName`, etc. It's somewhat less common to use these methods to query the DOM these days. They existed before `querySelector` and `querySelectorAll` and honestly, I can't recall any modern code that still uses these. `querySelector` and `querySelectorAll` can do it all and is the preferred way of grabbing element objects.
- `console.log` is a tool so it's designed to show things in certain "convenient" ways. So note that it doesn't always represent things as the truth of what they really are. Example:

  let span = document.querySelector('span');
  console.log(span);
  // prints <span>Hello!</span>

While the output we say is "HTML" or maybe it even looks like a String of "HTML" - the reference `span` is still an element object.

  console.dir(span);
  // gives us an interactive map of the object

The `console.log` provides us with a convenient printout for debugging. But the `console.dir` gives us a deeper dive, closer look into what truly is. So just keep that in mind.
- I'm very pleased to see most of you all do well with the basic GET/READ/CHANGE/SET/WRITE/REPLACE values type of mini-problems based on the objects. If you can do this, you can manipulate the DOM.
- I'm also pleased to see many of you describe the computation for some of the more extended prompts - even if you don't know the actual syntax for certain things like conditionals yet.
- Clearly you'all are making close examinations of things utilizing the tools provided which is part of the stepping stone into this. Good to see.
- Really great use of formatting to make your points. I fully appreciate the use of `code` highlighting, `images`, `content`, as well as other markup to make your articulations and presentation clear. Part of why I like using HackMD is that Markup is a common way for programmers to document and communicate. Being mindful of the more "simple" syntax here goes to create strong habits of doing the proper syntax mindfulness in our JS code.
- Many of you have correctly inferred how element objects are basically connected to all the other element objects through things like `children`, `parentElement`, etc. and the way you describe it make me think you're getting the idea of what the DOM is. This is actually a pretty difficult concept for many novices!
- Also: special points for the group that observed the rabbit hole can actually be an endless loop. E.g. `el.parentElement.children[0].parentElement.children[0].parentElement.children[0]...`
- TIP: We're going to be working with `<input>` elements soon enough. These elements have a very special property called `value`. So be mindful of this as we go forward. Example: If I have a text input `<input type="text" id="x">` and type "MSTU5003" into it, then do `let inputEl = document.querySelector("#x"); inputEl.value;` what do you think will be returned?
- Some rather deep observations in interesting places including inferences and experimentations around tool outputs - followed by Google research. Impressed.
- Several of you asked about the `undefined` that comes up when doing `console.log` work. It's a fantastic inquiry and so do read this: [#ask-us-code response](https://cmltd.slack.com/archives/C020V5QC8TB/p1621456764025200)
- A common usecase of using `for` loops is to loop through all things in a list. Programmers, being lazy have come up with a shorthand to replace the `for i= yada yada` syntax.

  let myList = ["alpha","bravo","charlie"];
  
  // Regular LONG syntax
  for (let i=0; i < myList.length; i++) {
    console.log(myList[i]);
  }
  
  // SHORTER/LAZIER (awesome) For OF syntax
  for (let word of myList) {
    console.log(word);
  }

In the `for of` we don't have to use `i` for indices because the assumption is to do something with every *thing* in the list. That is, always increment the index by one in the background as a given. Hence, the first part of the pattern `for (let ___ of ____) { ... }` is just any variable that we will use to reference whatever individual item we're on within the loop. The second part is the reference to the list itself.
- Some of you'all are using FCC stuff in your tinkerings even if I hadn't asked for it. E.g. `typeof` `hasOwnProperty` etc. Love it, that's applying what you learned in an independent way.
- While not common, sometimes I saw some "incorrect" answers that could have been checked using the console or producing just a little (i.e. 1 line) HTML. It's common practice to create a sandbox to represent computational problems (isolated down to what you're testing) and then run code in the console to "check it out."
- The language many of you are using is very (good) technical. Even for seemingly simple prompts - Example:
- `console.log()` returns the **object** or our input in its **string representation**. `console.dir()` recognizes the **object** and just outputs its **properties**. Both `console.log` and `dir` **return** the input string as a string.
- Think like a programmer and *talk* like a programmer.
- A note about `textContent` vs. `innerHTML` properties of element objects. `textContent` property is for manipulating the String assigned directly into plain text. `innerHTML` will process the String assigned and convert it into HTML elements.

  <div>Original Text</div>

  let el = document.querySelector("div");
  el.textContent = "<h1>New Text</h1>";

The above will show the text (literally) as `"<h1>New Text</h1>"` in the page view. Probably not what we want. We want the browser to process this string and interpret it as an `h1` tag and make a Heading 1. For this we want to use `innerHTML`

  el.innerHTML = "<h1>I am a heading 1!</h1>";

In this example above, we won't see `<h1>` in our page view, but if we look at the element we will see an `h1` element was created with the `textContent` of it being `"I am a heading 1!"`. So think - if you want to produce actual new HTML inside some element, use `innerHTML` to process your HTML String into real HTML. If you want to manipulate just the plain text, use `textContent`.
- Be careful of capitalization of variables, properties, other references. `document.querySelector` is not the same as `Document.querySelector`. One will be a success and the other an error. JS is case-sensitive. As a rule, generally think of references as lower-case but if a reference name has multiple words, the convention is to capitalize the first letter of each word starting from the second to make it readable. This is called `camelCase`.
- Advanced conventions:
- `ALLUPPER` are conventionally used for variable references that will never change value. CONSTANTS. `const PI = 3.14;`
- `CapitalFirst` is conventionally used for variable references that indicate Classes. Not CSS classes, but object-oriented-programming-ish classes. Something we don't go into in this course very deeply.
- There's a convention for everything... programmers are a picky bunch.
- Some of you'all come up with some clever solutions to the prompts I've produced, solutions that I didn't think about but would definitely work. :grin:
- Interesting note on "no value".

  let x = ""; // Has a value, empty String. Conceptually tied to the idea of no STRING value.
  x = null; // Has assigned value, a null Object. Conceptually represents the value of no value. WTF?
  x = undefined; // Truly has no value assigned.

You don't have to get a headache with this. But thought I'd mention this as I'm seeing some of you use these terms. Some non-JS programmers hate Javascript for reasons like this.
- Be careful of fancy quotes/double-quotes vs. plain double-quotes. Often times people using non-English keyboards/languages will end up typing fancy-quotes (the ones that curl in and out depending on if it's an opening or closing quote) and this gets processed as a different character than plain double-single-quotes. This will lead to errors! If you want to write strings - use plain quotes. (Also, be careful of copy/pasting in fancy vs plain quotes.)
- On naming things - if you're naming things (i.e. variables, parameters, etc.) try to name them to represent the thing they are referring to.

  let el = document.querySelector("div"); // Okay since we'll get back an element.
  let divEl = document.querySelector("div"); // Very descriptive.
  let x = document.querySelector("#x"); // Not really great, we'd have to remember what id x really is. I promise I'll forget.
  function feed(animal) { ... } // Good - can't be sure if animal is a number, string, or object but it's descriptive. I'd guess an object by default.
  function feed(animalAge) { ... } // Good! I can guess it's a number, descriptive. e.g. 35
  function feed(animalName) { ... } // Good! I can guess it's probably a string and is very descriptive "tiger" etc.
  function feed(isFed) { ... } // Good! Implies Boolean and is descriptive. true/false
  function feed(a) { ... } // I have no idea what the parameter a is/was etc.

- One thing I'm always pleased to read about are your personal words of success and failures based on the efforts you've tried. Hashtag `#yaskweenyas`. I think I share your emotions whatever that hashtag means. :grin:
- Also love when you include "proof" of your success showing you've tried it. Programming is one of those rare domains where you can get instant correct/incorrect feedback from a computer instead of waiting on the instructor (whose feedback may be very asynchronous, if at all. Eh hem.) Computer is your friend. Ask it questions and get immediate answers!
- I see great examples of people using multiple different computational concepts and combining them to accomplish more sophisticated things. (E.g. variable assignments, loops and conditionals, function declaration and calling, and DOM query/manipulation.) Even if you can't code it yet, if you can THINK it (i.e. pseudocode) 80% of the battle is complete.
- Some of you are starting to up the game by referencing OFFICIAL documentation such as the [MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/API/Element/tagName). Getting comfortable with this is a huge step forward.
- TIP: In the Elements devtool, if you click on / hover over some element HTML, on the page you should see visual highlighting of what you're interacting with. Good for getting a sense of the relationship between different elements and what on the page it's actually influencing.
- Some of you have big dreams - Like **World Domination**. Good luck with that.

---

## Tinker: Bootstrap

- https://hackmd.io/TO7kMn8ASdGRwOI-3YaWQQ?both
- https://hackmd.io/@fIGQ0hRxR9S_zxiMbM7uFQ/HySWZqYOd
- https://hackmd.io/SiZoQQ5rTwePtUJhY4Ku5Q
- https://hackmd.io/E7TCOOVyT4yvtsBL8OFLDw?both
- https://hackmd.io/Q9PEfIeESZGWem7g3t9JNQ
- https://hackmd.io/@ah3836/ryGnd4tO_
- https://hackmd.io/KG-DtmzoRjytkGUAKTzFHA?both

### Feedback

So again, this is a running overall feedback that I see as "what is trending" with the class. Think about these positive/negative things and what/how it might apply to your own work, thinking, etc.

- I'm very much pleased that your interactions seem to not only be about specific coding concepts, but you're also observing and analyzing how you are each approaching *learning* of code. Makes mixing up social teams and having this collaborative work worth it in the end. Eat that Lynda.com!
- EXTENSIVE refactoring (i.e. revamping, changing code) of the original tinker code to make it almost yours! Including code and concepts that I definitely didn't write. (This is what I call tinkering for sure!)
- Cleaner formatting of the actual Markdown (HackMD) document. Using markup features like: `code`, `quotes`, `alerts`, etc. to make the presentation of the articulation clear. See notes below on examples.
- Flipside of this - it's super hard for me to read unformatted wall of plain text. Harder things are for me to read, the grouchier readers will get.
- Use of rich example forms: images, tables, etc. to communicate your ideas.
- For many of you, I'm noticing (and liking) the kind of specific technical language you are using in your articulations! Bravo.
- I get a sense that you'all are making more strategic observations (observations that come from particular inquiry/purpose).
- You're making deeper observations than the last tinker.
- More nuanced articulation. E.g. THIS vs. Well, it could be this in this sort of context, but we also see this, therefore it might mean...
- Expermentation that goes beyond what the tinker "tells you to do."
- Bringing in concepts from prior weeks and even FCC examples explicitly in your explanations!
- Some of you are posting interesting ideas that connect what we're learning here to things outside of this class. I find this fascinating that you can make these meaningful connections.
- Before and after analyses + rationale.
- Links to outside resources and examples that you've used to "think against" the tinker challenges. When I can see the efforts you make - that always reflects positively.
- Trying multiple things.
- E.g. If the question is does anything change?
- Changing hierarchical order of classes might change things.
- Changing the order of classes on an element might not. etc.
- Ha ha, some of you have picked up that you can incorporate HTML directly into HackMD and it will often render. Just keep in mind these are Markdown documents so try to be sparing in terms of how much HTML you want to actually write here (unless it's HTML code examples.) But I do get it. Making Tables in Markdown is somewhat of a pain although it's easier when you click the table button in the editor tools.

### Formatting Tips: HackMD

See the actual markup here: https://hackmd.io/M1nwSjn5RgaTYAo_ooxCXw?both to see how some of this is achieved in context.

For a COMPLETE guide to all HackMD flavored Markdown syntax you can observe this document and its code: **https://hackmd.io/features?both**

By the way, [Markdown](https://daringfireball.net/projects/markdown/) is a coding language in and of itself. So really, in this class if you use Markdown, you've learned a 4th language along with `html, css, js`. There are different variations to the basic standard Markdown language. HackMD is an online editor that uses it's own extended flavor of the Markdown language. HackMD *converts* Markdown into HTML for us to view. But you might have noticed, Slack uses Markdown as well, a slightly different customized flavor. And even sites like Reddit, you can use Markdown to post your comments using Reddit's flavor. So Markdown is very useful. I tend to write a lot of little notes in Markdown because you can create Markdown documents in plaintext and the symbols tell me things about the document that I could present online easily.

#### CODE

Single back-ticks \` in order to achieve `inline code`.
Triple back-ticks \`\`\` in order to achieve block code like this:

Multi-
Line-
Block Code

Block code with HTML/JS Syntax Highlighting:
Add `htmlmixed=` after your triple \`\`\` s.

To achieve:

<div>
<p>Stuff</p>
</div>

Or `javscript=` after your triple \`\`\` s.

To achieve:

let x = true;
if (x) {
// something
}

#### Blockquotes

Use the `>` sign to start a block quote.
> This is a quote.

#### Alerts

Triple `:::info` in order to get an alert like this. Hey, this looks like Bootstrap convention... `success, warning, info, danger, spoiler`

:::info
Info alert.
:::

And so on so forth. Of course, the standards are also appreciated - like using headings, bold, italics, strikethrough, lists. These can be done through the Markdown language or the WYSIWYG (what you see is what you get) editor functions.

---

## Tinker: HTML/CSS - Meow Mix

- https://hackmd.io/@pIMCeT-tRAWJEhI9T2E0cQ/SkdR_KbO_
- https://hackmd.io/SYaErBT6RdufMwSYy5OlTQ
- https://hackmd.io/@ixEvsW_oTw6y1BUE_A1ngA/week1meow
- https://hackmd.io/9Cssq3NdROu16ShsetYjjA
- https://hackmd.io/IGq31_OPTuqqqBP1P1FZAQ
- https://hackmd.io/@Yanqiuli/SkSAyJbOO
- https://hackmd.io/TX334X9bQBiHwz_jiySp6A?both

### Feedback

I generally don't provide specific answers to Tinkers. It's up to you to take a look at your peers observations, thoughts, inferences, conclusions to make sense of this.

That said, I was VERY impressed with how you all went about the tinkers. So many different approaches and things done right. I think there is a lot to learn here. Especially:

> How should I go about learning code?

There is a lot to :heart: here.

___

Finally - I do like to provide a little feedback for everyone.

### Things I Liked Seeing:

- Double check your submissions to make sure:
  1. It's the right thing
  2. It's accessible to others (since we share + I need to see it to evaluate it.)
- People showing examples of things they actually "tinkered" with beyond what is in the initial code.
- Recording observations of cause and effect.
- Actual novel code examples
- Also good to see some people using very specific formatting to illustrate points (i.e. in Markdown syntax.)
- Be careful of indentation and making it properly line up.
- Nice reflections - meaningful and deep for some of you.
- Some of you note interesting inquiries that are generated from your tinkering.
- Some of you are doing very interesting things where you first write up a hypothesis, then you tinker/test, then you explain your results. Very interesting.
- Some of you recognized that when you are trying to learn code - it's best to manipulate only ONE thing at a time. Problem ISOLATION. Manipulating more than one thing obfuscates the cause/effect.
- I like HOW some of you are talking like programmers, using specific language, keywords, syntax etc.
- Some of you use interesting analogies in explaining your observations.
- I like how some of you include how as a team you negotiated a common understanding from your unique perspectives.
- Some of you went very far in manipulating and changing up the original code - even going as far as generating very new pages based on the initial.
- Some of you record your own failures and attempts to fix them. Very interesting and obviously helped you have to think critically about the problems.
- Generally - the principles, rules, patterns that can be derived from your observations are more important than specific element names, attributes, properties etc. Focus on that and Google the rest.
- Some of you all make the tinker effort a more personal twist - including your motivations behind what you desired to create/modify/tinker and showed the URL results. Interesting.
- Some of you have brought in class outsiders into your tinker efforts. Hey, the more the merrier. I don't mind you asking others (experts) as long as the responsibility of understanding is carried on each person's shoulders.
- Some of you didn't quite get to the "final answer" but that's fine because you recorded your observations and thoughts of partial knowledge that will eventually lead to the answer as well as allow you to compare your thought process and observations when you cross-check your understanding against others in the class.
- Some of you have emphasized the importance of indentation. We will see whether your articulation that this is important, and whether you truly believe this to be important matches in your future code submissions.
- Some of you went into the console and started looking at pages from that tool (see elements tool) to analyze some code.
- Some of you went to good lengths to make the timezone differences work. Collaborative work across the globe is challenging - but with creativity it can be done.

### Things you should consider (i.e. in your articulations/writeups)

- What kind of inferences can you make based on what you observed?
- What's a generalizable RULE or pattern that you've come up with based on your tinkering?

// EXAMPLE

function doSomething() {
alert("Hello");
}

// PATTERN Syntax

/* keyword function followed by function
* name and parentheses to signify possible
* arguments, followed by curly braces to
* represent the function body, and the code
* to be executed inside the body. */

function funcName(arg1, arg2, ...) {
// code statements / routines
}

/* Anytime I want to define a function,
* I would use the above pattern to declare
* it. Which means I should memorize this
* pattern! */

- What does your observations and tinkering "mean"?
- What's the relationship between the different things and parts you've played with when you tinker by isolating change to one thing at a time?
- How does what you find affect how you will proceed to code your own stuff?
- I encourage use of more formatting tools to better communicate things. Try using `in-line preformatted formatting`,

<!-- block preformatted formatting, etc. -->
<div>
<p>Like This.</p>
</div>

<!-- Change the indentation settings to 2 spaces or tabspace of 2 -->