DEV Community: Linas Spukas

TypeSript Compiler Configuration

Linas Spukas — Sun, 21 Jun 2020 12:54:48 +0000

If you need to run a TypeScript project fast and with zero configuration, use Parcel, a web bundler with TypeScript support, and hot module reloading. But the same can be done with a TypeScript compiler and a little bit of configuration. That's what we are going to explore in this post.

TypeScript Compiler

To run TypeScript in the browser, it needs to be compiled into JavaScript first. We will use a compiler that is implemented in the TypeScript language. The compiler is accessible in the terminal with a shorthand tsc. If you don't have it installed yet, run a command in the terminal:

npm install -g typescript

When you run a compiler at the command line with a file path to the TypeScript file, it compiles and outputs a JavaScript file with the same name. So if you run tsc index.ts in a project directory, a new file index.js will be created in the same directory with a compiled code.

If you make changes in the index.ts file, they will not be re-compiled automatically into JavaScript. The compiler command needs to rerun; therefore, this can be avoided if you run a command with --watch flag. It will watch for any changes in the specified file, and if it detects one, re-compiles again:

tsc --watch index.ts

Project Structure

Let's make a simple project structure with two separate folders. An src folder to store TypeScript files, and a build folder to keep compiled JavaScript code. This will make a project more structured:

myapp
└───src
    │   index.ts
└───build
    │   index.js

To put compiled code automatically into the build folder we specify the outcome directory to the compiler:

tsc --watch src/index.ts --outDir build

Now the compiler will watch for file changes to the index.ts and automatically re-compiles to build/index.js file.

As it is a tedious job always to write the same long command, we can use the tsconfig.json configuration file. Use the terminal command tsc --init to create the file into the root directory. The file will consist of many configuration options, but for now, we are interested only in output and root directories. Let's put in the respective directory paths:

{
  "compilerOptions": {
    ...
    "outDir": "./build",                       
    "rootDir": "./src",
    ...
  }
}

After it, you should be able to compile TypeScript code with just tsc --watch terminal command. The compiler will use the configuration file to determine income and outcome paths automatically.

Running The Code

Running the code is straightforward: node build/index.js
But there are a couple of gotchas. First, the code will run only once, and it will not track changes to the file. After each file changes, you will need to rerun the command. Second, if you want to keep running the TypeScript compiler, a JavaScript file must run from a different terminal window.
Two of these obstacles can be fixed by using nodemon and concurrently libraries. Nodemon utility runs an application, tracks for file changes, and restarts the server if it detects them. Concurrently is a utility that lets to run multiple commands concurrently, which is what we want: to run index.js and compile idnex.ts at the same time.
To install dependencies, we need to create package.json first. All can be done with the following command:

npm init -y
npm install nodemon concurrently

In the created package.json file let's add following scripts to run the application concurrently:

{
  ...
  "scripts": {
    "start:build": "tsc -w",
    "start:run": "nodemon build/index.js",
    "start": "concurrently npm:start:*"
  },
  "dependencies": {
    "concurrently": "^5.2.0",
    "nodemon": "^2.0.4"
  }
}

A script command start will run concurrently that will look for scripts that begin with words npm:start: and run them. In our case, it will run start:build and start:run.
Now we can start the application with:

npm run start

Summing up

We have configured the Typescript compiler and the Node.js to run in the same terminal window, look for file changes to both index.ts and index.js, and restart the application to apply them.

TypeScript: Type Definition Files

Linas Spukas — Sun, 14 Jun 2020 19:28:17 +0000

When working with TypeScript, you can use JavaScript modules freely; create, export, import your own, or install third-party libraries. Whenever you install an external module, TypeScript doesn't know anything about it. And this is a problem for the language, as it cannot do its job - check your code for errors. When you import a module into the TS file from a JavaScript library, you will likely see a warning, saying that a module doesn't have a definition file. In this post, I want to briefly explain what it is, why TS needs it, and where to get one if it is not included in the module.

Why Definition Files Are Important

TypeScript's purpose is to analyze your code for possible errors. For that, it needs to know what types are you working with, what functions and methods you are using, and what kind of arguments they accept and return. Without this information, TypeScript can't check your code. So when you install and import a third-party library, TypeScript doesn't have information about the types used in these modules.
We need to add a definition file to help TypeScript to know about the existing properties, functions, arguments, and return values used in the third-party modules. These files include information about the types used in the module.
Sometimes definition files are included in the libraries by default. In that case, you will not see an error when hovering over the imported module name, and you don't need to add it manually.

How To Add Type Definition Files

All definition files are publicly available and placed in the Definitely Typed project in Github. It includes generated types for most of the popular libraries out there. To add a definition file to your project, you need to install an npm module containing @types/{library_name} name. For example, to add a definition file for a lodash library, you would install a package: npm install @types/lodash. To check correct naming for the library types, search the npm repository.
After the installation of the type definition files, a warning for the imported module should be gone.

Benefits Of Type Definitions

Type definition file for a module can be accessed by hovering over the module import in a code editor and pressing command + click (on Mac). You will be redirected to the file containing all the information about the current module: methods, objects, classes, values, properties, and their respective types, everything in TypeScript. It can be used as a source of documentation, to check what type a function will return or arguments accept.
Another advantage is the autocomplete of the module. You initiate a class of the module, and the editor lists all the functions and properties.

Summing Up

The purpose of type definition files is to describe all the functions, properties, and values of the modules. By installing them, we help TypeScript to check and analyze our code for possible errors, and it serves as a source of documentation for the used module.

Quick and Easy TypeScript Project Setup

Linas Spukas — Sun, 07 Jun 2020 17:25:13 +0000

One of the fastest and easiest ways to set up and run a TypeScript project in the browser is with the help of the web bundler Parcel. This command-line tool is fantastic, it offers built-in TypeScript support, development server, hot module replacement to track changes and reload, and it requires zero configuration. So it is a perfect tool to start a TypeScript project.

First, let's start by creating a project folder, setting up an npm package and install parcel-bundler locally:

mkdir myapp
cd myapp
npm init -y
npm install --save-dev parcel-bundler

The starting project structure will look like this:

myapp
│   index.html
│   package.js
│
└───src
    │   index.ts

We will feed an index.html as an entry file and make a reference to src/index.ts in the script tag:

<html>
<body>
    <script src="./src/index.ts"></script>
</body>
</html>

As soon as Parcel sees the TypeScript file in the script tag, it will parse it, compile to JavaScript file, replace script tag with a new compiled index.js file and run in the browser.

To run the app we need to call a parcel command with a path to an entry file, which is index.html. As we installed Parcel locally, we cannot just call parcel index.html within the project directory in a terminal. For that, we will use an npm script. In the package.js add following script commands for starting the development server (start) and building for production (build):

{
  "name": "myapp",
  ...
  "scripts": {
    "start": "parcel index.html",
    "build": "parcel build index.html"
  },
  ...
  "devDependencies": {
    "parcel-bundler": "^1.12.4",
    "typescript": "^3.9.5"
  }
}

Both commands can be initiated from a terminal within the project directory with npm run start or npm run build. When you start a project with the start command, a local server will be built for you with the hot module reloading feature. Whenever you save changes, Parcel will recompile your code and reload the browser with the newest changes.

To test it up, add a simple console.log command to index.ts file and run the app. In the browser console, you should see your printed message.

Parcel is a magical tool. So easy and quick way to start your next project in minutes, and not only for TypeScript. Have fun and happy coding.

TypeScript: Interfaces

Linas Spukas — Sun, 31 May 2020 09:33:33 +0000

TypeScript has a feature, an Interface, that let you create custom data types, very similar to already existing types, like strings, numbers or booleans. Interfaces contain properties, such as named types and methods, and shape, that objects or classes have to implement.

What problem does it solve?

By writing Interfaces we tackle couple main obstacles. First one is readability. With interface the code becomes more readable by replacing long annotations with an Interface, like in the following example:

// with object literal annotation
const person: { name: string; age: number; isFriend: boolean } = {
    name: "John",
    age: 30,
    isFriend: true,
};

// with Interface
interface Person {
    name: string;
    age: number;
    isFriend: boolean;
}

const person: Person = {
    name: "John",
    age: 30,
    isFriend: true,
};

Second, it solves the repeatability problem. If you have several places with the same value types, it is easy to reuse the defined Interface. In the next example we will reuse Person interface to annotate array and a function argument:

interface Person {
    name: string;
    age: number;
    isFriend: boolean;
}

const friendsList: Person[] = [];

function addToFriendsList(person: Person): void {
    friendsList.push(person);
}

addToFriendsList({
    name: "John",
    age: 30,
    isFriend: true,
});

Syntax

Interfaces has no restrictions what comes to data types. You can define strings, numbers, booleans, complex objects, arrays, tuples or functions:

interface Person {
    name: string;
    age: 30;
    isFriend: true,
    friendsWith: string[]; // array of strings
    getName() : string; // a function that returns a string
    createdAt: Date; // an instance of a Date object
}

Interface makes sure, that data meet defined criteria and not the other way around. In other words, objects or classes must have at least the same properties as defined in an Interface. The Interface does not care if the data will have more fields, it makes sure, that it has at least those types that are defined. Take the following example, where the object literal can be applicable to both Interfaces, even though they consist of a different structure:

interface Person {
    name: string;
    getName() : string;
}

interface Summary {
    getName(): string;
}

function printName(person: Person): void {
    console.log(person.getName());
}

function printName(person: Summary): void {
    console.log(person.getName())
}

const friend = {
    name: "John",
    age: 30,
    getName() {
        return this.name;
    }
};

printName(friend)

Function printName in one case receives Person and in another Summary Interfaces. Both cases will be validated correctly because the friend object has met their requirements; has getName() and name properties. Interfaces do not care about other fields, such as age.

Summary

The main purpose of Interfaces is to add a protection layer for data to meet the requirements. In other words, objects and classes must implement the defined Interface structure to be usable. Additionally, Interfaces make the code more readable and less repeatable.

TypeScript: Arrays and Tuples

Linas Spukas — Sun, 24 May 2020 14:16:05 +0000

Working with arrays in TypeScript does not differ much compared with JavaScript. The same basic principles and methods apply, like iterations, filter, reduce, push, pull and etc. The main difference in TS is the restriction of what data types we would like to have in an array. For example, if we annotate that array should include only strings, we will get an error message if we try to push a number to the same array.

Inference and Annotations

Inference system works great for arrays as well. If an array is filled with values, the corresponding types will be assigned automatically, and manual annotations are not needed. In the example below an array includes primitive string types. When hovering over the variable, an annotation with correct types is seen:

If you wonder why do we need to annotate manually if the inference system works so well? One of the cases is when we need to initialize an array before we push values in it. When declaring an empty array, the inference doesn't know what data type values will be added in the future, so it assigns error-prone any[] type:

Syntax

The annotation syntax for array is a value type followed by brackets : Type[]. Here's some examples of arrays with different value types:

// primitive types
const arrayOfStrings: string[] = []; // ['apple', 'pear']
const arrayOfNumbers: number[] = []; // [1, 2, 3]
const arrayOfBooleans: boolean[] = []; // [true, false]


// object types
const arrayObjects: { name: string }[] = []; // [{ name: 'John' }]
const arrayOfArrays: string[][] = []; // [['apple'], ['pear']]
const arrayOfDates: Date[] = []; // [new Date()];

// multiple values
// ['apple', 133, false];
const arrayOfPrimitiveMix: (string | number | boolean)[] = []; 

// [{ name: 'John'}, [133]]
const arrayOfObjectMix: ({ name: string } | number[])[] = [];

When an array is restricted to a certain type of values, an error message will be thrown if trying to assign different type:

When working with array methods like map, filter or reduce, you gain an advantage of type inference and autocomplete. If we map through an array of strings, then each array element in the function will be assigned to string and get autocomplete for a full list of String properties.

Tuples

It is a TypeScript feature that lets you restrict an array to a specific amount and type of values. It has a signature of : [Type] that slightly differs from an array : Type[].
Let's express an array to be a tuple of string and number:

const myTuple: [string, number] = ['John', 30];

This tuple will always have a fixed amount of values of two, and order for a string to come first and number the second. If you mix the order of types or add a different amount of values, TS will throw an error.

Tuples are hard to understand. When you read code and see a tuple of a string and a number, you don't see a context for them. For example, in a tuple ['John', 30] you can guess that the first value probably represents a name, but what does 30 represent? It can be a weight or a foot size. So for context purposes, it is better to use an object: { name: 'John', age: 30 }.
There are special cases for Tuples. For example when working with CSV files. To represent a row entry it is convenient to use Tuples.

Summing up

Expressing an array with known values, manual annotations are not needed, the inference system will do just fine. On the other hand, if values for an array are unknown, defining value types will make your development less error-prone.

TypeScript: Object Destructuring

Linas Spukas — Sun, 17 May 2020 18:55:59 +0000

Writing annotations for primitive values and object literals is pretty straightforward, but it differs slightly when it comes to object destructuration. In this post, I want to shortly mention differences and give a couple of examples of how to write annotations for the destructured properties of object literals.

Object literal

For simple object literals we can write annotations just after the variable and before the object. For example:

const car: { model: string; year: number } = {
  model: "Ford",
  year: "1969",
};

In short, we write the whole object structure and assign types before the actual object.
If the object has nested properties, we list them in the similar structure:

const car: { model: string; year: number; owner: { name: string } } = {
    model: 'Ford Mustang',
    year: 1969,
    owner: {
        name: 'John',
    },
}

Object Destructuring

Giving types for destructured object properties is not very common. Usually, the inference system is reliable and assigns correct types for variables accurately, well most of the time. But there are cases when you need to add types manually. For example, if a function returns an object and it has any type, or if the object is initiated first and some properties are added later.
We will use a declared object bellow as an example. It has a couple of properties, including a nested object and a method. We will destructure all properties using ES6 syntax and explain how to add annotations to them.

const car = {
    model: 'Ford Mustang',
    year: 1969,
    owner: {
        name: 'John',
    },
    setOwner(name: string): void {
        this.owner.name = name;
    }
}

Lets take out the first property from the object:

const { model } = car;

First, we cannot add just a type for a variable. Meaning, that writing const { model }: string = car is incorrect. What's wrong with this approach? Well, imagine if you have to pull out a second property from the same object: const { mode, year }: string = car then which is the string?

When destructing, a type system expects you to write the full object property, which gives the ability to add types for all the properties:

const { model }: { model: string } = car;

// pull out more properties
const { model, year }: { model: string; year: number } = car;

The same goes for the nested properties:

// destructure name property
const { owner: { name } } = car;

// mirror the whole "owner" property
const { owner: { name } }: { owner: { name: string } } = car;

The methods will have similar syntax, though they need to mention that preferable methods should be annotated inside the object, and TypeScript will notify you. Nevertheless, let's add type for a destructured method:

const { setOwner }: { setOwner: (name: string) => void } = car;

Conclusion

To sum up, if annotations are required for destructured object properties, we have to mirror and write the exact structure of that property.

TypeScript Function Annotations

Linas Spukas — Sun, 10 May 2020 19:20:21 +0000

TypeScript has a robust inference system, which automatically assigns the best possible data type for values. It works very well for variables, objects, arrays and more, so you do not need to think about writing annotations for them. But for functions, inference evaluates only a return value and assign best possible type candidate for it. That means function arguments are not evaluated, and we need to do it by writing annotations manually.

Function annotations can be written in couple of ways. First you can annotate a variable as a function type (which is more variable annotation then a function):



const myFunction: (name: string) => void = (name) => console.log(name);

and a regular function annotation, which I will focus on:



const myFunction = (name: string): void => console.log(name);

Don't trust inference

Coming back to the inference system, I want to show why we should not rely on it for functions. Take the following picture, for example, where a function receives two strings as arguments, first and second name, and returns a full name. I will not add annotations on purpose, see how the inference evaluates the functions. Firstly, TypeScript cannot determine which types used for function arguments, so they are marked as any type, which we try to avoid:

But the function return statement was evaluated and data type assigned correctly:

Furthermore, if you accidentally forgot a return statement, then will get a void type and no errors:

That is why to trust inference for functions is not an ideal and very error-prone way.

Writing annotations

By writing annotations for arguments and return values, we help TypeScript to prevent errors and notify us early if we try to use different types.
The syntax for a different kind of functions is pretty much the same: (arg: Type): Type. Annotations for arguments go into the parentheses, and return type follows right after them.

Arrow functions:

Taken the same example from above, we would annotate it this way:



const getFullName = (firstName: string, secondName: string): string => {
   return firstName + ' ' + secondName;
}

Now if you accidentally forget a return statement, you will be notified that function should return, and it must be a string. Same goes for both arguments.

Function declarations:



function multiply(x: number, y: number): number {
    return x * y;
}

Function expressions:



const multiply = function(x: number, y: number): number {
    return x * y;
}

Destructuring function arguments

To annotate an object as function argument you would follow the same object literal annotation, only in a function parentheses:



const logPerson = (person: { name: string; age: number }) => {
    console.log('name:', person.name, 'age:', person.age);
}

And if you prefer argument destructuring, it goes with the same syntax:



const logPerson = ({ name, age }: { name: string; age: number }) => {
    console.log('name:', name, 'age:', age);
}

Also, I should mention a function return type never, which is used for sporadic cases. It makes sure the function will never reach its end. A use case for it if an error will be thrown inside the function:



function neverReachAnEnd(): never {

    throw new Error();

}

Conclusion

While the inference system works very well for other data types, do not trust it for functions. Write annotations manually to help TypeScript understand what we intend to pass for function arguments and what is expected return statement. This way, we make functions less error-prone and get early notifications for any type mismatch.

TypeScript Annotations and Inferences

Linas Spukas — Sun, 03 May 2020 16:05:02 +0000

Annotation and Inference are two TypeScript systems for referring value types to variables. Both of them tells you which value type assign to a variable. The critical difference is that the annotations you have to assign manually, while the Inference will do it automatically. In other words, annotations you have to write yourself, and Inference will be guessed and assigned by TypeScript.
In this article, we will analyse a few examples with annotations and Inference to better understand when and where to use them both.

Annotations

Type annotation is an explicit value type assignment to a variable. It has a syntax : Type, that must become after the variable name. You can write annotations for all value types manually: strings, booleans, arrays, functions. When you write an annotation, you are telling TypeScript that this particular variable should have this explicit type.

Primitive types

Here's an example how to write annotations for a primitive types:

let age: number = 30; // for numbers
let fruit: string = "kiwi"; // for strings
let flatEarth: boolean = false; // for booleans
let aliens: null = undefined; // for undefined or null values

Once we assign a type, the compiler will always check and make sure that the variable stays with it for the rest of its lifetime. If you try to reassign to another type, you will be notified that such reassignment is not valid:

Object types

Annotations for object types are a little bit different.

To set a type for Arrays you would write : Type[]. It will include only the specified type to the array, nothing more:

const price: number[] = [10, 20, 300]; // only array of numbers
const fruits: string[] = ['apples', 'banana', 'kiwi']; // only array of strings

Object literals has a syntax : { value: Type }:

const person = {
    name: 'Mike', 
    age: 30,
}

// Note that name and age types are separated by semicolon
const person: { name: string; age: number } = {
    name: 'Mike',
    age: 30,
}

Classes:

class Person { }

const person: Person = new Person();

Function annotations looks confusing the most. The syntax for specifying types for arguments and a return value: : (arg: Type) => Type.

// simple arrow function
const double = (num) => num * 2;

// type signature - : (num: number) => number
const double: (num: number) => number = (num) => num * 2;

// for a function without return value
const print = (value) => console.log(value);

// we specify special type: void
const print: (value: any) => void = (value) => console.log(value);

Inference

TypeScript inference system helps to determine and assign a type for a variable without the need to do it manually. All the examples written above in the annotation section can be written without the actual annotations, and still, all the types would be assigned correspondently. The Inference happens when initialising variables and members, setting parameter default values. For example, in expression const name = "Mike", the name variable will automatically be inferred to be a type of String, and you can see that by hovering over it.

let name = "Mike";
let age = 30;

// both following reassignments will be rejected
// even if we have not explicitly assigned types for variables
name = 30; // trying to reassign a number for a string type variable
age = "Mike"; // trying to reassign a string to a number type variable

Furthermore, Inference assigns the best common types for object-based types. For example, if you have an array of different types, all of them will be evaluated and assigned to the best possible matching types:

Usage

When to use annotation and Inference is straightforward. You should use Inference most of the time. There are only a few cases where Inference comes short, and it is impossible to determine a type.

The first case is when you are calling a function, and it returns any type.
For example, JSON.parse() method return any type, because it is hard to predict for TypeScript what value type will be parsed. Here you would have to annotate the return value explicitly:

const person = '{"name":"Mike","age":30}';

const result: { name: string; age: number }  = JSON.parse(person);

Another example is when we have to declare a variable first and assign or reassign value later:

let result: number | boolean;

if (Math.random() > 0.5) {
    result = true;
} else {
    result = 0;
}

Summing up

TypeScript is smart enough for evaluating and assigning the best possible matching types automatically. Most of the time, you do not need to worry about writing annotations manually, except the cases where unknown return values come from functions or variables must be declared before the initialisation.

Basic Types in TypeScript

Linas Spukas — Sun, 26 Apr 2020 17:15:57 +0000

TypeScript adds optional static types to JavaScript. A Type in TypeScript means a reference to the value and all its methods and properties. And a Value in JavaScript (and TypeScript) is anything that can be assigned to a variable. That includes String, Boolean, Array, and so on. There are two value categories:

Primitives: Boolean, Number, String, Symbol, null
Objects: Array, Object, Function, Class

If we take for example a String data type, it includes many methods and properties, such as length, toUpperCase(), indexOf(), split() and many more. And if we create value by assigning that string to a variable, we will get a Type that will reference to all properties and methods of the string.

All values have a type:

"red car" // a type of String
42        // a type of Number
["one"]   // a type of Array
true      // a type of Boolean

interface Car {
  color: string;
  year: number;
}

{ color: "red", year: 1973 } // an object, a type of Car

Types are essential to TypeScript because the compiler is using them to search and analyses for possible bugs and errors. If you have defined a type of Car with properties color and year, the compiler will make sure that only these properties will exist in a value that you assign the Car type.

Type Annotations

TypeScript also uses types to annotate values. If we create a value of Date and hover over that value, the code editor will show you what type does this value belong to:

Also, it recognizes all the methods and properties this type has. When referencing this value with a dot, and autocomplete will list you all the properties this type has:

And will notify if you try to access undefined methods for this type. It is the best part of Typescript. You will be notified before running your code:

Another example of type annotation when values do not have a predefined type name, just a plain object. Then by default the compiler list all the methods in that object with values and not a short name:

Summing up

TypeScript is based on types. Everything you write, you'll be using types, and a compiler will make sure you won't leave errors and get pretty and helpful annotations.

What Is a TypeScript

Linas Spukas — Sun, 19 Apr 2020 11:20:12 +0000

TypeScript is a JavaScript but with an additional syntax that is called type system. All the JS rules also apply for TypeScript, so array functions, objects, arrays, spreading, everything that you know in JS can be used for writing a TypeScript.

The purpose of TypeScript is to catch errors early in the development process. To compare with JavaScript, to find a possible error or a bug, you first need to execute the code. That is not an ideal process, which makes development slower, because you need to continually rerun the code to see if you have left a bug somewhere.
With the help of the type system, during development your code is analysed continuously, looking for possible errors and or bugs. If it finds one, then you are noticed inside the code editor with a message of the error and a provided fix. And all of this happens without the need to execute the code.

TypeScript compiler analyses code by using type annotations. Type annotations let you define the type of variable, input or output for the function or method. For example, you can annotate the type of the function to be a String or some variable to be the type of a Boolean. And once you annotate, it tells the compiler that only this specific type is allowed to use. If the compiler detects a different type used on the identifier, it throws an error. In other words, you are describing the information that is going through your code.

Type annotations are used during development only. After the code is compiled from TypeScript to JavaScript, all the type system is removed. You will not see any types that you defined. And the browser or NodeJs does not understand what the TypeScript is, nor it needs to know about it. The types are used only during the development process to help catch errors fast.

Many strong typed language compilers provide an option for code optimisation. That is not the case with TypeScript. It does not do any performance optimisations during the compilation process. It just removes the type system and converts the code to the plain JavaScript.

Summary

To sum up, TypeScript is a JavaScript + Type System. It bounds types (i.e. Boolean, String or Number), to the expressions (i.e. variables, function inputs or outputs), and makes sure that only these types are used. It speeds up the development process because mistakes are caught early, before executing the code. TypeScript is used only in development, and after the compilation, the code converts to plain JavaScript getting stripped of all types.

HTTP Headers Explained

Linas Spukas — Sun, 12 Apr 2020 18:36:55 +0000

HTTP Request and Response objects consist of body and header. While the body in the Response holds the data message (HTML, JSON) or form fields in the Request, the headers let the client and the server to pass essential information about each other.

Headers can be grouped into four categories by their context:

General headers contain information that is relevant for both request and Response, but no information about the data in a body
Request headers hold information about the client and requested resource
Response headers include server details, like time, location, configuration
Entity header informs browser about the type and body of the resource

Let’s inspect more in details. Go to the webpage www.example.com, open the console > Network tab, and select the document to inspect headers. You will likely see the headers divided into General, Request, and Response.

The first, General group consist of the following information:

Request URL: https://www.example.com
The address of the Request and Response
Request Method: GET
A method that is used for the operation, like GET, POST, PUT or DELETE
Status Code: 200 OK
One of the most critical information that tells the status of the request/response. The different code number says what happened, did the operation succeeded or failed. Status codes are grouped:
1xx - Informational; the request is processing
2xx - Success; received, accepted, created
3xx - Redirect; actions needed, moved to a new location
4xx - Client Error; bad request, unauthorized or not found
5xx - Server Error; server failed to fulfill the request, internal server error
Remote Address: 93.184.216.34:80
The IP address of the server

Another group is Request Headers includes following properties:

Accept: text/html
Informs the server, what data types can be accepted, describes the content format. For example:
audio/ogg indicates an audio file
image/png - an image file
text/html - HTML file
application/json - data in the JSON format
Accept-Encoding: gzip, deflate
An algorithm, such as compression that is used on the recourse sent back.
Accept-Language: en-US,en
Hints the server about the expected language
Connection: keep-alive
Controls how long connection should stay open
Host: example.com
The domain name of the server
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4)
Lets server to identify the characteristics of the application, OS, vendor, and versions

Some of the important and common Request Header properties were not included from the domain example.com, but they should be mentioned:

Cookie: 'cookie-list'
Contains stored piece of information, previously sent by the server. For example: Cookie: name=value; name2=value2; name3=value3
Authorization: 'type' 'credentials'
Includes credentials to authenticate a user with a server. The two most used types are Basic, for base64-encoded credentials, and Bearer for access tokens.
Referer: 'url'
Contains the address of the previous page, from which the user was linked to the current page

The last group is Response Headers includes:

Age: 270773
Time in seconds how long the object was in the proxy cache
Cache-Control: max-age=604800
Set the instruction for caching. Other setting types: no-cache, no-store, no-transform
Content-Encoding: gzip
Specifies the compression algorithm used for the response body
Content-Length: 648
The size of the recourse in bytes
Content-Type: text/html; charset=UTF-8
The resource type received. The current type is an HTML document.
Date: Sun, 12 Apr 2020 16:49:25 GMT
The time when the message was created
Expires: Sun, 19 Apr 2020 16:49:25 GMT
Sets the date when the relevant content will no longer be new/fresh
Server: ECS (nyb/1D2C)
Specifies the software used by the server at the time of the sent Response
X-Cache: HIT
It means that the request was sent not from the origin servers, but from an exclusive network (CDN), designed to cache content, so the user could get Response faster
Set-Cookie: 'cookie-name=cookie-value'
Sent cookies from the server to the user-agent. May include other cookie settings, such as expiration date, max-age, domain, security. For example: Set-Cookie: id=qwerty123; Expires=Wed, 13 Apr 2020 07:00:00 GMT

Summing up

The Request and Response headers carry and define transaction information about the user agent, server and data. These headers in the example were the more common ones, there are a lot more of them. The complete list can be found here.

Fetching Data in React Applications

Linas Spukas — Sun, 05 Apr 2020 18:24:21 +0000

React is a library for building and handling user interface and is not responsible for fetching data. To make network or Ajax requests and load some information, we have to create a service, separate piece of code that will handle such requests. In this post, I will discuss how and where we can make requests within a React application.

How to Load Resources

To make HTTP requests we have a couple good options. One is a Fetch, a Web API that is supported by all (excluding IE) browsers natively. Another option is a third-party library, for example axios.
Both options have advantages and disadvantages. Let's take a close look at each of them.

Fetch API is a promise based Request and Response service. As it is supported by browsers, you can test it in your browser console.

  fetch("https://reqres.in/api/users/1")
    .then(response => response.json())
    .then(json => console.log(json));

It is slim, easy to use untill fetching requirements are minimal and does not require much configuration.

Pros:

have basic functionality for Request and Response objects
no need to install a third-party library (no dependencies)

Cons:

will not reject on HTTP error status, always resolves with ok status
will not receive cross-site cookies
you'll end up writing more code

Axios library is a prevalent HTTP client with much more extended functionality. It is very well documented, easy to use and gives an excellent development experience.

const axios = require('axios');

axios.get("https://reqres.in/api/users/1")
  .then(response => console.log(response)) // auto transform to JSON
  .catch(error => console.log(error)); // error handling

Pros:

the browser and node.js support
cancel requests
handles rejections
support Promises
supporting protection against XSRF
older browser support

Cons:

an extra dependency that needs to be loaded from an external source
consumes more client/server resources
includes features you will probably never use

For the most basic use cases on the client-side most of use probably can get with the native Fetch API.

Where to Load

In a React application, usually, requests are made on two occasions. First, as soon as the page loads, and the second is initiated by user interaction (search, submit).
To load resources as soon as the page loads, the data fetching must happen in componendDidMount() lifecycle method (for class components), or useEffect() hook (functional components).

Following example illustrates data fetching on the page load. First, we create an async data fetching function. Inside it, we call fetch() method to get recourses from API. In return, we receive a Promise and need to wait for it to resolve and transform data into JSON format. Then data can be saved to the components state.
To make sure the function runs once, we pass an empty dependency array as a second argument to useEffect().

function App() {
  const [users, setUsers] = React.useState([]);

  React.useEffect(() => {
    fetchUsers();
  }, []);

  async function fetchUsers() {
    const response = await fetch("https://reqres.in/api/users");
    const json = await response.json();

    setUsers([...users, ...json.data]);
  }

  return users.map(user => <li key={user.id}>{user.first_name}</li>);
}

If you need to load data only when the user explicitly asks for it through the interactions, like button clicks, then we do not need to use effect hook. The function can be called in a simple event handler:

function App() {
  const [users, setUsers] = React.useState([]);

  async function fetchUsers() {
    const response = await fetch("https://reqres.in/api/users");
    const json = await response.json();

    setUsers([...users, ...json.data]);
  }

  function handleClick() {
    fetchUsers();
  }

  return (
    <div>
      <button onClick={handleClick}>Load users</button>
      {users.map(user => <li key={user.id}>{user.first_name}</li>)}
    </div>
  );
}

And we can combine both methods. Load initial list of users on page render in useEffect(), and add to list more content by pressing the button. Only this time we add a page count as a second state to load different data from API. Adding a page state as a dependency to useEffect() we will trigger the function inside it to run when we increment the page count:

function App() {
  const [users, setUsers] = React.useState([]);
  const [page, setPage] = React.useState(1);

  React.useEffect(() => {
    fetchUsers()
  }, [page]);

  async function fetchUsers() {
    const response = await fetch(`https://reqres.in/api/users/${page}`);
    const json = await response.json();

    setUsers([...users, ...json.data]);
  }

  function handleClick() {
    setPage(page + 1);
  }

  return (
    <div>
      <button onClick={handleClick}>Load more</button>
      {users.map(user => <li key={user.id}>{user.first_name}</li>)}
    </div>
  );
}

To make the code more extendable and readable must be cleaned a little bit. API related configuration should be moved into separate function or a custom hook.
And that's about it, these examples should cover basic cases for data fetching and storing in a React application, but leave a comment if I missed something to add.