Forem: Alexander Oguejiofor

Getting started with TypeScript

Alexander Oguejiofor — Wed, 12 Aug 2020 14:04:34 +0000

TypeScript is a strongly-typed object-oriented superset of JavaScript that compiles to plain JavaScript. What this means is that any valid JavaScript code is valid TypeScript. TypeScript is essentially JavaScript plus a type system and can be be used both as a language and a set of tools.

The type system provides type checking which can help catch errors during development. This is however optional and can be ignored in favor of JavaScript’s dynamic typing, but type checking is what makes TypeScript so powerful that it allows us to scale our applications much better.

TypeScript has a compiler that translates the instructions written in TypeScript to JavaScript. This compiler uses type annotations to analyze our code and catch errors. TypeScript’s type system is only active during development, ergo, the browser or node has no idea what TypeScript is.

It is perhaps important to note that TypeScript does not provide any performance optimization, as opposed to other strongly typed languages. You can think of TypeScript as a colleague that sits beside you while you code, helping you catch errors.

Setting up TypeScript

You need a compiler to run TypeScript as it is a compiled language, and you will need to have NodeJS installed.

In your terminal, run npm i -g typescript ts-node to install TypeScript and ts-node (a command-line tool that allows us to compile TypeScript with one line in our terminal) globally on your computer.
If running tsc -v and ts-node -v both reveal the versions of TypeScript and ts-node you have installed, you’re all set!

Compiling TypeScript

You only need the compiler to run the TypeScript code. So, create a new project with npm init. Then in the root of your project, create a file called index.ts and put the code below in it.
To run this piece of code, we'll be using the axios npm package to fetch data from an API, so you can install that at the root of your project using npm i axios

import axios from 'axios'

const url = 'https://jsonplaceholder.typicode.com/todos/1'

const logTodo = (id, title, completed) => {
  console.log(`
    The Todo with ID: ${id}
    Has a title of: ${title}
    Is it finished? ${completed}
  `)
}
axios.get(url).then((res) => {
  const todo = res.data
  const id = todo.ID
  const title = todo.TITLE
  const completed = todo.COMPLETED
  logTodo(id, completed, title)
})

This code fetches some JSON data from an API and logs the result.

To compile the code, open up a terminal in your root folder and access the TypeScript compiler using the tsc command i.e tsc index.ts.
This will generate a compiled JavaScript file called index.js. Then we can proceed to run the compiled code with node index.js in the terminal.

Having to type tsc filename.ts followed by ‘node filename.js’ every time we need to compile and run code can get tiring after a while so we can combine the two commands using the ‘ts-node’ module we installed earlier.
Running ts-node index.ts in the terminal will both compile the Typescript file and run the compiled JavaScript code.

Catching errors

If you tried to run the program above, you’ll notice we have an error in the console. It logs undefined, instead of the correct values from the API.

The Todo with ID: undefined
Has a title of: undefined
Is it finished? undefined

Our program fetches data from an API and we tried to access the individual properties of the JSON objects using the wrong property labels.
Also, you may have noticed that we didn’t pass the arguments to the logTodo function in the right order. JavaScript didn’t warn us or throw an error, so we’ll use TypeScript to prevent that.

import axios from 'axios'

const url = 'https://jsonplaceholder.typicode.com/todos/1'
interface Todo {
  id: number
  title: string
  completed: boolean
}

const logTodo = (id: number, title: string, completed: boolean) => {
  console.log(`
    The Todo with ID: ${id}
    Has a title of: ${title}
    Is it finished? ${completed}
  `)
}
axios.get(url).then((res) => {
  const todo = res.data as Todo
  const id = todo.ID
  const title = todo.TITLE
  const completed = todo.COMPLETED
  logTodo(id, completed, title)
})

As you can see, the changes here from the initial vanilla JavaScript code are:

First, interface describes the requirements (types of data) in the object ‘todo'. Interfaces are used to describe the structure of an object. It’s worth pointing out that the type checker does not require that these properties come in any sort of order, only that the properties the interface requires are present and have the required type.
Also, we added a few type annotations, : string, : boolean, and : number. This allows TypeScript to warn us to fix the order of our arguments if we do them incorrectly, whereby JavaScript wouldn’t let us know until we compile our code which is a bit inefficient from a developer perspective. By adding a bit of type annotation, we can avoid this problem.

You would realize that as soon as we made those changes, our code editor starts moaning about possible errors, so we fix them by using the correct arguments and property labels, and then when we run the program again, it logs the right result to the console.

import axios from 'axios'

const url = 'https://jsonplaceholder.typicode.com/todos/1'
interface Todo {
  id: number
  title: string
  completed: boolean
}

const logTodo = (id: number, title: string, completed: boolean) => {
  console.log(`
    The Todo with ID: ${id}
    Has a title of: ${title}
    Is it finished? ${completed}
  `)
}
axios.get(url).then((res) => {
  const todo = res.data as Todo
  const id = todo.id
  const title = todo.title
  const completed = todo.completed
  logTodo(id, title, completed)
})

The Todo with ID: 1
Has a title of: delectus aut atem
Is it finished? false

One of the goals of TypeScript is to help us catch extremely common errors during development, helping us become more efficient developers. Checkout the TypeScript handbook to learn more about its syntax and cool features.

Find the factorial of a number in JavaScript

Alexander Oguejiofor — Fri, 31 Jul 2020 17:05:00 +0000

The factorial of a natural number in mathematics is defined as that number multiplied by that number minus one, then that number minus two, and so on until that number gets to 1. Ergo, if we choose to represent the number with the letter n, the factorial will be the product of all the positive integers less than or equal to n. The factorial of a number n is often denoted as n!

For example:

n! = n * (n - 1) * (n - 2) * …*1
4! = 4 * 3 * 2 * 1 = 24

The Challenge

Write a function that returns the factorial of a number n.

Here, I will explore two approaches.

The recursive approach

Keeping in mind that the factorial of a number can be computed by finding the factorial of that number - 1 and then multiplying the result with the number. The factorial of the number - 1 is a subproblem that needs to be solved first, so we compute that again and again (recursively).

const factorial = (n) => {
  //base case 1: return -1 if the number is less than 0
  if (n < 0) return -1
  //base case 2: return 1 if the number is 0
  if (n === 0) return 1;
  //else call the recursive case
  return n * factorial(n - 1);
}

factorial(6) //--> 720

This solution has greater memory requirements as all the function calls would remain on the call stack until it gets to the base case.

Computing iteratively...

The input n is decremented gradually until it gets to 1. In each iteration, a result variable is updated with the value of multiplying the result with the current value of the input.

const factorial = (n) => {
  //create variable to save final result
  let res = n
  // if input = 0 or input = 1, return 1
  if (n === 0 || n === 1) return 1
  //initialize loop; should run wile num > 1
  while (n > 1) {
    n-- //decrease num by 1 with each iteration
    res = res * n //update result by multiplying with decreased num
  }
  //return the computed factorial of the input
  return res
}

factorial(6) //--> 720

The upside of this approach is that it takes less memory than the recursive implementation at the cost of writing a bit more code.

We've now examined two ways to find the factorial of a number in JavaScript. Both implementations are okay and could help you pass that coding challenge.

Implementing Conway’s game of life.

Alexander Oguejiofor — Thu, 25 Jun 2020 15:49:41 +0000

We just completed Build Week at Lambda school. What it is, in a nutshell, is a week without lectures, coding challenges, or instructions. All there is to do is apply all the knowledge garnered in the previous three weeks learning algorithms and Data Structures to build an implementation of Conway’s game of life. Exciting, no?

Usually, build weeks in Lambda school would be in teams of about five to six students from different cohorts forming some sort of Voltron to constitute a product team. However, we were required to work solo this time due to the scope of the project.

About the project

Conway’s game of life is a zero player game which means its evolution is determined by its initial input and no further interaction is required.

The game was invented by Cambridge mathematician, John Horton Conway. It became very popular when it was mentioned in an article published by Scientific American in 1970.

Also, the algorithm which the game is based on is Turing complete, which means that it is a system able to recognize or decide other data manipulation sets.

Fundamentally, Conway’s game of life is a grid featuring a collection of cells which can live, die or multiply, depending on the initial input configurations. These cells form various patterns as the grid evolves. These patterns are formed by the individual cells responding to the rules of the game.

The Rules

The rules examine each cell in the grid. For each cell, it counts the active neighbors. That is, the eight surrounding cells (up, down, left, right, and diagonals), and then acts on that result.

If the cell is alive and has 2 or 3 neighbors, then it remains alive. Else it dies.
Else, if the cell is dead and has exactly 3 neighbors, then it comes to life. Else, it remains dead.

Any number of different possible configurations can be used as the initial input, but one thing to note is that after a time, there might be nothing left on the grid, or as in some cases, the configuration lives forever.

There is no algorithmic way of telling if the configuration will last forever or fade away completely. If there is a configuration on the grid and you follow it for a thousand moves and it doesn’t die off, it could die-off on the thousand and first move, or the billionth. Following the progress gives you no clue, regardless of whether you track the cells for a hundred or a billion moves.

One would assume that if a thing is governed by rules as clear and simple as this, there would be a way of predicting future outcomes, but it turns out there isn’t. It is what makes the game astonishing.

My Implementation

The specs for the minimum viable product given to us by Lambda School stated that the 2d grid could be any size above 25 by 25. I chose to build mine with a 40 by 40 grid for no reason other than the fact that 1600 sounds to me like a very respectable number.

The next and probably the most important decision was what data structure to use in designing the grid. Here I chose to go with arrays in an object. That is, 40 arrays each containing 40 values in an object. These values will be either 0 or 1 representing the two possible cell states, alive and dead. Obviously, there are a plethora of options when it comes to possible data structures, each with their pros and cons, but I chose to opt for arrays and objects because of how relatively easy they are to manipulate, and also the size of data I was working with.

Since this implementation was created using React and Redux, what followed was architecting the Component and state structures. Nothing too complicated here, just decisions to be made on what components would be reused and what slices of state need to be managed globally.

Another important consideration was what behavior I wanted from the cells when they got to the end of the grid. I chose to design it such that that the cells that are off the edge of the grid wrap around to the far side. Another possible implementation would be to have every cell at the end of the grid to be in the ‘dead’ state. Obviously various implementations will have different effects on the lifecycle of the cells in the grid.

...some code

A helper function to create the actual grid.

const buildBoard = (height, width, random = false) => {
  let board = {};
  for (let i = 0; i < height; i++) {
    let row = [];
    for (var j = 0; j < width; j++) {
      if (random) {
        row.push(Math.round(Math.random()));
      } else {
        row.push(0);
      }
    }
    board[i] = row;
  }
  return board;
};

This buildGrid function takes in the height, width, and a boolean as inputs. The boolean is responsible for deciding whether or not the grid is made up of all dead cells or seeded with random living cells. Ergo, to build a 40 by 40 grid with random living cells, I will call the function like so.

buildGrid(40, 40, true)

Next, another function to implement the algorithm that sets the rules for the game.

export const nextSlide = (board = {}) => {
  // height is number of keys in object
  // width is length of each nested array
  let boardHeight = Object.keys(board).length;
  let boardWidth = board[0].length;

  const activeNeighbours = (x, y) => {
    const topRow = x - 1 < 0 ? boardHeight - 1 : x - 1;
    const bottomRow = x + 1 === boardHeight ? 0 : x + 1;
    const leftColumn = y - 1 < 0 ? boardWidth - 1 : y - 1;
    const rightColumn = y + 1 === boardHeight ? 0 : y + 1;

    let neighbours =
      board[topRow][leftColumn] +
      board[topRow][y] +
      board[topRow][rightColumn] +
      board[x][leftColumn] +
      board[x][rightColumn] +
      board[bottomRow][leftColumn] +
      board[bottomRow][y] +
      board[bottomRow][rightColumn];
    return neighbours;
  };

  let newSlide = {};
  for (let i = 0; i < boardHeight; i++) {
    let row = [];
    for (let j = 0; j < boardWidth; j++) {
      let isActive = board[i][j];
      let neighbours = activeNeighbours(i, j);
      if (isActive === 1) {
        if (neighbours < 2) {
          row.push(0);
        } else if (neighbours > 3) {
          row.push(0);
        } else {
          row.push(1);
        }
      }
      if (isActive === 0) {
        if (neighbours === 3) {
          row.push(1);
        } else {
          row.push(0);
        }
      }
    }
    newSlide[i] = row;
  }
  return newSlide;
};

This function takes in the grid object as its input, then calculates the height and width of the grid by checking how many keys are in the object and checking the length of the nested arrays. Since all the arrays are of the same size, it makes sense to check the length of just one.

Nested in the nextSlide function is a function to calculate the living neighbors of every cell passed to it. This function takes the x and y coordinates of the cell as input.

After that, I am passing every cell in the grid through the newSlide function to calculate the neighbors and then make sure that each cell lives or dies based on the rules of the algorithm. Pass each array into a new object, and then return that new object. Whew!

Fast-forward to creating a few popular presets (cell configurations), making play, fast forward, and random buttons. The game was almost complete with all the major features nailed down. All in three days of work.

Finally, I added a bit of copy and styled using just CSS. No CSS framework as I thought it'd be overkill.

You can find the repo on github, and the deployed site.

Moving forward

Working on this project was a great way to end the first half of my Computer Science section at Lambda School. Next week, we’ll be covering Hash tables. I don’t know very much about them at the moment so I’ll be reviewing the materials in the Training kit before then just so I don’t get stumped.

Also, and just as important, I’ll try to finish reading Joseph Heller’s Catch-22!

Asynchronous JavaScript - How I understand it.

Alexander Oguejiofor — Wed, 10 Jun 2020 22:39:01 +0000

JavaScript is a single threaded language, which means that one command runs at time. It is also synchronously executed, making each command run in the order the code appears.

So imagine we have a task that in our application which accesses a server to get data, and this process takes a long time. What if we have code that we need to run that displays the data response from the server? This poses a challenge, we want to wait for data from the server so that it is there to be displayed, but no code can be run in the meantime.

Enter Asynchronous JavaScript, the feature that makes dynamic web apps possible. We know that the JavaScript engine has three main parts - The thread of execution, Memory (Heap) and the Call stack. However, these aren’t enough as JavaScript needs other external pieces from the Browser like the Console, Timer, Sockets, Network requests and the HTML DOM to function the way we want it to.

JavaScript lets us interact with these tools by providing us with a bunch of functions (Web APIs) like FETCH for Network Requests, Document for the HTML DOM, setTimeout for the Timer and Console for the Console.

The FETCH API is two pronged, ergo it not only initiates the task in the web browser to make a network request to the address passed into it. It also has a consequence in JavaScript which returns a placeholder object called a Promise.

What is a promise?

A promise in JavaScript is very much like a promise in real life. For example, if you make a promise in real life to visit a friend, this promise has two possible results. It is either fulfilled and resolved, or failed and rejected. What this means is that if you go visit your friend, the promise has been fulfilled and resolved, but if you don’t, the promise will be rejected because you were unable to fulfil the promise.

In JavaScript, a promise is an object with three properties, Values, onFulfilled and onRejected. This promise will produce a value in future: a resolved value, or a reason why it is not resolved (e.g., if a network error occurs).

We’ll see an example of how promises work using some code, but before we start we need to define some concepts that will help us along the way.

Event Loop - This is responsible for executing the code, collecting and processing events, and executing queued sub-tasks.

Callback queue - This is where your asynchronous code gets pushed to wait for the event loop to push it into the call stack for execution.

Micro-task queue - Like the callback queue, but has a higher priority which means the event loop checks to see that the micro task queue is empty before moving on to the callback queue.

Execution context - This basically holds all the information about the environment within which the current code is being executed.

const display = (response) => {console.log(response)}
const sayHi = () => {console.log(`say Hi`)}
const runFor300ms = () => { 
   // code that will run for 300ms
}
setTimeout(sayHi, 0)
const futureDisplay = fetch(`https://someserver.com/data/alex/1`)
futureDisplay.then(display)
runFor300ms()
console.log(`I am first`)

Going through the code snippet above synchronously like the JavaScript engine would:

const display = (response) => {console.log(response)}

First, declare and store the function display in global memory.

const sayHi = () => {console.log(`say Hi`)}

We declare and store the function sayHi in global memory.

const runFor300ms = () => { 
   // code that will run for 300ms
}

On line three, we also declare and store the function runFor300ms in global memory.

setTimeout(sayHi, 0)

The setTimeout( ) method is called, and it triggers the timer in the web browser to execute the function sayHi at 0ms, which is when the timer is set to expire. At exactly 0ms, which is immediately, the sayHi function is pushed into the callback queue where it waits for the call stack to be empty and the global thread of execution complete.

const futureDisplay = fetch(`https://someserver.com/data/alex/1`)

Next, at say 1ms, the constant futureDisplay is declared in global memory and its value is the evaluation of FETCH which is a WEB API that returns a promise object to be stored immediately in futureDisplay. This object will have three properties, Value, which will be set to undefined, onFulfilled and onRejected which will both be empty arrays. In the web browser, the FETCH function will also trigger a network request to get data from the address passed to it. Whenever this response gets back, the data will be stored in the Value property of the promise object, replacing its previous ‘undefined’ value.

futureDisplay.then(display)

On the next line, the request is sent to the address. The data response can come back at anytime, so we need JavaScript to somehow automatically use the data when it is returned. This is where the onFulfilled property on the promise object comes in. We can slide a function into the onFulfilled array, and when the value property is filled, the function is executed with the contents of the value property as input. The .then method is what is used to push the display function into the onFulfilled property on the promise object.

runFor300ms()

At 2ms, we execute the function runFor300ms, create a brand new execution context, and push the function into the call stack. This block of code could be a for loop of some sort that will run for 300ms. Meanwhile, at say 250ms, the network request that was triggered as a result of calling the FETCH function resolves and responds with a string ‘Hello’. This string will replace ‘undefined’ as futureDisplay’s value property. The function display will be returned from the onFulfilled object and stored in the micro-task queue where it will wait to be executed.
runFor300ms( ) is done executing and is popped off the call stack.

console.log(`I am first`)

The last line executes and the console logs ‘I am First’.
At say 303ms, the Event Loop checks that the call stack and the global execution context are empty. The micro-task queue has priority over the callback queue, so the Event Loop checks it to see if anything needs to be run. It finds the display function sitting pretty there waiting to be run, and pushes it into the call stack to be executed. The function executes and the string ‘Hello’ is printed.
The event loop then checks the callback queue, where it finds sayHi waiting patiently. It pushes it into the call stack to be executed. Upon execution, it prints ‘Hi’.
Our output will be in the order

'I am First'
'Hello'
'Hi'

Conclusion

Remember the promise object has an onRejected property which is also an empty array? Any function stored in this array will be run if the network request fails. This is used for error handling, and functions are pushed into this array using the .catch method.

Promises, WEB APIs, the event loop, micro task and callback queues constitute Asynchronous JavaScript which is the spine of the modern web. It provides us with functionality that allows us not have to wait in a single thread and block further code from running.