Cwd on blog.iankulin.com

Expired packages

Mon, 30 Jan 2023 00:00:00 +0000

At several points in the Complete Web Developer course, deprecated packages have been used, with the slide before the video explaining what’s happening, and giving a work around, or sometimes - as is the case for the bit I’m just starting - exhorting the benefits of dropping you into a non-working mess and having you figure it out yourself.

While this argument can be reasonably made - that figuring things out on your own is a valuable skill - it’s also a useful fig leaf to cover up the fact that they haven’t bothered to fix the course to make it work out of the box.

A recent example of this was the particles.js library. The card preceding the video says the library used in the video is no longer available, but hey, this other one is pretty much the same. And, I mean it was very similar, but the instructions on it’s npm page for using it were different from what was in the video, the video instructions didn’t work with it, and following the install page instructions led to one of those repeated npm audit fix --force cycles where you keep just breaking more things.

I got it going eventually, but only by starting with a new create-react app with the particles template then slowly adding back my previous code from git a bit at a time and fixing errors as they came up. The whole process from watching the video to having the project working as per the video was probably four or five hours. Was this a good investment of learning time? Probably not.

Straight out of that experience, Andrei advises that the next section uses a deprecated api, that he’s persisting with because he wants to teach REST apis. In order to make it work, we need to downgrade the react-scripts version which he assures will not cause any problems. Naturally there is a list of critical warnings, and the server can’t start because of a heap of errors.

Starting the development server...

Error: error:0308010C:digital envelope routines::unsupported
 at new Hash (node:internal/crypto/hash:71:19)
 at Object.createHash (node:crypto:133:10)
 at module.exports (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/util/createHash.js:135:53)
 at NormalModule._initBuildHash (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/NormalModule.js:417:16)
 at handleParseError (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/NormalModule.js:471:10)
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/NormalModule.js:503:5
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/NormalModule.js:358:12
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/loader-runner/lib/LoaderRunner.js:373:3
 at iterateNormalLoaders (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
 at iterateNormalLoaders (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/react-scripts/scripts/start.js:19
 throw err;
 ^

Error: error:0308010C:digital envelope routines::unsupported
 at new Hash (node:internal/crypto/hash:71:19)
 at Object.createHash (node:crypto:133:10)
 at module.exports (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/util/createHash.js:135:53)
 at NormalModule._initBuildHash (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/NormalModule.js:417:16)
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/NormalModule.js:452:10
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/webpack/lib/NormalModule.js:323:13
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/loader-runner/lib/LoaderRunner.js:367:11
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/loader-runner/lib/LoaderRunner.js:233:18
 at context.callback (/Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
 at /Users/ianbailey/Developer/CWD/facerecognitionbrain/node_modules/babel-loader/lib/index.js:59:103 {
 opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
 library: 'digital envelope routines',
 reason: 'unsupported',
 code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v18.12.1
➜ ~/Developer/CWD/facerecognitionbrain > git:(main) ✗

Clearly this (or perhaps the next step) is a spot in the course that receives a few complaints, since Andrei goes to the effort of making a special video in front of it extolling the virtues of solving your own problems, and saying he has a script that runs weekly on his code for this section proving it does work. He also explains that after the app is built with the deprecated REST API, he’d got a new video using the new package, then after that we’ll be removing all this code anyway to move this functionality to a node server.

So I’ve got a few options in front of me.

Try and wind back all of the packages that are causing problems until the app runs again.
Just watch the REST API content but don’t bother trying it.
Clone Andrie’s project and see if he’s actually managed to get it going with the outdated script somehow and figure out how and bring that technique over to my project.

(2) is the logical option, but it’s frustrating since the point of this section is to learn REST API’s. In an ideal world, ZTM would have rewritten this part of the course to use a REST API that works. No doubt this would mean coming up with a new app and remaking some videos, but really that’s what they need to do.

Slightly compounding the frustration is that support for the course is community based centred around a Discord, and there’s no channel for this course.

I decide to watch the videos first then make a decision, and in the meantime revert back to the current version of react-script. Of course, when I do this, it suddenly has some critical vulnerabilities in webpack 🤦. I run the force, and now I’ve got 80 critical vulnerabilities and the server won’t run due to errors five deep in Babel somewhere.

To be continued…

CWD - 185 - Problem solving

Sat, 14 Jan 2023 00:00:00 +0000

/* 
Question 1: Clean the room function: given an input of [1,2,4,591,392,391,2,5,10,2,1,1,1,20,20], 
make a function that organizes these into individual array that is ordered. For example 
answer(ArrayFromAbove) should return: [[1,1,1,1],[2,2,2], 4,5,10,[20,20], 391, 392,591]. 
*/

function ctrFunction1(inputArray) {
 // copy the array since we're mutating it
 const array = [...inputArray];
 array.sort();

 const numberObject = {};
 for (const number of array) {
 if (numberObject[number] === undefined) {
 // this property does not exist, so add it
 numberObject[number] = [];
 }
 numberObject[number].push(number);
 }

 // object now contains arrays for each number, but the ones with a
 // single element need degloved
 for (property in numberObject) {
 if (numberObject[property].length === 1) {
 numberObject[property] = numberObject[property][0];
 }
 }

 // now turn back to array 
 return Object.values(numberObject);
}

const array1 = [1, 2, 4, 591, 392, 391, 2, 5, 10, '2', 1, 1, 1, 20, 20];
const transformedArray1 = ctrFunction1(array1);
console.log(transformedArray1);
// [1, 1, 1, 1], [2, 2, '2'], 4, 5, 10, [20, 20], 391, 392, 591]

Line 10

When I’m looking at a function, I’d prefer not to also have to hold global state in my head - so I’m all for functional programming as far as that goes. I’m less concerned about side effects, so I wouldn’t always bother to copy a parameter like this, but the argument is stronger for an array than an object since in other languages an array might be a value type.

The copy itself is noteworthy since I’m using the cool [...x] spread syntax. This is one of the newish iterator tools which returns any iterate-able data as an array. Since this is right at the top of our function, we’re also indicating to the reader we’re expecting a one-dimensional array.

Line 11

array.sort() works as expected, and in place - so our new array is mutated - hence the copying earlier. It can optionally be passed in an arrow function to determine the sort test, but if omitted assumes ascending according to the < and > rules. The format of this function is a bit different that in Swift. For the standard sort it is array.sort((a, b) => (a - b)) whereas in Swift it would have been ( a > b ). This is because in JS the function result is compared against zero to see if the positions are swapped. This seems odd, but I’m sure there’s a reason.

Lines 13-20

The for (x of y) syntax is a neat iterator loop for when you need the item (but not index) of a collection. I slightly regret using number for the array element - since this is JS it could be number, string or anything.

We check the new object we created to see if it has a property with the name of the current element. For example if this element of our array is 254, we check to see if the object has a property of that name - eg numberObject.254. That’s the square brackets on the object. It’s a neat bit of meta that would be challenging in other languages.

If there’s no property with that name we add it as an empty array. The value from the array is appended to this array in the object. So if we had an array of [2, 2, 3, 4] we’d end up with an object.

2 - [2, 2]
3 - [3]
4 - [4]

Lines 22-28

Where there’s more than one of the same value (as in 2 above) we want an array, but if there’s only a single value, we want the raw value. So the next segment of code is to work through each property of the object and change any single values to just their values instead of a single element array. This is a great example of something that’s neat and clear in JS but would not be possible in a strictly typed language.

We use for x **in** y this time to inspect each property of an object (rather than elements in an array).

Line 31

values() is just a standard method that returns an array version of an object.

Step Ahead

Wed, 04 Jan 2023 00:00:00 +0000

I was a bit pleased with myself when I started the next content element in the Complete Web Developer course to find that one and a half of the extensions I’d made to the tutorial app for my own fun were specified as the next task.

In my previous post, I’d talked about using a class to denote if an item was completed, and using a style to indicate this by crossing it out. What I haven’t discussed was that I’d captured right click events on the list items to make this delete them. I wasn’t entirely happy with that for a couple of reasons:

It wasn’t obvious to the user how to delete if they wanted to, and perhaps worse, it might accidentally be invoked - never a good idea for a destructive action with no undo.
It was accessibility un-friendly There was no way to tab through the available actions or to have them read out. This was also the case for crossing items off.

The new task was to add a delete button for each item, which is a much better idea. I decided to do both a “check off” and “delete” button to address the accessibility point above.

The HTML for them looks like:

<ul id="ulItems">
 <li>
 Sample Item
 <button type="button" class="btnCheck">✔️</button>
 <button type="button" class="btnDelete">❌</button>
 </li>
</ul>

I might have been a bit too clever using emoji. I assume they are well supported but not really sure. I also could not change the check mark to green which I would have liked to. I wasn’t sure how important the type=“button” was, but w3schools say to “Always” use it, so that’s good enough for me.

Having two buttons complicated some of the handling code a bit. In the section where I attach the listeners to the buttons for any items that have been specified in the HTML (which could probably just be removed) it looks a bit hacky:

var links = document.getElementsByTagName('li');
for (var i = 0; i < links.length; i++) {
 var link = links[i];
 link.onclick = onListItemClick;
 console.assert(link.childNodes.length === 3)
 link.childNodes.item(1).onclick = onBtnCheck
 link.childNodes.item(2).onclick = onBtnDelete
}

Using the indexes into the childNodes like this is quite fragile. For example, the indexes change if the buttons in the HTML are separated by a new line character, so something as simple as a linter in the build chain could break it. There’s probably a way to get child nodes by tagname (edit: there is - the well named getElementByTagName()) but concerns about performance, along with laziness associated by knowing I’ll probably remove this whole code block prevented me from using it.

I thought I’d reuse the function for clicking on an item for clicking on the check button, but of course the event contains a different caller. So they ended up like this:

function onListItemClick(event) {
 if (event.target.tagName === "LI") {
 event.target.classList.toggle("completed") 
 }
}

function onBtnCheck(event) {
 event.target.parentNode.classList.toggle("completed") 
}

The test in onListItemClick() for the tagname is to stop this being triggered as a side effect of clicking with either of the buttons. Worth noting is that the tagname seems always to be in capitals even if it’s lowercase in the HTML. Lowercase for tags seems to be the convention so that was surprising to me.

The code for adding the buttons for new items is pretty straightforward:

function addNewItem() {
 if (txtItem.value.length > 0) {
 
 var btnCheck = document.createElement("button")
 btnCheck.innerText = "✔️"
 btnCheck.type="button"
 btnCheck.classList.add("btnCheck")
 btnCheck.onclick = onBtnCheck

 var btnDelete = document.createElement("button")
 btnDelete.innerText = "❌"
 btnDelete.type="button"
 btnDelete.classList.add("btnDelete")
 btnDelete.onclick = onBtnDelete

 var li = document.createElement("li");
 li.appendChild(document.createTextNode(txtItem.value));
 li.onclick = onListItemClick
 li.appendChild(btnCheck)
 li.appendChild(btnDelete)
 ulItems.appendChild(li);

 txtItem.value = ""
 }
}

In the code above I’ve used two different methods of inserting the text into an element. One by using the innerText property, and one by creating a TextNode and inserting it with the appendChild() method. In the CWD course, Andrei had commented “//Dangerous” next to innerText, but hasn’t discussed it yet. There’s a good discussion here from Marian Čaikovski.

Another thing I’ve got two different versions of in this codebase is adding the event handlers for when things are clicked on. In some places I’ve got the succinct, clear onClick =, in others, addEventListener().

txtItem.addEventListener("keydown", onKeyPress)
btnItem.addEventListener("click", addNewItem)

var links = document.getElementsByTagName('li');
for (var i = 0; i < links.length; i++) {
 var link = links[i];
 link.onclick = onListItemClick;
 console.assert(link.childNodes.length === 3)
 link.childNodes.item(1).onclick = onBtnCheck
 link.childNodes.item(2).onclick = onBtnDelete
}

It sounds like onClick is better supported, but really only a marginal difference. addEventListener can support more than one handler for any particular event, and covers more events.

source for this project, or try it out here. I should also note that since I’m still working on this those might not exactly match the code above.