DEV Community: Famini-ProDev

Testing with Jest

Famini-ProDev — Sat, 23 Apr 2022 12:41:43 +0000

Jest is a Javascript Testing Framework by Facebook. It is used most commonly for unit testing. Unit testing is when you provide input to a unit of code(usually, a function) and match the output with the expected output.

Jest Features:

zero config: As we will see later in this article, close to none configuration is required to get started with writing tests and deploying them. However, a config file can be supplied to the test suite as well.
snapshots: Jest has the ability to enable snapshot testing as well. Essentially, the snapshots are matched with the saved snapshot and check for matching functionality.
isolated tests: Jest tests are run parallelly to improve run time.

Setting up a jest project

- Install Jest using npm
:

Project Structure:
In the project root directory, make a tests folder. This folder will store all the test files.
Note that the js files(which are to be tested) are mapped by their names.
For example, index.js is mapped to index.test.js. This index.test.js file is placed in the 'tests' folder. This is the conventional project structure.

Start testing:

To start, lets see a basic test workflow.

To run the test, use the script

npm run test

This will look for the test script mentioned in the package.json of the project.

We will use the 'expect' method to test our functions. The functions can also be tested using 'describe' and 'it'.
A basic test: adding two positive nums and checking result.


//index.js
testForAdd: (a, b) => { return (a + b) },
//index.test.js
test('test adding two positive nums', function() {
    expect(testFns.testForAdd(4, 5)).toBe(9);
});

When the 'npm run test' is run, the index.test.js file is gone through. Then the testForAdd _function is run which is placed in the '_testFns' object. The toBe is used to 'match' the returned response from the test to what is expected. This 'result matching' leads to either a 'fail' or a 'pass'.

The following test will fail because of the 'toBe(8)'.

//example of a failing test
 test('test adding two positive nums - failing test', function() {
     expect(testFns.testForAdd(4, 5)).toBe(8);
 });

Opposite of toBe: not.toBe()
The opposite of the 'toBe' matcher is created by simply prefixing it with 'not.'
For example:


//test successful - test for opposite of a matcher.
//The following test will 'Pass' if the returned value is not equal to 8.
test('test adding two positive nums - failing test', function() {
    expect(testFns.testForAdd(4, 5)).not.toBe(8);
});

Using 'toBe' with JS Objects:
Let's think of a case where every field of a JS object is to be tested. Jest provides us a way to do this using 'toEqual'. The 'toEqual' is a deep-matcher(checks every field and sub-fields possible).

//expect toEqual example - check every field's value
// testFns.test_toEqual(gfgObj)
test('check gfgObj toEqual', () => {
    let gfgObj = { name: "GFG" };
    gfgObj['type'] = "company";
    expect(gfgObj).toEqual({ name: "GFG", type: "company" });
});

Running the above test will 'Pass'.

Another variation of doing this is matching two objects using the 'toEqual'.
This is done so like this :

test('check gfgObj toEqual', () => {
    let gfgObj = {
        name: "GFG",
        type: "company",
        members: {
            employees: 100,
            contributors: 500
        }
    };
    let testObj = {
        name: "GFG",
        type: "company",
        members: {
            employees: 100,
            contributors: 500
        }
    };
    expect(gfgObj).toEqual(testObj);
});

This test demonstrates the deep-matching feature of toEqual.
The above test passes as every key-pair in gfgObj matches with testObj.

*toBeCloseTo - for floating point numbers and other approximate matches *

//see here that a+b != c even though simple addition is taking place.
> var a = 1.32
> undefined
> var b = 2.31
> undefined
> c = a+b;
> 3.63
> var res = false;
> if(c==(a+b)) {c=true;}
> undefined
> c
> false

In such conditions, it is good to use 'toBeCloseTo' matcher from the Jest library.

test('floating point number - use toBeCloseTo instead', function() {
    // const num1 = 0.3;
    // const num2 = 0.2;
    const result = 9.31 + 9.2;
    expect(result).toBeCloseTo(18.51);
})

The above test passes too.

matching truthy and falsy:

https://jestjs.io/docs/en/using-matchers#truthiness
A lot of times, tests are written to check for truthy and falsy values returned by 'expect'.
**Falsy **values in JS.
**Truthy **values in JS.

//checking for truthy values - All the tests will return truthy.

test('check for truthy', function() {
    const gfgObj = {
        first: null,
        second: undefined,
        third: false
    }
    expect(gfgObj.first).not.toBeTruthy(); // True - Pass
    expect(gfgObj.second).toBeUndefined(); // True - Pass
    expect(gfgObj.third).toBeFalsy();      // True - Pass
})

The above test passes.

However, if any of the 'expect' above fails, Jest returns **meaningful **error **messages **like below.
**Note **that in above case, if any of the 'expect'-s fail, the test also completely fails.

** Matching Numbers:**

//tests for Number matches
test('test for numbers', function() {
    const result = 3 + 9;
    // expect(result).toBe(12); //the plain old matcher
    expect(result).not.toBeLessThan(10); // result > 10
    expect(result).toBeLessThan(15);  // result < 15
    expect(result).not.toBeGreaterThan(15); // result  10
    expect(result).toBeGreaterThanOrEqual(12);  //result >= 12
    // expect(result).not.toBeGreaterThanOrEqual(12); // result == 12, this Fails
    // expect(result).toBeLessThanOrEqual(10); // result >= 10, this Fails
})

**
Testing values contained in arrays: **

We can also test if particular values are contained in an array. Note that this test will 'Fail' if at least one value is not present in the array. For example,

//testing arrays
const gfgUsers = [
    'user1',
    'user2',
    'user3'
];
test('test for a value in gfgUsers', function() {
    // expect(gfgUsers).toContain('user2');
    // expect(gfgUsers).not.toContain('user2');
    //expect array containing
     expect(gfgUsers).toEqual(expect.arrayContaining(['user1', 'user3']));
})

Th above test passes as user1 and user3 are present in gfgUsers.

However, the following test will fail because 'user4' is not present in gfgUsers.

//testing arrays
const gfgUsers = [
    'user1',
    'user2',
    'user3'
];
test('test for a value in gfgUsers', function() {
    //expect array containing
     expect(gfgUsers).toEqual(expect.arrayContaining(['user1', 'user4']));
})

test('string match tests - toMatch - used for regex-es', function() {
    const str = 'GeeksforGeeks';
    // expect(str).toMatch(/f/);
    // expect(str).toMatch(/Z/);
    //you can create more complex Regexes
    const str1 = 'This is a test paragraph. I wrote it.'
    expect(str1).toMatch(/[pP][hH][\.]/);  //matches 'ph.' in the word 'paragraph'
})

Extending the Matchers
Jest also has the provision to extend its 'Matchers' functionality, which is accomplished using the 'expect.extend()' keyword. The .extend() function is passed matchers as objects.
Syntax: expect.extend({matcher1, matcher2}) ;
For example, if we want to build a matcher that checks for a phrase presence in a string:

expect.extend({
stringPresent(receivedString, phraseString) {
bool phrasePresent = true;
var re = new RegExp(phraseString);
if (re.test(receivedString)) {
    phrasePresent = true;
} else {
    phrasePresent = false;
}
if (phrasePresent === true) {
      return {
        message: () =>
          `string present`,
        pass: true,
      };
    } else {
      return {
        message: () =>
          `string absent`,
        pass: false,
      };
    }
},
});

Dealing with exceptions
We can also check the types of errors that a unit of code throws. We can check the error thrown by name, message, object, etc.
Syntax:expect( fnName() ).toThrow( error );
The error parameter/argument is optional here.
Let's suppose that we want to test a function by the message of the error thrown.

function testGFGMessage() {
  throw new Error('this is testGFGMessage function error');
}
test('testing testGFGMessage', function(){
  expect(testGFGMessage).toThrow('this is testGFGMessage function error');
})

There are many other ways to throw Errors and check for them. A detailed reference can be found here.
Skipping/Running a subset of tests
https://jestjs.io/docs/en/api#testskipname-fn
Jest also has a provision for skipping specific tests while running the test suite.
To implement it, simply use the 'skip' keyword. For example,

function addFn(num1, num2){
  return num1 + num2;
}
test.skip('skip test example - skipping the addition test', () => {
  expect(addFn(2, 3)).toBe(5);
});

The opposite of this is implementing only a subset of tests, which is achieved by using the 'only' keyword. For example,

function addFn(num1, num2){
  return num1 + num2;
}
test.only('skip test example - skipping the addition test', () => {
  expect(addFn(2, 3)).toBe(5);
});

Reference:

Interfaces in TypeScript

Famini-ProDev — Sat, 23 Apr 2022 11:38:44 +0000

Introduction
TypeScript is an extension of the JavaScript language that uses JavaScript’s runtime with a compile-time type checker.
TypeScript offers multiple ways to represent objects in your code, one of which is using interfaces. Interfaces in TypeScript have two usage scenarios: you can create a contract that classes must follow, such as the members that those classes must implement, and you can also represent types in your application, just like the normal type declaration. (For more about types, check out How to Use Basic Types in TypeScript and How to Create Custom Types in TypeScript.)
You may notice that interfaces and types share a similar set of features; in fact, one can almost always replace the other. The main difference is that interfaces may have more than one declaration for the same interface, which TypeScript will merge, while types can only be declared once. You can also use types to create aliases of primitive types (such as string and boolean), which interfaces cannot do.
Interfaces in TypeScript are a powerful way to represent type structures. They allow you to make the usage of those structures type-safe and document them simultaneously, directly improving the developer experience.
In this tutorial, you will create interfaces in TypeScript, learn how to use them, and understand the differences between normal types and interfaces. You will try out different code samples, which you can follow in your own TypeScript environment or the TypeScript Playground, an online environment that allows you to write TypeScript directly in the browser.

Creating and Using Interfaces in TypeScript

In this section, you will create interfaces using different features available in TypeScript. You will also learn how to use the interfaces you created.
Interfaces in TypeScript are created by using the interface keyword followed by the name of the interface, and then a {} block with the body of the interface. For example, here is a Logger interface:

interface Logger {
  log: (message: string) => void;
}

Similar to creating a normal type using the typedeclaration, you specify the fields of the type, and their type, in the {}:

interface Logger {
  log: (message: string) => void;
}

The Loggerinterface represents an object that has a single property called log. This property is a function that accepts a single parameter of type stringand returns void.
You can use the Loggerinterface as any other type. Here is an example creating an object literal that matches the Loggerinterface:

interface Logger {
  log: (message: string) => void;
}
const logger: Logger = {
  log: (message) => console.log(message),
};

Values using the Loggerinterface as their type must have the same members as those specified in the Loggerinterface declaration. If some members are optional, they may be omitted.
Since values must follow what is declared in the interface, adding extraneous fields will cause a compilation error. For example, in the object literal, try adding a new property that is missing from the interface:

interface Logger {
  log: (message: string) => void;
}
const logger: Logger = {
  log: (message) => console.log(message),
  otherProp: true,
};

In this case, the TypeScript Compiler would emit error 2322, as this property does not exist in the Logger interface declaration:

Output
Type '{ log: (message: string) => void; otherProp: boolean; }' is not assignable to type 'Logger'.
  Object literal may only specify known properties, and 'otherProp' does not exist in type 'Logger'. (2322)

Similar to using normal type declarations, properties can be turned into an optional property by appending ? to their name.

Extending Other Types
When creating interfaces, you can extend from different object types, allowing your interfaces to include all the type information from the extended types. This enables you to write small interfaces with a common set of fields and use them as building blocks to create new interfaces.
Imagine you have a Clearable interface, such as this one:

interface Clearable {
  clear: () => void;
}

You could then create a new interface that extends from it, inheriting all its fields. In the following example, the interface Logger is extending from the Clearable interface. Notice the highlighted lines:

interface Clearable {
  clear: () => void;
}
interface Logger extends Clearable {
  log: (message: string) => void;
}

The Loggerinterface now also has a clearmember, which is a function that accepts no parameters and returns void. This new member is inherited from the Clearable interface. It is the same as if we did this:

interface Logger {
  log: (message: string) => void;
  clear: () => void;
}

When writing lots of interfaces with a common set of fields, you can extract them to a different interface and change your interfaces to extend from the new interface you created.
Returning to the Clearable example used previously, imagine that your application needs a different interface, such as the following StringList interface, to represent a data structure that holds multiple strings:

interface StringList {
  push: (value: string) => void;
  get: () => string[];
}

By making this new StringListinterface extend the existing Clearable interface, you are specifying that this interface also has the members set in the Clearable interface, adding the clear property to the type definition of the StringList interface:

interface StringList extends Clearable {
  push: (value: string) => void;
  get: () => string[];
}

Interfaces can extend from any object type, such as interfaces, normal types, and even classes.

Interfaces with Callable Signature

If the interface is also callable (that is, it is also a function), you can convey that information in the interface declaration by creating a callable signature.
A callable signature is created by adding a function declaration inside the interface that is not bound to any member and by using : instead of => when setting the return type of the function.
As an example, add a callable signature to your Logger interface, as in the highlighted code below:

interface Logger {
  (message: string): void;
  log: (message: string) => void;
}

Similar to creating a normal type using the type declaration, you specify the fields of the type, and their type, in the {}:

interface Logger {
  log: (message: string) => void;
}

The Logger interface represents an object that has a single property called log. This property is a function that accepts a single parameter of type string and returns void.
You can use the Loggerinterface as any other type. Here is an example creating an object literal that matches the Loggerinterface:

interface Logger {
  log: (message: string) => void;
}
const logger: Logger = {
  log: (message) => console.log(message),
};

interface Logger {
  log: (message: string) => void;
}
const logger: Logger = {
  log: (message) => console.log(message),
  otherProp: true,
};

In this case, the TypeScript Compiler would emit error 2322, as this property does not exist in the Logger interface declaration:

Output
Type '{ log: (message: string) => void; otherProp: boolean; }' is not assignable to type 'Logger'.
  Object literal may only specify known properties, and 'otherProp' does not exist in type 'Logger'. (2322)

Similar to using normal typedeclarations, properties can be turned into an optional property by appending ?to their name.

Extending Other Types

When creating interfaces, you can extend from different object types, allowing your interfaces to include all the type information from the extended types. This enables you to write small interfaces with a common set of fields and use them as building blocks to create new interfaces.
Imagine you have a Clearable interface, such as this one:

interface Clearable {
  clear: () => void;
}

interface Clearable {
  clear: () => void;
}
interface Logger extends Clearable {
  log: (message: string) => void;
}

The Loggerinterface now also has a clearmember, which is a function that accepts no parameters and returns void. This new member is inherited from the Clearableinterface. It is the same as if we did this:

interface Logger {
  log: (message: string) => void;
  clear: () => void;
}

When writing lots of interfaces with a common set of fields, you can extract them to a different interface and change your interfaces to extend from the new interface you created.
Returning to the Clearable example used previously, imagine that your application needs a different interface, such as the following StringListinterface, to represent a data structure that holds multiple strings:

interface StringList {
  push: (value: string) => void;
  get: () => string[];
}

interface StringList extends Clearable {
  push: (value: string) => void;
  get: () => string[];
}

Interfaces with Callable Signature
If the interface is also callable (that is, it is also a function), you can convey that information in the interface declaration by creating a callable signature.
A callable signature is created by adding a function declaration inside the interface that is not bound to any member and by using : instead of => when setting the return type of the function.
As an example, add a callable signature to your Logger interface, as in the highlighted code below:

interface Logger {
  (message: string): void;
  log: (message: string) => void;
}

Notice that the callable signature resembles the type declaration of an anonymous function, but in the return type you are using : instead of =>. This means that any value bound to the Logger interface type can be called directly as a function.
To create a value that matches your Logger interface, you need to consider the requirements of the interface:

It must be callable.
It must have a property called log that is a function accepting a single string parameter. Let’s create a variable called loggerthat is assignable to the type of your Loggerinterface:

interface Logger {
  (message: string): void;
  log: (message: string) => void;
}
const logger: Logger = (message: string) => {
  console.log(message);
}
logger.log = (message: string) => {
  console.log(message);
}

To match the Logger interface, the value must be callable, which is why you assign the logger variable to a function:

interface Logger {
  (message: string): void;
  log: (message: string) => void;
}
const logger: Logger = (message: string) => {
  console.log(message);
}
logger.log = (message: string) => {
  console.log(message);
}

You are then adding the log property to the logger function:

interface Logger {
  (message: string): void;
  log: (message: string) => void;
}
const logger: Logger = (message: string) => {
  console.log(message);
}
logger.log = (message: string) => {
  console.log(message);
}

This is required by the Loggerinterface. Values bound to the Loggerinterface must also have a logproperty that is a function accepting a single string parameter and that returns void.
If you did not include the log property, the TypeScript Compiler would give you error 2741:

Output
Property 'log' is missing in type '(message: string) => void' but required in type 'Logger'. (2741)

The TypeScript Compiler would emit a similar error if the log property in the logger variable had an incompatible type signature, like setting it to true:

interface Logger {
  (message: string): void;
  log: (message: string) => void;
}
const logger: Logger = (message: string) => {
  console.log(message);
}
logger.log = true;

In this case, the TypeScript Compiler would show error 2322:

Output
Type 'boolean' is not assignable to type '(message: string) => void'. (2322)

A nice feature of setting variables to have a specific type, in this case setting the logger variable to have the type of the Logger interface, is that TypeScript can now infer the type of the parameters of both the logger function and the function in the log property.

You can check that by removing the type information from the argument of both functions. Notice that in the highlighted code below, the message parameters do not have a type:

interface Logger {
  (message: string): void;
  log: (message: string) => void;
}
const logger: Logger = (message) => {
  console.log(message);
}
logger.log = (message) => {
  console.log(message);
}

And in both cases, your editor should still be able to show that the type of the parameter is a string, as this is the type expected by the Loggerinterface.

Interfaces with Index Signatures
You can add an index signature to your interface, just like you can with normal types, thus allowing the interface to have an unlimited number of properties.
For example, if you wanted to create a DataRecordinterface that has an unlimited number of string fields, you could use the following highlighted index signature:

interface DataRecord {

}

You can then use the DataRecordinterface to set the type of any object that has multiple parameters of type string:

interface DataRecord {

}
const data: DataRecord = {
  fieldA: "valueA",
  fieldB: "valueB",
  fieldC: "valueC",
  // ...
};

In this section, you created interfaces using different features available in TypeScript and learned how to use the interfaces you created. In the next section, you’ll learn more about the differences between type and interface declarations, and gain practice with declaration merging and module augmentation.

Differences Between Types and Interfaces

So far, you have seen that the interface declaration and the type declaration are similar, having almost the same set of features.
For example, you created a Logger interface that extended from a

Clearable interface:
interface Clearable {
  clear: () => void;
}
interface Logger extends Clearable {
  log: (message: string) => void;
}

The same type representation can be replicated by using two type declarations:

type Clearable = {
  clear: () => void;
}
type Logger = Clearable & {
  log: (message: string) => void;
}

As shown in the previous sections, the interface declaration can be used to represent a variety of objects, from functions to complex objects with an unlimited number of properties. This is also possible with type declarations, even extending from other types, as you can intersect multiple types together using the intersection operator &.
Since type declarations and interface declarations are so similar, you’ll need to consider the specific features unique to each one and be consistent in your codebase. Pick one to create type representations in your codebase, and only use the other one when you need a specific feature only available to it.
For example, the type declaration has a few features that the interface declaration lacks, such as:

Union types.
Mapped types.
Alias to primitive types. One of the features available only for the interface declaration is declaration merging, which you will learn about in the next section. It is important to note that declaration merging may be useful if you are writing a library and want to give the library users the power to extend the types provided by the library, as this is not possible with type declarations.

Declaration Merging
TypeScript can merge multiple declarations into a single one, enabling you to write multiple declarations for the same data structure and having them bundled together by the TypeScript Compiler during compilation as if they were a single type. In this section, you will see how this works and why it is helpful when using interfaces.
Interfaces in TypeScript can be re-opened; that is, multiple declarations of the same interface can be merged. This is useful when you want to add new fields to an existing interface.
For example, imagine that you have an interface named DatabaseOptionslike the following one:


interface DatabaseOptions {
  host: string;
  port: number;
  user: string;
  password: string;
}

This interface is going to be used to pass options when connecting to a database.
Later in the code, you declare an interface with the same name but with a single string field called dsnUrl, like this one:

interface DatabaseOptions {
  dsnUrl: string;
}

When the TypeScript Compiler starts reading your code, it will merge all declarations of the DatabaseOptionsinterface into a single one. From the TypeScript Compiler point of view, DatabaseOptionsis now:

interface DatabaseOptions {
  host: string;
  port: number;
  user: string;
  password: string;
  dsnUrl: string;
}

The interface includes all the fields you initially declared, plus the new field dsnUrlthat you declared separately. Both declarations have been merged.

Module Augmentation
Declaration merging is helpful when you need to augment existing modules with new properties. One use-case for that is when you are adding more fields to a data structure provided by a library. This is relatively common with the Node.js library called express, which allows you to create HTTP servers.
When working with express, a Request and a Response object are passed to your request handlers (functions responsible for providing a response to a HTTP request). The Request object is commonly used to store data specific to a particular request. For example, you could use it to store the logged user that made the initial HTTP request:

const myRoute = (req: Request, res: Response) => {
  res.json({ user: req.user });
}

Here, the request handler sends back to the client a jsonwith the user field set to the logged user. The logged user is added to the request object in another place in the code, using an express middleware responsible for user authentication.
The type definitions for the Requestinterface itself does not have a userfield, so the above code would give the type error 2339:

Property 'user' does not exist on type 'Request'. (2339)

Reference :

Hoisting

Famini-ProDev — Sat, 23 Apr 2022 11:05:25 +0000

By now, you should be fairly comfortable with the idea of scope, and how variables are attached to different levels of scope depending on where and how they are declared. Both function scope and block scope behave by the same rules in this regard: any variable declared within a scope is attached to that scope.
But there’s a subtle detail of how scope attachment works with declarations that appear in various locations within a scope, and that detail is what we will examine here

Chicken or the Egg?
There’s a temptation to think that all of the code you see in a JavaScript program is interpreted line-by-line, top-down in order, as the program executes. While that is substantially true, there’s one part of that assumption that can lead to incorrect thinking about your program.
Consider this code:

a = 2;

var a;

console.log( a );

What do you expect to be printed in the console.log(..) statement?
Many developers would expect undefined, since the vara statement comes after the a = 2, and it would seem natural to assume that the variable is redefined, and thus assigned the default undefined. However, the output will be 2.
Consider another piece of code:

console.log( a );
var a = 2;

You might be tempted to assume that, since the previous snippet exhibited some less-than-top-down looking behavior, perhaps in this snippet, 2will also be printed. Others may think that since the a variable is used before it is declared, this must result in a ReferenceErrorbeing thrown.
Unfortunately, both guesses are incorrect. undefined is the output.
The Compiler Strikes Again
the best way to think about things is that all declarations, both variables and functions, are processed first, before any part of your code is executed.
When you see var a = 2;, you probably think of that as one statement. But JavaScript actually thinks of it as two statements: var a; and a = 2;. The first statement, the declaration, is processed during the compilation phase. The second statement, the assignment, is left in place for the execution phase.
Our first snippet then should be thought of as being handled like this:

var a;
a = 2;
console.log( a );

…where the first part is the compilation and the second part is the execution.
Similarly, our second snippet is actually processed as:

var a;
console.log( a );
a = 2;

So, one way of thinking, sort of metaphorically, about this process, is that variable and function declarations are “moved” from where they appear in the flow of the code to the top of the code. This gives rise to the name hoisting.
In other words, the egg (declaration) comes before the chicken (assignment).

NOTE

Only the declarations themselves are hoisted, while any assignments or other executable logic are left in place. If hoisting were to re-arrange the executable logic of our code, that could wreak havoc.

foo();
function foo() {
    console.log( a ); // undefined
    var a = 2;
}

The function foo’s declaration (which in this case includes the implied value of it as an actual function) is hoisted, such that the call on the first line is able to execute.
It’s also important to note that hoisting is per-scope. So while our previous snippets were simplified in that they only included global scope, the foo(..) function we are now examining itself exhibits that vara is hoisted to the top of foo(..) (not, obviously, to the top of the program). So the program can perhaps be more accurately interpreted like this:

function foo() {
    var a;
    console.log( a ); // undefined
    a = 2;
}
foo();

Function declarations are hoisted, as we just saw. But function expressions are not.

foo(); // not ReferenceError, but TypeError!
var foo = function bar() {
    // ...
};

The variable identifier foo is hoisted and attached to the enclosing scope (global) of this program, so foo() doesn’t fail as a ReferenceError. But foo has no value yet (as it would if it had been a true function declaration instead of expression). So, foo() is attempting to invoke the undefined value, which is a TypeErrorillegal operation.
Also recall that even though it’s a named function expression, the name identifier is not available in the enclosing scope:

foo(); // TypeError
bar(); // ReferenceError
var foo = function bar() {
    // ...
};

This snippet is more accurately interpreted (with hoisting) as:

var foo;
foo(); // TypeError
bar(); // ReferenceError
foo = function() {
    var bar = ...self...
    // ...
}

Functions First

Both function declarations and variable declarations are hoisted. But a subtle detail (that can show up in code with multiple “duplicate” declarations) is that functions are hoisted first, and then variables.
Consider:

foo(); // 1
var foo;
function foo() {
    console.log( 1 );
}
foo = function() {
    console.log( 2 );
};

1is printed instead of 2! This snippet is interpreted by the Engine as:

function foo() {
    console.log( 1 );
}
foo(); // 1
foo = function() {
    console.log( 2 );
};

Notice that varfoo was the duplicate (and thus ignored) declaration, even though it came before the function foo()… declaration, because function declarations are hoisted before normal variables.
While multiple/duplicate vardeclarations are effectively ignored, subsequent function declarations do override previous ones.

foo(); // 3
function foo() {
    console.log( 1 );
}
var foo = function() {
    console.log( 2 );
};
function foo() {
    console.log( 3 );
}

While this all may sound like nothing more than interesting academic trivia, it highlights the fact that duplicate definitions in the same scope are a really bad idea and will often lead to confusing results.
Function declarations that appear inside of normal blocks typically hoist to the enclosing scope, rather than being conditional as this code implies:

foo(); // "b"
var a = true;
if (a) {
   function foo() { console.log("a"); }
}
else {
   function foo() { console.log("b"); }
}

However, it’s important to note that this behavior is not reliable and is subject to change in future versions of JavaScript, so it’s probably best to avoid declaring functions in blocks.

Review

We can be tempted to look at var a = 2; as one statement, but the JavaScript engine does not see it that way. It sees vara and a = 2 as two separate statements, the first one a compiler-phase task, and the second one an execution-phase task.
What this leads to is that all declarations in a scope, regardless of where they appear, are processed first before the code itself is executed. You can visualize this as declarations (variables and functions) being “moved” to the top of their respective scopes, which we call hoisting.
Declarations themselves are hoisted, but assignments, even assignments of function expressions, are not hoisted.
Be careful about duplicate declarations, especially mixed between normal vardeclarations and function declarations—peril awaits if you do!

Reference
You Don’t Know JS: Kyle Simpson Quotes

Closure in javaScript

Famini-ProDev — Sat, 23 Apr 2022 10:48:59 +0000

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

Lexical Scoping
Consider the following example code:

function init() {
  var name = 'Mozilla'; // name is a local variable created by init
  function displayName() { // displayName() is the inner function, a closure
    alert(name); // use variable declared in the parent function
  }
  displayName();
}
init();

init() creates a local variable called name and a function called displayName(). The displayName() function is an inner function that is defined inside init() and is available only within the body of the init() function. Note that the displayName() function has no local variables of its own. However, since inner functions have access to the variables of outer functions, displayName() can access the variable name declared in the parent function, init().
Run the code using this JSFiddle link and notice that the alert() statement within the displayName() function successfully displays the value of the name variable, which is declared in its parent function. This is an example of lexical scoping, which describes how a parser resolves variable names when functions are nested. The word lexical refers to the fact that lexical scoping uses the location where a variable is declared within the source code to determine where that variable is available. Nested functions have access to variables declared in their outer scope.

Closure

Consider the following code example:

function makeFunc() {
  var name = 'Mozilla';
  function displayName() {
    alert(name);
  }
  return displayName;
}
var myFunc = makeFunc();
myFunc();

Running this code has exactly the same effect as the previous example of the init() function above. What's different (and interesting) is that the displayName() inner function is returned from the outer function before being executed.
At first glance, it might seem unintuitive that this code still works. In some programming languages, the local variables within a function exist for just the duration of that function’s execution. Once makeFunc() finishes executing, you might expect that the name variable would no longer be accessible. However, because the code still works as expected, this is obviously not the case in JavaScript.
The reason is that functions in JavaScript form closures. A closure is the combination of a function and the lexical environment within which that function was declared. This environment consists of any local variables that were in-scope at the time the closure was created. In this case, myFuncis a reference to the instance of the function displayNamethat is created when makeFuncis run. The instance of displayNamemaintains a reference to its lexical environment, within which the variable name exists. For this reason, when myFuncis invoked, the variable name remains available for use, and "Mozilla" is passed to alert.

Here’s a slightly more interesting example — a makeAdderfunction:

function makeAdder(x) {
  return function(y) {
    return x + y;
  };
}
var add5 = makeAdder(5);
var add10 = makeAdder(10);
console.log(add5(2));  // 7
console.log(add10(2)); // 12

In this example, we have defined a function makeAdder(x), that takes a single argument x, and returns a new function. The function it returns takes a single argument y, and returns the sum of xand y.
In essence, makeAdderis a function factory. It creates functions that can add a specific value to their argument. In the above example, the function factory creates two new functions—one that adds five to its argument, and one that adds 10.
add5 and add10 are both closures. They share the same function body definition, but store different lexical environments. In add5's lexical environment, xis 5, while in the lexical environment for add10, xis 10.

Partical Closures

Closures are useful because they let you associate data (the lexical environment) with a function that operates on that data. This has obvious parallels to object-oriented programming, where objects allow you to associate data (the object’s properties) with one or more methods.
Consequently, you can use a closure anywhere that you might normally use an object with only a single method.
Situations where you might want to do this are particularly common on the web. Much of the code written in front-end JavaScript is event-based. You define some behavior, and then attach it to an event that is triggered by the user (such as a click or a keypress). The code is attached as a callback (a single function that is executed in response to the event).
For instance, suppose we want to add buttons to a page to adjust the text size. One way of doing this is to specify the font-size of the body element (in pixels), and then set the size of the other elements on the page (such as headers) using the relative emunit:

body {
  font-family: Helvetica, Arial, sans-serif;
  font-size: 12px;
}
h1 {
  font-size: 1.5em;
}
h2 {
  font-size: 1.2em;
}

Such interactive text size buttons can change the font-size property of the bodyelement, and the adjustments are picked up by other elements on the page thanks to the relative units.
Here’s the JavaScript:

function makeSizer(size) {
  return function() {
    document.body.style.fontSize = size + 'px';
  };
}
var size12 = makeSizer(12);
var size14 = makeSizer(14);
var size16 = makeSizer(16);

size12, size14, and size16are now functions that resize the body text to 12, 14, and 16 pixels, respectively. You can attach them to buttons (in this case hyperlinks) as demonstrated in the following code example.

document.getElementById('size-12').onclick = size12;
document.getElementById('size-14').onclick = size14;
document.getElementById('size-16').onclick = size16;
<a href="#" id="size-12">12</a>
<a href="#" id="size-14">14</a>
<a href="#" id="size-16">16</a>

Emulating private methods with closures

Languages such as Java allow you to declare methods as private, meaning that they can be called only by other methods in the same class.
JavaScript previously didn’t have a native way of declaring private methods, but it was possible to emulate private methods using closures. Private methods aren’t just useful for restricting access to code. They also provide a powerful way of managing your global namespace.
The following code illustrates how to use closures to define public functions that can access private functions and variables. Note that these closures follow the Module Design Pattern.

var counter = (function() {
  var privateCounter = 0;
  function changeBy(val) {
    privateCounter += val;
  }
  return {
    increment: function() {
      changeBy(1);
    },
    decrement: function() {
      changeBy(-1);
    },
    value: function() {
      return privateCounter;
    }
  };
})();
console.log(counter.value());  // 0.
counter.increment();
counter.increment();
console.log(counter.value());  // 2.
counter.decrement();
console.log(counter.value());  // 1.

In previous examples, each closure had its own lexical environment. Here though, there is a single lexical environment that is shared by the three functions: counter.increment, counter.decrement, and counter.value.
The shared lexical environment is created in the body of an anonymous function, which is executed as soon as it has been defined (also known as an IIFE). The lexical environment contains two private items: a variable called privateCounter, and a function called changeBy. You can't access either of these private members from outside the anonymous function. Instead, you can access them using the three public functions that are returned from the anonymous wrapper.
Those three public functions are closures that share the same lexical environment. Thanks to JavaScript’s lexical scoping, they each have access to the privateCountervariable and the changeByfunction.

var makeCounter = function() {
  var privateCounter = 0;
  function changeBy(val) {
    privateCounter += val;
  }
  return {
    increment: function() {
      changeBy(1);
    },
    decrement: function() {
      changeBy(-1);
    },
    value: function() {
      return privateCounter;
    }
  }
};
var counter1 = makeCounter();
var counter2 = makeCounter();
alert(counter1.value());  // 0.
counter1.increment();
counter1.increment();
alert(counter1.value()); // 2.
counter1.decrement();
alert(counter1.value()); // 1.
alert(counter2.value()); // 0.

Notice how the two counters maintain their independence from one another. Each closure references a different version of the privateCountervariable through its own closure. Each time one of the counters is called, its lexical environment changes by changing the value of this variable. Changes to the variable value in one closure don't affect the value in the other closure.

Note: Using closures in this way provides benefits that are normally associated with object-oriented programming. In particular, data hiding and encapsulation.

Closure Scope Chain
Every closure has three scopes:

Local Scope (Own scope)
Outer Functions Scope
Global Scope

A common mistake is not realizing that in the case where the outer function is itself a nested function, access to the outer function’s scope includes the enclosing scope of the outer function — effectively creating a chain of function scopes. To demonstrate, consider the following example code.

// global scope
var e = 10;
function sum(a){
  return function(b){
    return function(c){
      // outer functions scope
      return function(d){
        // local scope
        return a + b + c + d + e;
      }
    }
  }
}
console.log(sum(1)(2)(3)(4)); // log 20
// You can also write without anonymous functions:
// global scope
var e = 10;
function sum(a){
  return function sum2(b){
    return function sum3(c){
      // outer functions scope
      return function sum4(d){
        // local scope
        return a + b + c + d + e;
      }
    }
  }
}
var sum2 = sum(1);
var sum3 = sum2(2);
var sum4 = sum3(3);
var result = sum4(4);
console.log(result) //log 20

In the example above, there’s a series of nested functions, all of which have access to the outer functions’ scope. In this context, we can say that closures have access to all outer function scopes.

Creating Closures in loops : A Common mistake

Prior to the introduction of the letkeyword in ECMAScript 2015, a common problem with closures occurred when you created them inside a loop. To demonstrate, consider the following example code.

<p id="help">Helpful notes will appear here</p>
<p>E-mail: <input type="text" id="email" name="email"></p>
<p>Name: <input type="text" id="name" name="name"></p>
<p>Age: <input type="text" id="age" name="age"></p>
function showHelp(help) {
  document.getElementById('help').textContent = help;
}
function setupHelp() {
  var helpText = [
      {'id': 'email', 'help': 'Your e-mail address'},
      {'id': 'name', 'help': 'Your full name'},
      {'id': 'age', 'help': 'Your age (you must be over 16)'}
    ];
  for (var i = 0; i < helpText.length; i++) {
    var item = helpText[i];
    document.getElementById(item.id).onfocus = function() {
      showHelp(item.help);
    }
  }
}
setupHelp();

Try running the code in JSFiddle.
The helpText array defines three helpful hints, each associated with the ID of an input field in the document. The loop cycles through these definitions, hooking up an onfocus event to each one that shows the associated help method.
If you try this code out, you’ll see that it doesn’t work as expected. No matter what field you focus on, the message about your age will be displayed.
The reason for this is that the functions assigned to onfocus are closures; they consist of the function definition and the captured environment from the setupHelp function's scope. Three closures have been created by the loop, but each one shares the same single lexical environment, which has a variable with changing values (item). This is because the variable item is declared with var and thus has function scope due to hoisting. The value of item.help is determined when the onfocus callbacks are executed. Because the loop has already run its course by that time, the item variable object (shared by all three closures) has been left pointing to the last entry in the helpText list.
One solution in this case is to use more closures: in particular, to use a function factory as described earlier:

function showHelp(help) {
  document.getElementById('help').textContent = help;
}
function makeHelpCallback(help) {
  return function() {
    showHelp(help);
  };
}
function setupHelp() {
  var helpText = [
      {'id': 'email', 'help': 'Your e-mail address'},
      {'id': 'name', 'help': 'Your full name'},
      {'id': 'age', 'help': 'Your age (you must be over 16)'}
    ];
  for (var i = 0; i < helpText.length; i++) {
    var item = helpText[i];
    document.getElementById(item.id).onfocus = makeHelpCallback(item.help);
  }
}
setupHelp();

This works as expected. Rather than the callbacks all sharing a single lexical environment, the makeHelpCallbackfunction creates a new lexical environment for each callback, in which helprefers to the corresponding string from the helpTextarray.
One other way to write the above using anonymous closures is:

function showHelp(help) {
  document.getElementById('help').textContent = help;
}
function setupHelp() {
  var helpText = [
      {'id': 'email', 'help': 'Your e-mail address'},
      {'id': 'name', 'help': 'Your full name'},
      {'id': 'age', 'help': 'Your age (you must be over 16)'}
    ];
  for (var i = 0; i < helpText.length; i++) {
    (function() {
       var item = helpText[i];
       document.getElementById(item.id).onfocus = function() {
         showHelp(item.help);
       }
    })(); // Immediate event listener attachment with the current value of item (preserved until iteration).
  }
}
setupHelp();

If you don’t want to use more closures, you can use the letkeyword introduced in ES2015 :

function showHelp(help) {
  document.getElementById('help').textContent = help;
}
function setupHelp() {
  var helpText = [
      {'id': 'email', 'help': 'Your e-mail address'},
      {'id': 'name', 'help': 'Your full name'},
      {'id': 'age', 'help': 'Your age (you must be over 16)'}
    ];
  for (let i = 0; i < helpText.length; i++) {
    let item = helpText[i];
    document.getElementById(item.id).onfocus = function() {
      showHelp(item.help);
    }
  }
}
setupHelp();

This example uses let instead of var, so every closure binds the block-scoped variable, meaning that no additional closures are required.
Another alternative could be to use forEach() to iterate over the helpTextarray and attach a listener to each <input>, as shown:

function showHelp(help) {
  document.getElementById('help').textContent = help;
}
function setupHelp() {
  var helpText = [
      {'id': 'email', 'help': 'Your e-mail address'},
      {'id': 'name', 'help': 'Your full name'},
      {'id': 'age', 'help': 'Your age (you must be over 16)'}
    ];
  helpText.forEach(function(text) {
    document.getElementById(text.id).onfocus = function() {
      showHelp(text.help);
    }
  });
}
setupHelp();

Performance Considerations

It is unwise to unnecessarily create functions within other functions if closures are not needed for a particular task, as it will negatively affect script performance both in terms of processing speed and memory consumption.
For instance, when creating a new object/class, methods should normally be associated to the object’s prototype rather than defined into the object constructor. The reason is that whenever the constructor is called, the methods would get reassigned (that is, for every object creation).
Consider the following case:

function MyObject(name, message) {
  this.name = name.toString();
  this.message = message.toString();
  this.getName = function() {
    return this.name;
  };
  this.getMessage = function() {
    return this.message;
  };
}

Because the previous code does not take advantage of the benefits of using closures in this particular instance, we could instead rewrite it to avoid using closures as follows:

function MyObject(name, message) {
  this.name = name.toString();
  this.message = message.toString();
}
MyObject.prototype = {
  getName: function() {
    return this.name;
  },
  getMessage: function() {
    return this.message;
  }
};

However, redefining the prototype is not recommended. The following example instead appends to the existing prototype:

function MyObject(name, message) {
  this.name = name.toString();
  this.message = message.toString();
}
MyObject.prototype.getName = function() {
  return this.name;
};
MyObject.prototype.getMessage = function() {
  return this.message;
};

Refrences :

Async Nature Of setState() (React js)

Famini-ProDev — Fri, 22 Apr 2022 15:04:31 +0000

Gist:
React batches updates and flushes it out once per frame (perf optimization) However, in some cases React has no control over batching, hence updates are made synchronously eg. eventListeners, Ajax, setTimeout and similar Web APIs
Main Idea
setState() does not immediately mutate this.state but creates a pending state transition. Accessing this.state after calling this method can potentially return the existing value. There is no guarantee of synchronous operation of calls to setState and calls may be batched for performance gains.
Run the below code and you will make the following observations:
You can see that in every situation (addEventListener, setTimeout or AJAX call) the state before and the state after are different. And that render was called immediately after triggering the setState method. But why is that? Well, it turns out React does not understand and thus cannot control code that doesn’t live inside the library. Timeouts or AJAX calls for example, are developer authored code that executes outside of the context of React.
So why does React synchronously update the state in these cases? Well, because it’s trying to be as defensive as possible. Not being in control means it’s not able to do any performance optimisations so it’s better to update the state on spot and make sure the code that follows has access to the latest information available.

class TestComponent extends React.Component {
  constructor(...args) {
    super(...args);
    this.state = {
      dollars: 10
    };
    this._saveButtonRef = (btn => { this._btnRef = btn });
    [
      '_onTimeoutHandler',
      '_onMouseLeaveHandler',
      '_onClickHandler',
      '_onAjaxCallback',
    ].forEach(propToBind => {
      this[propToBind] = this[propToBind].bind(this);
    });
  }

  componentDidMount() {
    // Add custom event via `addEventListener`
    //
    // The list of supported React events does include `mouseleave`
    // via `onMouseLeave` prop
    //
    // However, we are not adding the event the `React way` - this will have
    // effects on how state mutates
    //
    // Check the list here - https://reactjs.org/docs/events.html
    this._btnRef.addEventListener('mouseleave', this._onMouseLeaveHandler);

    // Add JS timeout
    //
    // Again,outside React `world` - this will also have effects on how state
    // mutates
    setTimeout(this._onTimeoutHandler, 10000);

    // Make AJAX request
    fetch('https://api.github.com/users')
      .then(this._onAjaxCallback);
  }

  render() {
    console.log('State in render: ' + JSON.stringify(this.state));

    return (
       <button
         ref={this._saveButtonRef}
         onClick={this._onClickHandler}>
         'Click me'
      </button>
    );
  }

  _onClickHandler() {
    console.log('State before (_onClickHandler): ' + JSON.stringify(this.state));
    this.setState({
      dollars: this.state.dollars + 10
    });
    console.log('State after (_onClickHandler): ' + JSON.stringify(this.state));
  }

  _onMouseLeaveHandler() {
    console.log('State before (mouseleave): ' + JSON.stringify(this.state));
    this.setState({
      dollars: this.state.dollars + 20
    });
    console.log('State after (mouseleave): ' + JSON.stringify(this.state));
  }

  _onTimeoutHandler() {
    console.log('State before (timeout): ' + JSON.stringify(this.state));
    this.setState({
      dollars: this.state.dollars + 30
    });
    console.log('State after (timeout): ' + JSON.stringify(this.state));
  }

  _onAjaxCallback(response) {
    if (response.status !== 200) {
      console.log('Error in AJAX call: ' + response.statusText);
      return;
    }
    console.log('State before (AJAX call): ' + JSON.stringify(this.state));
    this.setState({
      dollars: this.state.dollars + 40
    });
    console.log('State after (AJAX call): ' + JSON.stringify(this.state));
  }
};

// Render to DOM
ReactDOM.render(
  <TestComponent />,
  document.getElementById('app')
);

Possible solution?

We’re used to calling setState with one parameter only, but actually, the method’s signature support two. The second argument that you can pass in is a callback function that will always be executed after the state has been updated (whether it’s inside React’s known context or outside of it).

An example might be:

_onClickHandler: function _onClickHandler() {
   console.log('State before (_onClickHandler): ' + JSON.stringify(this.state));
   this.setState({
   dollars: this.state.dollars + 10
   }, () => {
   console.log('Here state will always be updated to latest version!');
   console.log('State after (_onClickHandler): ' + JSON.stringify(this.state));
   });
}

A note on the async nature of setstate

To be politically correct, setState, as a method, is always synchronous. It's just a function that calls something behind the scenes - enqueueState or enqueueCallback on updater.
In fact, here's setState taken directly from React source code:

ReactComponent.prototype.setState = function(partialState, callback) {
  invariant(
    typeof partialState === 'object' ||
    typeof partialState === 'function' ||
    partialState == null,
    'setState(...): takes an object of state variables to update or a ' +
    'function which returns an object of state variables.'
  );
  this.updater.enqueueSetState(this, partialState);
  if (callback) {
    this.updater.enqueueCallback(this, callback, 'setState');
  }
};

What's actually sync or async are the effects of calling setState in a React application - the reconciliation algorithm, doing the VDOM comparisons and calling render to update the real DOM.

Reference :
React-bits :Design Patterns and Techniques

Component Lifecycle's

Famini-ProDev — Fri, 22 Apr 2022 14:51:59 +0000

React components live certain life events that are called lifecycle events. These lifecycle's events are tied to lifecycle methods. I discussed several of these methods at the start of this chapter when discusses the creation of components.
The lifecycle methods provide hooks into the phases and the nature of a component. In the code example, taken from section 6.2, I am console logging the occurrence of the lifecycle events componentDidMount, componentWillUnmount, and getInitialStatelifecycle methods.

var Timer = React.createClass({
    getInitialState: function() { 
        console.log('getInitialState lifecycle method ran!');
        return {secondsElapsed: Number(this.props.startTime) || 0};
    },
    tick: function() {
        console.log(ReactDOM.findDOMNode(this));
        if(this.state.secondsElapsed === 65){
            ReactDOM.unmountComponentAtNode(ReactDOM.findDOMNode(this).parentNode);
            return;
        }
        this.setState({secondsElapsed: this.state.secondsElapsed + 1});
    },
    componentDidMount: function() {
        console.log('componentDidMount lifecycle method ran!');
        this.interval = setInterval(this.tick, 1000);
    },
    componentWillUnmount: function() {
        console.log('componentWillUnmount lifecycle method ran!');
        clearInterval(this.interval);
    },
    render: function() {
        return (<div>Seconds Elapsed: {this.state.secondsElapsed}</div>);
    }
});

ReactDOM.render(< Timer startTime = "60" / >, app);

The methods can be divided into three categories (Mounting, Updating, and Unmounting phases).
Below I show a table for each category and the containing lifecycle methods.

Mounting Phase (happens once in a components life):

The first phase of the React Component life cycle is the Birth/Mounting phase. This is where we start initialization of the Component. At this phase, the Component's props and state are defined and configured. The Component and all its children are mounted on to the Native UI Stack (DOM, UIView, etc.). Finally, we can do post-processing if required. The Birth/Mounting phase only occurs once.

Updating Phase (happens over and over in a components life):

The next phase of the life cycle is the Growth/Update phase. In this phase, we get new props, change state, handle user interactions and communicate with the component hierarchy. This is where we spend most of our time in the Component's life. Unlike Birth or Death, we repeat this phase over and over.

*Unmounting Phase (happens once in a components life): *

The final phase of the life cycle is the Death/Unmount phase. This phase occurs when a component instance is unmounted from the Native UI. This can occur when the user navigates away, the UI page changes, a component is hidden (like a drawer), etc. Death occurs once and readies the Component for Garbage Collection.

Reference :
How to React EnlightenmentTypeScript

Use axios with React

Famini-ProDev — Fri, 22 Apr 2022 14:39:03 +0000

Many projects on the web need to interface with a REST API at some stage in their development. Axios is a lightweight HTTP client based on the $http service within Angular.js v1.x and is similar to the native JavaScript Fetch API.
Axios is promise-based, which gives you the ability to take advantage of JavaScript’s asyncand awaitfor more readable asynchronous code.
You can also intercept and cancel requests, and there’s built-in client-side protection against cross-site request forgery.
In this article, you will see examples of how to use Axios to access the popular JSON Placeholder API within a React application.

Step 1 — Adding Axios to the Project
In this section, you will add Axios to a React project

$ npx create-react-app react-axios-example

To add Axios to the project, open your terminal and change directories into your project:

$ cd react-axios-example

Then run this command to install Axios:

$ npm install axios@0.24.0

Next, you will need to import Axios into the file you want to use it in.

Step 2 — Making a GETRequest

In this example, you create a new component and import Axios into it to send a GETrequest.
Inside your React project, you will need to create a new component named PersonList.
First, create a new componentssubdirectory in the srcdirectory:

$ mkdir src/components

In this directory, create PersonList.js and add the following code to the component:
src/components/PersonList.js:

import React from 'react';
import axios from 'axios';

export default class PersonList extends React.Component {
  state = {
    persons: []
  }

  componentDidMount() {
    axios.get(`https://jsonplaceholder.typicode.com/users`)
      .then(res => {
        const persons = res.data;
        this.setState({ persons });
      })
  }

  render() {
    return (
      <ul>
        {
          this.state.persons
            .map(person =>
              <li key={person.id}>{person.name}</li>
            )
        }
      </ul>
    )
  }
}

First, you import React and Axios so that both can be used in the component. Then you hook into the componentDidMountlifecycle hook and perform a GETrequest.

You use axios.get(url) with a URL from an API endpoint to get a promise which returns a response object. Inside the response object, there is data that is then assigned the value of person.

You can also get other information about the request, such as the status code under res.status or more information inside of res.request.
Add this component to your app.js:

import PersonList from './components/PersonList.js';

function App() {
  return (
    <div ClassName="App">
      <PersonList/>
    </div>
  )
}

Then run your application:

$ npm start

View the application in the browser. You will be presented with a list of 10 names.

Step 3 — Making a POSTRequest

In this step, you will use Axios with another HTTP request method called POST.
Inside your React project, you will need to create a new component named PersonAdd.
Create PersonAdd.js and add the following code to create a form that allows for user input and subsequently POSTsthe content to an API:

src/components/PersonAdd.js:

import axios from 'axios';

export default class PersonAdd extends React.Component {
  state = {
    name: ''
  }

  handleChange = event => {
    this.setState({ name: event.target.value });
  }

  handleSubmit = event => {
    event.preventDefault();

    const user = {
      name: this.state.name
    };

    axios.post(`https://jsonplaceholder.typicode.com/users`, { user })
      .then(res => {
        console.log(res);
        console.log(res.data);
      })
  }

  render() {
    return (
      <div>
        <form onSubmit={this.handleSubmit}>
          <label>
            Person Name:
            <input type="text" name="name" onChange={this.handleChange} />
          </label>
          <button type="submit">Add</button>
        </form>
      </div>
    )
  }
}

Inside the handleSubmitfunction, you prevent the default action of the form. Then update the stateto the userinput.
Using POSTgives you the same response object with information that you can use inside of a thencall.
To complete the POSTrequest, you first capture the userinput. Then you add the input along with the POSTrequest, which will give you a response. You can then console.log the response, which should show the user input in the form.
Add this component to your app.js:

src/app.js:

import PersonList from './components/PersonList';
import PersonAdd from './components/PersonAdd';

function App() {
  return (
    <div ClassName="App">
      <PersonAdd/>
      <PersonList/>
    </div>
  )
}

Then run your application:

$ npm start

View the application in the browser. You will be presented with a form for submitting new users. Check the console after submitting a new user.

Step 4 — Making a DELETERequest

In this example, you will see how to delete items from an API using axios.delete and passing a URL as a parameter.
Inside your React project, you will need to create a new component named PersonRemove.
Create PersonRemove.js and add the following code to delete a user:
src/PersonRemove.js :

import React from 'react';
import axios from 'axios';

export default class PersonRemove extends React.Component {
  state = {
    id: ''
  }

  handleChange = event => {
    this.setState({ id: event.target.value });
  }

  handleSubmit = event => {
    event.preventDefault();

    axios.delete(`https://jsonplaceholder.typicode.com/users/${this.state.id}`)
      .then(res => {
        console.log(res);
        console.log(res.data);
      })
  }

  render() {
    return (
      <div>
        <form onSubmit={this.handleSubmit}>
          <label>
            Person ID:
            <input type="number" name="id" onChange={this.handleChange} />
          </label>
          <button type="submit">Delete</button>
        </form>
      </div>
    )
  }
}

Again, the res object provides you with information about the request. You can then console.log that information again after the form is submitted.
Add this component to your app.js:

import PersonList from './components/PersonList';
import PersonAdd from './components/PersonAdd';
import PersonRemove from './components/PersonRemove';

function App() {
  return (
    <div ClassName="App">
      <PersonAdd/>
      <PersonList/>
      <PersonRemove/>
    </div>
  )
}

Then run your application:

$ npm start

View the application in the browser. You will be presented with a form for removing users.

Step 5 — Using a Base Instance in Axios

In this example, you will see how you can set up a base instance in which you can define a URL and any other configuration elements.
Create a separate file named api.js:

$ nano src/api.js

Export a new axiosinstance with these defaults:
src/api.js :

import axios from 'axios';

export default axios.create({
  baseURL: `http://jsonplaceholder.typicode.com/`
});

Once the default instance is set up, it can then be used inside of the PersonRemovecomponent. You import the new instance like this:
src/components/PersonRemove.js :

import React from 'react';

import API from '../api';

export default class PersonRemove extends React.Component {
  // ...

  handleSubmit = event => {
    event.preventDefault();

    API.delete(`users/${this.state.id}`)
      .then(res => {
        console.log(res);
        console.log(res.data);
      })
  }

  // ...
}

Because http://jsonplaceholder.typicode.com/ is now the base URL, you no longer need to type out the whole URL each time you want to hit a different endpoint on the API.

Step 6 — Using asyncand await

In this example, you will see how you can use asyncand awaitto work with promises.
The awaitkeyword resolves the promiseand returns the value. The valuecan then be assigned to a variable.

src/components/PersonRemove.js :

import React from 'react';

import API from '../api';

export default class PersonRemove extends React.Component {
  // ...

  handleSubmit = event => {
    event.preventDefault();

    const response = await API.delete(`users/${this.state.id}`);

    console.log(response);
    console.log(response.data);
  }

  // ...
}

*Refrences : *

7 JavaScript Design Patterns Every developer should knows.

Famini-ProDev — Fri, 22 Apr 2022 13:59:10 +0000

Design patterns help combine experiences of many developers to structure the codes in an optimized manner that meet the problems we are seeking solutions to, and gives common vocabulary used to describe solutions to our problems than describing the syntax and semantics of our code.
JavaScript design patterns assist developers to write organized, beautiful and well-structured codes. Although design patterns, when used can easily be re-used, they can never supplement developers, rather they only support them by preventing minor issues that could lead to major problems on the web application development by providing generalized solutions that are not tied to a specific problem.
They decrease the overall codebase by doing away with unnecessary repetitions, thus makes our code more robust than the ad-hoc solutions.
In this article, I will explore seven best and most popular JavaScript design patterns, which of course most of them will fall under three categories namely; creation design patterns, structural design patterns, and behavioral design patterns. A pattern is something like the following image; just to acquaint you into the context.

1. Constructor Design Pattern.

This is a special method that is used to initialize the newly created objects once a memory is allocated. Since JavaScript is typically object-oriented, it deals with objects most, therefore I intend to delve in to object constructors. There are three ways to create new objects in JavaScript:
The following is one way to create a constructor design pattern.

// This creates a new empty Object
var newObject = {};
// This creates a new empty Object
var newObject = Object.create(Object.prototype);
var newObject = newObject();

To access the properties of a function, you need to initialize the object.

const object = new ConstructorObject()

Whereby the new keyword above tells JavaScript that a constructorObjectshould act as a constructor. Inheritance is one thing this design pattern does not support. Find out more detail here.

2. Prototype Pattern

The prototype pattern is based on prototypical inheritance whereby objects created to act as prototypes for other objects. In reality, prototypes act as a blueprint for each object constructor created.
Example

name:"Ford",
brake:function(){
console.log("Stop! I am applying brakes");
}
Panic : function (){
console.log ( "wait. how do you stop thuis thing?")
}
}
// use objec create to instansiate a new car
var yourCar= object.create(myCar);
//You can now see that one is a prototype of the other
console.log (yourCar.name);]

3. Module Design Pattern

In the module design pattern, there is an improvement from the prototype pattern. The different types of modifiers (both private and public) are set in the module pattern. You can create similar functions or properties without conflicts. There is the flexibility of renaming functions publicly. The daunting part of this is the inability to override the created functions from the outside environment.
Example

var myCar= {
function AnimalContainter () {
const container = [];
function addAnimal (name) {
container.push(name);
}
function getAllAnimals() {
return container;
}
function removeAnimal(name) {
const index = container.indexOf(name);
if(index < 1) {
throw new Error('Animal not found in container');
}
container.splice(index, 1)
}
return {
add: addAnimal,
get: getAllAnimals,
remove: removeAnimal
}
}
const container = AnimalContainter();
container.add('Hen');
container.add('Goat');
container.add('Sheep');
console.log(container.get()) //Array(3) ["Hen", "Goat", "Sheep"]
container.remove('Sheep')
console.log(container.get()); //Array(2) ["Hen", "Goat"]

4. Singleton Pattern

It is essential in a scenario where only one instance needs to be created, for example, a database connection. It is only possible to create an instance when the connection is closed or you make sure to close the open instance before opening a new one. This pattern is also referred to as strict pattern, one drawback associated with this pattern is its daunting experience in testing because of its hidden dependencies objects which are not easily singled out for testing.
Example

function DatabaseConnection () {
let databaseInstance = null;
// tracks the number of instances created at a certain time
let count = 0;
function init() {
console.log(`Opening database #${count + 1}`);
//now perform operation
}
function createIntance() {
if(databaseInstance == null) {
databaseInstance = init();
}
return databaseInstance;
}
function closeIntance() {
console.log('closing database');
databaseInstance = null;
}
return {
open: createIntance,
close: closeIntance
}
}
const database = DatabseConnection();
database.open(); //Open database #1
database.open(); //Open database #1
database.open(); //Open database #1
database.close(); //close database

5. Factory Pattern.

It is a creational concerned with the creation of objects without the need for a constructor. It provides a generic interface for creating objects, where we can specify the type of factory objects to be created. Therefore, we only specify the object and the factory instantiates and returns it for us to use. It is wise for us to use factory pattern when the object component set up has a high level of complexity and when we want to create different instances of objects easily depending on the environment we are in. We can also use factory pattern when working with many small objects sharing the same properties and when composing objects that need decoupling.
Example

// Dealer A
DealerA = {};
DealerA.title = function title() {
return "Dealer A";
};
DealerA.pay = function pay(amount) {
console.log(
`set up configuration using username: ${this.username} and password: ${
this.password
}`
);
return `Payment for service ${amount} is successful using ${this.title()}`;
};
//Dealer B
DealerB = {};
DealerB.title = function title() {
return "Dealer B";
};
DealerB.pay = function pay(amount) {
console.log(
`set up configuration using username: ${this.username}
and password: ${this.password}`
);
return `Payment for service ${amount} is successful using ${this.title()}`;
};
//@param {*} DealerOption
//@param {*} config
function DealerFactory(DealerOption, config = {}) {
const dealer = Object.create(dealerOption);
Object.assign(dealer, config);
return dealer;
}
const dealerFactory = DealerFactory(DealerA, {
username: "user",
password: "pass"
});
console.log(dealerFactory.title());
console.log(dealerFactory.pay(12));
const dealerFactory2 = DealerFactory(DealerB, {
username: "user2",
password: "pass2"
});
console.log(dealerFactory2.title());
console.log(dealerFactory2.pay(50));

6. Observer Pattern

The observer design pattern is handy in a place where objects communicate with other sets of objects simultaneously. In this observer pattern, there is no unnecessary push and pull of events across the states, rather the modules involved only modify the current state of data.
Example

function Observer() {
this.observerContainer = [];
}
Observer.prototype.subscribe = function (element) {
this.observerContainer.push(element);
}
// the following removes an element from the container
Observer.prototype.unsubscribe = function (element) {
const elementIndex = this.observerContainer.indexOf(element);
if (elementIndex &gt; -1) {
this.observerContainer.splice(elementIndex, 1);
}
}
/**
* we notify elements added to the container by calling
* each subscribed components added to our container
*/
Observer.prototype.notifyAll = function (element) {
this.observerContainer.forEach(function (observerElement) {
observerElement(element);
});
}

7. Command Pattern

To wrap up, I would say the command design pattern ends my 7 best sums of JavaScript design patterns. The command design pattern encapsulates method invocation, operations, or requests into a single object so that we can pass method calls at our discretion. The command design pattern gives us an opportunity to issue commands from anything executing commands and delegates responsibility to different objects instead. These commands are presented in run() and execute() format.

(function(){
var carManager = {
//information requested
requestInfo: function( model, id ){
return "The information for " + model + " with ID " + id + " is foo bar";
},
// now purchase the car
buyVehicle: function( model, id ){
return "You have successfully purchased Item " + id + ", a " + model;
},
// now arrange a viewing
arrangeViewing: function( model, id ){
return "You have successfully booked a viewing of " + model + " ( " + id + " ) ";
}
};
})();

Reference:
Learning Javascript design Patterns : Addy Osmani

Understanding Asynchronous Redux Actions with Redux Thunk

Famini-ProDev — Fri, 22 Apr 2022 13:37:55 +0000

By default, Redux’s actions are dispatched synchronously, which is a problem for any non-trivial app that needs to communicate with an external API or perform side effects. Redux also allows for middleware that sits between an action being dispatched and the action reaching the reducers.
There are two very popular middleware libraries that allow for side effects and asynchronous actions: Redux Thunk and Redux Saga. In this post, you will explore Redux Thunk.
Thunk is a programming concept where a function is used to delay the evaluation/calculation of an operation.
Redux Thunk is a middleware that lets you call action creators that return a function instead of an action object. That function receives the store’s dispatch method, which is then used to dispatch regular synchronous actions inside the function’s body once the asynchronous operations have been completed.
In this article, you will learn how to add Redux Thunk and how it can fit in a hypothetical Post List application.
.The first step:

Adding redux-thunk

First, use the terminal to navigate to the project directory and install the redux-thunk package in your project:

npm install redux-thunk@2.1.0``

Now apply the middleware when creating your app’s store using Redux’s applyMiddleware. Given a React application with redux and react-redux, your configurationStore.js file might look like this:

` import { createStore, applyMiddleware } from 'redux'; import thunk from 'redux-thunk'; import rootReducer from '../reducers'; export default function configureStore(initialState) { const enhancer = applyMiddleware(thunk) return createStore( rootReducer, initialState, enhancer ); } `
Using Redux Thunk in a Sample Application
The most common use case for Redux Thunk is for communicating asynchronously with an external API to retrieve or save data. Redux Thunk makes it easy to dispatch actions that follow the lifecycle of a request to an external API.
showing a list of posts involves first dispatching an action. Then, if the list of post is successfully showed and returned by the external server, then list of posts are shown Otherwise an error message is displayed
Let’s see how this would be accomplished using Redux Thunk.

`
import React, { Component, PropTypes } from 'react';
import { connect } from 'react-redux';
import { ListGroup, ListGroupItem } from 'react-bootstrap';
import { itemsFetchData } from '../actions/items';
class ItemList extends Component {
componentDidMount() {
this.props.fetchData('https://jsonplaceholder.typicode.com/posts');
}
render() {
if (this.props.hasError) {
return

Sorry! There was an error loading the items

;
}
if (this.props.isLoading) {
return

Loading…

;
}
return ( {this.props.items.map((item) => ( Body: {item.body}

))}

);
}
}
var setMargin = {
padding: "0px 200px 20px 200px"
};
var borderNone = {
border: "none",
background: "#fff"
};
var setDistanceBetweenItems = {
marginBottom: "5px",
padding: "30px",
paddingBottom: "50px",
background: "#fff"
};
ItemList.propTypes = {
fetchData: PropTypes.func.isRequired,
items: PropTypes.array.isRequired,
hasError: PropTypes.bool.isRequired,
isLoading: PropTypes.bool.isRequired
};
const mapStateToProps = (state) => {
return {
items: state.items,
hasError: state.itemsHaveError,
isLoading: state.itemsAreLoading
};
};
const mapDispatchToProps = (dispatch) => {
return {
fetchData: (url) => dispatch(itemsFetchData(url))
};
};
export default connect(mapStateToProps, mapDispatchToProps)(ItemList);



**Fetching data from an API**

Now onto our application. All of the above code snippets were just examples. We will now dive into the important bits of the code of our app. Also, a github repo will be available at the end of the article, containing the entire app.

Our app will fetch (asynchronously) data that is retrieved by an API — assuming we already built and deployed a working API, how convenient :) — and then display the fetched data as nice as my UI design skills go (not too far).

TVmaze’s public API contains tonnes of data and we will fetch all the shows they have ever aired. Then, the app will display all the shows, toghether with their rating and premiere date.

Designing our state

In order for this application to work properly, our state needs to have 3 properties:

isLoading,hasError `and items. So we will have one action creator for each property and an extra action creator where we will fetch the data and call the other 3 action creators based on the status of our request to the API.
Action creators

Let’s have a look at the first 3 action creators:

` export function itemsHaveError(bool) { return { type: 'ITEMS_HAVE_ERROR', hasError: bool }; } export function itemsAreLoading(bool) { return { type: 'ITEMS_ARE_LOADING', isLoading: bool }; } export function itemsFetchDataSuccess(items) { return { type: 'ITEMS_FETCH_DATA_SUCCESS', items }; } `
The last one will be called after the fetching was successful and will receive the fetched items as an parameter. This action creator will return an object with a property called items that will receive as value the array of items which were passed as an argument. Instead if items: items, we can just write items, using an ES6 syntactic sugar called property shorthand.
To visualize a bit what was described earlier, this is how it looks in Redux DevTools:
Out of the box, action creators can return just actions. That’s where Redux Thunk comes in handy. Thunk allows us to have action creators that return a function instead of an action and dispatch an action only in certain cases.
If it wasn’t for Redux Thunk, we would probably end up having just one action creator, something like this:

` export function itemsFetchData(url) { const items = axios.get(url); return { type: 'ITEMS_FETCH_DATA', items }; } `
Obviously, it would be a lot harder in this scenario to know if the items are still loading or checking if we have an error.
Knowing these and using Redux Thunk, our action creator will be:

` export function itemsFetchData(url) { return (dispatch) => { dispatch(itemsAreLoading(true)); axios.get(url) .then((response) => { if (response.status !== 200) { throw Error(response.statusText); } dispatch(itemsAreLoading(false)); return response; }) .then((response) => dispatch(itemsFetchDataSuccess(response.data))) .catch(() => dispatch(itemsHaveError(true))); }; } `
Reducers
Now that we have our action creators in place, let’s start writing our reducers.
All reducers will be called when an action is dispatched. Because of this, we are returning the original state in each of our reducers. When the action type matches, the reducer does what it has to do and returns a new slice of state. If not, the reducer returns the original state back.
Each reducer takes 2 parameters: the (soon to be previous) slice of state and an action object:

` export function itemsHaveError(state = false, action) { switch (action.type) { case 'ITEMS_HAVE_ERROR': return action.hasError; default: return state; } } export function itemsAreLoading(state = false, action) { switch (action.type) { case 'ITEMS_ARE_LOADING': return action.isLoading; default: return state; } } export function items(state = [], action) { switch (action.type) { case 'ITEMS_FETCH_DATA_SUCCESS': return action.items; default: return state; } } `
Now that we have the reducers created, let’s combine them in our index.js from our reducersfolder:

`
import { combineReducers } from 'redux';
import { items, itemsHaveError, itemsAreLoading } from './items';
export default combineReducers({
items,
itemsHaveError,
itemsAreLoading
});

Understanding Asynchronous Redux Actions with Redux Thunk

Famini-ProDev — Fri, 22 Apr 2022 13:28:42 +0000

Adding redux-thunk

First, use the terminal to navigate to the project directory and install the redux-thunk package in your project:

npm install redux-thunk@2.1.0

import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import rootReducer from '../reducers';
export default function configureStore(initialState) {
const enhancer = applyMiddleware(thunk)
return createStore(
rootReducer,
initialState,
enhancer
);
}

Using Redux Thunk in a Sample Application
The most common use case for Redux Thunk is for communicating asynchronously with an external API to retrieve or save data. Redux Thunk makes it easy to dispatch actions that follow the lifecycle of a request to an external API.
showing a list of posts involves first dispatching an action. Then, if the list of post is successfully showed and returned by the external server, then list of posts are shown Otherwise an error message is displayed
Let’s see how this would be accomplished using Redux Thunk.

import React, { Component, PropTypes } from 'react';
import { connect } from 'react-redux';
import { ListGroup, ListGroupItem } from 'react-bootstrap';
import { itemsFetchData } from '../actions/items';
class ItemList extends Component {
componentDidMount() {
this.props.fetchData('https://jsonplaceholder.typicode.com/posts');
}
render() {
if (this.props.hasError) {
return <p>Sorry! There was an error loading the items</p>;
}
if (this.props.isLoading) {
return <p>Loading…</p>;
}
return (
<div style={setMargin}>
{this.props.items.map((item) => (
<div key={item.id}>
<ListGroup style={setDistanceBetweenItems}>
<ListGroupItem style={borderNone} header={item.title}>
<span className="pull-xs-right">Body: {item.body}</span>
</ListGroupItem>
</ListGroup>
</div>
))}
</div>
);
}
}
var setMargin = {
padding: "0px 200px 20px 200px"
};
var borderNone = {
border: "none",
background: "#fff"
};
var setDistanceBetweenItems = {
marginBottom: "5px",
padding: "30px",
paddingBottom: "50px",
background: "#fff"
};
ItemList.propTypes = {
fetchData: PropTypes.func.isRequired,
items: PropTypes.array.isRequired,
hasError: PropTypes.bool.isRequired,
isLoading: PropTypes.bool.isRequired
};
const mapStateToProps = (state) => {
return {
items: state.items,
hasError: state.itemsHaveError,
isLoading: state.itemsAreLoading
};
};
const mapDispatchToProps = (dispatch) => {
return {
fetchData: (url) => dispatch(itemsFetchData(url))
};
};
export default connect(mapStateToProps, mapDispatchToProps)(ItemList);

Fetching data from an API
Now onto our application. All of the above code snippets were just examples. We will now dive into the important bits of the code of our app. Also, a github repo will be available at the end of the article, containing the entire app.
Our app will fetch (asynchronously) data that is retrieved by an API — assuming we already built and deployed a working API, how convenient :) — and then display the fetched data as nice as my UI design skills go (not too far).
TVmaze’s public API contains tonnes of data and we will fetch all the shows they have ever aired. Then, the app will display all the shows, toghether with their rating and premiere date.
Designing our state
In order for this application to work properly, our state needs to have 3 properties: isLoading, hasErrorand items. So we will have one action creator for each property and an extra action creator where we will fetch the data and call the other 3 action creators based on the status of our request to the API.
Action creators

Let’s have a look at the first 3 action creators:

export function itemsHaveError(bool) {
        return {
            type: 'ITEMS_HAVE_ERROR',
            hasError: bool
        };
    }
    export function itemsAreLoading(bool) {
        return {
            type: 'ITEMS_ARE_LOADING',
            isLoading: bool
        };
    }
    export function itemsFetchDataSuccess(items) {
        return {
            type: 'ITEMS_FETCH_DATA_SUCCESS',
            items
        };
    }

The last one will be called after the fetching was successful and will receive the fetched items as an parameter. This action creator will return an object with a property called items that will receive as value the array of items which were passed as an argument. Instead if items: items, we can just write items, using an ES6 syntactic sugar called property shorthand.
To visualize a bit what was described earlier, this is how it looks in Redux DevTools:
Out of the box, action creators can return just actions. That’s where Redux Thunk comes in handy. Thunk allows us to have action creators that return a function instead of an action and dispatch an action only in certain cases.
If it wasn’t for Redux Thunk, we would probably end up having just one action creator, something like this:

export function itemsFetchData(url) {
        const items = axios.get(url);
        return {
            type: 'ITEMS_FETCH_DATA',
            items
        };
    }

Obviously, it would be a lot harder in this scenario to know if the items are still loading or checking if we have an error.
Knowing these and using Redux Thunk, our action creator will be:

export function itemsFetchData(url) {
        return (dispatch) => {
            dispatch(itemsAreLoading(true));
            axios.get(url)
                .then((response) => {
                    if (response.status !== 200) {
                        throw Error(response.statusText);
                    }
                    dispatch(itemsAreLoading(false));
                    return response;
                })
                .then((response) => dispatch(itemsFetchDataSuccess(response.data)))
                .catch(() => dispatch(itemsHaveError(true)));
        };
    }

Reducers
Now that we have our action creators in place, let’s start writing our reducers.
All reducers will be called when an action is dispatched. Because of this, we are returning the original state in each of our reducers. When the action type matches, the reducer does what it has to do and returns a new slice of state. If not, the reducer returns the original state back.
Each reducer takes 2 parameters: the (soon to be previous) slice of state and an action object:

export function itemsHaveError(state = false, action) {
        switch (action.type) {
            case 'ITEMS_HAVE_ERROR':
                return action.hasError;
            default:
                return state;
        }
    }
    export function itemsAreLoading(state = false, action) {
        switch (action.type) {
            case 'ITEMS_ARE_LOADING':
                return action.isLoading;
            default:
                return state;
        }
    }
    export function items(state = [], action) {
        switch (action.type) {
            case 'ITEMS_FETCH_DATA_SUCCESS':
                return action.items;
            default:
                return state;
        }
    }

Now that we have the reducers created, let’s combine them in our index.js from our reducersfolder:

import { combineReducers } from 'redux';
    import { items, itemsHaveError, itemsAreLoading } from './items';
    export default combineReducers({
        items,
        itemsHaveError,
        itemsAreLoading
    });

Creating the store
Don’t forget about including the Redux Thunk middleware in the configureStore.js:

import { createStore, applyMiddleware } from 'redux';
    import thunk from 'redux-thunk';
    import rootReducer from '../reducers';
    export default function configureStore(initialState) {
        const composeEnhancers = 
            window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ ?   
                window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__({
                    // options like actionSanitizer, stateSanitizer
                }) : compose;
        const enhancer = composeEnhancers(
            applyMiddleware(thunk)
        );
        return createStore(
            rootReducer,
            initialState,
            enhancer
        );
    }

Using the store in our root index.js

import React from 'react';
    import { render } from 'react-dom';
    import { Provider } from 'react-redux';
    import configureStore from './store/configureStore';
    import ItemList from './components/ItemList';
    const store = configureStore();
    render(
        <Provider store={store}>
            <ItemList />
        </Provider>,
        document.getElementById('app')
    );

Writing our React component which shows the fetched data
Let’s start by talking about what we are importing here.
In order to work with Redux, we have to import connectfrom 'react-redux':

import { connect } from 'react-redux';

Also, because we will fetch the data in this component, we will import our action creator that fetches data:

import { itemsFetchData } from '../actions/items';

We are importing only this action creator, because this one also dispatches the other actions to the store.
Next step would be to map the state to the components’ props. For this, we will write a function that receives stateand returns the props object.

const mapStateToProps = (state) => {
        return {
            items: state.items,
            hasError: state.itemsHaveError,
            isLoading: state.itemsAreLoading
        };
    }

When we have a new state, the propsin our component will change according to our new state.
Also, we need to dispatch our imported action creator.

const mapDispatchToProps = (dispatch) => {
        return {
            fetchData: (url) => dispatch(itemsFetchData(url))
        };
    };

With this one, we have access to our itemFetchDataaction creator through our propsobject. This way, we can call our action creator by doing
this.props.fetchData(url);
Now, in order to make these methods actually do something, when we export our component, we have to pass these methods as arguments to connect. This connects our component to Redux.

export default connect(mapStateToProps, mapDispatchToProps)(ItemList);

Finally, we will call this action creator in the componentDidMount lifecycle method:

this.props.fetchData('https://jsonplaceholder.typicode.com/posts');

Besides this, we need some validations:

if (this.props.hasError) {
        return <p>Sorry! There was an error loading the items</p>;
    }
    if (this.props.isLoading) {
        return <p>Loading ...</p>;
    }

And the actual iteration over our fetched data array:

{this.props.items.map((item) => (
        // display data here
    ))}

In the end, our component will look like this:

import React, { Component, PropTypes } from 'react';
    import { connect } from 'react-redux';
    import { ListGroup, ListGroupItem } from 'react-bootstrap';
    import { itemsFetchData } from '../actions/items';
    class ItemList extends Component {
        componentDidMount() {
            this.props.fetchData('https://jsonplaceholder.typicode.com/posts');
        }
        render() {
            if (this.props.hasError) {
                return <p>Sorry! There was an error loading the items</p>;
            }
            if (this.props.isLoading) {
                return <p>Loading ...</p>;
            }
            return (
                <div style={setMargin}>
                    {this.props.items.map((item) => (
                        <div key={item.id}>
                                <ListGroup style={setDistanceBetweenItems}>
                                    <ListGroupItem  header={item.title}>
                                        <span className="pull-xs-right">Body: {item.body}</span>
                                    </ListGroupItem>
                                </ListGroup>
                        </div>
                    ))}
                </div>
            );
        }
    }
    ItemList.propTypes = {
        fetchData: PropTypes.func.isRequired,
        items: PropTypes.array.isRequired,
        hasError: PropTypes.bool.isRequired,
        isLoading: PropTypes.bool.isRequired
    };
    const mapStateToProps = (state) => {
        return {
            items: state.items,
            hasError: state.itemsHaveError,
            isLoading: state.itemsAreLoading
        };
    };
    const mapDispatchToProps = (dispatch) => {
        return {
            fetchData: (url) => dispatch(itemsFetchData(url))
        };
    };
    export default connect(mapStateToProps, mapDispatchToProps)(ItemList);

And that was all !

You can see the full source of this project in : https://github.com/Famini-ProDev/PostList-redux-thunk