{"data":{"allBlogJson":{"edges":[{"node":{"title":["Child Process in Nodejs"],"link":["https://medium.com/@gkverma1094/child-process-in-nodejs-b2cd17c76830?source=rss-445df3ce30f2------2"],"content_encoded":["
\"\"

I have been working on nodejs for a long time. Since we all know Nodejs is not made for heavy server-side calculations. Node.js processes IOs in a non-blocking way, meaning that its single thread can manage several IO requests at the same time.

But sometimes we have to do some heavy calculations on the server-side, since nodejs is single-threaded, we can’t block the main thread for these kinds of calculations.

For these kinds of computations, we need to use the inbuilt library called child_process. Let's see why?

Child_process opens a process by creating a pipe, forking, and invoking the shell. Since a pipe is by definition unidirectional, the type argument may specify only reading or writing, not both the resulting stream is correspondingly read-only or write-only.

In simple words, child_process enable you for doing heavy computation by creating native OS or kernel threads. So, you can execute any script which that system (where you running your node script) supports.

I’m going to discuss some of the main methods from these libraries which save you from a lot of hell.

child_process.spawn

The child_process.spawn() method spawns the child process asynchronously, without blocking the Node.js event loop. The child_process.spawnSync() function provides equivalent functionality in a synchronous manner that blocks the event loop until the spawned process either exits or is terminated.

Let’s take an example

const { spawn } = require("child_process");
const ls = spawn("cat", ["index.js"]);
ls.stdout.on("data", (data) => {
console.log(`stdout: ${data}`);
});
ls.stderr.on("data", (data) => {
console.error(`stderr: ${data}`);
});
ls.on("close", (code) => {
console.log(`child process exited with code ${code}`);
});

Here, if we save above code as index.js, we get an output as

>> node index.js 
stdout: const { spawn } = require("child_process");
const ls = spawn("cat", ["index.js"]);
ls.stdout.on("data", (data) => {
  console.log(`stdout: ${data}`);
});
ls.stderr.on("data", (data) => {
  console.error(`stderr: ${data}`);
});
ls.on("close", (code) => {
  console.log(`child process exited with code ${code}`);
});

We are here just running a shell command inside nodejs (shell-command because I'm running the script on my Linux machine).

child_process.exec

`child_process.exec() spawns a shell and runs a command within that shell, passing the stdout and stderr to a callback function when complete. It spawns a shell then executes the command within that shell, buffering any generated output.

Let’s see an example

const { exec } = require('child_process');
exec('python run.py', (err, stdout, stderr) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(stdout);
});
//output v12.16.3

Here, with the help of the exec method, you can run any script just passing the command as a first parameter, and second as a callback so we can get the output from that file.

child_process.execFile

The child_process.execFile() is similar to child_process.exec() except that it does not spawn a shell by default. Rather, the specified executable file is spawned directly as a new process making it slightly more efficient than child_process.exec().

Let’s see an example

const { execFile } = require('child_process');
const child = execFile('node', ['--version'], (error, stdout, stderr) => {
  if (error) {
    throw error;
  }
  console.log(stdout);
});
//output
v12.16.3

child_process.fork

The child_process.fork() method is a special case of child_process.spawn() used specifically to spawn new Node.js processes. Like child_process.spawn(), a ChildProcess object is returned. The returned ChildProcess will have an additional communication channel built-in that allows messages to be passed back and forth between the parent and child. See subprocess.send() for details.

By default, child_process.fork() will spawn new Node.js instances using the process.execPath of the parent process. The execPath property in the options object allows for an alternative execution path to be used.

//index.js
const { fork } = require("child_process");
const ls = fork("./child.js");
let count = 0;
//exiting the thread when child process ended
ls.on("exit", (code) => {
console.log(`child_process exited with code ${code}`);
});
ls.on("message", (msg) => {
console.log(`PARENT: message from child process is ${msg}`);
count = parseInt(msg) + 1;
console.log("PARENT: +1 from parent");
ls.send(count);
});
//child.js
var count = Math.floor(Math.random() * 100);
process.on("message", (msg) => {
console.log("CHILD: message received from parent process", msg);
count = parseInt(msg) + 1;
console.log("CHILD: +1 from child");
if (count <= 100) process.send(count);
else process.exit(1);
});
console.log(count);
process.send(count);

Well, this code simply passing messages back and forth between child process and its parent. The output will be something like this:

>> node index.js
89
PARENT: message from child process is 89
PARENT: +1 from parent
CHILD: message received from parent process 90
CHILD: +1 from child
PARENT: message from child process is 91
PARENT: +1 from parent
CHILD: message received from parent process 92
CHILD: +1 from child
PARENT: message from child process is 93
PARENT: +1 from parent
CHILD: message received from parent process 94
CHILD: +1 from child
PARENT: message from child process is 95
PARENT: +1 from parent
CHILD: message received from parent process 96
CHILD: +1 from child
PARENT: message from child process is 97
PARENT: +1 from parent
CHILD: message received from parent process 98
CHILD: +1 from child
PARENT: message from child process is 99
PARENT: +1 from parent
CHILD: message received from parent process 100
CHILD: +1 from child
child_process exited with code 1

I tried to explain as simple as I can. But if you found anything missing just reach out to me in comments.

If you want to support me, please give claps to my blog and follow me,

“Lets code better”

\"\""]}},{"node":{"title":["A simple rectangles problem"],"link":["https://medium.com/@gkverma1094/a-simple-rectangles-problem-1b37964857f4?source=rss-445df3ce30f2------2"],"content_encoded":["

Problem Statement -

Find the total area covered by rectangles on given axis?

Well, it seems easy, but its not. Think about what if multiple rectangle overlapping on it. We need to remove the areas of overlapping on each others. But still we need to include those area which is removed many times because of multiple rectangle overlap. Sounds Complicated ?

\"\"
Overlapping Rectangles

So, in here if we try to calculate total area covered by rectangles, that will be something like this :

Total Area covered by Rectangles = area(A1) + area(A2) + area(A3) + area(A4) — area(A1 overlap A2) — area(A1 overlap A3) — area(A2 overlap A3) + Area(A1 overlap A2 and A2)

So, i guess now you got the idea what we are talking here. Right ?

Mathematically, it seems easy to calculate but its not. Atleast for me.

I’m going to solve it with a different approach. I called it Cover Box Algorithm, you can call whatever you want.

Basically, i’m going to make a rectangle which contains all these rectangle and then i’m going to clip the area which is not covered by rectangles. Simple right

\"\"
Boundary Rectangle deleting white area

So we are going to remove the white part from the boundary rectangle to get the total area. Python code for algorithm is:

or you can go https://gist.github.com/glearner/1ea67478d10fccf5e47cee1ab2908886.js

Thanks for reading.

\"\""]}},{"node":{"title":["WHEN TO USE USESTATE OR USEREDUCER?"],"link":["https://medium.com/@gkverma1094/when-to-use-usestate-or-usereducer-26e01d8a2187?source=rss-445df3ce30f2------2"],"content_encoded":["
\"\"

Everyone starting out with React Hooks quickly gets to know the useState hook. It’s there to update state in functional components by setting the initial state and returning the actual state and an updater function.

import React, { useState } from 'react';
const Counter = () => {
const [count, setCount] = useState(0);
const handleIncrease = () => {
setCount(count => count + 1);
};
const handleDecrease = () => {
setCount(count => count - 1);
};
return (
<div>
<h1>Counter with useState</h1>
<p>Count: {count}</p>
<div>
<button type="button" onClick={handleIncrease}>+</button>
<button type="button" onClick={handleDecrease}>-</button>
</div>
</div>
);
};
export default Counter;

The useReducer hook also can be used to update the state, but it does so in a more sophisticated way: it accepts a reducer function and an initial state, and it returns the actual state and a dispatch function. The dispatch function alters state in an implicit way by mapping actions to state transitions:

import React, { useReducer } from 'react';
const counterReducer = (state, action) => {
switch (action.type) {
case 'INCREASE': return { ...state, count: state.count + 1 };
case 'DECREASE': return { ...state, count: state.count - 1 };
default: throw new Error();
}
};
const Counter = () => {
const [state, dispatch] = useReducer(counterReducer, { count: 0 });
const handleIncrease = () => {
dispatch({ type: 'INCREASE' });
};
const handleDecrease = () => {
dispatch({ type: 'DECREASE' });
};
return (
<div>
<h1>Counter with useReducer</h1>
<p>Count: {state.count}</p>
<div>
<button type="button" onClick={handleIncrease}>+</button>
<button type="button" onClick={handleDecrease}>-</button>
</div>
</div>
);
};
export default Counter;

SIMPLE VS. COMPLEX STATE WITH HOOKS

The reducer example encapsulated the count property into a state object, but we could have done this more simply by using count as the actual state. Refactoring to eliminate the state object and code count as a JavaScript integer primitive, we see that this use case doesn't involve managing a complex state:

import React, { useReducer } from 'react';
const counterReducer = (state, action) => {
switch (action.type) {
case 'INCREASE':
return state + 1;
case 'DECREASE':
return state - 1;
default:throw new Error();
}
};
const Counter = () => {
const [count, dispatch] = useReducer(counterReducer, 0);
const handleIncrease = () => {
dispatch({ type: 'INCREASE' });
};
const handleDecrease = () => {
dispatch({ type: 'DECREASE' });
};
return (
<div>
<h1>Counter with useReducer</h1>
<p>Count: {count}</p>
<div>
<button type="button" onClick={handleIncrease}>+</button>
<button type="button" onClick={handleDecrease}>-</button>
</div>
</div>
);
};
export default Counter;

Anyway, I would argue that once you move past managing a primitive (i.e. a string, integer, or boolean) and instead must manage a complex object (e.g. with arrays and additional primitives), you may be better of using useReducer. Perhaps a good rule of thumb is:

The decision of whether to use useState or useReducer isn’t always black and white; there are many shades of grey. I hope this article has given you a better understanding of when to use useState or useReducer.

If you want to support me, please give claps to my blog and follow me,

“Lets code better”

\"\""]}},{"node":{"title":["Service workers: A detailed look"],"link":["https://medium.com/@gkverma1094/service-workers-a-detailed-look-83336036c1af?source=rss-445df3ce30f2------2"],"content_encoded":["

Whenever I use CRA(Create React App), I always wonder why we use serviceWorker.unregister().

\"\"
Lifecycle of service worker

I am going to take you through what a service worker is, why it was created, and how you can use it in your apps.

What is a service worker?

A service worker is a script that the client (your browser) runs in the background separate from the web page. Operating in the background separate from the web page enables you to use features that don’t actually require a web page or user interaction to trigger — like a push notification or background sync.

Why is this API such an exciting development? Because it allows you to support offline experiences, giving engineers and developers end-to-end control over the user’s interactions with the app. A service worker enables you to run JavaScript before a page even exists, makes your site faster, and allows you to display content even if there is no internet connection.

Key Properties of the service worker

As you can tell, service workers are extremely important in creating a Progressive Web App (learn more about PWA’s here). Before I dive into how to implement a service worker, here are some key traits and properties that it has:

Quick Note: Service workers in Mozilla are not accessible in the private window, and chrome is also removing support.

There are some pretty interesting things to note about a service worker. Since it can’t access the DOM directly, it needs a workaround to communicate with the pages it controls. It does this by responding to messages sent via the postMessage interface (through a MessagePort), allowing those pages it’s controlling to manipulate the DOM as directed. Additionally, being event-driven, you can’t rely on the state in a service worker’s onfetch and onmessage handlers to persist any data. According to the React documentation, if there is information that you need to persist and reuse across restarts, service workers have access to the IndexedDB API.

It’s clear that service workers are complicated yet powerful tools that we have at our disposal. What’s even better? React sets us up for success with implementing them just by running create-react-app. In this next section, I’ll walk you through how to set up a service worker with your React app.

How do I use a service worker?

After creating a new React app, you’ll see the following file structure created for you:

\"\"
The file structure automatically created for you when you build a new React app.

By default, the React build process will generate a serviceWorker.js file in your src folder. However, the default for the service worker is unregistered, meaning that it won’t yet be able to take control of your web app.

So, we’ll need to first opt-in to the offline-first behavior. In your code look forsrc/index.As it states, switching serviceWorker.unregister() to serviceWorker.register() will allow you to opt into using the service worker.

Without React’s handy provided code, you’d have to code the entire service worker lifecycle. Here’s a brief overview on what that looks like via Google documentation:

\"\"

So, you’d have to manually code the register → install → cache & return requests → so on and so forth process.

Luckily, we have React! If you pop into your src/serviceWorker.js file, you can see a lot of things are going there.

The benefits of opting-in to using the service worker are great, including creating faster and more reliable web apps and providing a more engaging mobile experience. However, just like most functionalities, there are some things to take into account if you decide to opt-in to service worker registration. You can learn about those in the official React.js documentation here.

So, the next time you get a push notification when your friend likes your Instagram or you start receiving ads for a local business the minute you set foot in that store’s town — you have service helpers to thank for that!

\"\""]}},{"node":{"title":["What new features added to ES2020?"],"link":["https://medium.com/@gkverma1094/what-new-features-added-to-es2020-7e7d4d70184e?source=rss-445df3ce30f2------2"],"content_encoded":["
\"\"

So, it has been a while ES20 features around us, but we are not using it. Some of us know about them but some may not. So, I’m just giving you the basic idea about new features which is going to make your life easier as a developer. So, let’s begin.

Dynamic Import

This is my most favorites feature in all of them. So, dynamic Import introduces a new function-like form of import that unlocks new capabilities compared to static import. Dynamic Import introduces a new function-like form of import that caters to those use cases.

<script type="module">
  const moduleSpecifier = './utils.mjs';
  import(moduleSpecifier)
    .then((module) => {
      module.default();
      // → logs 'Hi from the default export!'
      module.doStuff();
      // → logs 'Doing stuff…'
    });
</script>

Since import() returns a promise, it’s possible to use async/await instead of the then-based callback style:

<script type="module">
  (async () => {
    const moduleSpecifier = './utils.mjs';
    const module = await import(moduleSpecifier)
    module.default();
    // → logs 'Hi from the default export!'
    module.doStuff();
    // → logs 'Doing stuff…'
  })();
</script>

FYI, import() looks like a function call, it is specified as syntax that just happens to use parentheses (similar to super()).

Nullish coalescing

As we all know, sometimes we need to handle null and undefined conditions separately, but in general, how we do that is demoed below

const enable = props.enabled || true; 
//if props.enabled undefined, it will take true as its value

Now, there’s an issue, props.enabled will assign true even if props.enabled is false or 0 but here, we only want to handle only null and undefined, then we have manually check typeof or we do another check but nullish coalescing (??) will solve this issue very easily.

false ?? true;   // => false
0 ?? 1;          // => 0
'' ?? 'default'; // => ''
null ?? [];      // => []
undefined ?? []; // => []

Promise combinators

Promise combinators like Promise.all and Promise.race. But now, we got 2 new more static methodsPromise.allSettled and Promise.any .With those additions, there’ll be a total of four promise combinators in JavaScript, each enabling different use cases.Promise.allSettled gives you a signal when all the input promises are settled, which means they’re either fulfilled or rejected. This is useful in cases where you don’t care about the state of the promise, you just want to know when the work is done, regardless of whether it was successful.

const promises = [
  fetch('/api-call-1'),
  fetch('/api-call-2'),
  fetch('/api-call-3'),
];
// Imagine some of these requests fail, and some succeed.
await Promise.allSettled(promises);
// All API calls have finished (either failed or succeeded).
removeLoadingIndicator();

Promise.any gives you a signal as soon as one of the promises fulfills. This is similar to Promise.race, except any doesn’t reject early when one of the promises rejects.

const promises = [
  fetch('/endpoint-a').then(() => 'a'),
  fetch('/endpoint-b').then(() => 'b'),
  fetch('/endpoint-c').then(() => 'c'),
];
try {
  const first = await Promise.any(promises);
  // Any of the promises was fulfilled.
  console.log(first);
  // → e.g. 'b'
} catch (error) {
  // All of the promises were rejected.
  console.log(error);
}

String.matchAll

For me, it is very common to repeatedly apply the same regular expression on a string to get all the matches. To some extent, this is already possible today by using the String#match method. Something like this.

const string = 'Magic hex numbers: DEADBEEF CAFE';
const regex = /\\b\\p{ASCII_Hex_Digit}+\\b/gu;
for (const match of string.match(regex)) {
  console.log(match);
}
// Output:
// 'DEADBEEF'
// 'CAFE'

However, this only gives you the substrings that match. Usually, you don’t just want the substrings, you also want additional information such as the index of each substring, or the capturing groups within each match.

It’s already possible to achieve this by writing your own loop, and keeping track of the match objects yourself, but it’s a little annoying and not very convenient:

const string = 'Magic hex numbers: DEADBEEF CAFE';
const regex = /\\b\\p{ASCII_Hex_Digit}+\\b/gu;
let match;
while (match = regex.exec(string)) {
  console.log(match);
}
// Output:
// [ 'DEADBEEF', index: 19, input: 'Magic hex numbers: DEADBEEF CAFE' ]
// [ 'CAFE',     index: 28, input: 'Magic hex numbers: DEADBEEF CAFE' ]

But now, new String#matchAll API makes this easier than ever before: you can now write a simple for-of loop to get all the match objects.

const string = 'Magic hex numbers: DEADBEEF CAFE';
const regex = /\\b\\p{ASCII_Hex_Digit}+\\b/gu;
for (const match of string.matchAll(regex)) {
  console.log(match);
}
// Output:
// [ 'DEADBEEF', index: 19, input: 'Magic hex numbers: DEADBEEF CAFE' ]
// [ 'CAFE',     index: 28, input: 'Magic hex numbers: DEADBEEF CAFE' ]

String#matchAll is especially useful for regular expressions with capture groups.

globalThis

If I’ve written JavaScript for use in a web browser before, I have used window to access the global this. In Node.js, I have used global. If you’ve written code that must work in either environment, you may have detected which of these is available, and then used that — but the list of identifiers to check grows with the number of environments and use cases you want to support.

Some of my naive attempt to get ‘this’. Please don’t judge me.

const getGlobalThis = () => {
  if (typeof globalThis !== 'undefined') return globalThis;
  if (typeof self !== 'undefined') return self;
  if (typeof window !== 'undefined') return window;
  if (typeof global !== 'undefined') return global;
  // Note: this might still return the wrong result!
  if (typeof this !== 'undefined') return this;
  throw new Error('Unable to locate global `this`');
};
const theGlobalThis = getGlobalThis();

The globalThis proposal introduces a unified mechanism to access the global this in any JavaScript environment (browser, Node.js, or something else?), regardless of the script goal (classic script or module?).

And now that ugly code can be written in one line of code.

const theGlobalThis = globalThis;

First, I looked at this, it looks like magic to me.

Optional chaining

We all know, long chains of property accesses in JavaScript can be error-prone, as any of them might evaluate to null or undefined (also known as “nullish” values). Checking for property existence on each step easily turns into a deeply-nested structure of if-statements or a long if-condition replicating the property access chain:

// Error prone-version, could throw.
const nameLength = db.user.name.length;
// Less error-prone, but harder to read.
let nameLength;
if (db && db.user && db.user.name)
  nameLength = db.user.name.length;

The above can also be expressed using the ternary operator, which doesn’t exactly help readability:

const nameLength =
  (db
    ? (db.user
      ? (db.user.name
        ? db.user.name.length
        : undefined)
      : undefined)
    : undefined);

But now, optional chaining comes for us to rescue. The above ugly code can be written as:

const nameLength = db?.user?.name?.length;

For me, its lifesaver, like checking a method exist in nested object and then executing it. Like:

const adminOption = db?.user?.validate?.()

Here, we can execute validate once validate exist and not undefined.

BigInt: arbitrary-precision integers

Finally, we got bigInt in javascript. BigIntis a new primitive in the JavaScript language.BigInt is a new numeric primitive in JavaScript that can represent integers with arbitrary precision. With BigInts, you can safely store and operate on large integers even beyond the safe integer limit for Numbers. This article walks through some use cases and explains the new functionality in Chrome 67 by comparing BigInts to Numbers in JavaScript.

BigInts make it possible to correctly perform integer arithmetic without overflowing. Example:

const max = Number.MAX_SAFE_INTEGER;
// → 9_007_199_254_740_991

So, what’s the issue. Let see what happen when we add 1 and 2

max + 1;
// → 9_007_199_254_740_992 (correct)
max + 2;
// → 9_007_199_254_740_992 (false)

So now BigInt is here to save us:

BigInt(Number.MAX_SAFE_INTEGER) + 2n;
// → 9_007_199_254_740_993n (correct)
Don't try to multiply like this
1234567890123456789 * 123;
// → 151851850485185200000 (wrong)
1234567890123456789n * 123n;
// → 151851850485185185047n (correct)

The safe integer limits for Numbers don’t apply to BigInts. Therefore,with BigInt we can perform correct integer arithmetic without having to worry about losing precision.

Module namespace exports

Last but not least, we use the default exports to export only a single value. During import, we can omit the curly braces, and we can use the name that we want:

//------ utils.js ------
export default 10;
//------ main.js ------
import aValue from 'utils.mjs';//------ utils.js ------
export default class MyClass {}
//------ main.js ------
import oneClass from 'utils.mjs';

But now we can also do something like this:

//------ utils.js ------
export * as utils from './utils.mjs'

Namespace exports introduce the same usage style for import/export keywords to the developer, obtaining symmetrical behavior, and helping to avoid errors.

That’s all, now you know more about Javascript and its new features which made you a better coder than before.

If you want to support me, please give claps to my blog and follow me,

“Lets code better”

\"\""]}},{"node":{"title":["What’s new in React 16.13.0"],"link":["https://medium.com/@gkverma1094/whats-new-in-react-16-13-0-b730f2ef0b4f?source=rss-445df3ce30f2------2"],"content_encoded":["

Well, Reactjs become one of best javascript framework, i ever used. It’s simple and elegant. But we have also accept the framework fatigue with it. React is changing very rapidly with every version of it. Most of people have no idea what we got in new version of Reactjs.

So, we are going to see new features which added to Reactjs 16.13.0.

Introducing Concurrent Mode (Experimental)

By the way if you don’t know what is concurrency in reactjs mean, let me explain you. So, concurrent mode is a set of new features that help React apps stay responsive and gracefully adjust to the user’s device capabilities and network speed. You can check react fiber for this new feature implementation.

Blocking vs Interruptible Rendering

To explain Concurrent Mode, i’ll use version control as a metaphor. If you work on a team, you probably use a version control system like Git and work on branches. When a branch is ready, you can merge your work into master so that other people can pull it.

Before version control existed, the development workflow was very different. There was no concept of branches. If you wanted to edit some files, you had to tell everyone not to touch those files until you’ve finished your work. You couldn’t even start working on them concurrently with that person — you were literally blocked by them.

This illustrates how UI libraries, including React, typically work today. Once they start rendering an update, including creating new DOM nodes and running the code inside components, they can’t interrupt this work. I’ll call this approach “blocking rendering”.

In Concurrent Mode, rendering is not blocking. It is interruptible. This improves the user experience. It also unlocks new features that weren’t possible before.

You can check more on here.

Renaming Unsafe Lifecycle Methods

Since last year, react developers made some lifecycle to unsafe. Basically three of them, i remember :

componentWillMount → UNSAFE_componentWillMount

componentWillReceiveProps → UNSAFE_componentWillReceiveProps

componentWillUpdate → UNSAFE_componentWillUpdate

React 16.9 does not know componentWillMount anymore, and the old names are going to break your code. So now what, our code is going to break because we used these cycles in many components. The answer is NO. How ?

Well, react provided a tool called codemod. So if you are using earlier version of react 16.9 and you want to update to latest version, and you have to convert all componentWill to UNSAFE_componentWill.

Just run a simple command

npx react-codemod rename-unsafe-lifecycles
\"\"

The new names like UNSAFE_componentWillMount will keep working in both React 16.9 and in React 17.x.

Scheduler (Experimental)

So, these experimental feature are planned to get merge in React 17.x.

Scheduler is added to react because they want to improve queue performance by switching its internal data structure to a min binary heap. Till now, you can usepostMessage loop with short intervals instead of attempting to align to frame boundaries with requestAnimationFrame. But since its in experimental, I will not like to add this in my project because who know when they might get dropped.

But if they included it in react, our render performance will increased and animation will be more smoother. FYI, they just trying to change slower algorithm to faster one.

Normal Bug Fixes

Lots of bug fixed now which where in earlier version. Some of fixes are :-

Deprecate React.createFactory()

Warn when changes in style may cause an unexpected collision

Warn when a function component is updated during another component’s render phase

Fixed onMouseEnter being fired on disabled buttons.

Call shouldComponentUpdate twice when developing in StrictMode.

Show component stacks in more warnings.

Adjust SuspenseList CPU bound heuristic.

Fixed React.memo components dropping updates when interrupted by a higher priority update.

And many others. If you want to see full list, visit here

If you like this blog, please give me a clap. :)

\"\""]}},{"node":{"title":["Writing a custom render method in Reactjs."],"link":["https://medium.com/@gkverma1094/writing-a-custom-render-method-in-reactjs-8ccb9d3782e?source=rss-445df3ce30f2------2"],"content_encoded":["
\"\"

This implementation of render just a demo, how render method is implemented. You can’t replace the real render method by this.

When I see all lifecycle methods in react and I always wondered how they’re implemented. So, I tried to implement my own custom render method.

Let’s see what a render method does in React.

Render method used to render a React element into the DOM in the supplied container and return a reference to the component (or returns null for stateless components).

ReactDOM.render(element, container[, callback])

From the above declaration, I know the render method takes 2 arguments, element whom I want to render and container which is previously rendered element or basically its parent.

Let’s set up the project by running a create-react-app command.

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

Now, I have to remove the default render method from Index.js and adding my own render method.

import React from 'react';
// import ReactDOM from 'react-dom';
import ReactDomMini from './ReactDomMin';
import './index.css';
import App from './App';
import * as serviceWorker from './serviceWorker';
ReactDomMini.render(<App />, document.getElementById('root'));
serviceWorker.unregister();

Now create a new file in the src folder, named RectDomMin. Now, we going to add one npm library which helps us for reconciliation. React-reconciler provides a declarative API so that you don’t have to worry about exactly what changes on every update.

npm i react-reconciler

Now, I added the react-reconciler for accessing some important methods. Adding import in ReactDomMin.js.

import ReactReconciler from 'react-reconciler';

Our render method looks like this.

let ReactDomMini = {
render(whatToRender,div){
let container = reconciler.createContainer(div,false,false); 
//first false for concurrent and second false for hydration
reconciler.updateContainer(whatToRender,container,null,null)
},
};

Our reconciler method will look like this.

let reconciler = ReactReconciler({})

Now, start passing methods to the ReactReconciler.

createInstance, is a method that takes your element and converts the instance which we can add up to our parent tree (made by react).

createInstance(type,props,rootContainerInstance,hostContext, internalInstanceHandle,)

So, let see the arguments of the above method:-

  1. type: what type of element is passed. Like h1, p, etc.

2. props: props basically contains the properties of elements like alt, href, etc.

3. rootContainerInstance: root parent of the element or instance.

4. hostContext: basically contains the access of passed context to the element from its parent.

5. internalInstanceHandle: returns obj which is a type of React fiber node. So it can add to virtual dom. React fiber node basically contains state property, listeners and access of other variables which needed for reconciliation.

So, now we have to create an element with the help of document.create().

let el = document.createElement(type);

Now, with the help of props, we going to map properties from props.

if (props.className) el.className = props.className;
if (props.src) el.src = props.src;
if (props.bgColor){
el.style.backgroundColor = props.bgColor;
}

Now, we loop through the list of properties to map the props to the created instance.

//tags of react element(dom element)
['alt','className','href','rel','src','target'].forEach(k=>{
if(props[k]) el[k] = props[k];
});

Now, we want to add an event listener to the created instance.

if(props.onClick){
 el.addEventListener('click',props.onClick);
}

So, now my createInstance method looks like below :

createInstance(type,props,rootContainerInstance,hostContext, internalInstanceHandle,){
let el = document.createElement(type);
if (props.className) el.className = props.className;
if (props.src) el.src = props.src;
if (props.bgColor){
el.style.backgroundColor = props.bgColor;
}
//tags of react element(dom element)['alt','className','href','rel','src','target'].forEach(k=>{
if(props[k]) el[k] = props[k];
});
if(props.onClick){
el.addEventListener('click',props.onClick);
}
return el;
},

createTextInstance, is a method to create an instance of the text node because reactjs handle those element separately which enable us for injecting dynamic text in the tags.

createTextInstance(text,rootContainerInstance,hostContext,internalInstanceHandle){
 return document.createTextNode(text);
}

appendChildToContainer, is a method to append the child node or instance to the react parent container. It takes 2 parameters one is container (parent container) and child (which we going to append).

appendChildToContainer(container,child){
  container.appendChild(child)
}

appendInitialChild, is a method to create and initialize the root node or instance.

appendInitialChild(parent,child){
  parent.appendChild(child)
}

removeChildFromContainer, is a method to remove the child from the container(react-dom tree).

removeChildFromContainer(container,child){
   container.removeChild(child)
}

removeChild, is a method of react-reconciler, is a method to remove the child from dom.

removeChild(parent,child){
   parent.removeChild(child)
}

We have to also need to pass the default parameters, like commitUpdate, finalizeInitialChildren, getChildHostContext, etc.

So implementing these methods, our RectDomMin.js file looks like this.

import ReactReconciler from 'react-reconciler';
let reconciler = ReactReconciler({
supportsMutation : true,
createInstance(type,props,rootContainerInstance,hostContext, internalInstanceHandle,){
let el = document.createElement(type);
if (props.className) el.className = props.className;
if (props.src) el.src = props.src;
if (props.bgColor){
el.style.backgroundColor = props.bgColor;
}
//tags of react element(dom element)['alt','className','href','rel','src','target'].forEach(k=>{
if(props[k]) el[k] = props[k];
});
if(props.onClick){
el.addEventListener('click',props.onClick);
}
return el;
},
createTextInstance(text,rootContainerInstance,hostContext,internalInstanceHandle){
console.log(text)
return document.createTextNode(text);
},
appendChildToContainer(container,child){
container.appendChild(child)
},
appendInitialChild(parent,child){
parent.appendChild(child)
},
commitUpdate(instance,updatePayload,type,oldProps,newProps,finishedWork){},
finalizeInitialChildren(){},
getChildHostContext(){},
getPublicInstance(){},
getRootHostContext(){},
prepareForCommit(){},
resetAfterCommit(){},
shouldSetTextContent(){
     return false
},
removeChildFromContainer(container,child){
container.removeChild(child)
},
removeChild(parent,child){
parent.removeChild(child)
},
insertInContainerBefore(container,child,before){
container.insertBefore(child,before)
},
insertBefore(parent,child,before){
parent.insertBefore(child,before)
},
prepareUpdate(instance,type,oldProps,newProps,rootContainerInstance,currentHostContainer){
let payload;
if(oldProps.bgColor !== newProps.bgColor){
    payload = { newBgColor: newProps.bgColor}
}
return payload
},
commitUpdate(instance,updatePayload,type,oldProps,newProps,finishedWork){
if(updatePayload.newBgColor){
instance.style.backgroundColor = updatePayload.newBgColor;
}
}
});
let ReactDomMini = {
render(whatToRender,div){
let container = reconciler.createContainer(div,false,false); 
//first false for concurrent and second false for hydration
reconciler.updateContainer(whatToRender,container,null,null)
},
};
export default ReactDomMini;
\"\"

If, you want to clone, please go to my GitHub repo.

Please give a clap if you like the post.

\"\""]}}]}}}