Forem: palaklive

Introducing dynamic import for React apps and speed up development with code splitting.

palaklive — Thu, 28 Jan 2021 12:47:20 +0000

Suppose you have a page that renders different components depending on user input. At the moment, managed to solve the issue I was having and have shown my code below which shows how I solved it:

(Before the introduction of dynamic import)

ComponentList.js

import React from "react";
import ComponentOne from "./ComponentOne";
import ComponentTwo from "./ComponentTwo";
import ComponentThree from "./ComponentThree";
export default function ComponentList({ name }) {

switch (name) {
 case "ComponentOne":
   return <ComponentOne />;
  case "ComponentTwo":
   return <ComponentTwo />;
  case "ComponentThree":
   return <ComponentThree />;
  default:
   return null;
 }
}

Main.js

import React, { Component } from "react";
import ErrorBoundary from "./ErrorBoundary";
import ComponentList from "./ComponentList";
import "./styles.css";

export default class Main extends Component {
  constructor(props) {
   super(props);
   this.state = {name: ""};
   this.handleChange = this.handleChange.bind(this);
  }
  handleChange(event) {
   const {value: name} = event.target;
   this.setState({ name });
  }
  render() {
    const {name} = this.state;
    return (
     <ErrorBoundary>
      <select value={name} onChange={this.handleChange}>
       <option value="">None</option>
       <option value="ComponentOne">Component One</option>
       <option value="ComponentTwo">Component Two</option>
       <option value="ComponentThree">Component Three</option>
     </select>
     <ComponentList name={name} />
    </ErrorBoundary>
   );
  }
}

This method allows me to add/remove components very quickly, as I only need to change one import line at a time.

Bundling

Most React apps will have their files “bundled” using tools like Webpack, Rollup, or Browserify. Bundling is the process of following imported files and merging them into a single file: a “bundle”. This bundle can then be included on a webpage to load an entire app at once.

If you’re using Create React App, Next.js, Gatsby, or a similar tool, you will have a Webpack setup out of the box to bundle your app.

Code-Splitting

Bundling is great, but as your app grows, your bundle will grow too. Especially if you are including large third-party libraries. You need to keep an eye on the code you are including in your bundle so that you don’t accidentally make it so large that your app takes a long time to load.

To avoid winding up with a large bundle, it’s good to get ahead of the problem and start “splitting” your bundle. Code-Splitting is a feature supported by bundlers like Webpack, Rollup, and Browserify (via factor-bundle) which can create multiple bundles that can be dynamically loaded at runtime.

Code-splitting your app can help you “lazy-load” just the things that are currently needed by the user, which can dramatically improve the performance of your app. While you haven’t reduced the overall amount of code in your app, you’ve avoided loading code that the user may never need and reduced the amount of code needed during the initial load.

import()

The best way to introduce code-splitting into your app is through the dynamic import() syntax.

Before:

import { add } from './math';
console.log(add(16, 26));

After:

import("./math").then(math => {
  console.log(math.add(16, 26));
});

When Webpack comes across this syntax, it automatically starts code-splitting your app. If you’re using Create React App, this is already configured for you and you can start using it immediately. It’s also supported out of the box in Next.js.

If you’re setting up Webpack yourself, you’ll probably want to read Webpack’s guide on code splitting. Your Webpack config should look vaguely like this.

When using Babel, you’ll need to make sure that Babel can parse the dynamic import syntax but is not transforming it. For that, you will need @babel/plugin-syntax-dynamic-import.

React.lazy

The React.lazy function lets you render a dynamic import as a regular component.

Before:

import OtherComponent from './OtherComponent';

After:

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

This will automatically load the bundle containing the OtherComponent when this component is first rendered.

React.lazy takes a function that must call a dynamic import(). This must return a Promise which resolves to a module with a default export containing a React component.

The lazy component should then be rendered inside a Suspense component, which allows us to show some fallback content (such as a loading indicator) while we’re waiting for the lazy component to load.

Let us now rewrite the logic of the first example.

import React, { Suspense } from "react";
import ErrorBoundary from "./ErrorBoundary";
import "./App.css";

export default function App() {
  const [name, setName] = React.useState("");
  const [DynamicComponent, setDynamicComponent] =
  React.useState(null);
  React.useEffect(() => {
   if (name) {
   const Component = React.lazy(() => import(`./${name}.jsx`));
   return setDynamicComponent(Component);
  }
  return setDynamicComponent(null);
  }, [name]);

  function loadComponent(event) {
   const { value } = event.target;
   setName(value);
  }
  return (
   <Suspense fallback={<div>Loading...</div>}>
     <ErrorBoundary>
       <select value={name} onChange={loadComponent}>
       <option value="">None</option>
       <option value="ComponentOne">Component One</option>
       <option value="ComponentTwo">Component Two</option>
       <option value="ComponentThree">Component Three</option>
       </select>
      {DynamicComponent && <DynamicComponent />}
     </ErrorBoundary>
   </Suspense>
  );
}

From this code sample, we set up our routes using React API, and the ComponentOne, ComponentTwo, and ComponentThree are lazy-loaded. Notice how all the Suspense code encapsulates all the components. This ensures a fallback UI is rendered to the user while the requested components are lazy-loaded.

Because of our setup, webpack chunks our code ahead of time. Consequently, the user receives only the chunks necessary to render a page on demand. For example, when a user visits the homepage, the user receives the ComponentOne.js chunk, and when users visit the shop page, they’ll see the ComponentTwo.js chunk.

Thus, we have significantly reduced our application’s initial load time, even without reducing the amount of code in our app.

7 tips for better React performance

palaklive — Sun, 10 Jan 2021 07:20:40 +0000

React is an amazing JavaScript library for building user interfaces and is well suited for developing large and small apps built to get the highest performance possible today on the web. But sometimes we as a developer end up doing things that result in the poorly performing app.

In this post, I have put together React-specific best practices to boot runtime performance. Also, apart from React. My intention in this post is just to list down the best practices and avoiding the detailed explanation thus keeping the post small.

Identify Performance Issues

In react-dom 16.5+ the React team has provided enhanced profiling capabilities in DEV mode through the React DevTools. This is always the first tool that I grab when investigating potential performance optimizations. You can find them here:

React DevTools Profiler.
- Profiling the performance of a React app can be a difficult and time-consuming process. By installing the React developer tools, you can record and interrogate the performance of individual components in your app and make this process much easier.
- The React DevTools Profiler is usually the first place I will look. There is an official blog post and video walkthrough that goes into great detail on using the profiler to gather performance data.
React DevTools Update Highlighting
- React maintains a virtual DOM that it reconciles against to determine which parts of the UI need to re-render based on props or state changing. This is great, but it also means we don’t really know which parts of our application are updating at any given time. In the React DevTools, there is a setting you can turn on that will visually highlight elements on the screen as they render (or re-render).

3. Why Did You Render

Sometimes you know a certain React component should not be re-rendered unless there’s a very good reason. But how can you identify it? Let me share an incredible utility called @welldone-software/why-did-you-render this will notify you of to cause of the re-rendering. After configuring your console will fill with information to help you track when and why certain components re-render.

4. shouldComponentUpdate

The shouldComponentUpdate() method is the first real life cycle optimization method that we can leverage in React. We can look at our current and new props & state and make a choice if we should move on.
- The purpose of shouldComponentUpdate is to indicate if render should be called. In your case, some parent component has rendered and indicated it wanted to also render an instance of your child component.
- shouldComponentUpdate is your opportunity to short-circuit that render and say 'don't bother, nothing changed down here'.
- Now, to your question, "why was it even called since nothing changed"? React does not compare the old and new props itself. You can get a mixin to do it for you, (ie. PureRenderMixin), but by default React just lets the render run.

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

  shouldComponentUpdate(nextProps, nextState) {
    if (this.props.color !== nextProps.color) {
      return true;
    }
    if (this.state.count !== nextState.count) {
      return true;
    }
    return false;
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Count: {this.state.count}
      </button>
    );
  }
}
}

The reason React doesn't do the comparison itself is for a couple of reasons. Firstly, the performance savings of skipping render may be negligible compared to analyzing props and state. Since React's render mechanism is already optimized to avoid unnecessary DOM manipulation it can just assume the component needs to update and expect reasonable performance. Secondly, doing the comparison is not exactly straight-forward. Is your prop a primitive?, an Immutable? an array? a complex object? will a deep comparison be necessary?
React's model is "We will render everything asked by default. If you want something to opt-out for performance, then go ahead and tell us by implementing shouldComponentUpdate".

5. React.PureComponent

When a class component extends React.PureComponent base class then React treated the component as a Pure component. The major difference between React.Component class and React.PureComponent is the implementation of shouldComponentUpdate(). In React.Component shouldComponentUpdate() will always return true on the other hand in React.PureComponent will compare the current state and props with the new state and props.

import React, {PureComponent} from ‘react’;
export default class Test extends PureComponent{
   render(){
      return ‘’;
   }
}

But, the point is React.PureComponent’s shouldComponentUpdate() only shallowly compares the objects. If these contain complex data structures, it may produce false-negatives for deeper differences. Only extend PureComponent when you expect to have simple props and state, or use forceUpdate() when you know deep data structures have changed. Or, consider using immutable objects to facilitate fast comparisons of nested data.
Furthermore, React.PureComponent’s shouldComponentUpdate() skips prop updates for the whole component subtree. Make sure all the children components are also “pure”.

6. React.memo

React.memo provides similar functionality if you use function components instead of class-based components.
React.memo is a higher order component.
If your component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result.
React.memo only checks for prop changes. If your function component wrapped in React.memo has a useState or useContext Hook in its implementation, it will still rerender when state or context change.
By default it will only shallowly compare complex objects in the props object. If you want control over the comparison, you can also provide a custom comparison function as the second argument.

function MyComponent(props) {
  /* render using props */
}
function areEqual(prevProps, nextProps) {
  /*
  return true if passing nextProps to render would return
  the same result as passing prevProps to render,
  otherwise return false
  */
}
export default React.memo(MyComponent, areEqual);

7. Virtualize large lists with react-window

There may be times where you need to display a large table or list that contains many rows. Loading every single item on such a list can affect performance significantly.
List virtualization, or "windowing", is the concept of only rendering what is visible to the user. The number of elements that are rendered at first is a very small subset of the entire list and the "window" of visible content moves when the user continues to scroll. This improves both the rendering and scrolling performance of the list.

react-window is a library that allows large lists to be rendered efficiently. Here is a beautiful article on this topic.

(Sidenote: If you are interested in productivity, tech, and product topics, follow me on Twitter where I post about these things in an easy and fun way.)

7 hacks to optimize your react app

palaklive — Sun, 10 Jan 2021 06:34:18 +0000

Identify Performance Issues

React DevTools Profiler.
- Profiling the performance of a React app can be a difficult and time-consuming process. By installing the React developer tools, you can record and interrogate the performance of individual components in your app and make this process much easier.
- The React DevTools Profiler is usually the first place I will look. There is an official blog post and video walkthrough that goes into great detail on using the profiler to gather performance data.
React DevTools Update Highlighting
- React maintains a virtual DOM that it reconciles against to determine which parts of the UI need to re-render based on props or state changing. This is great, but it also means we don’t really know which parts of our application are updating at any given time. In the React DevTools, there is a setting you can turn on that will visually highlight elements on the screen as they render (or re-render).

3. Why Did You Render

Sometimes you know a certain React component should not be re-rendered unless there’s a very good reason. But how can you identify it? Let me share an incredible utility called @welldone-software/why-did-you-render this will notify you of to cause of the re-rendering. After configuring your console will fill with information to help you track when and why certain components re-render.

4. shouldComponentUpdate

The shouldComponentUpdate() method is the first real life cycle optimization method that we can leverage in React. We can look at our current and new props & state and make a choice if we should move on.
- The purpose of shouldComponentUpdate is to indicate if render should be called. In your case, some parent component has rendered and indicated it wanted to also render an instance of your child component.
- shouldComponentUpdate is your opportunity to short-circuit that render and say 'don't bother, nothing changed down here'.
- Now, to your question, "why was it even called since nothing changed"? React does not compare the old and new props itself. You can get a mixin to do it for you, (ie. PureRenderMixin), but by default React just lets the render run.

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

  shouldComponentUpdate(nextProps, nextState) {
    if (this.props.color !== nextProps.color) {
      return true;
    }
    if (this.state.count !== nextState.count) {
      return true;
    }
    return false;
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Count: {this.state.count}
      </button>
    );
  }
}
}

The reason React doesn't do the comparison itself is for a couple of reasons. Firstly, the performance savings of skipping render may be negligible compared to analyzing props and state. Since React's render mechanism is already optimized to avoid unnecessary DOM manipulation it can just assume the component needs to update and expect reasonable performance. Secondly, doing the comparison is not exactly straight-forward. Is your prop a primitive?, an Immutable? an array? a complex object? will a deep comparison be necessary?
React's model is "We will render everything asked by default. If you want something to opt-out for performance, then go ahead and tell us by implementing shouldComponentUpdate".

5. React.PureComponent

When a class component extends React.PureComponent base class then React treated the component as a Pure component. The major difference between React.Component class and React.PureComponent is the implementation of shouldComponentUpdate(). In React.Component shouldComponentUpdate() will always return true on the other hand in React.PureComponent will compare the current state and props with the new state and props.

import React, {PureComponent} from ‘react’;
export default class Test extends PureComponent{
   render(){
      return ‘’;
   }
}

But, the point is React.PureComponent’s shouldComponentUpdate() only shallowly compares the objects. If these contain complex data structures, it may produce false-negatives for deeper differences. Only extend PureComponent when you expect to have simple props and state, or use forceUpdate() when you know deep data structures have changed. Or, consider using immutable objects to facilitate fast comparisons of nested data.
Furthermore, React.PureComponent’s shouldComponentUpdate() skips prop updates for the whole component subtree. Make sure all the children components are also “pure”.

6. React.memo

React.memo provides similar functionality if you use function components instead of class-based components.
React.memo is a higher order component.
If your component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result.
React.memo only checks for prop changes. If your function component wrapped in React.memo has a useState or useContext Hook in its implementation, it will still rerender when state or context change.
By default it will only shallowly compare complex objects in the props object. If you want control over the comparison, you can also provide a custom comparison function as the second argument.

function MyComponent(props) {
  /* render using props */
}
function areEqual(prevProps, nextProps) {
  /*
  return true if passing nextProps to render would return
  the same result as passing prevProps to render,
  otherwise return false
  */
}
export default React.memo(MyComponent, areEqual);

7. Virtualize large lists with react-window

There may be times where you need to display a large table or list that contains many rows. Loading every single item on such a list can affect performance significantly.
List virtualization, or "windowing", is the concept of only rendering what is visible to the user. The number of elements that are rendered at first is a very small subset of the entire list and the "window" of visible content moves when the user continues to scroll. This improves both the rendering and scrolling performance of the list.

react-window is a library that allows large lists to be rendered efficiently. Here is a beautiful article on this topic.

(Sidenote: If you are interested in productivity, tech, and product topics, follow me on Twitter where I post about these things in an easy and fun way.)

Functions in JavaScript

palaklive — Fri, 03 May 2019 20:45:57 +0000

What is a Function?

Functions are basically “building blocks” of the program or we can say a function is a process which takes some input called arguments and produces some output called a return value.They allow the code to be called many times without repetition.

It looks like this:

function showMessage() {
  alert('Hello everyone!');
}
showMessage()

Function Declarations Are Hoisted

Function declarations are hoisted—moved in their entirety to the beginning of the current scope. That allows you to refer to functions that are declared later:

function foo() {
    bar();  // OK, bar is hoisted
    function bar() {
        console.log('bar executed successfully.')
    }
}

Note that while var declarations are also hoisted (see Variables Are Hoisted), assignments performed by them are not:

function foo() {
    bar();  // Not OK, bar is still undefined
    var bar = function () {
        // Uncaught TypeError: bar is not a function
    };
}

The Special Variable arguments

You can call any function in JavaScript with an arbitrary amount of arguments; the language will never complain. It will, however, make all parameters available via the special variable arguments. arguments look like an array, but has none of the array methods:

> function f() { return arguments }
> var args = f('a', 'b', 'c');
> args.length
3
> args[0]  // read element at index 0
'a'

Way to Define a Function:

Pure Functions
Function Declaration
Function Expression
Native Function
Recursion Function
Callback
Immediately-invoked function expression

Pure Functions

Given the same input, will always return the same output.
Produces no side effects.

Function declaration:

The function keyword goes first, then goes the name of the function, then a list of parameters between the parentheses (empty in the example above) and finally the code of the function, also named “the function body”, between curly braces.

function add(param1, param2) {
    return param1 + param2;
}

The preceding code defines a function, add, that has two parameters, param1 and param2, and returns the sum of both parameters. This is how you call that function:

> add(6, 1)
7
> add('a', 'b')
'ab'

Function expression

Another way of defining add() is by assigning a function expression to a variable add:

var add = function (param1, param2) {
    return param1 + param2;
};

Native Function

The "prototype" property is widely used by the core of JavaScript itself. All built-in constructor functions use it and native prototypes can be modified.
i.e. If we add a method to String.prototype it becomes available to all strings:


"hello folks!".toUpperCase() // HELLO FOLKS!

"Hello Folks!".toLowerCase() // hello folks!


"hello folks!".toTitleCase()
// Uncaught TypeError: "hello folks!".toTitleCase is not a function


// Let's Define a native function
String.prototype.toTitleCase = function() {
  return this.replace(
            /\w\S*/g,
            function(txt) {
                return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase();
            }
        );
};

"hello folks!".toTitleCase()

During the process of development, we may have ideas for new built-in methods we’d like to have, and we may be tempted to add them to native prototypes. But that is generally a bad idea.

Important:

Prototypes are global, so it’s easy to get a conflict. If two libraries add a method String.prototype.toTitleCase, then one of them will be overwriting the other.

So, generally, modifying a native prototype is considered a bad idea.

Recursion Function

Recursion is a technique for iterating over an operation by having a function call itself repeatedly until it arrives at a result.

Recursion is best applied when you need to call the same function repeatedly with different parameters from within a loop.

var factorial = function(number) {
  var result = 1;
  var count;
  for (count = number; count > 1; count--) {
    result *= count;
  }
  return result;
};

console.log(factorial(5)); // 120


function factorial(x) {
    if(x === 0) return 1
    return x * factorial(x-1);
}

Callback

In JavaScript, functions are first-class objects.First-class manner like any other object (String, Array, Number, etc).

Because functions are first-class objects, we can pass a function as an argument in another function and later execute that passed-in function or even return it to be executed later. This is the essence of using callback functions in JavaScript.

// classic example of callback functions:

var newbies = ["Amit", "Darshan", "Dharmesh", "Priya", "Shivangi"];

newbies.forEach(function (bee, index){
    console.log(index + 1 + ". " + bee);
});


// User define

function sandwich(param1, param2, callback) {
  alert('Started eating my sandwich.\n\nIt has: ' + param1 + ', ' + param2);
  callback();
}

sandwich('jam', 'cheese', function() {
  alert('Finished eating my sandwich.');
});

Again, note the way we pass an anonymous function (a function without a name) to the forEach method as a parameter.

So far we have passed anonymous functions as a parameter to other functions or methods. Lets now understand how callbacks work before we look at more concrete examples and start making our own callback functions.

How Callback Functions Work?

We can pass functions around like variables and return them in functions and use them in other functions. When we pass a callback function as an argument to another function, we are only passing the function definition. We are not executing the function in the parameter.

Note that the callback function is not executed immediately. It is “called back” (hence the name) at some specified point inside the containing function’s body.

the anonymous function will be called later inside the function body. Even without a name, it can still be accessed later via the arguments object by the containing function.

Use Named Functions as Callbacks

Here is a quick example:

function greeting(name) {
  if(name) alert('Hello ' + name);
}

function processUserInput(callback) {
  var name = prompt('Please enter your name.');
  callback(name);
}

processUserInput(greeting);

Pass Parameters to Callback Functions

function createQuote(quote, callback){ 
  var myQuote = "Like I always say, " + quote;
  callback(myQuote); // 2
}
function logQuote(quote){
  console.log(quote);
}
createQuote("Be a voice not an echo!", logQuote);

What is "callback hell"?
JavaScript that uses callbacks, is hard to get right intuitively. A lot of code ends up looking like this:

const verifyUser = function(username, password, callback){
   dataBase.verifyUser(username, password, (error, userInfo) => {
       if (error) {
           callback(error)
       }else{
           dataBase.getRoles(username, (error, roles) => {
               if (error){
                   callback(error)
               }else {
                   dataBase.logAccess(username, (error) => {
                       if (error){
                           callback(error);
                       }else{
                           callback(null, userInfo, roles);
                       }
                   })
               }
           })
       }
   })
};

How do I fix callback hell?

Callback hell is caused by poor coding practices. Luckily writing better code isn't that hard!

You only need to follow rules:

Keep your code shallow:
Here is some messy browser JavaScript that uses browser-request to make an AJAX request to a server:

var form = document.querySelector('form')
form.onsubmit = function (submitEvent) {
  var name = document.querySelector('input').value
  request({
    uri: "http://example.com/upload",
    body: name,
    method: "POST"
  }, function (err, response, body) {
    var statusMessage = document.querySelector('.status')
    if (err) return statusMessage.value = err
    statusMessage.value = body
  })
}

This code has two anonymous functions. Let's give them names!

var form = document.querySelector('form')
form.onsubmit = function formSubmit (submitEvent) {
  var name = document.querySelector('input').value
  request({
    uri: "http://example.com/upload",
    body: name,
    method: "POST"
  }, function postResponse (err, response, body) {
    var statusMessage = document.querySelector('.status')
    if (err) return statusMessage.value = err
    statusMessage.value = body
  })
}

Now we can move the functions to the top level of our program:

document.querySelector('form').onsubmit = formSubmit

function formSubmit (submitEvent) {
  var name = document.querySelector('input').value
  request({
    uri: "http://example.com/upload",
    body: name,
    method: "POST"
  }, postResponse)
}

function postResponse (err, response, body) {
  var statusMessage = document.querySelector('.status')
  if (err) return statusMessage.value = err
  statusMessage.value = body
}

Note that the function declarations here are defined at the bottom of the file. This is thanks to function hoisting.

Modularize

This is the most important part: Anyone is capable of creating modules (aka libraries)

Let's take out the boilerplate code from above and turn it into a module by splitting it up into a couple of files. I'll show a module pattern that works for either browser code or server code (or code that works in both):

// formuploader.js
module.exports.submit = formSubmit

function formSubmit (submitEvent) {
  var name = document.querySelector('input').value
  request({
    uri: "http://example.com/upload",
    body: name,
    method: "POST"
  }, postResponse)
}

function postResponse (err, response, body) {
  var statusMessage = document.querySelector('.status')
  if (err) return statusMessage.value = err
  statusMessage.value = body
}

The module.exports bit is an example of the node.js module system which works in node front-end frameworks follow the ES Module structure.

// formuploader.js
var formUploader = require('formuploader')
document.querySelector('form').onsubmit = formUploader.submit

Immediately Invoked Function Expression (IIFE)

An IIFE (Immediately Invoked Function Expression) is a JavaScript function that runs as soon as it is defined:

The function becomes a function expression which is immediately executed. The variable within the expression cannot be accessed from outside it.

(function () {
    var aName = "Barry";
})();
// Variable name is not accessible from the outside scope
aName // throws "Uncaught ReferenceError: aName is not defined"

Assigning the IIFE to a variable stores the function's return value, not the function definition itself.

var result = (function () {
    var name = "Barry"; 
    return name; 
})(); 
// Immediately creates the output: 
result; // "Barry"

Special Thanks to: