DEV Community: Amod Shinde

Prototype in Javascript

Amod Shinde — Tue, 21 Dec 2021 05:17:30 +0000

In this article, we shall discuss prototype in Javascript and how it works under the hood. Often developers who are new to Javascript wonder what is this magic keyword and how the heck it gives access to some methods you never define? Let us find out what prototype is all about.

Introduction to Javascript prototype

By default, Javascript provides the Object() function. You can verify it by printing it in the console.

console.log(Object);

output:

Object() though seems like an object, it's a function and not an object. It might be a little confusing but remember that Object() is a function and it provides an anonymous object that can be referenced using prototype keyword.

console.log(Object.prototype);

output:

This Object.prototype object has predefined methods such as toString() , valueOf(). In JS, when a function is a value of a property of an object, it's called a method.

The constructor of Object.prototype, in turn, references the Object function:

Let's understand it better using an example. let's define a constructor function called Programmer.

function Programmer(name, language) {
this.name = name;
this.language = language;
}

The above constructor function accepts name and language as parameters and assigns them to the name and language properties respectively. Behind the scene, JS creates a new function Programmer() and an anonymous object.

so similar to what we saw earlier in the case of object function, even this Programmer() function has a property called prototype that references an anonymous object and constructor of which references back to the Programmer() function.

Let us print both in the console and see the output:

console.log(Programmer);

Output:

console.log(Programmer.prototype);

Output:

We can observe that the object we get from Programmer.prototype has a constructor that is referencing the Programmer() function itself. In addition to this, JS links the Programmer.prototype to Object.prototype object via [[ prototype ]], this is known as prototype linkage.

The Image will help you understand it better:

Defining custom methods in the Javascript prototype

You can define your own custom methods in the prototype object. These custom functions are further accessible to the instances created from that function.

The following code defines a new method called intro() on Programmer.prototype:

Programmer.prototype.intro = function() {
    return "Hello, My name is " + this.name + " and I am a " + this.language + " Developer";
}

This intro() function is added to the Programmer.prototype object.

Now, let's create an instance of the Programmer

let p = new Programmer('Jay', 'Python');

The JS will now create a new object p and links to Programmer.prototype object via the prototype linkage.

Now let's call the intro() function from this p instance:

let introduction = p.intro();
console.log(introduction);

Output:

How does this work?

Since p doesn't have its own intro() method, Javascript follows the prototype linkage and finds it on the Programmer.prototype object and executes it.

Now let's try to call toString( ) method on p object.

let pString = p.toString();
console.log(pString);

How does this work?

Again, since p doesn't have its own toString( ) method, Javascript follows the prototype linkage and searches for it on the Programmer.prototype object. Because the Programmer.prototype doesn't have the toString( ) ,method, it further follows the prototype linkage and searches in the Object.prototype object. It finds toString( ) here and executes it:

If you call a method that doesn't exist up the prototype linkage, i.e. on the Programmer.prototype or Object.prototype, then Javascript will throw an error that it cannot find the method specified.

p.changeProfession();

since changeProfession( ); doesn't exist on any of the objects in the prototype chain javascript throws an error.

let's create another instance called q:

const q = new Programmer('Raj', 'Javascript');

Now, p and q both the objects have the same objects and properties. But what if we define another method on q ? will p be able to access it ?

The code defines method getSalary( ) on q object.

q.getSalary = function () {
    return "My salary is decent.";
}

This getSalary( ) method is added to only q object and not on Programmer.prototype or p.

If you try to call getSalary( ) function with p: it will throw an error:

The Dunder Proto (_ _ proto _ _)

The proto is pronounced as dunder proto. The proto is an accessor property of the Object.prototype object. It exposes the internal prototype linkage ( [[Prototype]]) of an object through which it is accessed.

The p.proto exposes the [[Prototype]] that references the Programmer.prototype object.

console.log(p.__proto__ === Programmer.prototype); // true
console.log(p.__proto__ === q.__proto__); // true

You should, however, use the Object.getPrototypeOf() method instead of the proto. The Object.getPrototypeOf() method returns the prototype of a specified object.

console.log(p.__proto__ === Object.getPrototypeOf(p)); // true

Another popular way to get the prototype linkage when the Object.getPrototypeOf() method wasn’t available is via the constructor property as follows:

p.constructor.prototype

The p.constructor returns programmer, therefore, p.constructor.prototype returns the prototype object.

Shadowing

See the following method call:

console.log(p.intro());

The p object doesn’t have the intro() method defined, therefore JavaScript goes up to the prototype chain to find it. In this case, it can find the method in the Programmer.prototype object.

Let’s add a new method to the object p with the same name as the method in the Programmer.prototype object:

p.intro = function() {
    console.log('Hello');
}

And call the intro( ) method:

console.log(p.intro());

Because the p object has the intro() method, JavaScript just executes it immediately without looking it up in the prototype chain.

This is an example of shadowing. The intro() method of the p object shadows the intro() method of the prototype object which the p object references.

Best Practices for Logging in Node.js

Amod Shinde — Thu, 02 Dec 2021 15:14:45 +0000

Let's be honest, developers do more debugging than writing the actual code. There are cases where you need to troubleshoot an issue Node.js application, logs are the saviours. They provide information about the severity of the problem, as well as insights into its root cause. Thus good logging practices are crucial for monitoring your Node.js servers, track errors, carry out different analyses and discover optimization opportunities. This article will outline best logging practices to follow when writing a Node.js application.

1. Choosing the correct library

Node.js developers tend to rely on the runtime's console methods ( like console.log()) to log events and provides a familiar API similar to the Javascript console mechanism in browsers. console.log() has its uses but it's not enough to use it as a logging solution in a production application. It does provide methods like console.warn(), console.error(), console.debug(), but these are mere functions that print the standard output and don't define the severity of the log.

Characteristics of a good logging library

A good logging library provides robust features that make it easier for developers to format and distribute the logs. For example, a typical logging framework will provide options for where to output log data. A developer can configure it to output logs in the terminal or save them in a filesystem or database or even send them over HTTP in case there is a separate log management service in place.

Major concerns while choosing a suitable library

Recording:

Formatting: A library should provide proper log formatting options that help you differentiate the different logging levels, customize the colours and priorities of the levels as per need and convenience

Storing: It should also provide ways to configure where a developer can save logs as we talked about earlier

Performance: As the logger will be used throughout the codebase, it can harm your application's runtime performance, therefore it is crucial to analyse and compare the performance characteristics before choosing a library.

one of such popular libraries is Winston, which we shall talk about in this blog.

2. Use the Correct Log Levels

Before proceeding with understanding the log levels let us install the library first so that you can try out commands and code as we go along.

Install the library :

npm install winston

Regardless of what naming system different libraries use to denote log levels, the concept remains largely the same. Here are the most commonly used log levels in decreasing order of severity:

FATAL: This represents a catastrophic situation, where your application cannot recover without manual intervention.

ERROR: Represents an error in the system that may halt a specific operation, but not the system as a whole. This is usually used to log the errors returned by a third party API.

WARN: Indicates runtime conditions that are unusual but don't affect the running system in any way.

INFO: This represents purely informative messages. May use to log user-driven or application-specific events. A common use of this level is to log startup or shutdown service.

DEBUG: Used to represent diagnostic information that may be needed for troubleshooting.

TRACE: Captures every possible detail about an application’s behaviour during development.

The Winston library in particular uses the following log levels by default — with the error being the most severe and silly being the least:

{
  error: 0,
  warn: 1,
  info: 2,
  http: 3,
  verbose: 4,
  debug: 5,
  silly: 6
}

If you are not comfortable with default naming you can change this by initializing custom logger as per your needs in winston.

const { createLogger, format, transports } = require('winston');

const logLevels = {
  fatal: 0,
  error: 1,
  warn: 2,
  info: 3,
  debug: 4,
  trace: 5,
};

const logger = createLogger({
  levels: logLevels,
  transports: [new transports.Console()],
});

When you want to log a message you can log the desire level directly on custom logger

logger.info('System Started');
logger.fatal('Fatal error occuered');

3. Structural Logging

When writing log messages priority should be to make the messages easily readable to both machines and humans. One of the main goals of logging is to enable post-mortem debugging, which involves reading log entries and reconstructing the steps that led to an event in the system.

Thus human-readable and easily understandable, descriptive messages will help developers and sysadmins. It’s also important to use a structured format that is easy to parse by machines.

One of the best practices is to use JSON for logging as it is easily readable by humans as well as can be parsed by machines and can be easily converted to other formats. When logging in JSON, it’s necessary to use a standard schema so that the semantics of each field is clearly defined. This also makes it easy to find what you’re looking for when analyzing log entries.

Winston outputs a JSON string by default with two fields: message and level. Message contains text that has been logged and level states the log level. we can customize this by using winston.format. for example you can add timestamp by combining timestamp and json.

const { createLogger, format, transports } = require('winston');

const logger = createLogger({
  format: format.combine(format.timestamp(), format.json()),
  transports: [new transports.Console({})],
});

4. Write Descriptive Messages

The message should clearly describe the event that occurred at that particular point. Each message should be unique to the situation so that the developer or system admin can differentiate and track down errors easily.

One of the bad examples of a log message is:

Error occured!!

The above log tells the user that an error has occurred but there are no specifics of what kind of error has occurred or which place it has occurred. A more descriptive message looks like this:

"PUT" request to "https://example.com/api" failed. Response code: "503", response message: "Internal Server Error!". Retrying after "60" seconds.

From this message, we know that the request to the server of example.com has failed. The probable reason is the third party server might be down for unknown reasons.

5. Avoid Logging Sensitive Data

Regardless of the type of application, you are working on, it is always important to avoid logging sensitive information in the logs. The sensitive information includes govt ID nos., addresses, phone numbers, email ids or access tokens etc.

6. Add Proper Context to your Logs

Another crucial step to keep in mind while logging is to provide the necessary context i.e. the developer should know where the log has come from or what it relates to. Context makes it possible to quickly reconstruct the actions leading up to an event.

Winston provides the ability to add global metadata (such as the component or service where an event occurred) to every generated log entry. In a complex application, this information in your logs is helpful for troubleshooting issues because it immediately directs you to the point of failure.

const logger = createLogger({
  format: format.combine(format.timestamp(), format.json()),
  defaultMeta: {
    service: 'auth-service',
  },
  transports: [new transports.Console({})],
});

the following output will be shown

1
{"message":"User loggedIn successfully","level":"info","service":"auth-service","timestamp":"2020-09-29T10:56:14.651Z"}

Originally posted at amodshinde.com

Memory Management with Nodejs

Amod Shinde — Thu, 02 Dec 2021 15:12:05 +0000

Over the past decade, Internet accessibility has seen a big shift from only the privileged class to almost anyone who owns a device that is capable of connecting to the internet. With more and more people accessing the internet, developers face the big challenge of managing the load on the application. Memory leaks have been the most common enemy for the tech industry has to fight every day with the growing user base and furthermore growing codebase with tons of features added every other software release. Memory leaks can result in problems such as application slowdowns, crashes, high latency, and so on.

For low-level languages like C, developers have to manually perform memory management with malloc and calloc. In contrast, JavaScript automatically allocates memory when objects are created and frees it when they are not used anymore. This process is known as Garbage Collection. But does this mean that javascript developers live with no knowledge of memory management? Definitely not! Whenever there is bad press coverage of Node.js, it is (typically) related to performance problems. The user must simply be aware of certain things about how Node.js works.

Regardless of programming language, the garbage collection cycle is pretty much similar

Reference-counting garbage collection

This is the most naive garbage collection algorithm. This algorithm determines whether or not there is at least one reference to the object. An object is said to be "garbage" if there are zero references pointing to it. Let's see in general how GC works.

Limitation: Circular References

let's say there are two objects in the memory who are referencing each other thus creating a cycle but are detached from the root. That is they are out of scope of function and no longer needed in the code execution. Now, this memory needs to be reclaimed. However, since the reference counting algorithm works by checking whether or not an object has at least a reference pointing to them, neither of them are marked as garbage and continue occupying space in the memory.

Note that circularly referenced nodes are not removed from the memory.

Mark-and-sweep algorithm

This algorithm reduces the definition of "an object is no longer needed" to "an object is unreachable". This algorithm assumes the knowledge of sets of objects called roots. In Javascript root is a global object. The garbage collector thus will start from the roots, find all objects referenced from these roots and the objects referenced from these and so on. Thus it finds reachable and non-reachable objects.

GC then frees the unreachable objects from the memory. This solves the problem of circular references. If two circularly referenced objects exist in the memory and are not reachable directly or indirectly through the roots then they are freed from the memory. This algorithm is further explained in detail under the Node.js memory management section.

Memory Management in Nodejs

Google V8 is a JavaScript engine initially created for Google Chrome, but it can also be used as a standalone. This makes it the perfect fit for Node.js. V8 compiles JavaScript down to native code and executes it.

V8’s memory scheme

A running program is represented through a memory space called Resident Set.
This divides the memory into certain sets:

Code: The actual code being executed

Stack: Contains static data like function frames, primitive values (like boolean / integer), pointers to objects in the heap etc.

Heap: V8 stores objects or dynamic data in heap. This is the biggest block of memory area and it's where garbage collection (GC) takes place.

Tip: The current memory usage in Node.js can be checked by calling process.memoryUsage().

Stack

Consider the following code:

function multiply(a,b) {
  return a * b;
}
multiply(a,b);

Here, both a and b will be placed on the stack.

Heap

Now consider the following code:

function Food(foodItem) {
  this.name = foodItem.name;
}
const Burger = new Food({ name: 'Big Mac'});

After this, Heap memory would look something like this:

Now let's two more objects:

function Food(foodItem) {
  this.name = foodItem.name;
}
const Burger = new Food({ name: 'Big Mac'});
const Pizza = new Food({ name: 'Cheesy Pizza'});
const Biryani = new Food({ name: 'Prawns Biryani'});

our memory gets updated to :

If GC would run now, nothing would be freed as the root is linked to all the objects in the memory. This tells GC that all the objects defined in the running code are being used for execution.

Consider, we no longer use Pizza object. Let's say we set Pizza to be undefined. (Please note that to change the value of Pizza, you need to use 'let' keyword to make the initial definition of Pizza & not const)

Now the memory would look something like this:

Now when GC runs, the original Pizza object cannot be reached from the root object, so on the next garbage collector run it will be freed up:

What Causes Memory Leaks in JS

So the biggest dilemma is if JS already has an automated garbage collector then why should a developer learn about memory leaks? Does Javascript still have memory leaks? The answer is yes.

Even though automatic memory management like garbage collection in V8 avoids most of the memory leaks, there could still be unwanted memory references in the heap which could happen due to various reasons.

Global Variables: Since global variables in JS exists in the global execution context (GEC), these variables are always referenced by the root node (window or global this) they are never garbage collected throughout the lifetime of the application and will occupy memory. Having a large graph of objects referenced from the root can cause a memory leak.

Multiple References: There may be a case where the same object is referenced from multiple objects and one of the references is left dangling.

Closures: Javascript closure is an excellent tool that helps in memorizing its context. When a closure holds a reference to a large object in the heap, the object remains in the memory as long as that particular closure is in use. If closures are improperly used, these can lead to memory leaks.

Timers & Events: The use of setTimeout, setInterval, Observers and event listeners can cause memory leaks if large object references are kept in their callback without proper handling.

Originally posted at amodshinde.com

Best Practices to Avoid Memory Leaks

Amod Shinde — Thu, 02 Dec 2021 15:10:55 +0000

In the Previous Blog we understood the Memory management in Node.js, how Garbage Collector (GC) works and what are the possible causes of memory leaks despite GC playing a crucial role. In this blog, let's look at best practices to ensure efficient memory use in Node.js.

REDUCE USE OF GLOBAL VARIABLES

Since global variables are never garbage collected, it's best to ensure you don't overuse them.

In javascript particularly you need to keep in mind certain aspects to reduce global variables

Avoid accidental globals

In Javascript, if you assign a value to an undeclared variable, Javascript automatically hoists it as a global variable in default mode. Also, this goes the same with the word 'this' used in functions in the global scope.

Examples:


function apple() {
    red = true; // this red variable gets hoisted in global space
}

function mango() {
// since 'this' in global functions refers to global this varible is hoisted in global space
this.type = "Alphanso";  
}

Solution: It is helpful to write javascript in a strict mode with 'use strict' annotation at the top of the JS file. In newer versions of Node.js you can globally enable strict mode by passing '- - use_strict ' flag when running node command.

'use strict'

function apple() {
    red = true; // this will throw an error
}

function mango() {
// this function will have its own scope for 'this'
this.type = "Alphanso";  
}

Caution: Be careful when you use arrow functions though, because even in use strict mode 'this' in arrow function will be in global space

// This will also become a global variable as arrow functions
const plantation = () => {
    this.coconut = "Brown";
}

solution: use the no-invalid-this rule from ESLint to avoid such cases.

Use global scope wisely :

As much as possible don't use the global scope, make the best use of the local scope inside the functions, as that will be garbage collected and will keep memory free.
Try to define only constants, cache and reusable variables in global. Mark variables as null whenever the values are not needed.
Do not use global space as a medium to pass values from one function to other, use function parameters instead.
Dont store big objects in the global scope. If you have to store them, then nullify them when not needed. Dont let cache objects grow indefinitely, cleanup once and while.

Use Stack Memory Effectively

Accessing stack is much faster than accessing heap memory, hence try to use stack variables more frequently than their counterparts. This also ensures we don't accidentally cause memory leaks. Ofcourse in a real-world scenario, it's impossible to create a usable application by only using static data. But we can follow some tricks to make better use of the stack.
1. Avoid heap object references from stack variables when possible. Also, don’t keep unused variables.
2. Destructure and use fields needed from an object or array rather than passing around entire objects/arrays to functions. This avoids keeping a reference to objects inside closures.
```
function outer() {
    const obj = {
        foo: 1,
        bar: "hello",
    };

    const closure = () {
        const { foo } = obj;
        myFunc(foo);
    }
}

function myFunc(foo) {}
```
1. Use Heap Memory Effectively
In real-world applications it is quite impossible to completely avoid using heap memory but we can make it more efficient by following a few tips:
1. copy objects instead of referencing them. Pass the reference only if the object is huge and copy operation is expensive.
2. Avoid object mutations as much as possible, instead use object spread or object.assign and create a copy.
3. Avoid creating multiple references to the same object
4. Avoid creating huge object trees else keep them short-lived
Use APM to track your heap memory usage.
1. Be Cautious when using Closures, Timers & Event Handlers
For timers always remember to pass copies of objects to avoid mutations and clear timers when done using clearTimeout and clearInterval methods.

Also, clear listeners once the job is done, don't keep them running forever. In cases where they are holding on to object reference from the parent scope.

Originally posted at amodshinde.com

useEffect() in ReactJs

Amod Shinde — Thu, 02 Dec 2021 15:07:06 +0000

Functional components gained popularity after React team included hooks in React 16 .8 release. The react hooks facilitate developers to do state management in the formerly called stateless components i.e. functional components. Many developers have switched to react hooks approach since their introduction.

one of the important hooks is useEffect(). For those who are familiar with the class based approach of React.js, useEffect is a combination of componentDidMount, componentDidUpdate and componentWillMount.

Importing hooks

The react hooks are part of 'react' library and can be imported in the component using

import React, { useEffect } from "react";

As the name states, it's related to side effects or effects that are being carried out throughout the component. Data fetching / calling an API, setting up subscriptions and manually altering the DOM are all examples of the side effect we are talking about.

sometimes we need to run additional code after React has finished updating DOM for eg. API requests, manual DOM mutations etc, these can be handled in this hook.

U*sing Classes*

In React class components, render cannot cause side effects. So we cause side effects in componentDidUpdate and componentDidMount. let us look at the example:

class Example extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0
    };
  }

  componentDidMount() {
    document.title = `clicked ${this.state.count} times`;
  }
  componentDidUpdate() {
    document.title = `clicked ${this.state.count} times`;
  }

  render() {
    return (
      <div>
        <p>You clicked {this.state.count} times</p>
        <button onClick={() => this.setState({ count: this.state.count + 1 })}>
          Click me
        </button>
      </div>
    );
  }
}

Here we want to update the count on every render. That means I have to make the side effect on both onMount - first load and onUpdate - subsequent render of the component.

But in useEffect we have to call just once.

Using useEffect hook

import React, { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

→ If your component needs to do something after render, that should go in the useEffect hook.

React will remember the function you passed and will call it after the DOM updates.

→ We place useEffect inside the component, this lets us access all the props and states. It makes use of javascript closures to achieve this.

→You need to be cautious about what code goes into useEffect as it is called both after the first render and every subsequent update. We can control this by passing an array of dependent states as a second argument. We shall read about it later in the article.

Effects with cleanup

so Earlier we saw effects that don't need a cleanup, like API or DOM manipulations. However, effects such as subscription need a cleanup. But functional component does not provide a method like componentWillUnmount as in the case of class components.

class component

class Example extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0
    };
  }

    onClickTest() {
        console.log('test  function');
  }

  componentDidMount() {
   document.body.addEventListener("click", this.onClickTest);
  }
  componentWillUnMount() {
   document.removeEventListener("click", this.onClickTest);
  }

  render() {
    return (
      <div>
        <p>You clicked {this.state.count} times</p>
        <button onClick={() => this.setState({ count: this.state.count + 1 })}>
          Click me
        </button>
      </div>
    );
  }
}

Let's see how can we achieve the above functionality from the functional components using useEffect hook.

import React, { useState, useEffect } from 'react';

function Example() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
    document.body.addEventListener("click", onClickTest);

    return () => {
             document.body.removeEventListener("click", onClickTest);
        }
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

→ The function returned from useEffect is optional cleanup mechanism for effects. The logic for adding and removing subscriptions can be at one place with useEffect hook.

→React performs cleanups at component unmount. However, the useEffect hook runs after every render, thus react cleans up effects from the previous render before running effects next time.

Optimal use of useEffect hook

In some cases cleanup or applying effects on every render might cause performance issue. In class based components we solve it using prevState and prevProps:

example:

componentDidUpdate(prevProps, prevState) {
  if (prevState.count !== this.state.count) {
    document.title = `You clicked ${this.state.count} times`;
  }
}

In useEffect hook, this comes built-in. you can tell react to skip applying useEffect if values of certain states haven't changed. We can pass an array of states as a second argument to the hook.

useEffect(() => {
  document.title = `You clicked ${count} times`;
}, [count]); // Only re-run the effect if count changes

If you want useEffect to run and clean it up only once each, then you can pass an empty array as a second argument.

useEffect(() => {
  document.title = `This runs on mount`;
}, []);

Originally posted at amodshinde.com

Best Practices for Node.js Development

Amod Shinde — Thu, 02 Dec 2021 15:03:56 +0000

The popularity of Node.js is growing at a rapid pace, with more and more unicorn companies adapting to the technology it has become very crucial to follow certain conventions to make code readable and modifiable by other developers. The code you write is also directly proportional to the scalability of the product you ultimately build.

Best Practice #1

Choose a Layered Approach: Separation of your concerns

Popular Node.js frameworks like Express.js allow you to define routes as callback functions that are executed when a client request is received. This gets you tempted to write all the business logic under a single function which unknowingly escalates to a messy code that is difficult to interpret for a human being.

Thus this should be implemented keeping in mind the' Separation of concerns' principle of programming. According to this principle, we should have distinct modules addressing distinct concerns in the application. The server-side aspects are broadly divided as

These aspects can be handled by programming three different layers:

Controller: API routes & endpoints
Service Layer: For business logic
Data Access Layer: For working with database

Controller layer

In this module, you only write API routes. In the route handler function, you can deconstruct the request object from HTTP to get params, query params, payload etc and pass them to the service layer for processing.

Service layer

This layer houses the business logic. This contains all the methods that take up singular responsibility and are reusable.

Data Access layer

The main role of this layer is talking to the Database - Fetching from, updating, writing to it. All DB connections, models, ODM/ORMs are defined here.

Best Practice #2

Folder Structure: Properly organize your code files

In the previous section, we spoke about how to logically modularize a project into layers. To get this abstract architecture in play we need a proper folder structure

src
      ├── app.js              app entry point
      ├── /api                  controller layer: api routes
      ├── /config             config settings, env variables
      ├── /services           service layer: business logic
      ├── /models             data access layer: database models  
      ├── /scripts            miscellaneous NPM scripts
      ├── /subscribers        async event handlers
      └── /test           test suites

Here, /apis (controller layer), /services and /models (data access layer) are the three layers we spoke about.

/config layer can store your constants and app configurations / settings like environment variables etc. /scripts directory can be used to store automation scripts like deployment pipelines. /tests will house the test cases you write for the application.

Best Practice #3

Publisher subscriber models

The Publisher/Subscriber models can be used for communication between two entities in your code. Publishers (Message Senders) send out messages, along specific channels without having knowledge of who the receiving entities are. Similarly, Subscribers ( receiving entities ) on other hand listen to one or more channels without the knowledge of publishing entities.

It is a good practice to implement this model in your project to manage multiple children operations corresponding to a single action. Let consider an example where, in your app, on user sign up, you do numerous things like - create a DB entry, generating an Auth key, sending a confirmation email. If you handle this in a single service function the function code tends to get lengthy and messy.

the structure of the code would look like:

export default class AuthService() {
        async function signup(user) {
            //1. create DB entry
            //2. generate auth key
            //3. send confirmation email
    }
}

We can very well simplify this with pub/sub model.

Pub/sub model can use Node.js Events API

var events = require('events');
      var eventEmitter = new events.EventEmitter();     

      export default class UserService() {

        async function signup(user) {
          // emit 'signup' event
          eventEmitter.emit('signup', user.data)
        }

      }

To handle such events emissions, you can have multiple subscribers that are essentially event listeners, waiting for certain events to be emitted. These subscribers can be organized into separate files based on their purpose and stored in the /subscribers directory.

// email.js

    // ...
    eventEmitter.on('signup', async ({ data }) => {  // event listener 
      // send email 
    })

// auth.js

    // ...
    eventEmitter.on('signup', async ({ data }) => { // event listener
      // generate auth key
    })

Best Practice #4

Clean Code & Easy Readability: Use code linters, formatters & comments

Linting & Formatting

The main goal here is improving code quality and readability. A linter warns you about syntactic errors (sometimes even semantic ) whereas code formatted styles the code in a more readable way. Some of the popular linters for javascript are Jslint and Eslint. For code formatting, Prettier is a well-known code formatter. Plugins for these linters and formatters are available in most of the code editors like Atom and VS code.

Adding Comments

When writing code it is important for a developer to write proper comments so that the team working on the project can benefit. A proper yet short comment explaining the functionality of the code can save much confusion and time for peer developers and ultimately the time of the entire team. The screenshot below shows one of the examples of a proper comment:

Proper nomenclature of functions, variables and constants

The function, variables and constants names that you define should indicate the use or significance of that function( / variable / constant). Poor nomenclature of the variables can create confusion among the team members and peer developers. Proper naming also helps you to recognize the functions when checking memory snapshots.

How not to write function name:

Here we are not clear about what kind of items have been defined in the items array, moreover, items is a common term that is likely to be used frequently. This is an example of bad nomenclature.

The function name too doesn't go with the functionality of the method. Like the function can both mark items available and unavailable, so naming it 'makeAvailable' doesn't seem to be right.
The parameter n inside the function is just a letter 'n' and doesn't tell what it signifies.
Better code would be:

Best Practice #5

Write Asynchronous code: Use Promises, Async/Await

Javascript is quite known for callback functions. They allow you to define the asynchronous behaviour in javascript. But with more and more callbacks in the code, the code gets clunkier, resulting in what is known as callback hell.
Javascript introduced promises in 2015 which is a much cleaner way to handle asynchronous behaviour. Furthermore, in 2017, the async/await syntax was introduced to further simplify things.

Therefore it's advisable to scrap the use of callback functions and choose promises or async/await.
These syntaxes make the code more readable and easier to look at the code flow and debug.
Just as an example, this is how the same code would look in callbacks vs the async/await:

With callbacks:

With Async/Await:

Code with async/await syntax does the exact same computation as the callback one, but is much easier to read and debug.

Best Practice #6

Testing, Logging & Error Handling

Testing

It's quite common for newbies to overlook the importance of writing test cases for the code. However, writing test cases is as important as writing the code as it checks the validity and accuracy of the code by bringing to light even the smallest inaccuracies.

Unit tests form the foundation of most testing setups. Here, individual units/components are tested in isolation from the rest of the code to verify their correctness. This allows your code to be validated at the (logically) lower level to ensure that each of the internal components is working accurately, as expected.

Logging

Logging is a crucial part of the development process as it helps track down the errors in case of failures. This helps you record your important information and analyse various aspects of it with respect to accuracy and performance metrics. It helps you manage the application better and helps in debugging. you can read more about logging in Node.js and recommended libraries here.

Catching Errors

The errors provide relevant information on what went wrong in the code and possibly where it went wrong. But instead of Node.js throwing errors, interrupt code execution or even fail sometimes, it's better if we take control by handling error conditions. We can achieve this through try/catch blocks. In such a way, we can keep things simple, stable and easier to debug as well as prevent poor user-end experience.

try {
 if(somethingHappened)throw "Error Message";
} catch (err) {
 console.log(e);
} finally {
 console.log("Finally Executed" );
}

Best Practice #7

Third-party solutions: Don't Reinvent the wheel | Dont overdo either

Node.js has a huge developer community across the world. As far as third-party support is concerned, Node’s package manager, NPM is full of feature-rich, well maintained, well documented, frameworks, libraries and tools for any use case you can imagine. It is therefore very convenient for developers to plug these existing solutions into their code and make the most of their APIs.

While these libraries and tools ease off a lot of the burden, it is important to be intelligent and responsible about every package that we import. We should be aware of the purpose, strengths and weaknesses of each package we import and ensure that we aren’t over-reliant on them.

Originally posted at amodshinde.com

Using refs in React.js

Amod Shinde — Thu, 02 Dec 2021 14:58:45 +0000

In this article, we are going to investigate why React.js, a library that keeps your code away from DOM manipulation, keeps its doors open for you to access. React rethinks a view as a result of a state of a component. It provides JSX, a syntactic sugar over Javascript, to design the view layer and then modifies the DOM itself rather than giving the control to the developer.

Still, the React team provided escape routes and kept the library open for certain situations that go beyond the scope of what React is designed for.

Creating refs

Refs are escape routes and it's better to avoid them whenever possible. When we obtain a DOM element using ref and then later modify its attribute, we might enter into a conflict with React's diff and update approach.

Let's start with a simple component and grab a DOM element using ref, assuming that you already know how to set up a basic react app.

import React, { useRef } from 'react'

function Button ({ label, action }) {
        // declare & initializing a reference to null
   const buttonRef = useRef(null)

   // attaching 'buttonRef' to the <button> element in JSX
    return (
      <button onClick={action} ref={buttonRef}>{label}</button>
    )
  }
}

In the above piece of code, we are using a react hook 'useRef' to create and initialize a variable called buttonRef. We then assign buttonRef to ref attribute on button JSX element.

Using React refs

As we discussed earlier in this article we are declaring views based on the state, and though we are still altering the state using functions, we are not in direct control of the DOM changes. But in a few use cases, it makes sense to introduce refs in your code.

Focus Control

To better understand the problem statement let's storify the situation.

Arjun is a software development intern at Doogle INC and his manager has given him the task of creating contact forms. The manager has asked him to focus on the first input element in the form when a modal is opened Arjun is confused about how he can achieve this in React.js. Let's help Arjun out.

import React, { useState } from "react";

const InputModal = ({ close }) => {
  const [value, updateVal] = useState("");
  const onChange = (e) => {
    updateVal(e.target.value);
  };

  const onSubmit = (e) => {
    e.preventDefault();
    close();
  };

  return (
    <div className="overlay">
      <div className="modal">
        <h1>Insert a new value</h1>
        <form action="?" onSubmit={onSubmit}>
          <input type="text" onChange={onChange} value={value} />
          <button>Save new value</button>
        </form>
      </div>
    </div>
  );
};

export default InputModal;

The first thing we need to do is to get a reference to the input.

import React, { useState, useRef } from "react";

const InputModal = ({ close }) => {
  const [value, updateVal] = useState("");
  const inputRef = useRef(null);

  const onChange = (e) => {
    updateVal(e.target.value);
  };

  const onSubmit = (e) => {
    e.preventDefault();
    close();
  };

  return (
    <div className="overlay">
      <div className="modal">
        <h1>Insert a value</h1>
        <form action="?" onSubmit={onSubmit}>
          <input type="text" onChange={onChange} value={value} ref={inputRef} />
          <button>Save</button>
        </form>
      </div>
    </div>
  );
};

export default InputModal;

Next, when our modal loads, we imperatively call focus on our input ref.

import React, { useState, useRef, useEffect } from "react";

const InputModal = ({ close }) => {
  const [value, updateVal] = useState("");
  const inputRef = useRef(null);

  useEffect(() => {
    inputRef.current.focus();
  }, []);

  const onChange = (e) => {
    updateVal(e.target.value);
  };

  const onSubmit = (e) => {
    e.preventDefault();
    close();
  };

  return (
    <div className="overlay">
      <div className="modal">
        <h1>Insert a value</h1>
        <form action="?" onSubmit={onSubmit}>
          <input type="text" onChange={onChange} value={value} ref={inputRef} />
          <button>Save</button>
        </form>
      </div>
    </div>
  );
};

export default InputModal;

Note: You need to access the element through the current property of the ref you declare.

Follow this link to check the working code. Try commenting out inputRef implementation and see how the input focus changes with and without ref.

Detect if an element is contained

Similarly, we would want to take an action in the app when an event is dispatched. Like close the modal when the user clicks outside of it.

import React, { useState, useRef, useEffect } from "react";

const InputModal = ({ close }) => {
  const [value, updateVal] = useState("");
  const inputRef = useRef(null);
  const modalRef = useRef(null);

  const onClickOverlay = (e) => {
    const overlay = e.target;
    if (modalRef.current && !modalRef.current.contains(overlay)) {
      e.preventDefault();
      e.stopPropagation();
      close();
    }
  };
  useEffect(() => {
    inputRef.current.focus();
    document.body.addEventListener("click", onClickOverlay);
  }, []);

  const onChange = (e) => {
    updateVal(e.target.value);
  };

  const onSubmit = (e) => {
    e.preventDefault();
    close();
  };

  return (
    <div className="overlay">
      <div className="modal" ref={modalRef}>
        <h1>Insert a value</h1>
        <form action="?" onSubmit={onSubmit}>
          <input type="text" onChange={onChange} value={value} ref={inputRef} />
          <button>Save</button>
        </form>
      </div>
    </div>
  );
};

export default InputModal;

Here, we are checking if the user click is out of the modal ref limit. If it is we are calling close() function from props to close the modal.

Integrating DOM-based libraries

Like React, there are other utilities and libraries outside its ecosystem that have been in use for years. To use such libraries refs come in handy.

GreenSock library is a popular choice for animation examples. To use it, we need to send a DOM element to any of its methods.

Let’s go back to our modal and add some animation

import React, { useState, useRef, useEffect } from "react";
import gsap from "gsap";

const InputModal = ({ close }) => {
  const [value, updateVal] = useState("");

  const inputRef = useRef(null);
  const modalRef = useRef(null);
  const overlayRef = useRef(null);

  const onComplete = () => {
    inputRef.current.focus();
  };
  const gaspTimeline = gsap.timeline({ paused: true, onComplete });

  const onClickOverlay = (e) => {
    const overlay = e.target;
    if (modalRef.current && !modalRef.current.contains(overlay)) {
      e.preventDefault();
      e.stopPropagation();
      close();
    }
  };
  useEffect(() => {
    //timeline - gasp
    gaspTimeline
      .from(overlayRef.current, {
        duration: 0.25,
        autoAlpha: 0
      })
      .from(modalRef.current, {
        duration: 0.25,
        autoAlpha: 0,
        y: 25
      });

    gaspTimeline.play();

    document.body.addEventListener("click", onClickOverlay);
  }, []);

  const onChange = (e) => {
    updateVal(e.target.value);
  };

  const onSubmit = (e) => {
    e.preventDefault();
    close();
  };

  return (
    <div className="overlay" ref={overlayRef}>
      <div className="modal" ref={modalRef}>
        <h1>Insert a value</h1>
        <form action="?" onSubmit={onSubmit}>
          <input type="text" onChange={onChange} value={value} ref={inputRef} />
          <button>Save</button>
        </form>
      </div>
    </div>
  );
};

export default InputModal;

**Here is the working demo.**

Forwarding Refs

Refs are useful for specific actions. The examples shown are a little simpler than what we usually find in a real-life web application. We need to deal with complex components and we barely use plain HTML elements directly. It's common to use a ref from one component in another component.

import React from 'react'

const LabelledInput = (props) => {
  const { id, label, value, onChange } = props

  return (
    <div class="labelled--input">
      <label for={id}>{label}</label>
      <input id={id} onChange={onChange} value={value} />
    </div>
  )
}

export default LabelledInput

The issue now is that passing a ref to this component will return its instance, a React component reference, and not the input element we want to focus on like in our first example.

React provides forwardRef, which allows you to define internally what element the ref will point at.

import React from 'react'

const LabelledInput = (props, ref) => {
  const { id, label, value, onChange } = props

  return (
    <div class="labelled--input">
      <label for={id}>{label}</label>
      <input id={id} onChange={onChange} value={value} ref={ref}/>
    </div>
  )
}

export default React.forwardRef(LabelledInput)

Now, when a parent component passes a ref value, it’s going to obtain the input, which is helpful to avoid exposing the internals and properties of a component and breaking its encapsulation.

Originally posted on amodshinde.com