DEV Community: dade!

Why I am offering NFTs as a crowdfunding reward

dade! — Mon, 13 Sep 2021 12:00:49 +0000

Non-equity funding campaigns are always based on promises: "Back us now, and we promise you early access to the product when we launch, or we promise you a discount, digital shout-out or swags". I am currently running an Indiegogo campaign where the promise will also include an NFT: Non Fungible Token, which is a digital artifact that can be used to prove things like ownership. This, as far as I know, is the first time NFTs would be used in this capacity.

In this post, I will shed some light on what NFTs are and share my thoughts on why they are a perfect perk for a non-equity crowdfunding campaign. In doing so, I will touch on my thoughts on the continual march towards the digitalization of the human experience. How digitalization and technologies like virtual/augmented reality, blockchain technology, etc are making it possible to further digitize aspects of society and human interaction that were previously rife with problems or just plain impossible to digitize.

By the way, my campaign is to kickstart the development of DishAfrik: a recipe app to discover, enjoy and share African recipes. Think of it as Yummly or Tasty.co but focused on African cuisine. One of the perks of the campaign is going to be 54 uniquely generated collages made up of 54 recipes from 54 countries. 54 because currently Africa is home to 54 fully recognised sovereign states.

You should check out the IndieGoGo campaign and support the project. Find the link here :)

TL;dr

Ever since the third industrial revolution, there has been a march towards digitalization of the physical world.
Blockchain-related technologies, like NFTs, provided the possibility to digitize aspects of the physical world that relied on scarcity, uniqueness, and proof of ownership, aspects that were previously hard to digitize.
DishAfrik's Indiegogo campaign will be making use of NFTs as a perk, using it as a way to capture participation, while also creating digital art in the form of a recipe collage that can also be owned.

Ever before The Metaverse

It started with the Third Industrial Revolution, often referred to as the Digital Revolution. A period that began in the late 1900s that led to the spread of automation and digitization through the use of electronics and computers.

The technological invention of this era made it possible for things that once existed only in the tactile realm to now also exist in a new and alternative realm: the digital world.

Obviously, such powerful technology would have an impact on society. It was not enough to have good old mails, we got new ones with an e as a prefix: e-mails. The music industry had its Napster scare, and then we had the spotify-cation of music distribution, which killed the CD, at whose hands, cassette and VHS suffered similar fatal fate. Journalism, Medicine, Education, Entertainment you name it, all got impacted by this continual digitalization wave.

Even with all these seismic shifts that digitalization brought, there were certain aspects of society and human interactions that just could not be properly represented in the digital world. This is because these human interactions are inherently at odds with the very nature of digitalization.

How would it be possible to properly digitize commerce for instance? How would it be possible to create e-money just like e-mail? Electronic mail is not problematic, because duplicating a message and sending it multiple times does not in any way compromise the objective of communication which email serves, the same can't be said of a naively designed digital version of money.

If the same endless duplication is possible with digital money, what is stopping someone from making multiple copies of a digital coin, to spend the coin multiple times? Being able to do this negates the ability to carry out commerce in the digital world. This problem, by the way, is called the double-spend problem.

Trusted third parties, bottlenecks, and anarchists.

To enable commerce on the internet, we resulted into having trusted third parties who mediate the commercial exchange. This is not a new thing. The antithesis of anything digital when it comes to commerce, the paper money, originated in China in the 7th century, on the back of trusted third parties.

Before the use of these notes, the Chinese used circular copper coins. If you were wealthy, these copper coins soon became a burden to carry around, especially when used for larger transactions. To solve this problem, the coins could be deposited with a trusted person, who then gave the wealthy merchant a slip of paper (the receipt) that says how much money they had deposited. This slip of paper was then used in commercial activities in the exchange of goods and services. When the recipient of the paper slip returns to the trusted party, they could then exchange the slip of paper for the actual coins.

In the hundreds of years between 7th century China and the 20th century, human monetary affairs came to follow the Chinese model. Therefore it is no surprise that a model involving trusted third parties was also employed when commerce first moved online. In this model, the trusted party serves as the electronic mint that creates and tracks every digital coin that is being spent. In doing so, they can prove ownership and who is allowed to spend what coin, when it is spent, and that it can't be spent twice.

The first successful foray into digitizing money was E-gold. E-gold was a digital gold currency run by Gold & Silver Reserve Inc, which served as trusted third parties. In this capacity they enabled people to transact business online by moving computer bits from one location to another with the assurance that transaction accounting was handled by the E-gold system and the actual money would be made available to parties when requested.

So with this model, digitalization of commerce, tracking, and transferring anything of value was made possible. Finally! Well, maybe not quite.

There is something not quite kosher, with a model involving a trusted third party: and that is the need to have a trusted third party. As the saying goes, absolute power corrupts absolutely. Trusted parties usually occupy a unique role that bestows upon them, if not absolute power, the closest thing to it.

Apart from the political schools of thought that would rather get rid of trusted third parties, there are other weaknesses to relying on trusted third parties. For one they are usually a single point of failure, or point of corruption, depending on the situation. They can also be bottlenecks as their inefficiencies can have rippling effects. Trusted third parties are also by their very nature centralized, and centralized systems are generally harder to scale. The internet would never have evolved into what it is today if it was centralized.

What then do we have? We are left with a deceleration in this march towards the digitalization of everything previously analog. The best we could come up with left us with an internet, where commerce, that quintessential human activity, could not be liberated from trusted third parties. It was also a state where concepts like ownership could not be fully grafted onto the digital world.

Cryptography wins again!

The genius of Satoshi Nakamoto, the creator of blockchain was in conceiving a protocol that relied on cryptographic primitives to mediate the transfer of value without requiring the services of trusted third parties. Instead of trust, the cryptographic proof is relied upon. This creation is often referred to as the blockchain.

The blockchain is often seen as a synonym for bitcoin, which is not surprising, as bitcoin was the first implementation of the blockchain. But the blockchain is more than bitcoin. At the most fundamental level, the blockchain can be seen as a distributed ledger. The protocol outlined by Satoshi Nakamoto made it possible to have a distributed ledger that can track ownership and the transfer of ownership of digital artifacts, without needing a centralized repository. Instead of trusted third parties, a peer-to-peer, decentralized model is used, which relies on cryptographic proofs to keep the integrity of the ledger.

This means, instead of relying on centralized, trusted third parties to keep records of ownership and transfer of ownership of digital artifacts, we rely on cryptography instead. Making it possible to put information in a distributed ledger where everyone and anyone can see its contents, inspect and verify. This means once a transfer of ownership is reflected in the ledger, another attempt to invoke the same ownership transfer would be visible to all relevant parties involved and declined.

This invention made it possible to truly elevate money into the digital realm. Usage of physical money has never had to deal with the problem of double-spending, due to the very nature of it being physical. Once a coin goes from one hand to another, it is impossible for the former holder to still have the exact coin and attempt to transfer it to someone else. This was possible in the digital realm and for a long time, having a mediating third party that serves as a mint, was the only solution. Blockchain created a system that was able to impose constraints similar to those that come with physical money on digital currency, while avoiding the centralization trap. The protocol was able to achieve this without the need to have a trusted third party.

Satoshi Nakamoto's outline of the blockchain was just the spark that ignited other ideas that have led to the emergence of the cryptocurrency/blockchain industry. Once it became clear how to transfer digital artifacts between parties, the next step was to make this programmable. And this is exactly the innovation Ethereum brought into the space.

Ethereum created a computation layer on top of the blockchain, making it possible to encode autonomous rules that control how digital artifacts are to be moved between parties on top of the blockchain. This layer of computation on the blockchain is often referred to as smart contracts. Even though it was coined in the 1990s, by Nick Szabo, arguably Ethereum was what made the term smart contract mainstream.

Another important idea that proved to be critical is the idea of permanence. There are cases where information is required to be unmodifiable. For example, the details of a contract for instance should be unmodifiable after the fact. Unfortunately digital information cannot generally guarantee such a constraint. Digital information is by nature modifiable.

Permanence is one of the central value propositions of the blockchain. If you think about this, it makes sense. A technology that records transactions of value should not allow rewriting of history. Information contained on the blockchain can be considered permanent because the way the protocol is assembled, again making use of cryptography, is such that the cost of going back to change any information on it is so great that it is effectively impossible.

The only snag is, the blockchain is not designed to be a store of arbitrary large data. It does not scale for such a use case. This is where the idea of a permanent web comes into the picture, which, simply put, is a web where contents are immutable. That is, once content is created it should not be editable.

The current web is mutable. Digital content at a particular URL can be changed even though the URL remains the same. Having such mutability is at odds with the need to make statements about permanent events on the web. For example, a contract between two parties found at a particular URL provides less value when there is no guarantee that the content at the URL would always stay the same. A permanent web provides such guarantees.

There has been, and continues to be many attempts at implementing such a permanent web. Arguably, the effort that has been enjoying the most success is IPFS. Which is not only a permanent web but also a distributed web. With IPFS, it is possible to offload large data that needs to be immutable out of the blockchain to the permanent web and have only a reference stored on the blockchain.

The appearance of these technologies: blockchain, smart contracts, permanent web, etc has made it possible for us to continue with the onward march of digitizing our world. These technologies have made it possible to replicate the properties of physical items like scarcity, uniqueness, and proof of ownership in the digital world. Properties that were previously hard to digitize.

Emergence of the NFT

Now that we have these technologies, as is usually the case, thanks to human ingenuity, what has followed is the realization that these technologies can be put to use in clever ways. We have since seen their applications in the financial industry (Defi — Decentralized finance), to new and creative ways organization can be managed (DAO — Distributed Autonomous Organisation), to applications in the supply chain industry.

How blockchain and smart contracts can be used is almost endless and rightly so. This is because a lot of society and human interaction involves dealing with scarcity, uniqueness of things, ownership, and transferring of value. Once we had the means to represent these in the digital world, the possibilities became endless.

A recent application of blockchain and smart contracts that succinctly captures this is the emergence of what is now known as NFTs (Non-Fungible tokens), which have proven to be particularly germane in the creative — music, art, collectible — industry.

What exactly are NFTs?

Let's start with what a token is. A token can be said to be a digital artifact that could either exist 100% in the digital world, without any physical counterpart or a digital representation of something physical.

A token could represent currency, lottery tickets, shares in a company, reputation points in an online platform, title deeds, etc.

Tokens could also be of two kinds. They are either fungible or non-fungible. A fungible token is a digital artifact without identity and hence not unique. Non-fungible tokens on the other hand are inherently unique because they possess an inherent identity.

To illustrate: A 5 dollar bill is as good as the next 5 dollar bill. This is because each banknote does not function on the basis of a unique identity, hence they are fungible. Which is another way of saying they are replaceable with one another, as long as their values are the same. Some other artifacts, on the other hand, carry intrinsic identity and can't just be replaced by another. For example a birth certificate, if tokenized, would be non-fungible.

An NFT is then a unique, digital artifact that can exist on a blockchain.

Why NFTs?

It turns out there are a lot of things in the physical world that are valuable because of their non-fungibility. Being able to capture this and represent it in the digital world is what makes an NFT such a valuable piece in the crypto space.

In the digital art sphere, an artist can create a work of art, sell it to a buyer and issue an NFT that can be used to prove ownership of that unique work of art.

In the gaming industry, NFTs can be used to represent and prove ownership of unique in-game items.

In the music industry, an artist can issue a unique NFT to everyone who buys an album. Such an NFT can then be used to prove ownership of purchase and/or to unlock extra content.

NFTs can also be used to create digital collectibles as well as memorabilia, in which case the NFT can be used to capture and document the authenticity of a memorable event.

NFTs can also be used as perks in crowdfunding campaigns. This is exactly what the DishAfrik NFT will do.

DishAfrik's NFT perk

As earlier stated, I am currently running an IndieGoGo campaign to kickstart the development of DishAfrik: a recipe app to discover, enjoy and share African recipes.

One of the perks for backers of the Indiegogo campaign will be an NFT. The NFT will be a uniquely generated image collage (similar to Beeple’s The First 5000 Days). The NFT will consist of pictures of 54 recipes from 54 African countries. The ingredients and cooking steps will be included as part of the NTTs meta-data.

The DishAfrik NFT perk will serve as a means for capturing participation in an activity (in this case the backing of a non-equity fundraising campaign) and encode that in the digital world. Recipients of the NFT perk will be able to prove that they indeed backed the Indiegogo campaign.

The NFT will also be a digital art that can be owned: a picture made up of a collage of 54 recipes from 54 African countries.

As the IndieGoGo campaign will be an event in time, the NFT will also have memorabilia value. Who knows what this will be worth in the coming years?

Participation in an event, prove-able ownership of art, and memorabilia artifacts were all things that existed without hassle in the physical world before now. But with the advent of new technologies that further the convergence of the physical and digital world, it is now possible to represent these things also in the digital world.

This is why the DishAfrik NFT perk exists.

Metaverse, virtual and augmented reality

This convergence of the physical and digital world that started with the digital revolution shows no sign of abating. One can say we are on the cusp of breakthroughs in these endeavors. Technologies within the space of virtual and augmented reality are exploring ways to further translate other unique physical attributes like "presence" into the digital world.

Mark Zuckerberg thinks this is the future. And spurred on by this belief he has laid out his intention to transform Facebook into a metaverse company. This would turn Facebook into a place where there is the convergence of physical, augmented, and virtual reality in a shared online space.

Although we do not have such a metaverse yet, and it might take a couple more years before its full realization, we do have technologies like NFTs now. And because of that, there is a campaign to build a platform to showcase African cuisine that if you back, you have an option of owning an NFT.

So you should go check that out now!

First impressions with Deno from building PlanetTypeScript.com

dade! — Mon, 07 Jun 2021 20:18:27 +0000

PlanetTypeScript.com is a content aggregator for all things TypeScript. It regularly polls RSS feeds for TypeScript related content, which it then list on the site, send out as a tweet via @planetypescript, and also as a weekly digest to subscribers.

Back when I used to write a lot of Java-related content on this blog, I found out that my blog ended up on www.topjavablogs.com/, which is a site that aggregates Java contents. So when I decided to play around with Deno, I thought a nice little idea would be to build something similar to topjavablogs.com, but for TypeScript. And that is how PlanetTypeScript.com was born.

In this post, I will share some of my first impressions with Deno. The things I enjoyed and the bits I found inconvenient. Let's start with the cool stuff.

Native TypeScript Support

I find it super convenient that I could just write TypeScript without worrying about setting up a build chain that would take care of the transpilation to JavaScript. This is really nice and it makes TypeScript feel more like a standalone language in its own rights. This has to be one of the top-selling points of Deno for me.

Built-in utilities

The deno CLI comes with a whole lot of useful utilities and just comes in handy. For example deno info to check the dependencies. deno fmt: a code formatter, deno bundle for bundling modules and dependencies into a single file, deno compile for creating a self-contained executable, etc.

I personally find dealing with build pipelines within the JavaScript ecosystem to be a tiring chore. Having something like deno bundle or deno compile, built-in is super useful, as it takes care of most of the heavy lifting when it comes to deployment.

Web API

Deno seeks to provide implementations of Web API, and this I found to be really handy. For PlanetTypeScript.com, I need to make HTTP requests and also run background tasks. I could use fetch and web workers for this. API's I am already familiar with coming from the Web, hence no need to install third-party libraries. This is super convenient.

Good Standard Library

In the course of building PlanetTypeScript.com, I needed to have logging, base64 encoding, use hash functions, and generating UUIDs. I was able to find modules within the Deno standard library that I could use for all of these. The Deno standard library is quite decent and has a battery-included feel to it. You can peruse the available modules here.

IDE Support

I primarily use Jetbrains IDEs. When not within a full-blown IDE environment, I use Microsoft Code. Both of these tools have plugins that implement support for Deno and they work very well. I was able to use the visual debugger in IntelliJ, which was quite handy.

So these are some of the cool things that made a good first impression on me with Deno. Below are some of the things that were a bit of a hassle.

No Registry and Package Manager.

Deno does not have any well-known central registry from which a package manager manages dependencies. Instead, Deno works with plain URLs. This setup leads to certain consequences which I believe hamper the developer experience.

For example, there is no central file to look into, to see all the dependencies of a project. To work around this, the convention in the Deno community is to re-import all dependencies from a file called deps.ts - basically recreating some sort of package.json as you have it in npm.

Also, there is no easy way to quickly see if there are new versions of any of my project's dependencies. Or even better still, no command I could run from the command line that updates dependencies.

I later learned about Trex and dmm which could be used to achieve some of these tasks. I can't comment on them now as I have not gotten around to try them out yet.

From the perspective of the developer, I am yet to see the advantage the Deno model brings to the table. Instead, it feels to me more like a philosophical design decision, rather than a pragmatic one.

Nascent Library Ecosystem.

The inability to find needed third-party libraries proved to be one of the main inconveniences.

I had issues finding a third-party library to deal with OAuth. I tried Dashpart, but it has become incompatible with recent versions of Deno and Oak (the HTTP middleware library I used). I tried using Firebase-auth, but there is no support for Deno.

I use MailChimp for sending the Weekly digests. Since the content of the emails would be different weekly, I needed to build the message dynamically. This involves interacting with MailChimp via its API. Unfortunately, MailChimp does not have an API client library for Deno, so I ended up having to directly call the needed HTTP endpoints.

Deno does have a compatibility layer that makes it possible to use Node/npm modules from within Deno. There are also CDN's like Skypack that make it possible to import npm modules for use within Deno. What I quickly realise is that these workarounds, work best for the simplest of libraries. It does not work for anything slightly complicated. For example, I could not use any of these methods to get the Node library for Firebase-auth nor Mailchimp client library to work.

This nascency is strictly not a structural issue with Deno and something to be expected, given how new Deno is. This is also the sort of thing that would improve with time.

Conclusion.

I enjoyed using Deno. Having native TypeScript support, various CLI utilities, and a battery included-standard library, makes it easy to get productive real quick. The main inconveniences I encountered can be chucked up to Deno still being relatively new, but even with that, it is still a hell of a lot usable/productive for a 3 years old project.

Callback, Promise and Async/Await by Example in JavaScript

dade! — Thu, 20 May 2021 20:05:38 +0000

This post is going to show, by way of code examples, how to take a callback based API, modify it to use Promises and then use the Async/Await syntax. This post won't go into a detailed explanation of callbacks, promises or the Async/Await syntax. For such a detailed explanation of these concepts please check Asynchronous JavaScript, which is a section of MDN Web Docs, that explains asynchronicity and how callbacks, promises, and the Async/Await syntax helps with working with asynchronous JavaScript.

This post is meant for the developer who has somewhat of an understanding of asynchronicity in JavaScript, but requires a straight to the point code example to serve as a quick syntax reference for how to take a callback based API, update it to use promises and finally use the Async/Await with it.

For demonstration purposes, we are going to use the fs.readFile, which is a callback based API from reading files. We will have a file test.txt that would contain some text, we will then have a file script.js that would open the file, read the contents, and print it to the terminal.

The code will first be implemented using callbacks, it would then be updated to use Promises, and finally, instead of using Promise directly, it will be updated to use Async/Await.

Let's get started.

Using Callbacks

We first create a directory where we are going to work from, create also the file that will contain our code, and the two files that we would be reading from.

We first create the two files with contents.

$ mkdir ~/code
$ touch ~/code/script.js
$ echo "Beam me up, Scotty" > ~/code/test.txt
$ cd ~/code/

Next in the script.js file, we have the following code:

const fs = require("fs")

function readFileCallBack() {

fs.readFile("./test.txt", 'utf8',  (err, data) => {
  if (err) {
     console.error(err)
     return
   }
   console.log(data.trim() + " [callback]")
  })

}

readFileCallBack()

Executing the script by running node script.js should get "Beam me up, Scotty" printed to the terminal:

$ node script.js
Beam me up, Scotty [callback]

Using Promises

Update script.js and add a version of readFileCallback that uses promises. It looks like this:


function readFilePromise() {
  return new Promise((resolve, reject) => {
     fs.readFile("./test.txt", 'utf8',  (err, data) => {
     if (err) {
       reject(err)
       return
     }

      resolve(data.trim())
    })
  });
}

readFilePromise()
 .then(data => console.log(data  + " [promise]"))
 .catch(err => console.log(err))

Execute the script by running node script.js:

$ node script.js
Beam me up, Scotty [callback]
Beam me up, Scotty [promise]

Using Async/Await

Update script.js and add a third version that uses the Async/Await syntax. Since Async/Await is a syntax that makes using promises easier, the Async/Await implementation would make use of the readFilePromise() function. It looks like this:

async function readFileAsync() {
  try {
    const data = await readFilePromise()
    console.log(data.trim() + " [async-await]")
  } catch (err) {
    console.log(err)
  }
}

readFileAsync()

Executing the script by running node script.js will print something similar to this, to the terminal:

Beam me up, Scotty [callback]
Beam me up, Scotty [promise]
Beam me up, Scotty [async-await]

The complete file with the 3 implementations is presented below:

const fs = require("fs")

// callback
function readFileCallBack() {

fs.readFile("./test.txt", 'utf8',  (err, data) => {
  if (err) {
    console.error(err)
    return
  }
  console.log(data.trim() + " [callback]")

 })

}

readFileCallBack()

// promise
function readFilePromise() {
  return new Promise((resolve, reject) => {
     fs.readFile("./test.txt", 'utf8',  (err, data) => {
     if (err) {
       reject(err)
       return
     }

      resolve(data.trim())
    })
  });
}


readFilePromise()
 .then(data => console.log(data  + " [promise]"))
 .catch(err => console.log(err))


// async/await
async function readFileAsync() {
  try {
    const data = await readFilePromise()
    console.log(data.trim() + " [async-await]")
  } catch (err) {
    console.log(err)
  }
}

readFileAsync()

Error Handling

To illustrate that the error handling in the 3 implementation work as expected, rename the test.txt file and rerun the script:

$ mv test.txt test.txt.backup
$ node script.js
[Error: ENOENT: no such file or directory, open './test.txt'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: './test.txt'
}
[Error: ENOENT: no such file or directory, open './test.txt'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: './test.txt'
}
[Error: ENOENT: no such file or directory, open './test.txt'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: './test.txt'
}

Showing that the error handling code, which is to just print the error to the console, works as expected in the 3 implementations.

How to apply type annotations to functions in TypeScript

dade! — Sun, 21 Feb 2021 07:04:11 +0000

This post explores the various ways of ascribing functions with type annotations in TypeScript. To fully appreciate the various ways of ascribing type annotations to functions, we would first take a quick look at the various ways functions can be defined in JavaScript. Once that is done, we then look at how to bring TypeScript's static type annotation into the picture.

There are mainly two ways of defining functions in JavaScript. Namely:

Function expressions
Function declarations.

Let’s quickly go over how these two work.

Function expressions

JavaScript allows creating functions by defining them as expressions that can be assigned to a variable. Defining such function expressions can make use of the function keyword or via the use of Arrow functions.

For example, defining an add function can take either of these forms:

Using the function keyword:

let add = function(a,b) { return a + b }

Using Arrow functions, It takes the form:

let add = (a,b) => { return a + b }

Functions defined in either of these ways can be called like any other function:

console.log(add(1,2)) // logs 3

Function declaration

Using function declaration is the regular way of defining a function that everyone knows.

It looks like this:

function add(a,b) {
   return a + b;
}

The above is a declaration, function declaration that creates an identifier, in this case, add, that can be later used as a function. The created add identifier can be called as follows:

console.log(add(1,2)) // logs 3

Now before we go ahead to see how to apply TypeScript’s type annotations, another important thing to be aware of, is the fact that functions in JavaScript are also objects!

Yes, a function in JavaScript is a JavaScript object.

This means the function add created above, either via function declaration or function expression, is also an object and can have properties assigned to it like any other object in JavaScript.

That is:

add.serial = "A01"
console.log(add.serial) // logs A01

For a more in-depth take on functions being objects, see Understanding Constructor Function and this Keyword in Javascript.

Knowing that functions are also objects is important, as this also influences the syntax that can be used for type annotation in TypeScript. We will see how later in the post.

Now that we have covered the basics, let’s now go into applying type annotations to functions.

We will start with function expressions.

Adding Type Annotations to Function Expressions

Adding type annotations to function expressions is straight forward because the definition is an expression that is assigned to a variable.

This makes it obvious where to place the type annotation, which is right after the variable declaration.

Knowing this, adding type annotation to the add function will look like this:

let add: (a: number, b: number) => number = (a,b) => { 
   return a + b 
}

Notice that the actual function definition remains unchained. That is (a,b) => { return a + b } remains the way it was in the JavaScript version, and no type annotations are added to the function parameters, but TypeScript is able to infer the types based on type annotation ascribed to the variable.

That being said, it is also possible to update the function definition to have type annotations. That is:

let add: (a: number, b: number) => number = 
         (a:number,b:number):number => { return a + b }

In which case, the type annotation placed after the variable becomes redundant and can be removed, which leads to another way of typing the function expressions. This can be seen below:

let add = (a: number, b:number): number => { return a + b }

This demonstrates an important point. Which is, when typing functions in TypeScript, there are two ways to go about it. One way is to ascribe type annotations to the function parameters and return type. The other way is to ascribe annotation to the variable that holds the function.

Ascribing type annotations to variables is possible when using function expression since function expression are assigned to variables. Function expression can also choose to have parameters in their definition annotated, although often time this is not needed.

Another important point is when ascribing types to variable holding functions, the syntax used resembles how Arrow functions are used, that is it makes use of "=>". And this is the only way to annotate variables with functions.

For example, this is correct:

let add: (a: number, b: number) => number = 
         (a,b):number => { return a + b }

While this leads to a syntax error:

let add: (a: number, b: number): number = 
             (a,b):number => { return a + b }

Adding Type Annotations to Function Declaration

The add JavaScript function defined via function declaration:

function add(a,b) {
   return a + b;
}

With TypeScripts type annotations applied becomes

function add(a: number, b: number): number {
   return a + b;
}

Since there is no other way the TypeScript compiler can infer the types of the function parameters, the type annotation has to be supplied.

One might ask, what then is the type of the add function?

For example given a variable name defined as:

let name: string = “John Doe”;

When the question is asked, what is the type of name it is easy to see it is string.

When the same question is asked for the add function defined using function expressions, that is

let add: (a: number, b: number) => number = 
         (a,b) => { return a + b }

It is easy to respond that the type is (a: number, b: number) => number

But what about the add function defined using function declaration?

To help answer this question we can use the combination of an IDE and the typeof operator of TypeScript. The typeof operator when used in the type signature context can help extract the type of a value.

So to answer the question, what is the type of the add function defined using function declaration, we use typeof on add, in the type signature context and using a tool that offers IntelliSense, in this case, the TypeScript playground, we can see what the type is:

And as can be seen above, the type of add when defined using function declaration is (a: number, b: number) => number, which is exactly the same type annotation of the same function when defined using the function expression!

Typing functions using Call signature of an object literal type

Remember we mentioned that functions are also objects. And we showed how we can add properties to functions as we do to objects. Well, functions being objects also provide us another way of supplying type information about functions.

A question a curious reader might ask upon being told that functions are objects in JavaScript is this: if functions are objects, how come we can call them? How come functions can be called by appending () to the end of the function? That is something like functionName().

The answer to that question is in realising that the syntax functionName() is really a syntactic sugar for either functionName.call() or functionName.apply(). That is, calling a function, is really nothing but assessing the apply or call property of the object representing that function.

See MDN entries for Function.prototype.apply() and Function.prototype.call() for more information.

This knowledge helps in understanding another way of typing functions, which is using the call signature. Doing that builds on how object literal can be used to specify types.

For example to provide type annotation describing an object with a property name of type string, and property age, of type number, the following interface can be created and used:

interface Person {
  name: string
  age: number
  greet(): string
}

let john: Person = {
  name: "John Doe",
  age: 20,
  greet() {
    return “hello world”
   }
}

The type annotation outlines the property name together with a type annotation.

Knowing this, and knowing that functions are also objects, that can be called via a call, or apply property then we can provide a type annotation to our add function as shown below:

 interface Adder {
  apply(a: number, b: number): number
  call(a: number, b: number): number
 }

And we can then use this Adder in typing the add function. This looks like this:

let add: Adder = (a: number, b: number) => { return a + b }

Note that even though this type checks, confirming that the created Adder type can be used to annotate our add function, we still have to annotate the type parameters, because TypeScript is unable to infer their types from the provided Adder annotation used for the variable.

We can go one step further in the definition of Adder by removing the need to specify apply and call explicitly. This is because as we already know that a function (which is an object) can have its apply and call property called without having to explicitly specify them. That is, the call signature of a function is a syntactic sugar that will expand to explicitly use either apply or call. We can apply this knowledge of the call signature to the type definition by removing the apply and call. Doing that we end up with:

interface Adder {
  (a: number, b: number): number
}

This way of providing type annotations to functions is usually referred to as using the call signature of an object literal type.

It is worth noting that in TypeScript, the keyword type and interface are interchangeable in most cases hence, the above can also be defined using type instead of interface.

Summary

These conclude the overview of how functions can be typed in TypeScript. A quick outline of the key points is listed below:

The way functions are typed in TypeScript depends on the ways functions can be created in JavaScript.
Functions can be created either via function declaration or function expressions.
They are two main ways to ascribe type annotations to functions. T*yping the parameters and return type of the function, or **typing the variable that holds the function*.
Functions defined using function declaration can only be typed by providing type annotation to parameters and return value. A function expression can be typed by providing the type annotation to the variable that holds the function expression. Also, it is possible to ascribe type to the function parameters defined in the function expression, this is usually redundant. It is only needed in cases where the compiler cannot infer their types based on the type annotation ascribed to the variable.
When typing a variable that holds a function, the type annotation makes use of => to specify the return type. Using this Arrow function style is the only way to type variables holding function expressions.
Also, Functions are just objects! And this influences the third way of typing functions which is called: call signature using object literals.