DEV Community: Vignesh Pugazhendhi

Nestjs Series- Interceptors

Vignesh Pugazhendhi — Mon, 31 Jan 2022 20:30:19 +0000

Introduction

Interceptors are classes decorated with @Injectable() decorator. The core concept of interceptors is based on Aspect Oriented Programming (AOP) paradigm. AOP is a programming paradigm to that aims to increase the modularity by allowing the separation of cross-cutting concerns.

Interceptors are useful in the following scenarios:

to bind some logic before a method handler is called
to bind some logic after a method handler returns a response
transform the exception thrown from a handler
extend the basic function behaviour

Each interceptor class has to implement the NestInterceptor interface and thus have to satisfy all the method contracts.
intercept() is such a method, taking 2 arguments. First argument is ExecutionContext, which we have already discussed in nestjs pipes and guards. ExecutionContext inherits the ArgumentsHost which is a wrapper around the arguments that have been passed to the handler. By inheriting the ArgumentsHost, it has several methods to provide details about the current execution context. The second argument to intercept() is of type CallHandler. CallHandler inherits the handle() method which is used to call the route handler method at any point of the execution. This is called the Pointcut, where in additional or transformed information is being passed to the route handler method.

This means that the interceptor kind of wraps the request/response stream and thus can manipulate some logic before and after the route handler method calls. The handle() method returns an Observable, so we can use operators from rxjs to collect the response stream.

The below code snippet is taken from the official nestjs docs to cover the basic understanding of interceptors.

import {
  CallHandler,
  ExecutionContext,
  Injectable,
  Module,
  NestInterceptor,
  UseInterceptors,
} from '@nestjs/common';
import { Observable } from 'rxjs';
import { tap } from 'rxjs/operators';

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(
    context: ExecutionContext,
    next: CallHandler<any>,
  ): Observable<any> | Promise<Observable<any>> {
    console.log('Before...');
    const now = Date.now();
    return next
      .handle()
      .pipe(tap(() => console.log(`After...${Date.now() - now}`)));
  }
}

Following code snippet is used to get the request object and perform some operations on it:

import {
  CallHandler,
  NestInterceptor,
  Injectable,
  ExecutionContext,
  BadRequestException,
} from '@nestjs/common';
import { Observable } from 'rxjs';
import { tap } from 'rxjs/operators';

@Injectable()
export class DemoInterceptor implements NestInterceptor {
  intercept(
    context: ExecutionContext,
    next: CallHandler<any>,
  ): Observable<any> | Promise<Observable<any>> {
    const ctx = context.switchToHttp();
    const requestBody = ctx.getRequest()!.body as {
      name: string;
      age: number;
    };
    if (requestBody.name.length <= 7)
      throw new BadRequestException('name should be atleast 8 characters long');
    requestBody.name = requestBody.name.toUpperCase();
    return next
      .handle()
      .pipe(tap(() => console.log('response from the method handler')));
  }
}

Above code is very obvious. tap() operator of rxjs library is used to execute an anonymous function once the entire response stream is captured from the method handler().

Binding Interceptors

As with Guards and Pipes, Interceptors can be binded at one of the following three levels:

at method handler level
at module level
at global level

All you have to do is to decorator the levels with @UseInterceptors() decorator and pass on the Interceptor class or an instance of it as shown in the code below:

@Controller('user')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Post('demoInterceptor')
  @UseInterceptors(new DemoInterceptor())
  async demoInterceptor(
    @Body() userDto: { name: string; age: number },
  ): Promise<any> {
    return this.userService.createUser(userDto);
  }
}

At the global level:

const app = await NestFactory.create(AppModule);
app.useGlobalInterceptors(new LoggingInterceptor());

And at the module level:

import { Module } from '@nestjs/common';
import { APP_INTERCEPTOR } from '@nestjs/core';

@Module({
  providers: [
    {
      provide: APP_INTERCEPTOR,
      useClass: LoggingInterceptor,
    },
  ],
})
export class AppModule {}

Interceptors can be used to timeout a request handler manually. When your endpoint doesn't return anything after a period of time, you want to terminate with an error response. The following construction enables this:

mport { Injectable, NestInterceptor, ExecutionContext, CallHandler, RequestTimeoutException } from '@nestjs/common';
import { Observable, throwError, TimeoutError } from 'rxjs';
import { catchError, timeout } from 'rxjs/operators';

@Injectable()
export class TimeoutInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    return next.handle().pipe(
      timeout(5000),
      catchError(err => {
        if (err instanceof TimeoutError) {
          return throwError(new RequestTimeoutException());
        }
        return throwError(err);
      }),
    );
  };
};

Nestjs Series- Guards

Vignesh Pugazhendhi — Fri, 17 Dec 2021 18:51:28 +0000

Introduction

Guards! As the name suggests,it guards something from being accessible without permissions. Guards are a common concept in most backend frameworks,be it provided by the underlying framework or custom coded by the developer. Nestjs makes it simple for us to protect and safe guard apis from unauthorized or unauthenticated users.

Like pipes and filters, guards in nestjs are decorated with @Injectable() decorator.Every guard you use must implement the CanActivate interface. The CanActivate interface properties make it easy developers to custom code their own guard logic.

Let's understand the difference between a middleware and a guard to protect routes. A middleware is completely unaware of what is to be executed after it. A guard on the other hand has access to the ExecutionContext instance and thus knows what is to be executed exactly after it.They are much like filters and pipes and can interpose the correct logic at the correct time in a Request-Response cycle.This property proves that a middleware is dumb.

Guards are executed after each middleware and before and pipes or interceptors.

Let's understand whatever is said with an example (the below code snippet is taken from nestjs official docs):

@Injectable()
export class AuthGuard implements CanActivate{
canActivate(context:ExecutionContext):boolean|Promise<boolean>|Observable<boolean>{
   const request=context.switchToHttpRequest().getRequest();
   //code to validate the request object for roles and 
   //restrictions
}
}

Going through the snippet, most of you must have understood the use of ExecutioContext.But what if one is wants to get the websocket connection context or a gql execution context. ExecutionContext covers all of them. All you need to do is switch to the appropriate context of your need and manipulate the logic. The ExecutionContext class extends the ArgumentsHost, providing you with the right methods to switch between the contexts. You can checkout the official docs as per your needs as this is out of the scope of this article.

Let's talk about binding these guards now. As with pipes, filters and interceptors, guards can be controller-scoped,method-scoped or globally-scoped.Below we use a guard at the controller-scope level using @UseGuards() decorator.

@Controller('pokemons')
@UseGuards(AuthGuard)
export class PokemonController{}

We have passed the class name of the Guard to the decorator. You can even pass and instance to the Guard or even a list of instances or types.

Setting up roles

Roles are a way to tell the controller methods to allow the request-response cycle to complete.If a particular role is not authorized to access an endpoint, the request-response cycle is ended here by returning an unauthorized error message, typically with a 401 HTTP statuscode. Our guards are very smart but they do not know which roles are allowed for which endpoints.This is where custom metadata comes into play. With custom metadata, we can segregate endpoints based on the roles as shown below:

@Post("/updateAccess") 
@SetMetadata('roles',['admin','superadmin'])
async updateReadWriteAccessofUser(@Body() inputDto:any):Promise<boolean>{
  this.adminService(inputDto);
}

Now we have assigned the roles to the updateReadWriteAccessOfUser method. Only the user with "admin" and "superadmin" roles can access this endpoint "/updateAccess".While this is enough for this concept to be understood, it is not a good practice to assign roles directly on the controller methods. Instead we can code our own decorator for this and use it. We code this such that it follows DRY solid principle.

import {SetMetadata} from '@nestjs/common';

export const Roles = (...roles: string[]) => SetMetadata('roles', roles);

Now you can reuse this decorator whereever needed.

@Post("/updateAccess") 
@Roles(["admin","superadmin"])
async updateReadWriteAccessofUser(@Body() inputDto:any):Promise<boolean>{
  this.adminService(inputDto);
}

Now we combine the concepts of roles and guards to protect our endpoint from unauthorized requests.

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Reflector } from '@nestjs/core';

@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const roles = this.reflector.get<string[]>('roles', context.getHandler());
    if (!roles) {
      return true;
    }
    const request = context.switchToHttp().getRequest();
    const user = request.user;
    return verifyRoles(roles, user.roles);
  }
}

export function Roles(...roles: string[]) {
    return applyDecorators(
        SetMetadata('roles', roles),
        UseGuards(RolesGuard),
    );
}

The Reflector helper class is provided by the nestjs framework to access the controller method's roles. We verify the roles the current request's roles and return a boolean based on the verification. In the second code snippet, we make use of this RolesGuard as a paramter to the applyDecorators. The applyDecorators method combines multiple decorators and executes them.

Any exception thrown by a guard will be handled by the exceptions layer (global exceptions filter and any exceptions filters that are applied to the current context).

NestJS Series - Pipes

Vignesh Pugazhendhi — Sat, 20 Nov 2021 12:55:35 +0000

Most backend developers can relate the pain of validating and transforming the data passed in the request body or in params or in queries. Most of us either code custom validation and transformation methods or use any open source library. Nestjs supports both through pipes. Pipes in nestjs like any other backend framework have two typical use cases:

1. transformation
2. validation

In transformation, the input data is transformed into a desired form, eg: transforming every string in an array to lowercase or uppercase.

In validation, we validate the input data and simply pass it unchanged if the data is correct and throw an error if the data is incorrect.

Pipes handle both the cases by operating on the arguments being passed to a route controller or a resolver.Nest interposes pipes before any controlled or a resolver method is executed. Pipes receive the arguments passed to the controller and either of validation or transformation code is run on the arguments to decide whether to throw an exception or to transform the data or to pass it unchanged back to the controller's context.

NodeJS developers might worry about exception handling but nestjs takes care of exceptions thrown by pipes. Pipes run only inside the exception zone and all the error handing stuff is taken care by the underlying framework.

Nestjs comes with 8 built in pipes out of which 6 are transformation pipes and 1 is a validation pipe.There is an extra pipe which sets a default value, known as the DefaultValuePipe.Enough of the theory, let's jump into the code:

@Get(':_id')
async findUserById(@

Param('_id',ParseIntPipe) id:number):Promise<UserDto>{
   return this.userService.findById(id);
}

ParseIntPipe transforms the param _id from a string to a number. Notice how we have binded the pipe in the @param decorator.You can also instantiate the pipe yourself and change it's behaviour if needed or let nestjs do it for you:

@Get(':_id')
async findUserById(@Param('_id',new ParseIntPipe( errorHttpStatusCode: HttpStatus.NOT_ACCEPTABLE })) id:number):Promise<UserDto>{
   return this.userService.findById(id);
}

As long as your need is minute, you can use the nestjs's built-in transformation pipes.But what if your pipes need to transform or validate based on your project's use cases. Well nest allows us to build our own custom pipes. All we have to do is to implement the PipeTransform class and fulfill the contract of using it's method, transform. This is shown below:

import {PipeTransform,Injectable,ArgumentMetaData} from '@nestjs/common';

@Injectable()
export class CustomPipeTransformation implements PipeTransform{
async transform(value:any,metadata:ArgumentMetaData){
return value;
}
}

Here value is the data you pass in the request body or as params or as queries. metadata of type ArgumentMetaData contains the metadata associated with the data you pass.

This is an object with 3 keys, data,type and metatype.

export interface ArgumentMetadata {
  type: 'body' | 'query' | 'param' | 'custom';
  metatype?: Type<unknown>;
  data?: string;
}

type denotes how you pass the data, either in body or in params or in queries.
metatype is the type of the data you send, eg:string
data is the name you pass to the decorator. eg: @Body('email')

These 3 keys and the value argument can enough to transform or validate your data. Following code snippet converts an argument of array of strings to array of uppercase strings.That is each element in the array is transformed to it's uppercase version.

import {
  PipeTransform,
  Injectable,
  ArgumentMetadata,
  BadRequestException,
} from '@nestjs/common';
import { string } from 'joi';

@Injectable()
export class PipeTransformCustom implements PipeTransform<any> {
  async transform(value: any, { data, type, metatype }: ArgumentMetadata) {
    if (this.isTypeAcceptable(metatype, value) && type==='body') {
      return (value as string[]).map((val: string) => val.toLocaleUpperCase());
    }
    throw new BadRequestException(
      `Argument expected should be an array of strings!`,
    );
  }
  isTypeAcceptable(type: any, value: any): boolean {
    if (typeof type === 'function' && Array.isArray(value)) {
      return value.every((val) => typeof val === 'string');
    }
    return false;
  }
}

Note how we destructure the metadata and make use of it's keys. First the metatype is being checked if it is of type "function" and value being checked if it is an array. Once this is done, we check if every element in the array is of type "string". Once both the cases pass, we convert every element of the array to it's locale uppercase. This example is a combination of both validation and transformation.

To make use of this pipe,

@Controller('convert-upper-case')
@UsePipes(PipeTransformCustom)
async convertToUppercase(@Body('array') array:string[]):string[]>{
return Promise.resolve(()=>array);
}

There's another type of validation known as schema-based validation which validates your request body data against a schema. By schema I don't mean an actual DB schema,it may be an interface or class.

This is explained in the following code:

export class UserSignupDto{
email:string;
username:string;
phone:number;
above18:boolean;
}

Now to validate any incoming data against this schema, we have two options: either we can do it manually as explained above or we can make use of libraries. The Joi library allows you to create schemas in a straightforward way, with a readable API

npm i joi --save
npm i @types/joi --save-dev

We install types support for Joi as a dev dependency.Now to utilize this lib,

import { PipeTransform, Injectable, ArgumentMetadata, BadRequestException } from '@nestjs/common';
import { ObjectSchema } from 'joi';

@Injectable()
export class JoiValidationPipe implements PipeTransform {
  constructor(private schema: ObjectSchema) {}

  transform(value: any, metadata: ArgumentMetadata) {
    const { error } = this.schema.validate(value);
    if (error) {
      throw new BadRequestException('Validation failed');
    }
    return value;
  }
}

@Post()
@UsePipes(new JoiValidationPipe(UserSignupDto))
async create(@Body() createUserDto: UsersignupDto) {
  this.userService.create(createUserDto);
}

here we make use of Joi lib to validate the data against the UserSignupDto. The code is pretty starightforward and can be understood easily. That's how Joi makes validation look easy.

An added advantage of nest is it works well with class-validator library. This powerful library allows you to use decorator-based validation. Decorator-based validation is extremely powerful, especially when combined with Nest's Pipe capabilities since we have access to the metatype of the processed property.

npm i --save class-validator class-transformer

Once installed we can add decorators to our UserSignupDto schema.

import {IsString,IsBoolean,IsNumber} from 'class-validator';

export class UserSignupDto{
@IsString()
email:string;
@IsString()
username:string;
@IsNumber()
phone:number;
@IsBoolean()
above18:boolean;
}

If needed, you can read about class-validator here class-validator

You can also bind pipes at different contexts of the code- be it an controller level, module level or at global level.

I'm attaching the code snippets from official docs for module and global level. Please refer to the docs if an in-depth knowledge is needed.

Module level

import { Module } from '@nestjs/common';
import { APP_PIPE } from '@nestjs/core';

@Module({
  providers: [
    {
      provide: APP_PIPE,
      useClass: ValidationPipe,
    },
  ],
})
export class AppModule {}

Global Level

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe());
  await app.listen(3000);
}
bootstrap();

Pipes to some extent make the code less vulnerable to production bugs.

Conditionally render your DOM in ReactJS

Vignesh Pugazhendhi — Fri, 05 Nov 2021 21:24:56 +0000

Most single page applications are dynamic and change content frequently depending upon the end user's actions.One of the features of reactjs that allows this is called conditional rendering. Reactjs allows us to render a fragment of DOM conditionally. This is very much similar to conditional statements in any programming language.

Conditions can be applied to a number of scenarios. The below are not limited to but are some cases where condtional rendering can be used:

render data of an API call
show or hide elements based on user's actions such as a button click or a change in the value of a dropdown
to toggle application functionality
hide or display elements based on roles (authorization)

Below are some of the ways to condtionally render a DOM fragment:

1. Using If...Else

This can be opted if and only if the condition holds two values.Following code snippet explains the use of If..Else conditional statement.

const DISCOUNTS=["offer',"promocode"];
export default function App({...props})=>{
   const [discountSelected,setDiscountSelected]=useState(DISCOUNTS[0]);
   function renderForm(){
      if(discountSelected===DISCOUNTS[0]){
         <form>
           <label>Offer Name</label>
           <input type="text" />
         </form>
      }else{
         <form>
           <label>Promocode Name</label>
           <input type="text" />
         </form>
      }
   }
   function handleDiscountChange(){
     if(discountSelected===DISCOUNTS[0]){
        setDiscountSelected(DISCOUNTS[1]);
     }else{
        setDiscountSelected(DISCOUNTS[0])
     }
   }
   return (
     <div>
        <button onClick={handleDiscountChange}>Change Discount Type</button>
        {renderForm()}
     </div>
   );
}

We could have conditionally rendered the component inside the return statement but it is always advisable to keep your code clean.

2. Using Switch Statement

The above result could be achieved using a simple switch statement but always use a switch statement only when you want to render DOM based on many different values.

const AuthButton = props => {
  let { isLoggedIn } = props;

  switch (isLoggedIn) {
    case true:
      return <button>Logout</button>;
      break;
    case false:
      return <button>Login</button>;
      break;
    default:
      return null;
  }
};

3. Using variables

Variables can be used to render DOM conditionally. Initialize a variable and set it value to some snippet of DOM based on the conditions.Below code fragment explains the use case

export default function App(){
    let { isLoggedIn } = this.state;
    let AuthButton;

    if (isLoggedIn) {
      AuthButton = <button>Logout</button>;
    } else {
      AuthButton = <button>Login</button>;
    }

    return (
      <div className="App">
        <h1>
           Conditional rendering using variables
        </h1>
        {AuthButton}
      </div>
    );

}

4. Using ternary operator

Ternary operator is similar to If...Else statement expect for the fact that the code is clean and as small as possible.

export default function App({...props}){
  let { isLoggedIn } = this.state;

    return (
      <div className="App">
        <h1>
          This is a Demo showing several ways to implement Conditional Rendering in React.
        </h1>
        {isLoggedIn ? <button>Logout</button> : <button>Login</button>}
      </div>
    );
}

5. Using Short Circuit Evaluation
This can be used with a single condition or a combination of conditions. Below code fragment demonstrates the use case:

export const App=(props)=>{
  let { isLoggedIn } = this.state;

    return (
      <div className="App">
        <h1>
          This is a Demo showing several ways to implement Conditional Rendering in React.
        </h1>
        {isLoggedIn && <button>Logout</button>}
      </div>
    );
}

6. IIFEs

Immediately invoked functions or IIFEs can be used to execute a function code block with any of the above use cases:

export default function App(props){
  return (
      <div className="App">
        <h1>
          This is a Demo showing several ways to implement Conditional Rendering in React.
        </h1>
        {(function() {
          if (isLoggedIn) {
            return <button>Logout</button>;
          } else {
            return <button>Login</button>;
          }
        })()}
      </div>
    );
}

``

Unit testing a react component which uses context API

Vignesh Pugazhendhi — Tue, 31 Aug 2021 17:55:39 +0000

Unit Testing

In programming, unit testing is the method to test a single unit of code. A single unit of code may be one or more program modules combined together or the smallest unit of working code that cannot be divided further, by doing so the unit on the whole is not functional as expected.If you are familiar with reactjs testing libraries like jest and enzyme, jasmine or react-testing-library, you must have tested individual components on the top level by shallow rendering. Shallow rendering renders a particular component without rendering it's children for it to be tested.Here we will be learning how to unit test a react component using context API with the help of enzyme testing utility.

Enzyme

Enzyme is not a testing library.It is more of a testing utility which lets you manipulate,traverse,interact with the DOM elements. Enzyme can be used with jest or karma or mocha depending upon the need.

Context API

Context API by reactjs provides a way to pass down the data to the components without having to actually pass the data as props at each level. For example, consider component A having 3 nested children B,C and D.If A has to pass some values to D,instead of prop drilling the values, one can wrap the component D as a consumer of the context and A as a provider.
Context API might sound similar to react-redux architecture but it is completely different from it.
For those who do not have an experience working with context API, you can go through the reactjs documentation for better understanding

unit testing context api

Consider the following piece of code to setup a context:

import React from 'react';

export default React.createContext("en")

Let's call this file languageContext.js. Now since the context is now defined, we can wrap our root component as the provider.

import React, { useEffect, useState } from "react";
import "./App.css";
import GuessedWord from "./GuessedWord/GuessedWord";
import LanguagePicker from "./GuessedWord/LanguagePicker";
import languageContext from "./languageContext";

/**
 * @function reducer to update state automatically when dispatch is called
 * @param state {object} previous state
 * @param action {object} type and payload properties
 * @return {object} new state
 */

const reducer = (state, action) => {
  switch (action.type) {
    case "setSecretWord":
      return { ...state, secretWord: action.payload };
    case "setLanguage":
      return { ...state, language: action.payload };
    default:
      throw new Error(`Invalid action type ${action.type}`);
  }
};

function App(props) {
  //const [secretWord,setSecretWord]=useState('');

  const [state, dispatch] = React.useReducer(reducer, {
    secretWord: "",
    language: "en",
  });

  const success = false;
  const guessedWords = [];

  const setSecretWord = (secretWord) => {
    dispatch({ type: "setSecretWord", payload: secretWord });
  };

  const setLanguage = (lang) => {
    dispatch({ type: "setLanguage", payload: lang });
  };

  useEffect(() => {
    getSecretWord(setSecretWord);
  }, []);

  let content;
  if (!state.secretWord.length) content = <div data-test="spinner" />;
  else
    content = (
      <>
        <h1>Jotto</h1>
        <languageContext.Provider value={state.language}>
          <LanguagePicker setLanguage={setLanguage} />
          <GuessedWord guessedWords={guessedWords} />
        </languageContext.Provider>
      </>
    );

  return <div data-test="component-app">{content}</div>;
}

export default App;

The LanguagePicker component is as follows:

import React from "react";
import propTypes from "prop-types";

function LanguagePicker({setLanguage}) {
  const languages = [
    { code: "en", symbol: "🇺🇸" },
    { code: "ar", symbol: "🇦🇪" },
  ];
  const languageIcons = languages.map((lang) => {
    return (
      <span
        key={lang.code}
        data-test="language-icon"
        onClick={() => setLanguage(lang.code)}
      >
        {lang.symbol}
      </span>
    );
  });
  return <div data-test="component-language-picker">{languageIcons}</div>;
}

LanguagePicker.propTypes = {
  setLanguage: propTypes.func.isRequired,
};

export default LanguagePicker;

The LanguagePicker component allows us to select a language of preference which we store in a local state of our root-level component. We wrap the App.js,our root-level-component as a Context Provider. This is done so that the root-level component acts a data provider to the child components. We pass the data as a "value" prop. So each of the child components now has access to this value prop as each of them act as a consumer.

The GuessedWords component is as follows:

import React from "react";
import PropTypes from "prop-types";

//services and helpers
import languageContext from "../context/languageContext";
import {getStringsByLanguage} from './strings';

function GuessedWord({ guessedWords }) {
  const language=React.useContext(languageContext);
  if (!guessedWords.length)
    return (
      <div data-test="guessed-word-component">
        <span data-test="instructions">{getStringsByLanguage(language,"guessPrompt")}</span>
      </div>
    );
  return (
    <div data-test="guessed-word-component">
      <table data-test="table">
        <thead>
          <tr>
            <th>GuessedWord</th>
            <th>Match Count</th>
          </tr>
        </thead>
        <tbody>
          {guessedWords.map((guess, index) => (
            <tr key={index} data-test="rows">
              <th>{guess.guessedWord}</th>
              <th>{guess.match}</th>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

GuessedWord.propTypes = {
  guessedWords: PropTypes.arrayOf(
    PropTypes.shape({
      guessedWord: PropTypes.string.isRequired,
      match: PropTypes.number.isRequired,
    })
  ).isRequired,
};

export default GuessedWord;

We make use of React.useContext() hook to access the "value" prop of the parent component's provider wrapper. We pass the languageContext as an argument to the hook.
The function getStringsByLanguage returns the localized string based on the language chosen. Now our task is to unit test this component. We test two scenarios here. If the language chosen is "en", we will return "Try to guess the secret word". If the language chosen is "ar" , we return "حاول تخمين الكلمة السرية". The code for the unit test file is as follows:

import { shallow } from "enzyme";
import checkPropTypes from "check-prop-types";
import GuessedWord from "./GuessedWord";


const defaultProps = {
  guessedWords: [{ guessedWord: "train", match: 3 }],
};

const setup = (props = defaultProps) => {
  return shallow(<GuessedWord {...props} />);
};
describe("language picker scenarios", () => {
  test("should prompt the guess instruction in english", () => {
    const wrapper = setup({ guessedWords: [] });
    const guessInstruction = wrapper.find(`[data-test="instructions"]`);
    expect(guessInstruction.text()).toBe("Try to guess the secret word");
  });
  test("should prompt the guess instruction in arabic", () => {
    const originalUseContext = React.useContext;
    const mockReactUseContext = jest.fn().mockReturnValue("ar");
    React.useContext = mockReactUseContext;
    const wrapper = setup({ guessedWords: [] });
    const guessInstruction =  wrapper.find(`[data-test="instructions"]`);
expect(guessInstruction.text()).toBe("حاول تخمين الكلمة السرية");
React.useContext=originalUseContext;
  });
});

We shallow render the GuessedWords component. We know that the default language is "en" in the context provider.So the first test case should be obvious to you. In the second test case, we mock the original React.useContext() hook and we set the language as "ar"; Now since the language is set to arabic and the GuessedWords component is shallow rendered, our assertion should be the text displayed in arabic.It is always a good practice to mock your functions or hooks in your component and restore them after each assertion.This is done so that the original definition of your function or hook is restored for all other test cases in your test suite which are using them.

GraphQL-update cache and network fetch policies

Vignesh Pugazhendhi — Thu, 08 Jul 2021 17:24:14 +0000

I expect the readers to have basic graphql knowledge, how to setup a graphql server, how to mutate and query from a reactjs application using a gql library like apollo-client. We will move ahead with react apollo client library. Apollo client is a declarative data fetching and management library for your reactjs applications wherein different states of fetching data from an API or from a remote server can be managed. Traditional ways of doing the same thing can be achieved using RESTful webservice. In RESTful webservice, we expect the webAPI XMLHttpRequest to listen to various events based on which we can alter the UI. For example, when a XMLHttpRequest is made, we can show up a loader to indicate the request has been made and is been processed by the server.Once we receive the data from the server, we can render the result instead of showing up a loader. There are many libraries which can take care of all the events occuring in a promisified way like axios,superagent or the fetch api itself. So if all these events can be managed by such good well coded libraries, why do we opt for graphql?

Advantages of GQL over RESTful webservice:

Instead of working with fixed rigid server-defined endpoints,you can make a single query request to a gql server demanding only those parts of data you need.
GQL reduces the number of endpoints your application makes request to. A single resolver can be used to handle multiple request formats
In REST, each request calls exactly one request handler whereas in gql,one query may call many resolvers to construct a nested response.
In REST, you define the structure of the response, whereas in graphql the shape of the response is built up by the GraphQL execution library to match the shape of the query.

Understand how to update cache
In order to implement caching in GQL, one needs to figure it out which one of the following scenarios covers your requirement:

Consider the following code snippet of a gql server:

import {ApolloServer,gql} from 'apollo-server';

const typeDefs=gql`
type Book{
  id:ID!
  title:String!
  author:String!
}
type Mutation{
  createBook(title:String!,author:String!):Book!
  updateBook(id:String!,title:String!,author:String!):Book!
  deleteBook(id:String!):Boolean!
}
type Query{
  books:[Book!]!
  searchBook(searchKey:String!):[Book!]!
}
`;

const resolvers={
  Mutation:{
    createBook:(_,{title,author})=>{
    const book={id:`${books.length+1}`,title,author}
    books.push(book);
    return book;
  },
  updateBook:(_,Book){
    books=books.map(x=>x.id===book.id?book:x)
    return book;
  },
  deleteBook:(_,{id}){
    books=books.filter(x=>x.id!==id);
    return true;
  }
},
Query:{
  books:()=>books,
  searchBooks:(_,{searchKey})=>{
    const searchedBooks=books.filter((book)=>{
    return book.title.includes(searchey)
    }
    return searchBooks;
  }
}

This is a book repository backend application where you can create,read,update and delete a book.Also searchBooks query is used to search books from the repository based on a searchKey.

Now what we want is to show the user a created book without he/she refreshing a page, a delete book should be removed from UI without refreshing a page, a book should be update and again without refreshing the page.This is where caching comes into play. What gql does is it updates the cache based on a unique and __typename returned by the gql server.For eg, when we create a book, the response would be :

{
id,
title,
author
__typename:Book
}

Your web browser cache is a lookup table or a hashtable to be precise.GQL combines id and __typename to assign a key as a hash and the response as it's corresponding value.This key-value pair is responsible for fetching data from your browser's cache in a constant time O(1) which we will be looking at once we understand network fetch-policies.

Scenario 1 : creating a book

This case has two sub cases whereby you can update your UI without refreshing the page.

 createBook({
      variables: {
        title: "Megastructures",
        author: "Discovery",
      },
      refetchQueries:[{query:Q_FETCH_BOOKS}]
    });

createBook({
      variables: {
        title: "Malaysian Dreams",
        author: "travel and living",
      },
      update: (store, { data }) => {            //data is response from api
        const bookData = store.readQuery({ query: Q_FETCH_BOOKS });
        store.writeQuery({
          query: Q_FETCH_BOOKS,
          data: {
            books: [...bookData.books, data.createBook],
          },
        });
      },
    });

refetch is basically going to fetch the updated db and return it to the client once the mutation is completed whereas in the second case we manually update the cache.GQL makes use of the id and __typename of update the cache and UI automatically. A frontend developer need not do anything else other than updating the cache the cache manually and the rest is taken care by the apollo-client.

Scenario 2 : update a book:

updateBook({
      variables: {
        id: "1",
        title: "Banged up abroad",
        author: "National Geographic",
      },
    });

This is very much similar to scenario 1, except for the fact that we do not need to update the cache manually.Apollo client will map the updated data to the hashtable based on the combination of id+__typename

Scenario 3: Deleting a book

Delete is similar to the subcase 2 of scenario 1. Send a mutation to the server, once it is confirmed that the book is deleted in the server, update the cache manually.

Scenario 4: Searching a book

const [searchBook, { loading, data, error }] = useLazyQuery(Q_SEARCH_BOOKS, {
    onCompleted: (data) => {
      console.log(" search books onCompleted", data);
    },
    fetchPolicy: "cache-and-network",
  });

Fetch Policies:

cache-first

default policy
cache is checked first. If requested data is present,the data is returned. Else network request is made to api & cache is updated
Better option to update the cache

cache-and-network

cache is checked first. Regardless of whether data is found or not, a network request is made to get upto date data
updates the cache wrt to network response
can be useful when an operation is performed in one of the sub-component and you need updated data in it's sibling component.

network-only

always makes a network request. Will update the cache for other queries

no-cache

similar to network-only. Does not update cache

cache-only

never makes a network request,always returns data from the cache.

Lazy Loading In ReactJS

Vignesh Pugazhendhi — Mon, 29 Mar 2021 12:29:54 +0000

Ever worked with or tried to understand the concepts of a web bundler like webpack or browserify? We often split the source code and import the dependencies where ever required. What we work in, is a code splitted environment where we code UI and business logic into different components and import them at the required places. In a broad terminology, this is known as modular programming. If you try inspecting your UI in a developer's tool, you can see all the components are loaded at once. This is because all the dependencies are bundled together and imported as a single file. This is known as bundling.

Now, as your app grows, your bundler will try to import all the dependencies including any third party packages and libraries installed, all at once. This might make your application to take an ample amount of time to load. Reactjs >=16.6 has introduced a common design pattern called lazy loading, which defers the initialization of an object until the point in the code where it is really needed. This might sound analogous to promises in js, but trust me this is going to save millions for your company.

React.lazy

lazy is a function to import your components dynamically. By dynamically, I mean the component is only loaded when it is needed.

import someComponent from './someComponent';

The above code snippet might be bundled by your bundler as a normal dependency. What we might want could be:

const someComponent=React.lazy(()=>import('./someComponent'));

This is called dynamic importing. React.lazy() expects a promise. This promise resolves to a module. While this component is being loaded, you might need a fallback such as a loader.

Wrap the imported component with <Suspense></Suspense>. The component takes a fallback prop. The fallback is rendered meanwhile the dynamic import is resolved into a module.

import React from 'react';
import Loader from './loader';

const someComponent=React.lazy(()=>import('./someComponent'));
const otherComponent=React.lazy(()+.import('./otherComponent'));

export default ()=>{
return (
 <React.Suspense fallback={<Loader/>}>
   <someComponent/>
   <otherComponent/>
 </React.Suspense>
);
}

Instead of wrapping a whole component with component, you can wrap those sections of the component where lazy loading is to be applied. Adding further, there might a situation where a component may not be loaded due to technical issues such as a network error or gql error. In that case, global error handling can be done using ErrorBoundary.

Scenarios where you may need lazy loading

Routing : If your application is a SPA with multiple routes, you may need to load components only when they are routed.
To improve you app performance : You may not want your customers to experience a poor UI/UX experience by loading all heavy components at once.
Assets : If your application contains media files such as images and audio files, for eg in a music player app, you may want to load assets only when the end user needs it.

Limitations

Lazy loading feature is still not a usable feature is server-side rendered applications (SSR) . However, make use of reactjs provided Loadable components if needed.

let or const or var? When to use what?

Vignesh Pugazhendhi — Wed, 03 Mar 2021 19:14:20 +0000

Unlike most programming languages, javascript variables are declared with the var keyword. Before es6, var was much prevalent and was commonly used to declare and initialize variables. Javascript is a weird language. Expect the unexpected when working with js. So, what was the need of two new keywords when var does everything you need to declare and initialize variables. Well, there are three main issues to be looked upon next time you decide to use var.

Scope

Variables declared with var keyword can be either globally scoped or locally scoped(inside a function or a block of code).By globally scoped, I mean the variable is accessible throughout the document or in the whole window. Locally scoped variables are available only within the function body or block of code in which it is declared.

var pokemon="pikachu";
function catchNewPokemon(){
  var newPokemon="charmendar";
}

Here, pokemon is globally scoped and newPokemon is locally scoped.
newPokemon cannot be accessed outside the function. Doing so will throw a reference error.

Redeclaration
A variable declared with var keyword can be redeclared within the same scope. Doing so might produce buggy codes.

var pokemon="Bulbasaur";
var pokemon="Ivasaur";

Let's say you declare a variable pokemon in line 119 of your production code and again re-declare pokemon in line 556 unknowingly.
The subsequent code after line 556, will be carrying a value you assigned to it in line 556.

Hoisting

All variables declared with var are automatically hoisted to the top of their scopes. For example :

console.log(pokemon)
var pokemon="pikachu"

will throw no undefined variable error as pokemon is hoisted automatically to the top of it's scope.

Now, to overcome the above issues, ECMAScript, an internationally recognized standard, has come up with two new keywords let and const.

let
let is by default block scoped. Now matter how many times you declare the same variable in your code, the compiler won't throw an error unless the variables are in different scopes.

let pokemon="pikachu";
const catchPokemon=()=>{
   let pokemon="bulbasaur";
   console.log(pokemon)  //consoles bulbasaur
}
console.log(pokemon) //consoles pikachu

Also, variable declared with let can only be updated and cannot be declared within the same scope.

let pokemon="pikachu";
let pokemon="raichu"; //error:Identifier pokemon has been already declared

Like var, variables declared with let are hoisted to the top of their scopes. The only difference is, here they are not initialized as undefined. You will get a reference error if you try to use a variable before it is declared.

const

Identifiers declared with const are block scoped and cannot be updated once they are declared and initialized. Infact, declaration and initialization happens at the same time. You cannot declare a const and initialize it later.

const pokemon;
pokemon="pikachu"; //error: Uncaught SyntaxError: Missing initializer in const declaration

const pokemon="squirtle";
pokemon="Blastoise"; //error: Identifier 'pokemon' has already been declared

Try using let everywhere in the code whenever you declare a variable.
Use const only if you need an identifier to carry a constant value throughout your code.

How to setup a centralised data store using redux in your React application

Vignesh Pugazhendhi — Tue, 02 Mar 2021 18:03:59 +0000

Redux

Redux is an open source js library for managing your application's state. Redux is commonly used with js libraries like reactjs and frontend frameworks such as angular. A redux store works on the principle of a javascript reducer where the centralised application state is updated with the help of an action dispatcher. An action dispatcher dispatches an action object which describes what is to be done with the application state. An action object is a simple js object with keys "type" and "payload". "type" describes the action to be performed and "payload" is the actual data used to update or mutate the application state. Here's an example of an action object :

{type:'ADD_ITEM',payload:'Android'}

'ADD_ITEM' describes the action event and 'Android' is the data to be mutated in the state.

To make it clear, go through the following code snippet:

const initialState={
  items:[]
}

function rootReducer=(state=initialState,action){
  switch(action.type){
     case 'ADD_ITEM':
        return {...state,items:[...state.items,action.payload]}
     case 'REMOVE_ITEM':
        const filteredItems=state.items.filter(item=>item!==action.payload)
        return {...state,items:filteredItems}
     default:
        return {...state}
  }
}

Create a store with redux

Upto this point, I hope the concepts of state, action and dispatch objects might be clear. The next question is how do I create a store and update it with the help of action objects. For this, install the redux library using npm or you can go with a cdn if node is not installed in your system.

npm install redux

redux has made it possible to create a centralised store easily with a single line of code. All you have to do is, pass the reducer as an argument to the createStore() function of redux. This acts as a channel to dispatch your action objects and listen to state updates. Go through the modified snippet below :

import {createStore} from 'redux';

const initialState={
  items:[]
}

function rootReducer=(state=initialState,action){
  switch(action.type){
     case 'ADD_ITEM':
        return {...state,items:[...state.items,action.payload]}
     case 'REMOVE_ITEM':
        const filteredItems=state.items.filter(item=>item!==action.payload)
        return {...state,items:filteredItems}
     default:
        return {...state}
  }
}

const store=createStore(rootReducer);

console.log(store.getState());
store.dispatch({type:'ADD_ITEM',payload:'Android'})
store.dispatch({type:'ADD_ITEM',payload:'ios'})
console.log(store.getState());
store.dispatch({type:'REMOVE_ITEM',payload:'Android'})
console.log(store.getState());

Try to guess the outputs of the console.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
{items:['Android','ios']}
{items:['Android']}

This was a just a jist of the redux architecture. As mentioned already, redux is the perfect option for a centralised persistent state that goes well with reactjs.

Now to connect your store with your react application, install react-redux library. Assuming you are using npm package manager with a module bundler like webpack or browersify :

npm install react-redux

Now wrap your top level component, usually App.js , with a component, with your store passed as a prop. You can do this in index.js file too.

index.js

import { StrictMode } from "react";
import ReactDOM from "react-dom";
import {Provider} from 'react-redux';

import {store} from './configureStore.js';
import App from "./App";

const rootElement = document.getElementById("root");
ReactDOM.render(
  <StrictMode>
    <Provider store={store}><App /></Provider>
  </StrictMode>,
  rootElement
);

The above code snippet assumes you create a store in configureStore.js file in the same way as we did earlier. Now you can use the centralised state in your components without the need to prop drill through the components. Make use of useDispatch() and useSelector() hooks to dispatch an action object and get state values. Following code snippet gives an idea on how to use these two handy hooks :

import React,{useState} from 'react';
import {useDispatch,useSelector} from 'react-redux';
export default (props)=>{
  const [newItem,setNewItem]=useState('');
  const dispatch=useDispatch();
  const state=useSelector();

  function newItemHandler(){
    dispatch({type:'ADD_ITEM',payload:newItem})
  }

  return (
    <div>
    {!state.items.length?<h1>List is empty</h1>:
      <ul>
         {state.items.map(item=><li>{item}</li>)}
      </ul>
    }
    <input 
     type="text" 
     placeholder="add new item"
     value={newItem}
     onChange={e=>setNewItem(e.target.value}
     /> 
    <button onClick={newItemHandler}>Add New Item</button>
    </div>
  );
}

Difference between useCallback(),useMemo() and React.memo()

Vignesh Pugazhendhi — Mon, 01 Mar 2021 13:57:32 +0000

Reconciliation or selective re-rendering is a major boost in the performance optimization of a React application. By selective re-rendering, I mean only those sub-components are re-rendered which witness a change in it's state or props passed to it. This is taken care by the React's virtual DOM, which computes the differences between the DOM and updates the UI efficiently. A component is re-rendered if and only if either of the props passed or it's local state is changed. And when a component is re-rendered, it's child components are re-rendered.

React.memo

React.memo was introduced in functional components in react v16.6. React.memo is a convenient way to avoid re-rendering in functional components. All you have to do is to wrap the functional component with React.memo() HOC(Higher Order Component). It can be used for both class based and functional components. It compares the props passed and the local state between any two consecutive re-renders and can bail out a component from re-rendering if there is no change in the props and the state. Go through the following code snippet to understand the memoization of components:

import React,{useState} from 'react';
import ComponentB from './ComponentB';
import Trainer from './Trainer';

function ComponentA() {
    const [pokemons,setPokemons]=useState(
    ["bulbasaur","charmendar","pikachu"]
);
    const [trainer,setTrainer]=useState('');

    console.log('componentA rendered');

    return (
        <div>
            <Trainer handleTrainer={setTrainer}/>
            <ComponentB pokemons={pokemons}/>
            <span>{trainer}</span>
        </div>
    )
}

export default ComponentA

import React from 'react';
import styled from 'styled-components';

function Trainer({handleTrainer}) {

    console.log('Trainer rendered');

    return (
        <div>
            <Input onChange={(e)=>handleTrainer(e.target.value)}/>
        </div>
    )
}

const Input=styled
.input
.attrs((props)=>({type:'text',placeholder:'Trainer'}))`
border:2px solid black;
margin:auto;
margin-bottom:20px !important;
margin-top:10px !important;
max-width:50%;
`;

export default Trainer;

import React from 'react';
import styled from 'styled-components';

function ComponentB({pokemons}) {

    console.log('ComponentB rendered');

    return (
        <React.Fragment>
            <UnorderedList>
                {pokemons.map((pokemon,index)=>{
                    return <ListItem key={index}>{pokemon}</ListItem>
                })}
            </UnorderedList>
        </React.Fragment>
    )
}

const UnorderedList=styled.ul`
list-style-type:none;
`;
const ListItem=styled.li`
border:1px solid transparent;
margin:auto;
margin-top:20px !important;
width:50%;
background:#00e6ac;
color:white;
text-transform:capitalize;
`;

export default ComponentB;

Code breakdown

ComponentA is the parent component of ComponentB and Trainer. Local state pokemons is passed as a prop to ComponentB and setTrainer function is passed as a prop to Trainer. When the application loads for the first time, the parent component along with it's children are rendered. You can console.log and check the number of rendering in your browser's developer tools. For every state update of the ComponentA, both ComponentB and Trainer are re-rendered,which we do not want to. To avoid unnecessary renderings, wrap both the children components with React.memo() HOC. Wrapping the components with React.memo() compares the props between two consecutive renders and bails out unnecessary re-renders of it's children components. Though it can memoize the components and boost the performance of the application to a certain level, there is always a catch. A good use case where this can be used is when there are atleast 10 nested components with complex computations. Comparison of props for 2-3 components can be little costly in terms of memoization.

UseCallback
Suppose we pass a callback function clearTrainer() to ComponentB through props. The purpose of this function is to clear the trainer state to empty string. Now,run the application and you should see 'componentB rendering' in your developer console. This turns out to be unexpected as ComponentB is wrapped with React.memo(). For this to be understood,we need to understand function equality in javascript. Every function in js is an object. For two objects to be equal,it's necessary for both of them to be of same definition and share same location in memory. Now every time ComponentA is re-rendered,a new instance of clearTrainer() function is created. So for subsequent re-renders,we are passing two different instances of the same function definition and thus ComponentB also re-renders. To solve this,we need to wrap the callback function with useCallback() hook. Now useCallback takes two arguments-one is the callback function and second is an array of dependencies for which a new instance of the callback function is to be created. ComponentB's UI depends upon the prop pokemons. So,pass pokemons as a dependency.

function ComponentA() {
    const [pokemons,setPokemons]=useState(
    ["bulbasaur","charmendar","pikachu"]
);
    const [trainer,setTrainer]=useState('');

    const clearTrainer=useCallback(()=>{
        setTrainer('');
    },[pokemons]);

    return (
        <div>
            <Trainer handleTrainer={setTrainer}/>
            <ComponentB 
            pokemons={pokemons} 
            clearTrainer={clearTrainer}
            />
            <span>{trainer}</span>
        </div>
    )
}

useMemo
useMemo() is similar to useCallback().The only difference between these two hooks is, one caches the function and the other caches any value type. Consider a situation where you have to render a long list of elements and each element calls an expensive function for it to render some information. During the first render, the thread is completely blocked until the expensive functions are executed. In subsequent re-renders useMemo() makes use of the memoized value to avoid calls to those expensive functions. This can be understood with the following code snippet:

export const Items=({list})=>{
  const listContent=list.map(item=>{
    return {
     name:item.name
     price:item.price
     priceWithoutVat:expensiveFunctionOne(item.totalPrice,item.basePrice)
    }
  });
  return <div>{listContent}</div>
}

Let's assume this code snippet is in a component which re-renders frequently for some obvious reasons. Now to avoid the complex computations, we memoize the value of listContent. To do this,wrap it in useMemo() hook. useMemo() takes two arguments. One is the value to be memoized and the other, a list of dependencies for which this value is to be recalculated.

export const Items=React.useMemo(({list})=>{
  const listContent=list.map(item=>{
    return {
     name:item.name
     price:item.price
     priceWithoutVat:expensiveFunctionOne(item.totalPrice,item.basePrice)
    }
  });
  return <div>{listContent}</div>
},[list])