Forem: V

Git Better with Commitlint and Conventional Commits

Fri, 26 May 2023 03:22:44 +0000

Writing good commit messages for projects can be challenging. When a project scales and involves many developers, inconsistencies in format and writing style can arise. We can solve this by using the Conventional Commits specification and configuring our project with commitlint to enforce this standard.

Initialize a Project with Git

If you have a project set up in git already that you want to add this feature to, skip ahead to the section Configuring commitlint. Otherwise, follow the below steps to test this feature in a new project.

Create a new empty directory on your computer named git_better_demo
Navigate to the git_better_demo directory in your terminal
Run the command git init to initialize this directory with Git. This will create a hidden directory named .git/
Run the command npm init to initialize this directory with npm. You will be prompted for details about your repository. The details you provide will be added to your package.json and can be modified later as needed. To accept all default values, press Enter through full prompt.
Open in your preferred IDE.

Configuring commitlint

NOTE FOR WINDOWS USERS:

Make sure you are in Windows PowerShell rather than Command Prompt. The following commands will not work properly when using Command Prompt. Also make sure after running the command in step 2 to create the commitlint.config.js, the file must be UTF-8 in order to work (if in VSCode, check the bottom right corner. It may say UTF-16. This can be manually adjusted).

Installing @commitlint/cli and @commitlint/config-conventional

Run the command npm install --save-dev @commitlint/config-conventional @commitlint/cli in your terminal . This will install the commitlint command line tools and a commitlint configuration that enforces the Conventional Commits specification into your project.
Run the command echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js in the terminal. This will create the file commitlint.config.js and sets commitlint to use the pre-configured rules from the config-conventional package

Configuring Husky

We will use a tool called Husky to run commitlint checks any time we use git commit

Initialize Husky in the project by running npx husky-init. This will prompt you to install husky-init. Press enter to proceed. A hidden directory will be created in your project named .husky.
Delete the pre-commit file under the .husky directory. This will not be needed and can be added again in the future.
Add the commit-msg hook to enforce commitlint rules when using git commit by running npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"' . This will prompt you to install husky. Press Enter to proceed. You should see a commit-msg file appear under the .husky directory.
Test that the commit-msg hook is active by running git commit -m "fail: this is a failing commit message". Since fail is an invalid type based on Conventional Commits, the commitlint will prevent you from committing with this message.

This is great place to start in writing better commit messages, but this can be made even better with an interactive experience using commitizen and cz-commitlint.

Configuring commitizen with cz-commitlint

Run the command npm install --save-dev @commitlint/cz-commitlint commitizen inquirer@8
In the package.json, add "commit": "git-cz" under scripts.
```
"scripts": {
    "commit": "git-cz"
}
```
In the package.json, set up commitizen to use the @commitlint/cz-commitlint package by adding the below settings.
```
"config": {
    "commitizen": {
        "path": "@commitlint/cz-commitlint"
    }
}
```
In the terminal while still inside the project directory, run the command npm run commit. You should now have an interactive experience to create a commit message following the Conventional Commits specification!

Modifying Settings

All of these settings can be modified by following the guides provided with commitlint. For example, if we decide we want to change the character limit of the scope to 50, open the commitlint.config.js file and add "scope-max-length": [2, "always", 50] under rules.

module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "scope-max-length": [2, "always", 50],
  },
};

This is just a small example of how to change a rule, but commitlint allows flexibility to change these settings to fit your needs.

Summary

Commit messages play an essential role in the development process. Following a format such as Conventional Commits can help both you and your team to work in an organized manner and guide you to be more intentional with your commit messages. There are also various other benefits in using Conventional Commits.

Happy Committing!

Additional Links

Commitlint Local Setup Documentation
Commitlint Rules Documentation
Conventional Commits
Commitizen Repositories
Commitlint Respositories

Error handling in the JavaScript Fetch API

Mon, 08 May 2023 15:10:13 +0000

What's up with fetch?

When working with fetch in JavaScript, something that is often overlooked is proper error handling from a response. That catch block may not be doing what you think it is doing!

In the following code snippets, we will be covering an example from a React application of fetching a list of vendor names using the GET method, then setting them in state. The error handling applies to all scenarios using fetch in JavaScript, not just in React.

Let's start with the example below.

/* Initializing vendors to an empty array */
const [vendors, setVendors] = React.useState([]);

/* useEffect runs on mount to fetch data */
React.useEffect(() => {
    /* Setting up the fetch call */
    const fetchVendors = async () => {
        const response = await fetch('http://localhost:9000/vendors');
        const responseJSON = await response.json();

        return responseJSON;
    };

    /**
     * Calling fetchVendors. The intent is to set the response (vendor names)
     * in React state using setVendors if the fetch is successful. If an error
     * occurs, we do not want to set the state and instead want to log the error. 
     **/
    fetchVendors()
      .then((response) => setVendors(response))
      .catch((error) => console.error('Logging Error', error));
  }, []);

At first glance, it may appear that if the response received from the fetch call does not give a 200 as the status code, it will fall into the catch block and log the error. That is incorrect though and not how fetch works.

The fetch API returns a promise which either resolves or rejects. If it resolves, it will go into "then", and if it rejects, it will go into "catch". When a status code other than 200 is received, that does not mean that fetch had a bad response. An example of this could be if the database failed to connect. The backend could be configured to send a 500 status code with an error name and error message. Without additional configuration on our frontend, it doesn't know that this should go into the catch block. It simply assumes that we successfully receieved a response from the backend and resolves the promise. The MDN Web Docs also state that the fetch API will only reject when a network error occurs, rather than HTTP errors. That means that the user of fetch is responsible for setting up proper error handling. So how do we do that?

Checking the ok boolean of the response

If we log the following response from the initial example:

 const response = await fetch('http://localhost:9000/vendors');

This is what the resolved response may look like. This would differ based on several factors, such as status code, local testing, etc.

{
    body: ReadableStream,
    bodyUsed: true,
    headers: Headers {},
    ok: true,
    redirected: false,
    status: 200,
    statusText: "OK",
    type: "cors",
    url: "http://localhost:9000/vendors"
}

When making the fetch call, the response received will contain a key named ok. This will be a boolean value. Anything other than a 200 status will set the value of ok to false. Knowing that, we can now add a check to the fetch call.

React.useEffect(() => {
    const fetchVendors = async () => {
        const response = await fetch('http://localhost:9000/vendors');
        const responseJSON = await response.json();

        /** This will throw an error if the response status is anything other than 200 */
        if (!response.ok) {
            throw new Error('Something is broken!');
        }
        return responseJSON;
    };

    fetchVendors()
      .then((response) => setVendors(response))
      .catch((error) => console.error('Logging Error', error));
  }, []);

The above example would now go into the catch block if we received anything other than a 200 response and it logs the error of "Something is broken!".

Checking the content-type of the response

What if the response we receive back is not of JSON type? It's possible that we receive an error prior to checking ok of the response when running the following line of code.

const responseJSON = await response.json();

The response also contains Headers. Through the Headers, the content type received can be validated before processing it in any specific way.

React.useEffect(() => {
    const fetchVendors = async () => {
        let error;
        const response = await fetch('http://localhost:9000/vendors');

        /** Checking the response headers for the content type */
        const isContentTypeJson = response.headers.get('content-type')?.includes('application/json');

        /** If content is not JSON, will not be processed as a JSON and sets the error variable */
        const responseData = isContentTypeJson
            ? await response.json()
            : error = 'Not a JSON!';

        if (!response.ok) {
            throw new Error('Something is broken!');
        }

        // throw an error if error variable contains a value
        if (error) {
            throw new Error(error);
        }

        return responseData;
    };

    fetchVendors()
        .then((response) => setVendors(response))
        .catch((error) => console.error('Logging Error', error));
}, []);

Promise.resolve() and Promise.reject()

We can also use Promise.resolve() and Promise.reject() to control the flow of the fetch rather than throwing errors directly. Pretend we have our frontend connected to a backend and the backend is sending JSON objects with a status code, error name and error message. Assuming we want to keep that data to log on our frontend, we could use Promise.reject() to send this data as the error data of our catch block.

Example response JSON received from backend. This would be the response after response.json() resolves and is assuming our backend sends 500 as the status code:

    {
        name: 'Database',
        message: 'Failed to connect to database',
        status: 500,
    }

The example below allows for more robust error handling and logging if the response from the backend will be following a consistent format.

React.useEffect(() => {
    const fetchVendors = async () => {
        const response = await fetch('http://localhost:9000/vendors');
        const isContentTypeJson = response.headers.get('content-type')?.includes('application/json');

        /** Handle error object from backend */
        const responseData = isContentTypeJson
            ? await response.json()
            : { status: response.status, statusText: response.statusText };

        if (!response.ok) {
            /** since a 500 was received from backend, the flow would enter here and we can manually reject the Promise. This will move into the "catch" */
            return Promise.reject(responseData);
        }

        /** If a 200 was received, the promise would resolve and flow moves to "then" */
        return Promise.resolve(responseData);
    };

    fetchVendors()
      .then((response) => setVendors(response))
      /** error in the below case would contain { name: 'Database', message: 'Failed to connect to database', status: 500 } */
      .catch((error) => console.error('Logging Error', error));
}, []);

Wrap Up

There are a variety of ways that error handling with the fetch API can be handled. The examples given in this post are just a few and will change based on the needs in your application. The important piece to remember here is that it's not safe to assume that fetch will go into the catch block based on the HTTP status code! MDN Web Docs state that this will only happen with a network error, such as an invalid URL.

Happy error catching!

Immediately Invoked Function Expressions (IIFE) in JavaScript

Sun, 31 Jan 2021 07:48:21 +0000

Immediately Invoked Function Expression...sounds like a pretty intense term! Let's take a second to break it down.

Function Expression: a function that is stored in a variable
Invoked: the function has been executed

This is how we typically see a function expression set up in JavaScript:

  const eatFruit = function(){
    console.log('I took a bite of the apple');
  }

  eatFruit();  // I took a bite of the apple

If we want to invoke that function, we call eatFruit(). The parenthesis at the end of the function name is what is invoking it, which in this case would log "I took a bite of the apple."

Now we will look at an Immediately Invoked Function Expression (IIFE, which is pronounced "iffy"):

(function () {
    console.log('I happen immediately!') // I happen immediately!
})();

To invoke an IIFE, all we need to do is place the parenthesis at the end of the expression. There is no need to make a separate call to this function.

What is the tie between a function expression and an IIFE?

Function expressions give us the ability to store a function in a variable, while a function declaration does not. A function declaration expects different syntax.
The parenthesis that wrap the function allow JavaScript to treat this syntax as a function expression vs a function declaration. If the parenthesis are not present, JavaScript will throw an error because it will try to interpret it as a function declaration.

The below example does not work and will throw an error. Notice that the parenthesis that wrap an IIFE are not present.

function () {
    console.log('I happen immediately!')
}();
// "SyntaxError: Function statements require a function name."

Why use an IIFE?

I know at this point you're probably wondering why you would ever use this. Can't we also achieve the same results by creating either a function declaration or function expression and invoking it immediately after its creation? Well, kind of. There are a few areas that differ between a typical function declaration or expression vs an IIFE.

Many of the problems that IIFEs solve have been eliminated due to ES6 and the recent updates to the language, but I do think it's still important to point out some of its capabilities and to recognize them.

Private Data

IIFEs allow for private variables. This isn't so much of an issue now because with ES6 and the latest JavaScript updates, we are able to use const and let for block scoping. When var was the only option, we could have naming collisions with the global scope. Let's look at an example.

{
  var favoriteFood = 'French Fries';
}
console.log(favoriteFood) // French Fries

Wrapping a variable in curly brackets creates a block, but var does not allow block scoping. If you try the example above, you will see that the variable can still be accessed outside of the block and will log "French Fries".

Next try this with let or const.

{
  const favoriteFood = 'French Fries';
}
console.log(favoriteFood) 
// ReferenceError: favoriteFood is not defined

Here we will get a reference error since both let and const can be block scoped. This helps us make variables private and prevents naming collisions in the global scope. Before let and const were created, this scoping issue could be solved by using IIFEs since var can be function scoped.

Below you can see that the variable favoriteFood is no longer accessible to the global scope.

(function(){
    var favoriteFood = 'French Fries'
})();
console.log(favoriteFood)
// ReferenceError: favoriteFood is not defined

Another example of keeping variables private can be demonstrated with functions inside of an IIFE.

(function counter() {
    var count = 0;

    function increment() {
      count++;
    }

    increment();
    console.log(count) // 1
}());

We now have created a private function which can modify our private variables. We are able to access count inside of the function within the IIFE!

Closures

The last example I will provide is a little bit more of an advanced concept and involves the topic of closures. I'm not going to go into detail on closures in this post, but here is an example to demonstrate how IIFEs and closures work together.

const counter = (function add() {
    let count = 0;

    return function() {
      count++;
      return count;
    }
}());

console.log(counter()) // 1
console.log(counter()) // 2
console.log(counter()) // 3

Here's what is happening:

The IIFE "add" initializes the variable "count" at 0
It then returns a function that adds 1 to the "count" variable.
That function also returns "count".
Since "add" is an IIFE, it is immediately invoked and the result is stored in the variable "counter"
When we log the value of counter multiple times, you can see that the value continues to increment each time. This shows an example of a closure.

This is not possible with a "typical" function expression! The following examples demonstrate this:

Below when we log the result of the counter function, the internal function is logged.

const counter = function add() {
    let count = 0;

    return function() {
      count++;
      return count;
    }
};

console.log(counter()); // function() { count++; return count; }

If we want to run the internal function, we can invoke our function again! But even with this, we still do not get the results we get when using an IIFE.

const counter = function add() {
    let count = 0;

    return function() {
      count++;
      return count;
    }
};
// Notice below the extra set of parenthesis, which invokes the internal function!
console.log(counter()()); // 1
console.log(counter()()); // 1
console.log(counter()()); // 1

Quick Recap

There are many more examples that exist for the use of IIFEs and the conversation could go on forever! Some developers say they no longer have as much of a purpose, others say there are still benefits to using them. I wanted to write this post to introduce others to the syntax of IIFEs and some of the capabilities associated with them.

Here is our recap on IIFEs:

Interpreted as function expressions vs function declarations
Do not require us to invoke the function separately
Provide us with better scoping capabilities, but not much of an issue any longer because of let and const in ES6
Can be used to take advantage of closures

Defining Primitive and Non-Primitive Data Types in JavaScript

Fri, 15 Jan 2021 06:00:21 +0000

What are data types?

Data types specify the kind of information a variable is holding so that the computer knows which computations can be done. Data types do not care exactly “what” the data is, but “how” it can be used.

There are 7 primitive data types in JavaScript

string
number
BigInt
boolean
Symbol
undefined
null

There is only one non-primitive data type in JavaScript

object

Identifying JavaScript Data Types Examples

For any of the below values, you can use the typeof operator to return the data type. Try it out yourself!

const bookTitle = "The Great Gatsby";
console.log(typeof bookTitle) // string

Primitive Examples

const automobileMake = 'Honda'; // string
const temperatureInDegrees = 78; // number
const serialNumber = BigInt(83784639236484625) // bigint
const isRunning = true; // boolean
const typeOfSoda = Symbol('Pepsi') // symbol
const computerBrand; // undefined

Let's take a quick look at null.

const dogBreed = null; // object

The null data type will return as type object. Some places reference this as a bug built into JavaScript that cannot be fixed because it will break code that exists today. Other sources indicate that null is closely related to an object (similar to how NaN is related to number), so it was given the object type. Either way it is important to know that while this does return object, it is a PRIMITIVE data type.

Non-Primitive Examples

const employee = {
  firstName: 'John',
  lastName: 'Smith',
  role: 'developer',
}; // object

const colors = ['blue', 'green', 'purple'] // object

What is a Primitive Data Type?

Stored on the Call Stack

When a primitive data type is defined, it is given an address on the Call Stack, rather than the Memory Heap.

Immutable

A primitive data type cannot be changed after its creation, meaning that it is an immutable data type. If we assign a primitive data type a new value, the prior value’s address is still held in memory. The new value is given a different address.

let birdBreed = 'quail';
let favoriteBird = birdBreed;
favoriteBird = 'parrot';
console.log(birdBreed) // quail

Here we are setting favoriteBird equal to birdBreed. When we reassign favoriteBird with a different value, it does not effect the value of birdBreed. This is what we would expect to happen! This is an example showing immutability. You will see later that this is not the case for non-primitive data types.

What's happening behind the scenes?

birdBreed is created and assigned an address in the call stack with the value of 'quail'
favoriteBird is assigned birdBreed as its value, creating a completely new and separate address in the call stack.
favoriteBird is reassigned with the value of 'parrot', which again makes a completely new and separate address in the call stack.

Fixed Size

Primitive data types can only be one size. They cannot grow or shrink in size. They only hold a single value.

const candyName = 'Sour Patch Kids'; // A variable holding a single value of a string
const luckyNumber = 321 // A variable holding a single value of a number

Simple Data Type

Primitive data types cannot be broken down into smaller data types.

const birds = ['parrot', 'quail', 'canary'];
let allTheBirds = '';
birds.map((bird) => {
  allTheBirds = allTheBirds + bird
})
console.log(allTheBirds) // parrotquailcanary

Above is an example of how we can take a non-primitive data type and break it down into a primitive type. We are initializing birds and setting it to an array (non-primitive) of birds breeds. From here, we are able to run the map method, which loops over each value in the bird array. Next we are concatenating the bird values into a single string called allTheBirds.

No methods

This topic can get a bit confusing to beginners, because we can perform methods on primitive values.

const text = 'i like singing';
let upperCaseText = text.toUpperCase();
console.log(upperCaseText) // I LIKE SINGING

This is done because of autoboxing. I do not want to go into details on that in this post, but I did want to call it out and point out that this can be done!

What is a Non-Primitive Data Type

Stored on the Memory Heap

A non-primitive data type is assigned an address as a value, which then creates a pointer to that address location in the memory heap.

Mutable

Non-primitive data types are mutable, which means when they are modified, the original copy is modified. Modifying these will not create a copy at a different address. Any direct modifications will effect the same address in the heap.

const cup = {
  type: 'plastic',
  sizeInOunces: 12,
};

const mug = cup;
mug.type = 'glass';

console.log(cup) // { type: "glass", sizeInOunces: 12 }

Huh?! So what happened? Why when we updated type of the mug object was cup effected? This example shows mutability! Let's take a look behind the scenes...

cup is created in the call stack and is assigned an address.
The value of cup does not contain the object above, it contains another address pointing to a location in the memory heap.
The location in the memory heap contains the value of the cup object.
mug is assigned the value of cup. Since the value of cup contains an address pointing to a location in the memory heap, mug will also point to that same location in the memory heap.
Since these are both now pointing to the same location in the memory heap, any changes made to one will effect the other.

Dynamically Sized

Non-primitive data types can change in size. They can grow or shrink and hold multiple values.

const birds = ['quail', 'parrot'];
birds.push('parakeet');
console.log(birds) // ['quail', 'parrot', 'parakeet']

Complex Data Type

Non-primitive data types can be broken down into simpler data types.

Refer to the example under the section "Simple Data Type" of primitive values for an example of this.

Methods

Since non-primitive data types are objects, we can make use of JavaScripts built in methods to simplify our development. We can also create our own object methods by creating an object and assigning a function definition to a property.

Built-in method

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9];
const reversedNumbers = numbers.reverse();
console.log(reversedNumbers); // [9, 8, 7, 6, 5, 4, 3, 2, 1]

Custom method

const dog = {
  name: 'Jo',
  breed: 'poodle',
  color: 'white',
  getInformation: function() {
    return 'Name: ' + this.name + ', Breed: ' + this.breed + ', Color: ' + this.color;
  }
}
console.log(dog.getInformation()) // "Name: Jo, Breed: poodle, Color: white"

Let's do a quick recap

Primitive Data Types

7 total in JavaScript
Stored on the call stack
Immutable - will be made new in the call stack, never overwrites.
Cannot grow or expand in size
Cannot be broken down into a simpler data type
Cannot use methods (but also remember... autoboxing!)

Non-Primitive Data Types

1 total in JavaScript
Stored in the memory heap
Mutable - will be modified in the memory heap and overwritten.
Can grow or expand in size
Can be broken down into a simpler data type
Can use methods