Just a short post today. I’ve been following up on the practice exercises from last time, building a class and using it to create objects. I ran into some issues with it, though — I can’t access my new class and its constructor from the browser console.
My first suspicion is that it’s because I switched browsers (formerly using the Firefox console, now using Chrome). Maybe Firefox is more forgiving in some way — but I can’t think of why this would be. Might be some way in how I imported my code into the HTML doc, but I’d be very surprised about that. I checked the template to see whether I was missing something and saw a statement of export default [ClassName], so I added that to my new class, but it didn’t make a difference.
I went into an older example of script.js from one of the non-practice lessons, which showed how to import classes, and made sure I’d set everything up right (having different JS modules imported in the right order, etc.), but still couldn’t make it work.
That’s all for today, but I think next steps will be to go through the ES6 import syntax and see if there’s anything else I can do to fix this.
Another day, another example of JavaScript doing things strangely, where strange is defined in the self-centered manner of “not how I would expect, based on what I learned”. This time it’s the flexible method of creating a class: either using a declaration:
class ClassName { properties }
Or using an expression:
const ClassName = class { properties }
According to the lesson the trend is towards using an expression, but the instructor uses a declaration, and it seems to me to line up with other languages’ way of doing things a bit better.
You can also create a “class” of objects just by creating a constructor function, which will contain all the properties including other functions (in the declaration and expression options, the constructor function is separated out from the other methods of the “class”), like so:
function ClassName ( attributes ) { properties }
Here attributes are the variables passed into the constructor and properties are any work done to set the instance variables, any other variables, and any other functions the “class” might have.
The tutorial makes a point of saying that creating a “class” by just using the object constructor function is not the same as making a real class, and that real classes are much more flexible and extendable than just using a function, so the third option is not recommended; it’s just that JavaScript didn’t have classes for a while, so older code and tutorials might use object constructor functions.
That’s going to be all for today — hoping I get some time to put this into practice soon.
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.
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.
