Forem: Oheneba Poku-Marboah

My First Real Taste of Git Power: Fixing a Bug After an npm Upgrade

Oheneba Poku-Marboah — Sat, 01 Mar 2025 08:22:27 +0000

Story Time: My First Taste of the Real Power of Git

Ok, so I inherited a hot mess of a project—I've written a bit about it in another article. A chaotic work project that had spiraled into a state of 😬😬😬. No version control. A deathmatch of duplicated files named things like old_filename.extension and even a collection of zipped folders that served as backups whenever something got changed.

As I said in the article describing it, the project worked, and that counts for something. Whoever built and maintained it—whether it was one person or multiple—was probably thrown into the deep end and made the best of their situation. I respect that "get-it-done" energy.

Laying the Groundwork

Before I got into the main challenge, I introduced some software best practices:

Version control (finally!)
Reusability (the DRY principle)
Documentation
Removing unused files and dependencies (as much as time allowed)

And then, the thing that brought me to the main point of this article: Updating the npm packages.

The Package Update Saga

This project hadn’t received any TLC (tender loving care) in a while, so almost all the npm packages were outdated. Time to bring them back from the brink.

Just a quick FYI on npm package semantic versioning (SemVer) and what it means:

If a package, let's say nodemon, is listed as follows:

"nodemon": "^3.1.9"

3 → Major version
1 → Minor version
9 → Patch version

So, MAJOR.MINOR.PATCH.

Strategy: Updating in Stages

Since patch upgrades are very unlikely to introduce breaking changes, I started with:

npx npm-check-updates -t patch -u && npm install

Everything worked fine.

Next, I moved to minor updates:

npx npm-check-updates -t minor -u && npm install

Tested it. Everything seemed fine. I committed my changes. Or so I thought...

The Bug Hunt Begins

A few more commits in, and I noticed a logout bug had slipped through my manual tests. It must have been introduced in one of the minor version updates.

Time to go back—commit by commit—until I figured out exactly when it happened.

Step 1: Checking Recent Commits

I ran:

git log -n 8

This showed me the last 8 commits, with their messages and commit hashes:

commit 943e6.......77dd (HEAD -> some-branch-name)
Author: John Doe <john.doe@companymail.com>
Date:   Wed Feb 26 12:02:20 2025 +0200

    update lorem ipsum something something

commit 49fbfa........50f
Author: John Doe <john.doe@companymail.com>
Date:   Tue Feb 25 17:32:33 2025 +0200

    update major version of dotenv and nodemon

commit b144ba8f3........49d00
Author: John Doe <john.doe@companymail.com>
Date:   Tue Feb 25 17:21:00 2025 +0200

    remove unused packages according to depcheck and npm ls

commit 601......09342b4e0
Author: John Doe <john.doe@companymail.com>
Date:   Tue Feb 25 13:23:37 2025 +0200

    update minor versions of npm packages

commit bad04.........1d8
Author: John Doe <john.doe@companymail.com>
Date:   Thu Feb 20 12:08:51 2025 +0200

    update patches

I copied these commit hashes into a text file for easy reference.

Step 2: Finding When the Bug Was Introduced

To go back to a specific commit, I used:

git checkout <commit-hash>

I manually went back one commit at a time until I found exactly when the bug was introduced.

Eventually, I pinpointed the issue—it was introduced in commit 60.....23 (let’s call it the "bug-source commit").

Step 3: Fixing the Bug

I checked out a new branch based on the bug-source commit:

git checkout -b fix/bump-down-package-name 60.....23

I made the fix and committed it. Let’s call this commit 3a (the bug-fix commit).

Now, here's the issue:\
I had gone back in time and fixed a bug, but that fix didn't exist in later commits (3, 2, 1, and 0).

At any given point in the Git history, there was still a version where the bug was present.\
This is the main thing I wanted to highlight in this article:

Step 4: Ensuring the Fix Exists in Future Commits

The answer? Git rebase.

I rebased my fix branch on the bug-source commit:

git rebase 60.....23

Now, my commit history looks like this:

commit 0  (bug-spot commit, where I first noticed the bug)
commit 1  
commit 2  
commit 3  
commit 3a (bug-fix commit)  
commit 4  (bug-source commit, where the bug was introduced)

At this point, the fix existed in the timeline, but I needed to merge it into my working branch (let’s call it wip-branch).

So, I switched back to wip-branch:

git checkout wip-branch

Then, I rebased the fix onto it:

git rebase fix/bump-down-package-name

And voilà! The fix was now applied across all future commits.

Lessons Learned

Always test thoroughly after minor updates.

Minor updates can introduce breaking changes.

Git rebase is a lifesaver.

When you need to go back in history and fix something properly, rebase keeps your commit history clean.

Commit in small, logical chunks.

If I had updated one package at a time, tracking the issue would have been much easier.

Final Thought

As I write this, I realize I probably could have just amended the bug-source commit instead of rebasing, but hey—that’s the power of Git. There’s always more than one way to solve a problem.

There is also something that could have helped locate the bug commit more easily than manually going one-by-one - git bisect. That would have automated the process of finding the commit using a binary search algorithm through the commit history to pinpoint the exact change that introduced the bug. But I only found out about that whilst researching this article.

Icarus and the npm Updates: How Version Control Rescued My npm Upgrade Nightmare

Oheneba Poku-Marboah — Fri, 28 Feb 2025 16:55:20 +0000

Story time. So, I just inherited a chaotic work project that felt completely out of control. I had to take a moment to gather my thoughts before diving in. Time to roll up my sleeves and tackle this mess!

The Starting Mess

I inherited a project that had spiraled into a state of - well it was in some state for sure. No version control. Instead, a graveyard of duplicated files named things like old_filename.extension and even a collection of zipped folders that served as backups whenever something got changed.

To be fair, the project worked, and that counts for something. Whoever built and maintained it—whether it was one person or multiple—was probably thrown into the deep end and made the best of their situation. I respect that "get-it-done" energy.

Step 1: Implementing Version Control

Before touching a single file, I set up version control. If I messed anything up, I needed a way to revert changes easily. My initial commit had over 100 files, many of which were redundant.

Running:

git show --pretty="" --name-status

showed me the list of files in that commit, including all the old_filename.extension artifacts.

To keep track of my thought process and ensure that whoever inherited the project after me had some documentation, I created a decisions.md file. In it, I documented the state of the project when I found it and the cleanup I was able to do within my limited timeframe. My knowledge of Git was definitely stretched during this process, which was a bonus learning opportunity.

I introduced software best practices:

Version control
Reusability (DRY principle)
Documentation
Removing unused files and dependencies (as much as time allowed)

And then, finally, the main point of this article: Updating the npm packages.

Checking Outdated Packages

To check outdated npm packages, I ran:

npx npm-check-updates

which gave me the following output (grouped manually into minor and major versions).

Minor Versions:

package A           ^1.19.0  →  ^1.20.3
package B           ^1.7.4   →  ^1.8.0
package C           ^1.4.5   →  ^1.4.7
package D           ^3.1.6   →  ^3.1.10
package E           ^1.14.0  →  ^1.23.9
package F           ^4.17.1  →  ^4.21.2
package G           ^1.17.1  →  ^1.18.1
package H           ^3.1.0   →  ^3.1.1
package I           ^0.2.0   →  ^0.2.1
package J           ^0.4.1   →  ^0.7.0
package K           ^8.5.1   →  ^8.13.3
package L           ^2.3.3   →  ^2.3.4
package M           ^3.0.2   →  ^3.0.3
package N           ^6.9.0   →  ^6.37.5

Major Versions:

package O           ^0.16.0  →  ^1.0.4
package P           ^10.0.0  →  ^16.4.7
package Q           ^2.2.4   →  ^3.0.7
package R           ^2.0.12  →  ^3.1.9
package S           ^4.5.2   →  ^6.3.0

This project hadn’t taken a shower in a while. Five packages had to jump at least one major version, two had to jump more than one, and one package had to upgrade by six major versions. SIX! Some wars have lasted fewer days than that - I am looking at you, Anglo-Zanzibar War.

Oh, and Bootstrap was in the .gitignore, so even that required a manual backup just in case my update completely wrecked the UI. You know the unthinkable happened, and the roundness of the buttons affected sales

The Update Process

I started naturally with patch updates:

npx npm-check-updates -t patch -u && npm install

Smooth. No issues. Committed the changes.

Then, minor updates:

npx npm-check-updates -t minor -u && npm install

Tested it. Everything was fine. Committed again.

Then came the major versions. At this point, Icarus was soaring with his wax wings. Instead of going one package at a time, I decided to take a shortcut and upgrade everything at once:

npx npm-check-updates -u && npm install

Why not? I had backups. I had version control. This was controlled chaos, right?

IT. DIDN’T. WORK.

Cue the surprised Pikachu meme.

Back to One-by-One

I reverted and took the slow route:

Removed completely unused packages
Updated packages from smallest jump to largest
Tested thoroughly

The biggest offender? dotenv, which had to jump six major versions. Fortunately, it does exactly one thing in most projects, so I updated it with confidence:

npm install dotenv@latest

No issues.

Then came nodemon—another easy one. Also, it updated smoothly.

Now, three remaining major updates, but first—a detour into unused packages.

Tracking Down Unused Packages

To check if a package was actually in use:

npm ls <package-name>

Then, as a second check, I searched the entire codebase in VS Code.

A third approach:

npx depcheck

which gave me something like this:

Unused dependencies:
Package A
Package B
Package C

Missing dependencies:
Package J: ./index.js
Package K: ./index.js

Not 100% reliable—some "unused" packages were actually required. (RIP, pug. Uninstalling it broke everything.)

The Last Two Major Updates

Back to the 2 remaining major versions. Wait, what's that? Oh, it's just the sun being too close again—oooh, my wings are melting.

The app; crashing. Even before I attempted the major version update? Sigh!

Icarus had to deploy the parachute. I had been making commits regularly so that I could always revert. There indeed had been a breaking change when I updated the minor versions because suddenly, I was getting an error when logging out. I had to put on my git detective hat and go snooping for the point in time when it stopped working. My first guess, passport.js, when I arrived in that commit update, turned out to be correct. The bump in passport.js had broken the log-out functionality. So I checked out that commit and switched back to the older version of passport - to be handled later.

For the last time, back to the last 2 major version upgrades. One of them gave me no problems. The last one had some breaking changes, which means I had that and passport.js to take care of before I was done. But they both ended up being fixed within a day.

Wrapping Up

So that was the story of how I had to upgrade some decayed packages in an npm project. What started as a soup of outdated packages, missing version control, and abandoned dependencies ended up cleaner, more maintainable, and fully documented.

Would I do it again? Sigh! I got paid so... just kidding I ended up learning more about git and npm on this project than I ever imagined I would. No kidding - there is a senior dev I look up to who said he had never had to go down some of the git and npm rabbit holes i went down during this project. So would I do it again? Probably. But next time, I might just start with one package at a time instead of playing Icarus.

Lesson learned.

I bet you didn't know this about Javascript Arrays: The Javascript Array Constructor Quirk

Oheneba Poku-Marboah — Tue, 23 Jul 2024 02:46:56 +0000

Storyline

I recently learned about HashMaps and how they are implemented and encountered something fascinating about arrays.
It was an interesting quirk about initialising arrays. So, I shall tell you about it.

What is an Array?

An array is a data structure that allows you to store ordered collections of items of the same or varying types in the same variable. These items it stores can, in turn, be arrays. It is handy because you can iterate through arrays and transform the elements, allowing for a lot of dynamic computation on the elements of the array.

How do you create an array in js?

There are primarily 2 ways of initialising an array in js - Using the array literal and using the array constructor. This article is about something i recently discovered while using the array constructor so lets look at that last.
The array literal is used to initialise arrays in this manner

// Literal notation examples
const arrLit1= [];
const arrLit2= [1,2, 'two', 'joe', true];
const arrLit3= [1, 2, 3, 4, 5, 9];

// new Array constructor examples
const arrCon1= new Array();
const arrCon2= new Array(1,2, 'two', 'joe', true);
const arrCon3= new Array(1, 2, 3, 4, 5, 9);

What you came here for

The above examples are equivalent and get the same results, i.e. arrCon1 is equivalent to arrLit1, and so on.

But take a look at this -

const arrLit4= [5];

const arrCon4= new Array(5);

Do you think they are equivalent? I am sure you guessed since I am asking, they are probably not equivalent and that is right. They are not equivalent - they will not yield the same result. arrLit4 creates an array with one lement, 5, and arrCon4 is an array of size 5 where all the elements are undefined.

Let's break this down further. The Array constructor has an interesting function signature. Depending on what collection of parameters are passed in, it behaves a bit differently. If you pass in a single integer parameter between 0 and 2pow32 - 1 (inclusive), it creates an array of that size. Every element at every index is undefined until you populate it with something else. However, give it more than one integer, a negative integer, a single element of any other type, or multiple elements of any other type (including positive integers), and it will create a new array with those elements that you gave it as a parameter.

Side note: In computer science, the concept of having a function/method, which, when called with specific parameters, behaves in one way but, when given a differing type or number of parameters, behaves differently is called method or function overloading. Side side note: Function overloading in the traditional sense is not possible in JavaScript, but with some trickery, the same result can be achieved. If it walks like a duck, swims like a duck, and quacks like a duck, then ....

What about the examples below? Are they equivalent?

const arrLit5= ['Lorem Ipsum'];

const arrCon5= new Array('Lorem Ipsum');

Yes, they are. Even though the new Array constructor has a single parameter passed in, it is not an integer between 0 and 2pow32 - 1 (inclusive). Thus, both examples create an array with a single string element, 'Lorem Ipsum'.

In Javascript, arrays are dynamic—their sizes can be changed on the fly. This is not the case in all programming languages. For example, in Java or C, when you declare an array, you have to declare a size, and when it reaches max capacity or you need more space, you create a new, bigger array to accommodate your needs.

So, when you initialise an array in JavaScript with the constructor style, you can still add to it even when you reach the limit. It will expand to accommodate the new elements behind the scenes.
Here is an example -

const arrSizeTwo = new Array(2); 
console.log(arrSizeTwo.length); // 2
console.log(arrSizeTwo); // [ <2 empty items> ]
console.log(arrSizeTwo[0]); // undefined - all elements are until changed.

arrSizeTwo[0] = 'Element 1';
arrSizeTwo[1] = 'Element 2';
arrSizeTwo[2] = 'Element 3'; // Adding an element beyond the initial length

console.log(arrSizeTwo.length); // 3
console.log(arrSizeTwo);

On the contrary, here is an example in Java where you have to create a new, larger array if you need more space.


public class Main {
    public static void main(String[] args) {
        int[] arrTwoJava = new int[2]; // Array with length 2

 arrTwoJava[0] = 1;
 arrTwoJava[1] = 2;
        // arrTwoJava[2] = 3; Error Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2

        // Instead, we need to create a new array with a larger size
        int[] arrThreeJava = new int[3];
        System.arraycopy(arrTwoJava, 0, arrThreeJava, 0, arrTwoJava.length);
 arrThreeJava[2] = 3; // Adding the new element

        System.out.println(arrThreeJava.length); // 3
        for (int i : arrThreeJava) {
            System.out.println(i); // 1 2 3
 }
 }

}

Voila. I hope you learned something new: the array constructor quirk in Javascript, function overloading, and dynamic/static array sizing in programming languages.

That will be all for now.
Ciao!

Pass-By-Value or Reference in Javascript: A look into Primitives and Non-Primitives

Oheneba Poku-Marboah — Mon, 06 May 2024 13:17:48 +0000

Spot the difference between these two samples of code and how things change.

// SAMPLE A
let a = 2;
let b = a;

console.log('a->', a, 'b->', b); // a-> 2 b-> 2

b= b*2;
console.log('a->', a, 'b->', b); // a-> 2 b-> 4

and then take a look at this

// SAMPLE B
let a = {name: "Nelson M", age: 65 } ;
let b = a;
console.log('a->', a, 'b->', b);

// it affects the object that both a and b point to. This is because they both reference the same object in memory.
b.name = "Margaret Thatcher";
console.log('a->', a, 'b->', b);

They both end with changing variable b but look closely at how changing variable b affects a in both scenarios.
Do you see how variable a remains the same in Sample A but changes in Sample B even though we are seemingly doing the same thing in both scenarios? What is the reason for this discrepancy?

This is how data manipulation occurs in JavaScript. Changing a primitive and non-primitive data type in JavaScript happens differently.

What are primitives, you ask? According to MDN, "In JavaScript, a primitive (primitive value, primitive data type) is data that is not an object and has no methods or properties. There are seven primitive data types".
The primitive/non-primitive divide is the following in JavaScript

Type	Examples
Primitive	string, number, bigint, boolean, undefined, symbol, null
Non-primitive	Array, Object

When you assign a primitive, it is assigned by value. Non-primitives are passed by reference when being assigned. By the way, "reference value" is the correct term, but you will often hear just reference, and I will use those two interchangeably. Passed by reference value means that the thing you want to assign has a memory address, and the variable points to that memory address. So, that means that if you have multiple variables pointing to the same memory location and you make a modification, it changes for all those variables that are "referring" to it - pun not intended. That is akin to having a shared collaborative Google doc - if I make a change, you see the change and vice versa. The doc I work on does not have a life of its own, independent from yours, unless you decide to copy/duplicate it. Copying or duplicating the Google doc into its own independent entity is what happens when you pass by value.

Let's revisit the examples we've discussed to reinforce our understanding of variable manipulation in JavaScript.

// SAMPLE A
let a = 2;
let b = a;

console.log('a->', a, 'b->', b); // a-> 2 b-> 2

b= b*2;
console.log('a->', a, 'b->', b); // a-> 2 b-> 4

Sample A
The value 2 is assigned to the variable a. The same value that went to a is assigned to b, but it has its own memory address and is entirely independent from that of a.

// SAMPLE B
let a = {name: "Nelson M", age: 65 } ;
let b = a;
console.log('a->', a, 'b->', b);

// it affects the object that both a and b point to. This is because they both reference the same object in memory.
b.name = "Margaret Thatcher";
console.log('a->', a, 'b->', b);

Sample B
In non-primitives, a and b both point to the same thing. So when you change a property of b, it just changes the property of whatever in memory that b is pointing at. This happens to be the same thing that a is pointing at. Therefore, when you peek inside a, it will be identical to b because they really are the same thing.

So now let's make a little prediction -
So far, we know up to the part I wrote above. Let's see if we know enough to make a prediction based on what we have read. When you modify a primitive, e.g. number 2, it automatically is a reassignment to another thing. Because you are saying that the entirety of this 2 should change, unlike in the case of {name: "Nelson Mandela", age: 65 }, which has parts/properties that you can change. The 2 is the one and only value in and of itself, while the non-primitive value has changeable parts. So, in essence, when you do b = 3, it is a reassignment of b to a whole new thing.

So, this then begs the question of how it works when I want to reassign non-primitive b to a whole new thing. The prediction is that the non-primitive would behave similarly to a primitive reassignment if you were to change the full value. As in, if you were to do b = {name: "Margaret Thatcher", age: 55 }, the a would remain the original and b would have its own new value.

Let's put that to the test

// non-primitive
let a = {name: "Nelson M", age: 65 } ;
let b = a;
console.log('a->', a, 'b->', b); 
// a-> { name: 'Nelson M', age: 65 } b-> { name: 'Nelson M', age: 65 }


// it affects the object that both a and b point to. This is because they both reference the same object in memory.
b.name = "Margaret Thatcher";
console.log('a->', a, 'b->', b); 
// a-> { name: 'Margaret Thatcher', age: 65 } b-> { name: 'Margaret Thatcher', age: 65 }


// you are reassigning b to a completely new object. Doesn't affect a because a is still pointing to the first object
b= {name: "Margaret T", age: 55 };
console.log('a->', a, 'b->', b); 
// a-> { name: 'Margaret Thatcher', age: 65 } b-> { name: 'Margaret T', age: 55 }

The prediction checks out. So, in the case of reassignment, things work the same for both primitives and non-primitives; a new value is given. The variable is assigned a new value - unless you are assigning another variable e.g. c to b, in which case the same passing by reference value principle as mentioned above applies.

Let's go one step further. What happens when b = a but then later, b = c? Does changing c or b in this case affect a?

// non-primitive
let a = {name: "Nelson M", age: 65 } ;
let b = a;
console.log('a->', a, 'b->', b);
// a-> { name: 'Nelson M', age: 65 } b-> { name: 'Nelson M', age: 65 }

// it affects the object that both a and b point to. This is because they both reference the same object in memory.
b.name = "Margaret Thatcher";
console.log('a->', a, 'b->', b);
// a-> { name: 'Margaret Thatcher', age: 65 } b-> { name: 'Margaret Thatcher', age: 65 }

let c = {name: "Donald Duck", age: 31 };

b=c;

// c is passed by reference value to become what b is pointing to. a remains intact
console.log('a->', a, 'b->', b,'c->', c); 
// a-> { name: 'Margaret Thatcher', age: 65 } b-> { name: 'Donald Duck', age: 31 } c-> { name: 'Donald Duck', age: 31 }


//modify both b and c which should both be the same thing and thus should contain both changes
b.name= b.name+'1'
c.name= c.name+'1'
console.log('a->', a, 'b->', b,'c->', c);
// a-> { name: 'Margaret Thatcher', age: 65 } b-> { name: 'Donald Duck11', age: 31 } c-> { name: 'Donald Duck11', age: 31 }

As you can observe in the code snippet above, the answer is no. This is because the memory address that b is pointing to has been updated to be the address of what c is pointing to. This means that when b or c are modified, it modifies the same thing but a remains intact. Understanding this behaviour is crucial in JavaScript programming as it directly affects how your code operates.

We have examined how variable assignment is not uniform for all data types in JavaScript. We have also introduced the concepts of primitive and non-primitive data types and passing by reference or by value.

Check out this code snippet below and try to figure out what happens to the variables. Before reading the answer and explanation, think about it and take a guess. In the comments, let me know what you think would happen to a, b and c outside the function. Here is the Stack Overflow link where you can find out more.

function changeStuff(a, b, c)
{
  a = a * 10;
  b.item = "changed";
  c = {item: "changed"};
}

var num = 10;
var obj1 = {item: "unchanged"};
var obj2 = {item: "unchanged"};

changeStuff(num, obj1, obj2);

console.log(num);
console.log(obj1.item);
console.log(obj2.item);

Feel free to reach out and talk moreLinkedIn Github

PS: Always show up to your flight's gate at least 40 minutes before the departure time. I just missed one. I am writing this with a lighter wallet while stranded in the airport for 24 hours waiting for the next available flight.

javascript

programming

coding

datastructures

How to Add Base Maps to QGIS

Oheneba Poku-Marboah — Mon, 11 Mar 2024 21:39:36 +0000

How to Add Base Maps to QGIS

The why
Connect a base map source to QGIS
Add a base map layer
Some possible base map data sources
Summary
Some Map Layer Previews

Why

When you use QGIS, you may want a base map - i.e., a map of the world as a "background" to whatever spatial data you want to visualise in QGIS.

A base map can be handy for many reasons.

If the geometry against the backdrop of the base map seems suspect, it can easily show whether your geometries are in the wrong projection.
If you want to draw (digitise) a geometry at a specific location, it is several magnitudes easier to do so over a base map since you know exactly where you are drawing.
You see the location of other elements, which gives better spatial awareness.

Connect a base map source to QGIS

There are many ways to add layers to QGIS. In the QGIS desktop application, there is a section named browser, which is by default located on the left and in the top half of the area next to the map. There, you can see several different functions. Some of this functionality refers to ways of adding a map layer to QGIS, layers of types/sources such as Geopackage, Spatialite, PostgreSQL, and XYZ tiles, among others. For our purpose, we are going to use the XYZ tiles.

XYZ Tiles have a few other names - tiled web map, slippy map or tile map. It is a map displayed in a browser by stitching individually requested image or vector data files together to form singular totality. The X and Y refer to the coordinate system we are used to, i.e. up-down/left-right, and the Z is the 3rd dimension, i.e. depth/zoom.

To add a base map, you need to connect the source of the data to QGIS. Then, when that is done, you can add the base map as a layer to your QGIS project.
As shown in the image below - You add the source URL and then give it a name. We will use Open Street Map (https://tile.openstreetmap.org/{z}/{x}/{y}.png)

Add a base map layer

Adding a map layer from the data source you just configured couldn't be easier. Click on "XYZ tiles" in the browser section of QGIS. It will display a list of all XYZ tile data sources you have configured. Click on the one you want, drag it into the map view area, and Voila.
Alternatively, drag and drop the layer into the Layers section, and it will become part of the project. A third way of achieving the same goal is to right-click the XYZ Tile source you want to use - > click "Add to project".
Now the map is available as part of your project, and you can start zooming and plotting on it.

In the GIS Stack Exchange thread that ended up helping me, there are other ways of adding base maps to your QGIS that are not described here.

Through the use of a plugin
Through the Python console

Check them out here- Adding base maps in QGIS - Geographic Information Systems Stack Exchange

Some possible base map data sources

A bunch of the data sources can be found in this stack overflow answer.

Some example URLs

Name	Source
OpenTopoMap	https://tile.opentopomap.org/{z}/{x}/{y}.png
Bing Aerial	http://ecn.t3.tiles.virtualearth.net/tiles/a{q}.jpeg?g=1
OpenStreetMap	http://tile.openstreetmap.org/{z}/{x}/{y}.png
Google Hybrid	https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0xrm8ri1f1woxmq8cato.png
Google Road	https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pzo5rbtg4of4klkyih56.png
Google Satellite	https://mt1.google.com/vt/lyrs=s&x={x}&y={y}&z={z}

You can find previews of these at the end of the article

This comment is from this stack overflow thread and points to the change in URL for different map types from google.

For anyone who wants to save some time while looking for specific tile types:

Layer	Tile type (Google)
h	roads only
m	standard roadmap
p	terrain
r	somehow altered roadmap
s	satellite only
t	terrain only
y	hybrid

This list is in reference to the Google data sources.

So, e.g. for Google Satellite, you would use "lyrs=s", as shown here.
https://mt1.google.com/vt/lyrs=s&x={x}&y={y}&z={z}

Lastly, a neat little trick. At the bottom of QGIS is the coordinate input box. If you type in "world", a world map layer will be added to the current open QGIS project. It is not particularly useful at this juncture of my QGIS usage because it has zero details other than a plain visualisation of country borders.

Summary

I demonstrated how to add a map data source to QGIS
How to add that data to the QGIS project or, in essence, display it.
We got a brief introduction on what XYZ Tiles are.
We saw some visual examples of map data that can be used in QGIS.
Lastly, you can use the links to some of the data sources and instructions on how to get even more of the different types of Google map data sources.

Some Map Layer Previews


OpenTopoMap


Bing Aerial


OpenStreetMap


Google Hybrid


Google Road


Google Satellite

Yup.js validation in React without a third library

Oheneba Poku-Marboah — Wed, 07 Feb 2024 18:34:30 +0000

This article outlines how to do input field validation in a React application using Yup.js but without employing any third library to glue them together. Commonly, the Formik library is used to connect the Yup.js to React, but I wanted to do without that. I spent some hours trying to figure that out, and voila! This article shows how I went about achieving this.

According to the official Yup.js docs,

"Yup is a schema builder for runtime value parsing and validation. Define a schema, transform a value to match, assert the shape of an existing value, or both. Yup, schemas are extremely expressive and allow modelling complex, interdependent validations, or value transformation."

Yup.js is capable of a lot more than what I will show. My specific goal was to figure out how to do what is discussed in this article, so I only focused on that narrow part of Yup.js.
What is a schema (SKEE-mah)? I can imagine this is one of those English words messing with non-native speakers and probably native speakers too - btw it also has a weird plural form - schemas or schemata. According to the Cambridge Dictionary, a schema is a drawing that represents an idea or theory and makes it easier to understand. In computer science (CS), schema means a number of things, but the most common usage is in the realm of databases, where the schema is the blueprint of how the data in the database is structured.
In the case of Yup.js, schema simply means the predefined model (shape, restrictions) of what we want some information to look like. We want to register a kid for daycare, so we need their name and age. The name has to be longer than three characters, and the kid needs to be over one but at most five years old.

For my purposes, Yup.js is a validation library - I use it to assert that the values that are received conform to the shape and rules of a predefined ruleset. I display an error message under the form's input when the values are invalid. Then, I also make the borders of the input red, signifying the error state, based on a boolean that is set to false when the value is not valid. The state object kidErrors has both the boolean and the error message. FYI, this is a Next.js js project that uses material UI, TailwindCSS and Yup.js, so install the necessary packages. Alternatively, it can be done on any react project. You do not need the MaterialUI or the TailwindCSS, but you need a react app and Yup.js installed to try this out hands-on.

When I looked up examples of validating React inputs with Yup.js, most used third-party libraries, such as Formik, to connect the React inputs and Yup.js. However, I wanted to do this without the third-party connector library, so this is how I did it.

`Sections\KidSection.tsx`

import CustomTextField from '@/components/CustomTextField';
import React, { useState } from 'react';
export type Kid = { age?: number, name: string }
export type KidErrors = {
  age: boolean;
  ageErrMsg: string;
  name: boolean;
  nameErrMsg: string; 
}

interface KidSectionProps {
  kidValues: Kid
  kidErrors: KidErrors
  onChangeKidValues: (fieldName: string, value: any) => void
 }

export default function KidSection(props: KidSectionProps) {
  const { kidValues, onChangeKidValues, kidErrors } = props;

  return (
    <div>
      <h2>Tell us about your kid?</h2>
      <p> How old are they and what is their name</p>

      <div>

        <div className="sm:w-full md:w-1/4">
          <CustomTextField 
            autoFocus
            margin="dense"
            id="name"
            name='name'
            label="Name"
            type="text"
            required
            fullWidth
            isValid={kidErrors.name}
            errorMessage={kidErrors.nameErrMsg}
            value={kidValues.name}
            customOnChange={onChangeKidValues}  
          />
        </div>
        <div className="sm:w-full md:w-1/4" >
          <CustomTextField
            autoFocus
            margin="dense"
            id="age"
            name='age'
            label="Age"
            type="number"
            required
            fullWidth
            isValid={kidErrors.age}
            errorMessage={kidErrors.ageErrMsg}
            value={kidValues.age}
            customOnChange={onChangeKidValues}          
          />
        </div>

      </div>
    </div>

  );
}

`components\CustomTextField.tsx`


import { StandardTextFieldProps, TextField } from '@mui/material';
import React, { ChangeEvent, FocusEvent } from 'react';

interface CustomTextFieldProps extends StandardTextFieldProps {
  isValid: boolean;
  errorMessage: string;
  customOnChange:  (fieldName: string, value: any) => void
}

export default function CustomTextField(props: CustomTextFieldProps) {
  const { name, onChange, errorMessage, isValid, customOnChange, ...rest } = props;

  const [value, setValue] = React.useState('');

  const handleOnChange = (event: ChangeEvent<HTMLInputElement | HTMLTextAreaElement>) => {
    setValue(event.target.value);

    if (customOnChange) customOnChange(name || '', event.target.value);
  };

  return (
    <TextField 
      name={name}
      value= {value}
      onChange={handleOnChange}
      helperText= {errorMessage}
      error={!isValid}
      {...rest}

    />
  );
}

`index.tsx`

import KidSection, { Kid } from '@/Sections/KidSection';
import { generateKidSchema } from '@/utils/schemas';
import { useState } from 'react';
import { ValidationError } from 'yup';

const defaultKidErrors = { age: true, ageErrMsg: ' ', name: true, nameErrMsg: ' ' };


export default function Home() {
  const [kidValues, setKidValues] = useState<Kid>({ name: '', age: 3 });
  const [kidErrors, setKidErrors] = useState<typeof defaultKidErrors>(defaultKidErrors);


  const handleKidValueChange= async (fieldName: string, value: number | string ) => {

    const kidSchema = generateKidSchema();
    const newKidValues= { ...kidValues, [fieldName]: value };
    setKidValues(newKidValues);

      const handleKidValueChange= async (fieldName: string, value: number | string ) => {
        const kidSchema = generateKidSchema();
        const newKidValues= { ...kidValues, [fieldName]: value };
        setKidValues(newKidValues);    

        kidSchema.validate(newKidValues, { abortEarly: false }).catch((err: ValidationError) => {
          const errorMessages = err.inner.reduce((acc, curVal) => {
            const tempErrMsg = { [`${curVal.path}`]: false, [`${curVal.path}ErrMsg`]: curVal.message };

            return { ...acc, ...tempErrMsg  };
          }, {});
            // resets all values to as if the validation passed and then adds the current errors
          setKidErrors({ ...defaultKidErrors, ...errorMessages });
        });
      };
  };

  return (
    <div className='p-5'>
      <KidSection
        kidValues={kidValues}
        onChangeKidValues={handleKidValueChange}
        kidErrors={kidErrors}/>

    </div>
  );
};

When a value changes, we update it in the handleKidValueChange function. We update the Kid value in the state, then pass the updated kid object to the validator to test whether it conforms to our schema expectations. If it doesn't conform to what is described in the schema, we want to update the error message to match the error being produced. If there were a submit button, the logic for enabling and disabling it would fit here.

`utils\schemas.ts`

import { ObjectSchema, number, object, string } from 'yup';

export const generateKidSchema = (maxAge: number= 5): ObjectSchema<Kid> => {
  return object({
    name: string().required().min(3, 'must be at least 3 characters long'),
    age: number().required().positive().integer().min(1).max(maxAge),
  });
};

The yup schema I used is like this. I put it in a function because I may want to be able to change the maximum age on the fly if I need to. The restrictions we have set on the string and number are pretty basic, but Yup is capable of much more robust validation. It can be used to ensure that URLs, emails, and UUIDs are correct, ensure that string values don't include unnecessary whitespace (trim), validate the case of a string(upper/lower), validate one input based on the value of another input, among other more demanding things.

Sounds like it should make sense, right? WRONG! Something seems off. Things don't quite work the way we want it to work. The input field still has the error message even after I have typed in acceptable input. For example, if I start typing my name, "Oheneba", after I get to the third character, O-h-e, which is the minimum acceptable character amount, I still have an error message in the UI. Presently, it gives the impression that the validation doesn't work at all because it shows an error when the values are invalid, but when they are of the correct type, the UI errors don't change to a zero error state. So what could be wrong? What is supposed to happen when the data the user inputs is correct? We are supposed to not get an error at that point, right? If so, we are currently not updating the kidErrors to reflect a state of being valid when the input is indeed valid. In fact, we are missing the .then() method of the promise, so all we can do is check if our input value is correct or perform an action if it is wrong - no room has been left for an action to occur when the value is correct. Let's fix that.

### Corrected handleKidValueChange index.tsx

  const handleKidValueChange= async (fieldName: string, value: number | string ) => {
    const kidSchema = generateKidSchema();
    const newKidValues= { ...kidValues, [fieldName]: value };
    setKidValues(newKidValues);    

    kidSchema.validate(newKidValues, { abortEarly: false }).then((res) => {
      // No validation errors, clear the errors and set isValid to true
      console.log('res of validate then', res);
      setKidErrors({ ...defaultKidErrors });
    }).catch((err: ValidationError) => {
      // https://github.com/jquense/yup?tab=readme-ov-file#validationerrorerrors-string--arraystring-value-any-path-string
      const errorMessages = err.inner.reduce((acc, curVal) => {
        const tempErrMsg = { [`${curVal.path}`]: false, [`${curVal.path}ErrMsg`]: curVal.message };

        return { ...acc, ...tempErrMsg  };
      }, {});
        // resets all values to as if the validation passed and then adds the current errors
      setKidErrors({ ...defaultKidErrors, ...errorMessages });
    });

We add the then() method of the returned promise to deal with that case. In that scenario, we clear the kidErrors message and set the error boolean state so the input field doesn't have a red outline. In the then() method of the promise, the correct full value is returned, but we don't need that value, so we can omit the parameter from our then() method's callback without any parameter. It should be working correctly now.

We have now understood that the Validate() function returns a promise containing the value when all is ok and throws a validation error when things are not ok; we could do our handleKidValueChange in another way. The try-catch is another way of doing the validation instead of using the .then().catch(). When the validated value is not up to standard, it throws an error, which can be handled in the catch() branch. You can immediately handle the case in the try branch if it is valid. Let's give that a shot - it will reinforce our understanding of how this part of Yup.js works.

handleKidValueChange using a try-catch and async-await


  const handleKidValueChange= async (fieldName: string, value: number | string ) => {
    const kidSchema = generateKidSchema();
    const newKidValues= { ...kidValues, [fieldName]: value };
    setKidValues(newKidValues);


  try {
        const validationResult = await kidSchema.validate(newKidValues, { abortEarly: false });
        console.log('validationResult in try catch ',validationResult);
        // No validation errors, clear the errors and set isValid to true
        setKidErrors({ ...defaultKidErrors });

      } catch (err: any) {
        // https://github.com/jquense/yup?tab=readme-ov-file#validationerrorerrors-string--arraystring-value-any-path-string
        const errorMessages = err.inner.reduce((acc: any, curVal: { path: any; message: any; }) => {
          const tempErrMsg = { [`${curVal.path}`]: false, [`${curVal.path}ErrMsg`]: curVal.message };

          return { ...acc, ...tempErrMsg  };
        }, {});
          // resets all values to as if the validation passed and then adds the current errors
        setKidErrors({ ...defaultKidErrors, ...errorMessages });
      }
    };

I set out to illustrate that it is possible to validate input in React without using a third library to glue together Yup.js and the rendered React. In this article, I have demonstrated how to do some on-the-fly validation of inputs using Yup.js. I explained that it is a promise which returns the correct value when all is well but throws an error when the value passed does not match the schema's requirements. I also explained the branches in the code where the error logic can be handled and where you can wipe all error messages if the inputs are valid.

Forem: Oheneba Poku-Marboah

My First Real Taste of Git Power: Fixing a Bug After an npm Upgrade

Story Time: My First Taste of the Real Power of Git

Laying the Groundwork

The Package Update Saga

Strategy: Updating in Stages

The Bug Hunt Begins

Step 1: Checking Recent Commits

Step 2: Finding When the Bug Was Introduced

Step 3: Fixing the Bug

Step 4: Ensuring the Fix Exists in Future Commits

Lessons Learned

Final Thought

Icarus and the npm Updates: How Version Control Rescued My npm Upgrade Nightmare

The Starting Mess

Step 1: Implementing Version Control

Checking Outdated Packages

Minor Versions:

Major Versions:

The Update Process

Back to One-by-One

Tracking Down Unused Packages

The Last Two Major Updates

Wrapping Up

I bet you didn't know this about Javascript Arrays: The Javascript Array Constructor Quirk

Storyline

What is an Array?

How do you create an array in js?

What you came here for

Pass-By-Value or Reference in Javascript: A look into Primitives and Non-Primitives

javascript

programming

coding

datastructures

How to Add Base Maps to QGIS

How to Add Base Maps to QGIS

Table of Contents

Why

Connect a base map source to QGIS

Add a base map layer

Some possible base map data sources

Summary

Some Map Layer Previews

Yup.js validation in React without a third library

Sections\KidSection.tsx

components\CustomTextField.tsx

index.tsx

utils\schemas.ts

`Sections\KidSection.tsx`

`components\CustomTextField.tsx`

`index.tsx`

`utils\schemas.ts`