Category Archives: javascript

abstract (typescript)

December 24, 2020javascriptadmin

ref –

https://www.tutorialsteacher.com/typescript/abstract-class
https://stackoverflow.com/questions/260666/can-an-abstract-class-have-a-constructor?rq=1
https://www.typescripttutorial.net/typescript-tutorial/typescript-abstract-classes/
https://khalilstemmler.com/blogs/typescript/abstract-class/
https://khalilstemmler.com/blogs/typescript/abstract-class/

TypeScript – Abstract Class

Abstraction removes the need to implement all the low-level details upfront; instead, we can focus on the high-level and figure out the specifics later.

Abstract classes are mainly for inheritance where other children classes derive from parent classes.

An abstract class is typically used to:

define common behaviors for derived classes to extend
cannot be instantiated directly (although regularly parent class can be instantiated)
An abstract method does not contain implementation. It only defines the signature of the method without including the method body, which the child class MUST define

We deal primarily with two types of classes in object-oriented programming languages: concretions and abstractions.

Concrete classes are real, and we can construct objects from them to use at runtime using the new keyword. They’re what most of us end up using when we first start learning object-oriented programming.

// Concrete class

class User {

private name: string;

public getName (): string {

return this.name;

}

constructor (name: string) {

this.name = name;

}

const user = new User('Khalil'); // Creating an instance

// of a concrete class

On the other hand, abstractions are blueprints or contracts that specify the properties and methods that a concretion should have. We can use them to contractualize the valid structure of an object or a class.

// Interface (abstraction)

interface Box {

length: number;

width: number;

}

const boxOne: Box = { length: 1, width: 2 }; // ✅ Valid! Has all props

const boxTwo: Box = { length: 1 }; // ❌ Not valid, missing prop

another example:

// Interface (abstraction)

interface Box {

length: number;

width: number;

}

// Concrete class implementing Box abstraction

class MobileBox implements Box { // ✅ Valid! Implements all necessary props

public length: number;

public width: number;

constructor (length: number, width: number) {

this.length = length;

this.width = width;

}

let boxThree = new MobileBox(1, 2);

In the previous examples, we used the interface keyword to create abstractions. However, when we speak of abstractions in object-oriented programming, we’re generally referring to one of two tools:

interfaces (i.e.: the interface keyword) or
abstract classes (i.e.: the abstract keyword in front of a class)

We want to focus on defining a contract containing all the necessary things that a subtype needs to provide if they want it to work with the base type — and leave it to developers to implement them?

This satisifes:

Liskov Substitution Principle — since we define valid subtypes, each implementation should work and be interchangeable as long as it implements the contract.

Dependency Inversion — we do not directly depend on the concretions; instead, we rely on the abstraction that the concretions depend on; this keeps our core code unit testable.

Defining common properties

Within this Book abstraction, we can then decide on the contract for a Book. Let us say that all Book subclasses must have author and title properties. We can define them as instance variables and accept them as input using the abstract class constructor.

abstract class Book {

private author: string;

private title: string;

constructor (author: string, title: string) {

this.author = author;

this.title = title;

}

Defining common logic

We can then can place some of the common logic within the Book abstract class using regular methods.

abstract class Book {

private author: string;

private title: string;

constructor (author: string, title: string) {

this.author = author;

this.title = title;

}

// Common methods

public getBookTitle (): string {

return this.title;

}

public getBookAuthor (): string {

return this.title;

}

Remember that an abstract class is an abstraction comparable to an interface. We can’t instantiate it directly. Trying anyway for demonstration purposes, we’ll notice that we get an error that looks like this:

let book = new Book ( // ❌ error TS2511: Cannot create an

'Robert Greene', // instance of an abstract class.

'The Laws of Human Nature'

);

We’ll introduce one of our specific types of Book concretions — the PDF class. We extend/inherit the abstract Book class as a new subclass to hook it up.

class PDF extends Book { // Extends the abstraction

private belongsToEmail: string;

constructor (author: string, title: string, belongsToEmail: string) {

super(author, title); // Must call super on subclass

this.belongsToEmail = belongsToEmail;

}

Since PDF is a concrete class, we can instantiate it. The PDF object has all of the properties and methods of the Book abstraction, so we can call getBookTitle and getBookAuthor as if it were originally declared on the PDF class.

let book: PDF = new PDF(

'Robert Greene',

'The Laws of Human Nature',

'khalil@khalilstemmler.com'

);

book.getBookTitle(); // "The Laws of Human Nature"

book.getBookAuthor(); // "Robert Greene"

Defining mandatory methods

Abstract classes have one last important feature: the notion of the abstract method. Abstract methods are methods that we must define on any implementing subclass.

In the abstract class, we define them like so:

abstract class Book {

private author: string;

private title: string;

constructor (author: string, title: string) {

this.author = author;

this.title = title;

}

abstract getBookType (): string; // No implementation

}

Notice that there is no implementation for the abstract method? That’s because we implement it on the subclass.

Demonstrating with the PDF and an additional EPUB subclass, we add the required abstract method to both of them.

...

class PDF extends Book {

...

getBookType (): string { // Must implement this

return 'PDF';

}

class EPUB extends Book {

constructor (author: string, title: string) {

super(author, title);

}

getBookType (): string { // Must implement this

return 'EPUB';

}

Failing to implement the required abstract methods will fail to make the class complete and concrete — this means we’ll run into errors when trying to compile our code or create instances.

Use cases (when to use abstract classes)

Now that we know the mechanics behind how abstract classes work, let’s talk about real-life use cases for it — scenarios you are likely to encounter.

There are two primary use cases for needing to use abstract classes:

Sharing common behavior
Template method pattern (framework hook methods)

Sharing Common Behavior

Let’s say that we definitely need to fetch data from:

a Users API located at example.com/users
a Reviews API located at example.com/reviews

What’s the common logic?

Setting up an HTTP library (like Axios)
Setting up interceptors to set up common refetching logic (say, like when an access token expires)
Performing HTTP methods

export abstract class BaseAPI {

protected baseUrl: string;

private axiosInstance: AxiosInstance | any = null;

constructor (baseUrl: string) {

this.baseUrl = baseUrl

this.axiosInstance = axios.create({})

this.enableInterceptors();

}

protected get (url: string, params?: any, headers?: any): Promise<any> {

return this.getAxiosInstance({

method: 'GET',

url: `${this.baseUrl}${url}`,

params: params ? params : null,

headers: headers ? headers : null

})

}

protected post (url: string, params?: any, headers?: any): Promise<any> {

return this.getAxiosInstance({

method: 'POST',

url: `${this.baseUrl}${url}`,

params: params ? params : null,

headers: headers ? headers : null

})

}

Here, we’ve placed the low-level behavior within a BaseAPI abstraction. Now we can define the high-level behavior — the rich stuff — in the subclasses.

export class UsersAPI extends BaseAPI {

constructor () {

super('http://example.com/users');

}

// High-level functionality

async getAllUsers (): Promise<User[]> {

let response = await this.get('/');

return response.data.users as User[];

}

...

}

So now we can get all sort of data whether it us Users, Reviewers…etc.

Template Method Pattern ( framework hooking )

So then, a simplistic version of the abstract class for a component could look like the following:

abstract class Component {

private props: any;

private state: any;

abstract render (): void; // Mandatory

}

And then to use it, we’d need to extend the Component abstraction and implement the render method.

class Box extends Component {

render () {

// Must implement this method

}

We need to implement the render method because it is a critical part of the work involved with deciding what gets created on screen.

An abstract class is a suitable tool for this problem is because there is an algorithm running behind the scenes — an algorithm in which the render step is but a single step amongst many.

We can see that there are three distinct phases to React: mounting, updating, and unmounting. React’s abstract class further gives us (the client developer) the ability to customize our components by connecting the ability to hook into various lifecycle events. For example, you can perform some behavior as soon as your component mounts (componentDidMount), when it updates (componentDidUpdate), and when it’s about to unmount (componentWillUnmount).

so the algorithm may look like this:

abstract class Component {

private props: any;

private state: any;

abstract render (): void;

// Algorithm for mounting

constructor () {

this.render();

this.componentDidMount();

}

// The general algorithm for updating. Called when new props occur,

// when setState is called or when forceUpdate is called

onUpdate () {

if (this.componentShouldUpdate()) {

this.render();

this.componentDidUpdate();

}

// Algorithm for unmounting

onUnmount () {

this.componentWillUnmount();

// Complete unmounting

}

public componentDidMount (): void {

// No implementation lifecycle method, allow the client to override

}

public componentDidUpdate (): void {

// No implementation lifecycle method, allow the client to override

}

public componentWillUnmount (): void {

// No implementation lifecycle method, allow the client to override

}

private componentShouldUpdate (): boolean {

// Determines if the component should update

...

}

And now, a customized component subclass can plug in behavior within those key lifecycle hook methods. This is the concept of Inversion of Control.

class Box extends Component {

constructor () {

super();

}

componentDidMount () {

// (Optional) Perform custom logic

}

componentDidUpdate () {

// (Optional) Perform custom logic

}

componentWillUnmount () {

// (Optional) Perform custom logic

}

render () {

// Must implement this method

}

So as a framework designer, the Template Method design pattern is attractive when:

You need the client to implement a step of the algorithm → so you make that step an abstract method
You want to provide the ability for clients to customize behavior at various steps of the algorithm → so you expose optional lifecycle methods to the client

Supplementals

The following abstract class declares one abstract method find and also includes a normal method display.

abstract class Person {

constructor(name: string) {

this.name = name;

}

display(): void{

console.log(this.name);

}

abstract find(string): Person;

}

class Employee extends Person {

empCode: number;

constructor(name: string, code: number) {

super(name); // must call super()

this.empCode = code;

}

find(name:string): Person {

// execute AJAX request to find an employee from a db

return new Employee(name, 1);

}

let emp: Person = new Employee("James", 100);

emp.display(); //James

let emp2: Person = emp.find('Steve');

In the above example, Person is an abstract class which includes one property and two methods, one of which is declared as abstract.

The find() method is an abstract method and so must be defined in the derived class. In other words, the Employee class derives from the Person class and so it must define the find() method as abstract.

The Employee class must implement all the abstract methods of the Person class, otherwise the compiler will show an error.

Note:
The class which implements an abstract class must call super() in the constructor.

abstract class Person {

abstract name: string; // The abstract class can also include an abstract property

// does not have abstract keyword. Derived classes do not have to implement this.

// Instead they can call and use this.

display(): void {

console.log(this.name);

}

class Employee extends Person {

name: string; // this property must be declared as indicated in the abstract class

empCode: number;

constructor(name: string, code: number) {

super(); // must call super()

this.empCode = code;

this.name = name;

}

let emp: Person = new Employee("James", 100);

emp.display(); //James

GET POST using fetch from client to web api

September 14, 2020javascript, Node JSAzureadmin

Using fetch, we get a GET request on a web API using Azure authentication and passport

node server

// API endpoint

app.get("/hello",

passport.authenticate('oauth-bearer', {session: false}),

(req, res) => {

console.log('User info: ', req.user);

console.log('Validated claims: ', req.authInfo);

if ('scp' in req.authInfo && req.authInfo['scp'].split(" ").indexOf("demo.read") >= 0) {

// Service relies on the name claim.

res.status(200).json({'name': req.authInfo['name']});

} else {

console.log("Invalid Scope, 403");

res.status(403).json({'error': 'insufficient_scope'});

}

);

client

// helper function to access the resource with the token

function callApiWithAccessToken(endpoint, token) {

const headers = new Headers();

const bearer = `Bearer ${token}`;

headers.append("Authorization", bearer);

const options = {

method: "GET",

headers: headers

};

fetch(endpoint, options)

.then(response => response.json())

.then(response => {

logMessage("Web API returned:\n" + JSON.stringify(response));

}).catch(error => {

logMessage("Error calling the Web api:\n" + error);

});

}

Using fetch, we get a POST request on a web API using Azure authentication and passport

node server

app.post("/hello",

passport.authenticate('oauth-bearer', {session: false}),

(req, res) => {

console.log(`POST on /hello`);

console.log('message: ', req.body);

res.status(200).json({'message':`received`});

}

);

client

function callApiWithAccessToken(endpoint, token) {

const headers = new Headers();

const bearer = `Bearer ${token}`;

headers.append("Authorization", bearer);

headers.append("Content-Type", "application/json");

headers.append("Accept", "application/json");

let data = {

message: 'please call me'

};

const options = {

method: "POST",

headers: headers,

body: JSON.stringify(data)

};

fetch(endpoint, options)

.then(response => response.json())

.then(response => {

logMessage("Web API returned:\n" + JSON.stringify(response));

}).catch(error => {

logMessage("Error calling the Web api:\n" + error);

});

}

Passing a form data to the Web API with no authentication

client

<label for="exampleInputEmail1">Email address</label>

<small id="emailHelp" class="form-text text-muted">We'll never share your email with anyone else.</small>

</div>

<label for="exampleInputPassword1">Password</label>

</div>

<label class="form-check-label" for="exampleCheck1">Check me out</label>

</div>

<button type="submit" class="btn btn-primary" onclick="passEmailToApi(event)">Submit</button>

</form>

function passEmailToApi(e) {

e.preventDefault(); // stop the submission

let form = document.getElementsByName('emailForm')[0];

storeEmailData(form[0].value, form[1].value);

}

function storeEmailData(email) {

const headers = new Headers();

headers.append("Content-Type", "application/json");

headers.append("Accept", "application/json");

let data = {message: 'please call me'};

const options = {

method: "POST",

headers: headers,

body: JSON.stringify(data)

};

fetch('http://localhost:5000/saveMessage', options)

.then(response => response.json())

.then(response => {

logMessage("Web API returned:\n" + JSON.stringify(response));

}).catch(error => {

logMessage("Error calling the Web api:\n" + error);

});

}

Differences between es6 arrow functions and es5 functions

July 30, 2020javascriptadmin

ref – https://blog.logrocket.com/anomalies-in-javascript-arrow-functions

Named function parameters

Initially, we have an issue where if we create a function with duplicate parameter name, JS will use the latest name as the parameter.

function logParams (first, second, first) {

console.log(first + ', ' + second);

}

logParams('hi', 'rick', 'hey'); // output hey, rick

logParams('hi', 'rick'); // undefined, rick

As we can see, the first parameter is a duplicate; thus, it is mapped to the value of the third argument passed to the function call, completely overriding the first argument passed. This is not a desirable behavior.

The good news is that this behavior is not allowed in strict mode. Defining a function with duplicate parameters in strict mode will throw a Syntax Error indicating that duplicate parameters are not allowed. At compile time, it will throw an error:

Unlike regular functions, arrow functions do not allow duplicate parameters, whether in strict or non-strict mode. Duplicate parameters will cause a Syntax Error to be thrown during compile time.

// Always throws a syntax error

const logParams = (first, second, first) => {

console.log(first, second);

}

Function Overload

Function overloading is the ability to define a function such that it can be invoked with different call signatures (shapes or number of arguments). Arguments binding for JavaScript functions makes this possible.

function average() {

console.log(arguments);

}

However, for arrow function, arguments is not defined.

Unlike regular functions, the arguments binding does not exist for arrow functions. However, they have access to the arguments object of a non-arrow parent function.

function average() {

return (() => {

// have access to non-arrow parent function

console.log(arguments); // ok

}

For arrow functions, we have ES6 parameters.

const average = (...args) => {

console.log(args);

}

– A rest parameter is not the same as the internal arguments object inside the function. The rest parameter is an actual function parameter, while the arguments object is an internal object bound to the scope of the function.

– A function can only have one rest parameter, and it must always be the last parameter. This means a function can have a combination of named parameters and a rest parameter. In other words, if you declared other parameters, obviously, the rest parameter will not capture all the function’s arguments. The individually declared parameters will be bound to their respective param names. Thus, from a rest parameter sense, it will NOT be able to reach them.

– By definition, when it is the only function parameter, it captures all function arguments. On the other hand, the arguments object of the function always captures all the function’s arguments.

– The rest parameter points to an array object containing all the captured function arguments, whereas the arguments object points to an array-like object containing all the function’s arguments.

const baseConvert = (num, ...args) => {

// destructure the `args` array and

// set the `fromRadix` and `toRadix` local variables

let [fromRadix = 10, toRadix = 10] = args;

}

// num => 123, fromRadix => 10, toRadix => 10

console.log(baseConvert(123));

// num => 255, fromRadix => 10, toRadix => 2

console.log(baseConvert(255, 2));

// num => 'ff', fromRadix => 16, toRadix => 8

console.log(baseConvert('ff', 16, 8));

Constructor functions

When a regular JavaScript function is invoked with the new keyword, the function’s internal [[Construct]] method is called to create a new instance object and allocate memory. After that, the function body is executed normally, mapping this to the newly created instance object. Finally, the function implicitly returns this (the newly created instance object), except a different return value has been specified in the function definition.

Also, all regular JavaScript functions have a prototype property. The prototype property of a function is an object that contains properties and methods that are shared among all instance objects created by the function when used as a constructor.

Unlike regular functions, arrow functions can never be called with the new keyword because they do not have the [[Construct]] method. As such, the prototype property also does not exist for arrow functions.

Arrow functions cannot be used as constructors. They cannot be called with the new keyword. Doing that throws an error indicating that the function is not a constructor.

Also, because arrow functions cannot be called with the new keyword, there is really no need for them to have a prototype. Hence, the prototype property does not exist for arrow functions.

const Square = (length = 10) => {

this.length = parseInt(length) || 10;

}

// throws an error

const square = new Square(5);

console.log(Square.prototype); // undefined

// throws an error

Square.prototype.getArea = function() {}

This

arrow functions manipulate ‘this’ to reference its parent context, to whatever its nearest non-arrow function’s this context.
es5 functions’s this references the calling object.

function Timer (seconds = 60) {

this.seconds = parseInt(seconds) || 60;

console.log(this.seconds);

this.interval = setInterval(function () {

console.log(--this.seconds);

if (this.seconds == 0) {

this.interval && clearInterval(this.interval);

}

}, 1000);

}

const timer = new Timer(30);

If you run this code, you will see that the countdown timer seems to be broken. It keeps logging NaN on the console infinitely.

The problem here is that inside the callback function passed to setInterval(), this points to the global window object instead of the newly created instance object within the scope of the Timer() function. Hence, both this.seconds and this.interval are undefined.

to fix, use .bind function:

function Timer (seconds = 60) {

this.seconds = parseInt(seconds) || 60;

console.log(this.seconds);

this.interval = setInterval((function () {

console.log(--this.seconds);

if (this.seconds == 0) {

this.interval && clearInterval(this.interval);

}

}).bind(this), 1000);

}

or arrow function:

function Timer (seconds = 60) {

this.seconds = parseInt(seconds) || 60;

console.log(this.seconds);

this.interval = setInterval(() => {

console.log(--this.seconds);

if (this.seconds == 0) {

this.interval && clearInterval(this.interval);

}

}, 1000);

}

Error Boundary in React

July 1, 2020javascript, Reactadmin

ErrorBoundary.js

Error boundaries are components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed.

import React from 'react';

class ErrorBoundary extends React.Component {

constructor(props) {

console.log('---ErrorBoundary---');

super(props)

this.state = { hasError: false }

}

componentDidCatch(error, info) {

this.setState({

hasError: true

})

}

render() {

if (this.state.hasError) {

// You can render any custom fallback UI

return <h1>{'Something went wrong.'}</h1>

}

return this.props.children

}

export default ErrorBoundary;

App.js

import React from 'react';

import './App.css';

import ErrorBoundary from './ErrorBoundary';

class Item extends React.Component {

constructor(props) {

super(props);

}

render() {

const {name} = this.props;

if (name!== '1345577') {

throw new Error("ERROR");

}

return (

</div>

);

}

class App extends React.Component {

constructor() {

super();

this.state = {

// array of objects

// each object has property name, id

list: []

};

this.addItem = this.addItem.bind(this);

}

//prototype methods run in strict mode.

addItem() {

const id = new Date().getTime().toString();

this.setState({

list: [ {name: id, id} , ...this.state.list]

//list: [...this.state.list, {name: id, id} ]

});

}

render() {

const { list } = this.state;

return (

<b>Add item</b> to the beginning of the list

</button>

<h3>Better <code>key=id</code></h3>

{this.state.list.map((todo) =>

<Item {...todo}

key={todo.id} />

)}

</form>

</ErrorBoundary>

</div>

);

}

export default App;

Pure components in React

June 24, 2020javascript, Reactpure component, pure functionadmin

ref – https://medium.com/technofunnel/working-with-react-pure-components-166ded26ae48
https://en.wikipedia.org/wiki/Pure_function
https://stackoverflow.com/questions/52680508/can-pure-functions-be-asynchronous
demo

Pure Functions

First, let’s talk about pure functions.

The definition of Pure Function says that for specific input parameters, we always have a specific output. The output is solely dependent on Input parameters and no other external variable.

Wikipedia defines it as:

Its return value is the same for the same arguments. 1 to 1. For a particular input, you won’t get different outputs. No mutation of local static variables, non-local variables, mutable reference arguments or I/O streams
Its evaluation has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or I/O streams).

example:

var initialValue = 10;

function addData(newValue) {

return initialValue + newValue;

}

It uses non-local variable initialValue. So it is impure.

var getInitialValue = 0;

function getValue(inputValue) {

getInitialValue = inputValue;

return getInitialValue;

}

The code specified above is another example of the impure function, where the function is modifying the global variable getInitialValue, which does not lie under the scope of this function. Modifying this variable results in the introduction of Impurity to the function, making it Impure.

function addData(firstInput, secondInput) {

return firstInput + secondInput;

}

var getData = addData(1, 2);

The function given above defines the output on the basis of the input parameter only.
No outer variables is adding its impact to the output.
Also, we can see that the function does not modify any other variable that does not belong to this function. Hence it adheres to the concept of Pure Functions.

Browser optimizations via Pure Functions

Pure Functions have a huge performance benefit during execution on the Browser.

Picture a scenario where a specific Pure Function is getting called multiple times.
The Application calls for the same function multiple times with the same parameters — assume “add(10, 20)”.
After executing it multiple times, the Chrome V8 Engine tries to optimize the code further by storing the execution result of the following function call. On the next call to the same function, with the same parameter, instead of executing the function again, the cached result is returned. Hence enhancing the Application Performance.

Functions should not introduce side effects

If the application updates certain data that is observable outside the called function, it can be considered a side effect introduced by the function.

Here are a few scenarios:

Modifying any external variable or object property (DOM)

– self explanatory. You use or modify outside global variables such as the document object.

Logging data to the console

– Similar to DOM, it is using outside object (console). Also, it prints something onto the screen.

Writing Data to a file

– It changes data to a file, which is global.

Writing data to the network

– Modifies network resources, which is global.

Triggering any external process
Calling any other (impure) functions with side-effects
Making Asynchronous Data Calls

– asynchronous actions usually is impure.

Most things that we use asynchronous functions for are inherently side-effect(ful): I/O, network stuff, timers. But even if we ignore those, promises alone rely on some kind of global state for their asynchrony: the event loop. This violates purity.

Pure Components

Pure Components in React are components which do not re-renders when the value of state and props has been updated with the same values.
If the value of the previous state or props and the new state or props is the same, the component is not re-rendered. Pure Components restricts the re-rendering ensuring the higher performance of the Component.

Features of React Pure Components

Prevents re-rendering of Component if props and state is the same
Takes care of “shouldComponentUpdate” implicitly

– It is the same as Component except that Pure Components take care of shouldComponentUpdate by itself, it does the shallow comparison on the state and props data. If the previous state and props data is the same as the next props or state, the component is not Re-rendered.

State and Props are Shallow Compared – standard arrays won’t work anymore as pushing a value results in the same array. What we need to do is use dot notation to create another array, then push the value
Pure Components are more performant in certain cases

Similar to Pure Functions in JavaScript, a React component is considered a Pure Component if it renders the same output for the same state and props value. React provides the PureComponent base class for these class components. Class components that extend the React.PureComponent class are treated as pure components.

Pure Components Restricts Re-rendering

Let’s look at this Component where we extend from standard Component. It is a impure component because we did not extend from PureComponent.
What makes it Impure?

Notice we do setInterval where we do a setState every 1 second.

class ImpureComponent extends React.Component {

constructor() {

super();

this.state = {

counter: 0

}

// The value of Counter is updated to same value during continues interval

setInterval(() => {

this.setState({

counter: 0

});

}, 1000);

}

render() {

return <b>Counter Value: {this.state.counter}</b>

}

When the state gets set, it changes, so our virtual DOM gets diff-ed. Once it diffs, it writes the changes to the real DOM. We do this every second. However, the UI never changes because nothing changes. We’re drawing the same thing over and over again. There is effectively no difference in the UI — the new values are unchanged. Re-rendering, in this case, is an overhead.

In order to solve this problem, we introduce…

Pure Components

They compare the initial and final values for the state and props variables. If there is no difference between the two, they won’t trigger the re-rendering logic for the component.

class ImpureComponent extends React.PureComponent {

constructor() {

super();

this.state = {

counter: 0

}

// The value of Counter is updated to same value during continues interval

setInterval(() => {

this.setState({

counter: 0

});

}, 1000);

}

render() {

// This function wont be re-rendered in case when the new state is same as previous

return <b>Counter Value: {this.state.counter}</b>

}

Each time the state or props are updated it compares the previous and next value — if the values are the same the Render function is not triggered. Performance is then improved by not calling “render” repeatedly.

Props and State Changes are Shallow Compared

In Pure Component, the changes in react “props” and “state” is Shallow Compared to know whether they have changed. If they have changed, it renders. If it doesn’t, it does not render.

Before we proceed further, we need to understand the concept of Shallow Comparison in JavaScript. The values saved in the variable can be either a primitive or reference type.

Example “var a = 10”, the value saved in the variable “a” is of primitive type.

The data stored in Objects and Array can be referred to as Reference type data. Comparing Primitive Values is not a concern.

Problems arise when we have reference values during the comparison.

var initialData = {

age: 30

}

var finalData = {

age: 30

}

// The value of "isEqual" equates to be "false" even if the property values are same

var isEqual = (finalData == initialData);

Because the comparison used is shallow (only compare values), then the == will return true. However, these are actually two different objects. So even though their value may the same, their address reference is different. They are two different objects.

In this example, we’re only dealing with one object. We have two references pointing to it. Thus, value comparison between the two references will be the same.

var userInfo = {

age: 30,

designation: "Developer"

}

var cloneData = userInfo;

cloneData.name = "Anshul Gupta";

if(cloneData == userInfo) {

alert("Reference Comparison return true")

}

We can also use spread operator to create a new object, and then copy the values over.

var userInfo = {

age: 30,

designation: "Developer"

}

var cloneData = { ...userInfo };

if(cloneData == userInfo) {

alert("TRUE")

} else {

console.log('FALSE');

}

IN this example, we create a whole new object with reference cloneData pointing to it. We then copy all properties/values from userInfo into it.
Thus in the end, we have two objects, with same properties and values. One has reference userInfo pointing to it. The other has reference cloneData pointing to it. cloneData == userInfo will return false because the references are pointing to different memory locations.

This issue with Shallow Comparison

Say we have a reference pointing to an object with an array.
We then push 6 onto it. When the PureComponent does a comparison, it will see that the before state’s userArray (and after state’s userArray) are ‘==’ (value equal) because they are pointing to the same object.

class ShalloWCompareComponent extends React.PureComponent {

constructor() {

super();

this.state = {

userArray: [1, 2, 3, 4, 5]

}

// The value of Counter is updated to same value during continues interval

setInterval(() => {

this.setState({

userArray: userArray.push(6)

});

}, 1000);

}

render() {

return <b>Array Length is: {this.state.userArray.length}</b>

}

But its clear that they are not the same. Before state’s userArray is 1,2,3,4,5. After state’s userArray is 1,2,3,4,5,6.

In the case when the props and state changes are made to primitive type variable,
state and props changes to reference variable may lead to incorrect results and inconsistent rendering.

The simple answer to resolving the shallow issue is to work with immutable data using dot operator

In the example above, we can see that comparing reference variables can lead to a problem — only the address of the object are compared before and after the update. Since we’re comparing references, the address still remains the same and the Pure Component does not detect any changes and does not re-render. We can resolve this by creating a new instance of the state variable if it represents the reference type.

class ShalloWCompareComponent extends React.PureComponent {

constructor() {

super();

this.state = {

userArray: [1, 2, 3, 4, 5]

}

setInterval(() => {

// Here we are creating the new Array Object during setState using "Spread" Operator

this.setState({

userArray: [...this.state.userArray, 6] // <--- use dot operator to create new object, and add our new value

});

}, 1000);

}

render() {

return <b>Array Length is: {this.state.userArray.length}</b>

}

we’re creating a new reference array using the spread operator. When the setState is called, the component looks for the reference of a previous array object and a new array object is created. The reference is different since this is a new instance of the array, so the object has a new address. Now the pure component will get to know that the data has been updated, the “render” life cycle will be invoked and the component will be re-rendered with correct values.

Example

React.memo() does the same as PureComponent but it does not check for changes in state, only in props. Hence, I will use React.memo in functional component here as an example.

npx create-react-app my-app
cd my-app
npm start

Then in /src, create MyPureComponent.js:

import React, { useState } from 'react';

let cur = 100; // start at d

const MyPureComponent = React.memo(props => {

const [data, setData] = useState(['a', 'b', 'c']);

const addLetter = () => {

console.log('lets add letter to our arry');

let ch = String.fromCharCode(cur);

cur++;

data.push(ch);

// setData([...data]); // works because pure components does shallow comparison

setData(data);

console.log(data);

}

return (

hello

</button>

{data.map(item => {

return <b key={item}>{item}</b>

})}

</>

)

});

export default MyPureComponent;

Basically, we initialize an array with a, b, c. Every time we click, we add the next few letters d, e, f, g….etc. We do this by using number 100, incrementing it, and getting the ascii code for it. Then we append that letter onto the array.

In index.js, we use our component.

import MyPureComponent from './MyPureComponent';

...

ReactDOM.render(

<App />

</>,

document.getElementById('root')

);

Run the app and start clicking the button.

As you can see, after doing shallow comparison of the previous prop to current prop, it gets the same reference value of the object. Thus, it never renders.

The fix here is to re-create the array and then do the push. That way, whenever you manipulate the array, you put the results onto a new array. Thus when the objects are compared, they are not the same, and thus triggers the render.

const addLetter = () => {

console.log('lets add letter to our arry');

let ch = String.fromCharCode(cur);

cur++;

setData([...data]);

//setData(data);

console.log(data);

}

The other thing you can do is to use React.memo’s second parameter with a areEqual function

1	React.memo(Component, [areEqual(prevProps, nextProps)]);

Let’s look at another example where we start off with NOT using a comparator. We are erroneously using two references to point to an array object. When we update this array, our sub component does not update because it does a shallow compare on the same array object.

let func = ({ data }) => {

console.log("SubComp is running and rerendering");

return <>

</>;

};

const SubComp = React.memo(func);

// App

function App() {

const [count, setCount] = useState(100)

const [arr, setArr] = useState(['a', 'b', 'c']);

const handleBtnClick = event => {

event.preventDefault();

// two references pointing at same array object

let newArr = arr;

let ch = String.fromCharCode(count);

newArr.push(ch);

setArr(newArr);

// when setting value, we can see the difference right away

setCount(count+1);

};

return (

<h1>{count}</h1>

<button onClick={handleBtnClick}>Click here</button>

</div>

);

}

export default App;

When we run it, we see that in the subcomponent, nothing gets re-render because its shallow comparison of prevProp and nextProp comes out to be true.

We fix it by using […arr] so that it creates a whole new objectArray, then copying all the values over. Memo will shallowly compare against two different objects, which then will actually correctly re-render because it will return false due to the two array objects being different.

let newArr = [...arr];

let ch = String.fromCharCode(count);

newArr.push(ch);

setArr(newArr); // this is what nextProp will be

Now as you add in additional letters, you’ll see that the sub component re-renders.

Using Comparator Func

The code stays the same. All we need to do is to make sure we stick a comparator function in our memo’s 2nd parameter.

1	const SubComp = React.memo(func, areEqual);

The handling of adding a letter stays the same.

let newArr = [...arr];

let ch = String.fromCharCode(count);

newArr.push(ch);

setArr(newArr); // this is what nextProp will be

then create an areEqual comparator:

const areEqual = (prevProps, nextProps) => {

console.log('prevProps', prevProps);

console.log('nextProps', nextProps);

return true;

}

We default it to return true because we don’t want it to re-render for now. We want to see the previous prop and next prop.

Great. We see that there is a difference. This is because the previous array is [‘a’, ‘b’, ‘c’]. We setArr to a new Arr that is a totally different array object by using […arr].
That way, we can see that both props are different.

Now let’s implement areEqual. Because our previous and next array data are different, we can actually make some decisions. If they are of different length, we re-render. If they are of different characters, we re-render. Otherwise, we don’t render.

// if equal --> don't render

// if NOT equal --> render

const areEqual = (prevProps, nextProps) => {

let prevArr = prevProps.data;

let nextArr = nextProps.data;

if (prevArr.length !== nextArr.length) {

console.log('false! must re-render');

return false;

} else {

// same length

for (let i = 0; i < nextArr.length; i++) {

if (prevArr[i] !== nextArr[i]) {

console.log('false, must re-render');

return false;

}

console.log('same! NO render')

return true;

}

Full Code

Copy and paste into App.js

import React, { useState } from 'react';

const areEqual = (prevProps, nextProps) => {

console.log('prevProps', prevProps);

console.log('nextProps', nextProps);

let prevArr = prevProps.data;

let nextArr = nextProps.data;

if (prevArr.length !== nextArr.length) {

console.log('false! must re-render');

return false;

} else {

// same length

for (let i = 0; i < nextArr.length; i++) {

if (prevArr[i] !== nextArr[i]) {

console.log('false, must re-render');

return false;

}

console.log('same! NO render')

return true;

}

// return true; // no change, don't render

// return false; there are changes, we need to render it.

}

// memo looks at data and see that there are always differences

let func = ({ data }) => {

return <>

<h3>Memo Functional Component</h3>

</>;

};

// works when we use [...arr] for parameter data

// const SubComp = React.memo(func);

// Let's use comparator func to compare prevProp and nextProp

// note: This must make sure of [...arr] so that prevProp and nextProp are different.

const SubComp = React.memo(func, areEqual);

// App

function App() {

const [count, setCount] = useState(100)

const [arr, setArr] = useState(['a', 'b', 'c']);

const handleBtnClick = event => {

event.preventDefault();

let newArr = [...arr]; // so that prevProp and nextProp are different

let ch = String.fromCharCode(count);

newArr.push(ch);

setArr(newArr);

// when setting value, we see that it does not get reflected in SubComp in the case of just arr.

// This is because it does not detect change referentially when arr === arr.

setCount(count+1);

};

// solution:

// 1) use [...arr] so prevProp and nextProp are different

// 2) can then use comparator func for custom comparisons

return (

<h1>{count}</h1>

<button onClick={handleBtnClick}>Click here</button>

</div>

);

}

export default App;

Store it into React state or Redux state?

June 24, 2020javascript, Reactadmin

ref – https://spin.atomicobject.com/2017/06/07/react-state-vs-redux-state/
https://stackoverflow.com/questions/39977540/can-redux-be-seen-as-a-pub-sub-or-observer-pattern

React state

React state is stored locally within a component. When it needs to be shared with other components, it is passed down through props.

In practice, this means that the top-most component in your app needing access to a mutable value will hold that value in its state.

If your top most component needs access to a value that is changeable, you need to hope it in React state. If this state is shared with other components, it needs to be passed through props.

If it can be mutated by subcomponents, you must pass a callback (into the subcomponent) to handle the update in the top-most component.

If your children components need to change this value, your parent component should pass a callback into your child component. That way when the child component changes the value, it can pass it back up to the parent component so it can update it. That way, the parent component is not holding the old value, while the child component has the newest updated value.

Redux state

The need of something like Redux when you have a more complicated application, with top-level components that need to talk to each other (actions) and somehow share some state.

Any component that needs access to a value may subscribe to the store and gain access to that value. Typically, this is done using container components. This centralizes all data but makes it very easy for a component to get the state it needs, without surrounding components knowing of its needs.

Redux is a library to manage shared state between components and to coordinate state mutations. Redux uses a pub/sub pattern.

It has a subscribe method that is used by components to subscribe to changes in the state tree. Normally you don’t use store.subscribe directly, as the Redux-React bindings (Redux’s connect basically) do that for you. The store then emits the changes.

Consider also that it’s perfectly fine to keep using the components internal state together with Redux. You can use the internal state to store state you don’t need/want to share with other components.

Some Guidelines on where to store state

Duration

Different pieces of state are persisted for different amounts of time. I loosely categorize time into these groups:

Short term: data that will change rapidly in your app

Short term data will likely change rapidly. At the simplest level, this includes the characters present in a text field as the user types. I would also extend this to include data in an entire form; this data can be considered a work in progress until the form is submitted. This type of data can be stored in local React state. I would even include things like how to filter a list of items, and whether or not to show or hide completed items in a to-do app (assuming it is not tied to user preferences).

Medium term: data that will likely persist for a while in your app

By medium-term state, I mean state that will stick around while the user navigates your app. This could be data loaded from an API, or any changes that you want to be persisted up until a page refresh.

However, after submitting a form, I would store the state in the Redux store. As an example, if a user submits a form updating their profile information, it would make sense to store this in Redux.

Long term: data that should last between multiple visits to your site

This is state that should be persisted between refreshes of the page or between separate visits to the page. Since the Redux store will be created anew when refreshing, this type of data should be stored somewhere else (likely to a database on a server or into local storage in the browser).

Breadth of Use

Another consideration is how many components in your React app need to access the state. The more state needs to be shared between different components in your app, the more benefit there is to using the Redux store. If the state feels isolated to a specific component or a small part of your app, React state may be a better option.

Depth of passing down props

React state should be stored in the most top-level component for which a subset of its subcomponents will need access to the state. Sometimes, this can mean many layers between the component storing the state and the subcomponents that render the data, and each layer means another prop must be propagated down the virtual DOM.

Parent-to-Child prop passing and callback propagating works great if you only need to pass the state down one or two levels into the subcomponents. But beyond that, it can feel tedious and require edits to many components every time you find a subcomponent needs access to new state. In cases like this, I find it much easier to store the state in Redux and use a container component to pluck the desired data from the store.

Unrelated components needing the same state

It could also be that multiple, relatively unrelated components need access to the same state. Take the above example of a form to update a user’s profile. The component here should receive the initial user profile in its props. You might also have a header component with a subcomponent that displays the user’s username or related data.

You could, of course, take passing down props to the extreme, in which your top-level component knows about the user’s profile and passes it to the header, which passes it to a subcomponent (and maybe further), and also passes it down to the profile-editing component. However, this requires a lot of management between the whole virtual DOM.

This type of solution is solved much more cleanly by storing the profile in the Redux store, and allowing container components around the header and profile-editing component to grab data from Redux’s store.

Ability to Track Changes to the State

Another time to choose Redux is when you need to track changes to state:

Maybe you want to replay events.
Maybe you want to implement undo/redo in your app.
Maybe you just want to log how state is changing.

In cases like these, Redux is a great solution; each action that is created is an artifact of how the state changes. Redux makes all these tasks simpler by centralizing them in a single store.

Event Loop (JS)

June 21, 2020javascriptadmin

ref – https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop

So the runtime in our web browser works like so.

– We have a call stack that contains the execution contexts.
– We have a callback queue sitting and waiting.
– We also have a Web API section

Objects created in memory are stored in the heap.
Execution context happens on the callback.
We have a Web API that runs code used by the browser. It executes events and will place code in either the callback queue or other data structures.
We also have a callback queue that receives callback functions whenever an an event in the Web API is done or executed.

Say we start off with code like so

e1 = document.querySelector('img');

e1.src = 'dog.jpg';

e1.addEventListener('load', () => {

e1.classList.add('fadeIn');

});

fetch('https:....')

.then(res=>console.log(res)));

// more code ...

Thus, when we start the program, we start with an execution context for global scope.

It executes the first line of code, which is sync.
We then move on to the next line of code.

1	e1.src = 'dog.jpg';

This will load up an image asynchronously. Thus, the loading of the image happens in the Web API and we let the async tasks run.

We move on to the next line of code:

e1.addEventListener('load', () => {

e1.classList.add('fadeIn');

});

So now, in the Web API, we have this callback function added. Our Web API keeps track of all these callbacks.

So here as you can see, Web API has the current async operation going…and maintains a callback. This is so that when the async operation of loading up the image is done, it has a valid callback to execute. The callback will stay there until load event is emitted. This is why we want to add the event listener for when the image finishes loading.

Having telling the Web API to load an image, and declaring a callback for when load is done, we now move forward to the fetch operation:

1	fetch('https://....')

As always, the async fetch operation will happen in the Web API’s environment. Otherwise, we’d be blocking the call stack if we were to execute it using the execution context.

The Web API appends it to its running async operations and now have two async operations going:

Finally we use the then method returned by the fetch function. And this will also register a callback in the Web API’s environment. So we can react to the future resolved value of the promise.

In other words, we place the callback from then then in our Web API. This is so that when fetch operation is completed, it will know to execute the callback provided to then.

Now our Web API environment has two async operation working, and two callback to execute when they are done.

The execution goes forward and processes other code…

Now, comes the good part. Our loading of the image async operation is done! It signals with the load event. Load event has emitted. The callback for this event is then put into the callback queue.

Now, we DO NOT execute this callback right away. Instead, we now put this callback in the callback queue.

Callback queue is like a todo list. Whereas the event loop is an executor.

There could be other callbacks. Then our new callback would be queued and wait until the others are done. This callback will execute when the event loop has finished the other callbacks in the queue. It decides when each callback is worked upon.

This has implications.

Hence, keep in mind that if you decide to use setTimer and wait 5 seconds before putting a callback inside the callback queue, it doesn’t mean your callback will be executed at exactly 5 seconds later. It may be that the callback queue is still processing other queues in front. This will take whatever time those operations specify to be. And then, then they are done, the event loop will come to your callback and execute it.

Hence, when working with timers, just remember that the time you specify in milliseconds is the fastest time that your callback will execute.

Keep in mind that the callback queue also keeps callbacks from DOM events like clicks, or key presses.

DOM events are not async, but they still callback queue to run their attached callbacks. So if a click callback executes on a button with an event listener, it works in the same way that it stays in the event queue until others are finished. So if you somehow have a callback that takes some seconds IN FRONT of a button callback, then your button presses will not work. It will need for the hanging callback in the queue to finish, the event loop processes the button callback, which will then make your button presses work.

The event loop looks into the call stack. Aside from the global context, is it empty?

The Event Loop Tick

If the stack is empty, this means no code is being executed. It takes first callback from callback queue and put it onto the call stack to be executed. This is called the Event Loop Tick

It orchestrates javascript runtime.
Javascript language itself has no sense of time.
Everything that is async, does not happen in the engine.
Its the runtime that manages the async behavior, and it is the event loop that decides which code gets executed next.

The event loop got its name because of how it’s usually implemented, which usually resembles:

while (queue.waitForMessage()) {

queue.processNextMessage()

}

The Web API environment, the callback queue, and event loop all make it possible that async operations are executed in a non-blocking way, while using only 1 thread of execution in the engine.

The MicroTask Queue

Callbacks of Promises have priority over other callbacks by using the Microtask queue

So now say the data arrives, and fetch is done. Callback related to promises, actually DO NOT go into the callback queue. Instead, callbacks of promises go to a special queue for microtasks queue.

It is special because it has priority over callback queue. It will run ALL of the microtasks until it is empty. Only then will it process the callback queue again.

The way that it runs microtasks is the same as it would for callback queue. It puts the tasks onto the execution context to be executed. Note that if any microtasks add another microtask, then naturally the new microtask(s) will be processed until the microtask queue is empty. Only then will the callback queue continue to be processed.

Therefore, note that microtasks can starve a callback queue.

A Quick Example

console.log('Test start');

// timer, goes onto the callback queue

setTimeout( () => {

console.log('0 sec timer!');

}, 0);

// Promise callback. Placed on microtasks queue

Promise.resolve('Resolved Promise 1')

.then(res => console.log(res));

console.log('test end');

output:

Test start
test end
Resolved Promise 1
0 sec timer!

If microtask takes long time to run, then our timer tasks on the callback queue will be blocked for that amount of time.

console.log('Test start');

// timer, goes onto the callback queue

setTimeout( () => {

console.log('0 sec timer!');

}, 0);

// Promise callback. Placed on microtasks queue

Promise.resolve('Resolved Promise 1')

.then(res => console.log(res));

Promise.resolve('Resolved Promise 2').then(res => {

// have for loop to simulate time

// Hence, this tasks on the microtask will block the callback queue

for (let i = 0; i < 100000000; i++) {}

console.log(res);

});

console.log('test end');

So as you can see there will be few seconds when Promise #2’s callback is executing on the microtask queue because the loop from our callback in Promise #2 is running. Once its done, it will log its text, and then finally, the timer’s callback will run on the callback queue.

output:

Test start
test end
Resolved Promise 1

…then a few seconds here because the loop from our callback in Promise #2 is running.

Resolved Promise 2
0 sec timer!

Additional Information

A JavaScript runtime uses a message queue

It is a queue that contains type Message.

Each message object in the queue has a reference to an associated function.
The Event Loop decides when to call the referenced functions.

queue.waitForMessage() waits synchronously for a message to arrive. Because Javascript is single-threaded, it can only do one thing at at a time. It can only processNextMessage if it has nothing to do (waiting).

But if a new message comes into the queue, it will be busy adding it to the queue. Thus in that situation, it cannot processNextMessage. It must first finish adding to the Queue. Then when no more Messages comes in, it will go into waitForMessage status, and thus be able to ProcessNextMessage

Processing Message

Each message is processed completely before any other message is processed.

Pro
This offers some nice properties when reasoning about your program, including the fact that whenever a function runs, it cannot be pre-empted and will run entirely before any other code runs (and can modify data the function manipulates).

This differs from C, for instance, where if a function runs in a thread, it may be stopped at any point by the runtime system to run some other code in another thread.

Con
A downside of this model is that if a message takes too long to complete, the web application is unable to process user interactions like click or scroll. The browser mitigates this with the “a script is taking too long to run” dialog. A good practice to follow is to make message processing short and if possible cut down one message into several messages.

How Message are Added

In web browsers, messages are added anytime an event occurs. An event occurs whenever we attach an event listener to the element like so:

let newsBtn = document.querySelector('#News');

newsBtn.addEventListener('click', evt => {

// process click according to evt object

});

We have an element with the id News. We put a click handler on that element. Now, whenever the user clicks on that element, we can process it the way we like.

When the click happens, an event occurs, and the callback function in the example gets added to the queue as a Message. Similarly, any other event will be added as well. If there is no listener, the event is lost.

Example

The function setTimeout is called with 2 arguments: a message to add to the queue, and a time value (default is 0).

setTimeOut( function() {

console.log('hello');

}, 2000);

The time value represents a delay in milliseconds. After the delay, the message (anon function provided) will then be pushed into the queue. In other words, when setTimeOut executes, the delay happens instantaneously. After two seconds, our anon function that logs hello will be pushed onto the queue.

If there is no other message in the queue, and the stack is empty, the message is processed right after the delay. However, if there are messages, setTimeout’s anon function will have to wait for the other messages in the queue to be processed. For this reason, the second argument indicates a minimum time — not a guaranteed time.

Basic setTimeout Example

The code gets executed synchronously. However, all async operations such as our setTimeout be placed into our queue. The thing is, Synchronously, our code gets pushed onto the queue first. Even though the setTimeout is wedged in between, the dely starts to run after our code is placed into the queue.

const s = new Date().getSeconds();

setTimeout(function() {

// prints out "2", meaning that the callback is not called immediately after 500 milliseconds.

console.log("Ran after " + (new Date().getSeconds() - s) + " seconds");

}, 500)

while (true) {

if (new Date().getSeconds() - s >= 2) {

console.log("Good, looped for 2 seconds")

break;

}

So the code gets pushed onto the queue. Async operations will obviously not run because it has to do the delay first. Thus, as the sync code is being run (our while loop), the 500 ms delay is happening. Then when the 500 ms is up, it then places the async operation (our anon function that logs) onto the queue. Let’s look at some drawings to depict this situation:

But since our while loop is still running, we can’t process the async function yet. We need for the while loop to finish running.

– First, we get a starting timestamp in seconds. Then use while loop to continuously get another timestamp in seconds.
– We subtract the second timestamp from the initial timestamp to get the difference.
– Because the difference is less than two, we repeat the loop. As time moves forward, this difference gets bigger.
– We keep doing this until the difference is two seconds.
– When this happens, we break out of the loop. This finishes our task in the queue.

The queue then remove our while loop, and then moves on to the next task, which is our console log.

Therefore, if there are messages, the setTimeout message will have to wait for other messages to be processed. For this reason, the second argument (delay) indicates a minimum time — not a guaranteed time.

From this example, you’ll be tempted to ask…if we change the dealay from 500 ms to 0ms, wouldn’t the function in setTimeout run exactly AFTER the first line of code?

const s = new Date().getSeconds();

setTimeout(function() {

// prints out "2", meaning that the callback is not called immediately after 500 milliseconds.

console.log("Ran after " + (new Date().getSeconds() - s) + " seconds");

}, 0)

while (true) {

if (new Date().getSeconds() - s >= 2) {

console.log("Good, looped for 2 seconds")

break;

}

OUTPUT:
Good, looped for 2 seconds
Ran after after 2 seconds

Thus, as the output shows, the answer is no.

Here’s why.

Zero Delay

Zero delay doesn’t actually mean the call back will fire-off after zero milliseconds. Calling setTimeout with a delay of 0 (zero) milliseconds doesn’t execute the callback function after the given interval.

The execution depends on the number of waiting tasks in the queue. In the example below, the message this is just a message will be written to the console before the messages in the callback gets processed, because the delay is the minimum time required for the runtime to process the request (not a guaranteed time).

(function() {

console.log('this is the start');

setTimeout(function cb() {

console.log('Callback 1: this is a msg from call back');

}); // has a default time value of 0

console.log('this is just a message');

setTimeout(function cb1() {

console.log('Callback 2: this is a msg from call back');

}, 0);

console.log('this is the end');

})();

// "this is the start"

// "this is just a message"

// "this is the end"

// "Callback 1: this is a msg from call back"

// "Callback 2: this is a msg from call back"

We enter all the synchronous code into the queue first. Then we place the setTimeout async functions in according to delay.

In our case, our 3 sync code lines starts executing. As its running, our delay of 0 starts for the setTimeout async operations. We immediately place cb1 function into queue.

Then the thread continues to process the sync code for a step. Then it comes back to our async operations and places cb1 anon function into the queue.

1) Puts the sync code (all 3 logs) into the queue
2) starts processing the sync code
3) delay of 0 is executed
4) logs ‘this is the start’
5) queue cb into the queue
6) logs ‘this is a message’
7) queue cb1 into the queue
8) logs ‘this is the end’
9) pops sync code
10) executes cb and logs ‘Callback1…’
11) dequeue cb
12) execute cb1 and logs ‘Callback2…’
13) dequeue cb1

Never Blocks

A very interesting property of the event loop model is that JavaScript, unlike a lot of other languages, never blocks. Handling I/O is typically performed via events and callbacks, so when the application is waiting for an IndexedDB query to return or an XHR request to return, it can still process other things like user input. This is parallel programming. The single thread work between multiple tasks at the same time.

Legacy exceptions exist like alert or synchronous XHR, but it is considered a good practice to avoid them. Beware: exceptions to the exception do exist (but are usually implementation bugs, rather than anything else).

Mixins in JS

April 16, 2020javascriptadmin

ref – https://blog.bitsrc.io/understanding-mixins-in-javascript-de5d3e02b466

Mixin is a way properties are added to objects without using inheritance — Darren Jones
Mixins are a form of object composition, where component features get mixed into a composite object so that properties of each mixin become properties of the composite object. — Eric Elliot

Let’s create a destination object to contain all the data.

Then we create a whole bunch of other objects with properties.

Finally, we’ll write our custom assign to “mixin” these objects with properties into our destination object like so:

const mydetails = {}

const firstname = { firstname: "ricky" }

const surname = { surname: "qi ji" }

const occupation = { occupation: "Software Developer" }

console.log(mydetails) // {}

myAssign(mydetails,surname, firstname, occupation);

console.log(mydetails)

The result of mydetails would be:

{surname: “qi ji”, firstname: “ricky”, occupation: “Software Developer”}
surname: “qi ji”
firstname: “ricky”
occupation: “Software Developer”
__proto__: Object

It mixed in all the properties of the other objects.

// ...src takes in unknown number of parameters, and convert it to array

function myAssign(dest, ...src) {

// typeof dest is Object

// dest instanceof Array would return true

if(typeof dest == 'object') {

for(let s of src) { // loop through every element in this array

if(typeof s == 'object') { // if the item is an object

// for each key in this item, i.e firstname, surname....etc

for(prp of Object.keys(s)) {

console.log(`key ${prp}`);

console.log(`append or access key ${prp} in dest obj, have reference point to source object`);

dest[prp] = s[prp]

}

const mydetails = {}

const firstname = { firstname: "ricky" }

const surname = { surname: "qi ji" }

const occupation = { occupation: "Software Developer" }

// pass in our destination, and source objects.

myAssign(mydetails,surname, firstname, occupation);

console.log(mydetails)

Object as hash, and looping through its keys and values (JS)

April 15, 2020javascriptadmin

let hash = {

key1: "value 1",

key2: 'value 2',

key3: 'value 3'

}

console.log(hash['key1']);

for (key in hash) {

console.log('key:', key);

console.log('value:', hash[key]);

}

100

101

102

103

104

105

106

107

function Animal (name, energy) {

// Animal property

this.name = name

this.energy = energy

}

Animal.prototype.eat = function (amount) {

console.log(`${this.name} is eating.`)

this.energy += amount

}

Animal.prototype.sleep = function (length) {

console.log(`${this.name} is sleeping.`)

this.energy += length

}

Animal.prototype.play = function (length) {

console.log(`${this.name} is playing.`)

this.energy -= length

}

function Dog (name, energy, breed) {

// Dog property

Animal.call(this, name, energy)

this.breed = breed // property

}

Dog.prototype.eat = function (amount) {

console.log(`${this.name} is eating.`)

this.energy += amount

}

Dog.prototype.sleep = function (length) {

console.log(`${this.name} is sleeping.`)

this.energy += length

}

Dog.prototype.play = function (length) {

console.log(`${this.name} is playing.`)

this.energy -= length

}

Dog.prototype.bark = function () {

console.log('Woof-Woof!')

this.energy -= .1

}

const charlie = new Dog('Charlie', 10, 'Goldendoodle');

console.log(charlie)

// will display all properties

// also will display prototype function properties

// of parent and itself

for(key in charlie) {

console.log('key', key);

}

// The problem with a for...in loop is that it iterates through properties in the Prototype chain.

// When you loop through an object with the for...in loop,

// you need to check if the property belongs to the object.

// You can do this with hasOwnProperty.

for (var property in charlie) {

if (charlie.hasOwnProperty(property)) {

console.log(`charlie owns property ${property}`);

} else {

console.log(`${property} is part of charlie chain`);

}

// output:

// charlie owns property name

// charlie owns property energy

// charlie owns property breed

// eat is part of charlie chain

// sleep is part of charlie chain

// play is part of charlie chain

// bark is part of charlie chain

const keys = Object.keys(charlie);

console.log(keys); // ["name", "energy", "breed"]

const values = Object.values(charlie);

console.log(values); // ["Charlie", 10, "Goldendoodle"]

const entries = Object.entries(charlie)

console.log(entries);

// output:

// 0: (2) ["name", "Charlie"]

// 1: (2) ["energy", 10]

// 2: (2) ["breed", "Goldendoodle"]

// The better way to loop through objects is first convert it into an array with one of these three methods.

// Object.keys

// Object.values

// Object.entries

// Then, you loop through the results like a normal array.

// Note: Object.keys() does not return symbols

// Object.getOwnPropertySymbols returns array of all symbols attached to your 'this' context

Scope vs Context in Javascript

April 15, 2020javascriptadmin

ref –

https://medium.com/better-programming/scope-vs-context-in-javascript-b31818f58558#28ec
https://stackoverflow.com/questions/14328519/different-in-scope-and-context-in-this-javascript-code

scope has two levels: global scope and local scope.

Global scope refers to variables that are accessible anywhere because they are declared outside of any individual functions or methods — usually at the top of the file. They exist in the global space, ready to be called upon at any time.

let dog = 'good boy';

console.log(dog); // good boy

function showScopeExample() {

let dog = 'bad boy';

console.log(dog); //bad boy

}

showScopeExample();

console.log(dog); //good boy

Local scope refers to variables that are accessible within the boundaries of their function. In this example, we have our initial declaration of the variable dog at the top of our file, which is assigned to the string of “goodBoy.” Immediately below, we console.log the dog variable.

As expected, this first console.log prints ‘good boy,’. Then, we have a function of showScopeExample(), which reassigns our dog variable to the string of “bad boy”.

Our re-declaration of dog inside of showScopeExample() is locally scoped. The easiest way to know this is to look at its location. The re-declaration lies in between opening and closing curly brackets, which act as barriers to the relevancy of these variables.

Limiting the accessibility of the variables declared inside of functions allows us to reuse variable names that may apply to separate parts of our code. Locally scoped variables also prevent our code from having tens or hundreds of global variables floating around the global space unnecessarily. It’s also good practice to exercise proper abstraction in our JavaScript by limiting access to variables to areas where they are needed.

In other words, Scope defines the way JavaScript resolves a variable at run time. There is only two scopes in JavaScript — global and function scope. Moreover, it also deals with something called “scope chain” that makes closures possible.

Context

Context refers primarily to the use of the keyword ‘this’. The value of ‘this‘ depends on where it is being invoked.

First Rule – Invoking this in the global space will return the entire window object. This is because the window object is the starting point of all the code we write.

But what happens if we invoke this somewhere other than the global context?

Second Rule – If we invoke this in the context of a new object, it will return that object, just as it returned the entire window object.

let newContextObj = {

key: "testing 1 2 3",

myFunc: function() {

console.log('this is my function');

invokeThisInNewContext() {

return this;

invokeTwo() {

return "testing 1 2 3";

}

} // create an object literal

newContextObject.invokeThisInNewContext();

It returns the entire newContextObj. When it is invoked in the context of an object, ‘this‘ will refer to that object.

Third Rule – In JavaScript, we use classes (or function constructors) to create multiple instances of objects that share properties, even though those properties may differ in value.
By using new, it will return us an instance, where the ‘this’ is pointing to the instance itself. The ‘this’ is can be referenced within the the class/function constructors and its methods.

Furthermore, a context of a function is the value of this for that function — i.e. the object the function is called as a method of.

function F() {

this.doSomething('good');

}

You can invoke this function in different contexts like this:

obj1 = {

doSomething: function(x) {

console.log(x);

}

obj2 = {

doSomething: function(x) {

alert(x);

}

F.call(obj1);

F.call(obj2);