Tag: my code

Bracket Notation

The first big thing today was learning about accessing the properties of different objects. The standard notation – aka, what I’m used to – is dot notation (object.property), but today I discovered bracket notation, which looks like object["property"]. This is used for cases where the property is a variable rather than a constant, or the property might not conform to JavaScript naming conventions (basically, there’s nothing preventing an object or variable from being named in a way that breaks the rules, so the code will only break at runtime, and even though you would never write such messy code, you might end up using data that wasn’t meant for JavaScript). It’s a safety valve.

Object Practice

It looks like I actually worked a little bit ahead last time when I decided to design my own soup objects. There’s actually a built-in stopping point in the tutorial where you’re encouraged to pause and put into practice what’s just been covered. I ended up having to go back a little bit to last week’s exercises, as over the weekend my memory of the syntax got foggy, but I ended up building a JavaScript “earring box” object (the tutorial encouraged making a container object, so that you could have smaller objects inside your object).

const box = {
  name: "Earring Box",
  material: "velvet",
  color: "black",
  pairs: 1,
  earrings: {
    material: "gold",
    style: "dangly",
    length: 1,
    gems: "rubies",
  },
};

console.log(
  "My earrings are",
  box.earrings.material,
  "and I keep them in a",
  box.color,
  box.material,
  "box."
);

And a quick screenshot to fix those readability issues:

So far, so good. I’m sure I’m not breaking any new ground when I say that, for all that it’s based on Java, JavaScript has some major stylistic differences that are tripping me up. Most primarily the way it’s having me declare variables, though I’m currently willing to suspend judgement as the tutorial acknowledges that it’s doing things a little bit out of order for the sake of learning.

Functions

The next step, after making an object and giving it properties, was to work ahead on functions. This bit was also something I skipped ahead on last week, as knowing how objects and methods work means that I could recognize the patterns early. Interesting to me, though, was that in the same way that JavaScript has an alternative to dot notation, it also has an alternative syntax for declaring functions (and one which the instructor said was considered more common and better practice).

The difference is between method(arguments), what I would consider the conventional way of doing things, and method: function (arguments), where the method is listed as a property of the overall object in the same way that other variables and constants might be. In my example code, box might have openBox: function (lidUp) as a property alongside name and material.

Making My Own Functions

The function practice exercise didn’t involve adding functions to the object I designed (though I might go back and do that anyway); it gave a template backpack object and asked us to create functions to change the properties the backpack already had, and describe those changes. I also ended up creating an extra method called introduceMe() in order to save a little time on the sentence describing the changes:

introduceMe: function () {
    console.log(
      `This ${this.color} backpack is named ${this.name}. It has ${this.pocketNum} pockets and holds ${this.volume} liters.`
    );
  }

In doing so I figured out how to insert variable names into strings, which will save tons of time in the future.

End-of-day reflections: this tutorial isn’t doing a lot to teach me new principles of coding, but it is getting me more familiar with JavaScript syntax and getting me back into the rhythm of writing code, which is honestly all that I’d hoped for from it.

As per usual, the “first” day was all setup, and the real day one is where the learning starts. I’m following along with this tutorial in LinkedIn Learning, to get familiar with some of the basics of JavaScript.

Fun Little Tidbits

Special Commenting Trick: First, I learned that you can put your cursor on a line of code (or highlight multiple lines) hit CTRL+/ in order to comment out those line(s). Probably old news for some people, but absolutely magic to me, I’m a very big fan.

Special Editing Packages: Part of the tutorial was also installing ESLint and Prettier, two packages that will automatically check for syntax and formatting errors and either call your attention to them or clean them up (so, ESLint will flag errors, and Prettier will enforce rules about semicolons and spacing in order to make your code more human-readable).

Now I Know

Order of Operations

JavaScript works in concert with HTML and CSS. If HTML is the skeleton and the muscles, and CSS is the skin, JavaScript is the brain and the nerves that can make it all move (I made this metaphor up myself, so if it’s inaccurate or just plain gross, that one’s on me). In an HTML document, it might look like this:

<script src="script.js"></script>

It’ll be located somewhere in the <head> section of the HTML document, alongside the CSS source and other metadata information, for purposes of well-organized code.

If your HTML script tag written like this, then as the page loads, the browser will read through the document, hit the script section, and start working through whatever’s in script.js. Which is great, unless script.js needs to act on code that hasn’t loaded yet.

Okay, so we put script.js at the end, outside <head>, in the <body>. But no, wait — that’s bad for code organization, and what if we want script.js to be referenced by stuff that needs to load after it?

<script src="script.js" async></script>

The way to fix this is the HTML terms defer and async. async means that, rather than running the document, hitting JavaScript, loading the whole script, then running the whole script, it’ll run the document, hit JavaScript, and then load the script while continuing to run the document/load the page; once it’s done loading the script, it’ll stop loading the page, run the JavaScript, and then go back to loading the page; defer is similar, but it saves running the script until the entire page is loaded. This way you can have the code organized neatly and run at the right times.

The difference between the two is in part down to render time (or, how long it takes for the page to fully load). Without async, the page stops loading in order to both load and run the JavaScript, seriously impacting render time; async impacts render time slightly by loading the script in parallel with the page, then stopping momentarily to run the Javascript before continuing with the page; and defer doesn’t impact render time (because it doesn’t run until the page is all loaded) but does make you wait on your JavaScript.

What I Made

After messing around with the tutorial on how to create objects and declare their properties and methods, I decided to mess around a little in the console and create my own. What I learned is that if you create a constant object, run the code to see if it works, clear the console, add in some more properties and functions, and then re-run the code to see if it works, that doesn’t necessarily actually get rid of the original object, and you will get error messages telling you that you can’t re-create the object, because it already exists as a constant.

I ended up just renaming the object, because it was simpler.

Anyway, if you want to try my code, here you go! See if you can guess what it does before running it.

const beefSoup = {
  broth: "beef",
  numPotatoes: 6,
  noodles: true,
  strain: function () {
    this.numPotatoes = 0;
    this.noodles = false; },
  tellMeAboutIt: function () {    console.log(this.broth, this.numPotatoes, this.noodles); }
}

beefSoup.tellMeAboutIt();
beefSoup.strain();
beefSoup.tellMeAboutIt();

The formatting’s a little funky because WordPress doesn’t respect line breaks, so here’s a screencap of it as well.