DEV Community: Shubham Khatri

15 Useful VSCode shortcuts to improve your coding speed

Shubham Khatri — Tue, 24 Aug 2021 16:20:43 +0000

VSCode is one of the most popular editors for web development. When writing code, we often require certain formatting actions, and a lot of them are supported by VSCode itself. While most actions can be found from Menu options, having hands-on keyboard shortcuts can help improve your coding speed by a lot.

Here is a list of some shortcuts that I have been using for a while and found to be really useful.

Default shortcuts are for Mac, while shortcuts for Windows and Linux are mentioned below for each command

1. CMD + P: Opens the palette to search for a file

(Windows/Linux: CTRL + P)

Navigating through files is one of the most common options and this command can come in pretty handy. You can type the name of the file in the search box and select the file by clicking or by pressing enter on the search result to open the file

2. CMD + SHIFT + L: Add cursors to all matching selections

(Windows/Linux: CTRL + SHIFT + L)

One of my favorite features of VSCode is multi cursors. They allow you to replace text or append more text without copy-pasting or requiring you to change it one at a time.

Using this command, you can add cursors to all matching selections in the document

3. CMD + D: Add cursor to next matching selection

(Windows/Linux: CTRL + D)

Like the above command, this is also used to add cursors but with this, you can add the cursor to the next matching selection. This is especially helpful when you don't want to select all occurrences together

4. CMD + U: Undo last cursor operation

(Windows/Linux: CTRL + U)

If you need to undo cursor selection in a case where you selected more cursors than required or reset the cursor to a previous position, you can use this command to undo the last cursor action

5. CMD + L: Select current line.

(Windows/Linux: CTRL + L)

Often we use mouse drag to select the text, but if we want to select entire lines, we can use this command

6. CTRL + G: Go to a specific line

(Windows/Linux: CTRL + G)

We can navigate to a specific line of the document by using this simple command and typing the line number.

This is especially helpful in situations when error stack traces provide us the line number of the file and our file is large.

7. CMD + K + W: Close all open editor tabs

(Windows/Linux: CTRL + K + W)

This command is useful when we want to clear all tabs.

Often while debugging or developing, I have opened many tabs and when I want to change the context or start fresh, this command comes in very handy

8. SHIFT + OPTION + A : Toggle block comment

(Windows: SHIFT + ALT + A, Linux: CTRL+SHIFT+A)

This shortcut also allows us to add a new block comment or toggle existing ones.

We enclose a piece of Javascript code with /* */ to add a block comment. However, with this shortcut, we can add or remove a block comment for the selected code block or add new ones.

Line comments can be toggled with CMD + / (Windows/Linux: CTRL + /)

9. CMD + OPTION + [ : Fold code block

(Windows/Linux: CTRL + SHIFT + [ )

This command is especially useful when we want to focus on a specific area of the code and hence ignore some code blocks. This folds the block closest to the cursor.

You can unfold the code block with CMD + OPTION + ] (Windows/Linux: CTRL + SHIFT + ] )

10. OPTION + UP/DOWN : Move line up or down

(Windows/Linux: ALT + UP/DOWN)

When you want to move a piece of code, for example, a variable declaration either up or down, you cut and paste it to the appropriate place but if the readjustment is for a few lines you can use this command to move the current line/selection up or down

11. CTRL + ` : Open integrated terminal

(Windows/Linux: CTRL+ `)

One of the most amazing features of VSCode is that it supports an integrated terminal which you can use just like a normal terminal and to run code or perform other operations. This command helps you open the terminal when you need it

12. CMD + \ : Split editor view

(Windows/Linux: CTRL+)

You can split your editor view to open multiple files together.

This is especially helpful when you want to refer to content from a file while coding in another.

13. SHIFT + OPTION + F : Format document

(Windows: SHIFT+ALT+F, Linux: CTRL+SHIFT+I)

Often we have extensions enabled or settings configured to format documents on save but sometimes we like to control when we want to format the document. This is where this command comes in.

It allows us to format the current document according to the configured settings.

14. OPTION + SHIFT + UP / DOWN : Duplicate selection up or down

(Windows/Linux: SHIFT+ALT+UP/DOWN)

Using this command you can duplicate the selected code either above or below the current code.

I love to use this when some functions are almost identical except for some small changes which I make after duplicating the previous implementation

15. CMD + B: Toggle Sidebar

(Windows/Linux: CTRL+B)

You can use this command to toggle the sidebar to make more space for your file view as and when needed.

Cherry on the cake

code . : Open VSCode from the terminal

Although this isn't a keyboard shortcut, it is extremely useful when you are working with the terminal and want to open a directory in VSCode

P.S. If this isn't configured yet, you can do so from VSCode by open command palette with CMD+SHIFT+P and type in shell and then select Shell Command: Install 'code' command in PATH from the options.

Summary

In this article, I covered some of the common, uncommon, and useful shortcuts.

There are other shortcuts too which are useful like CMD+SHIFT+F for search, CMD+SHIFT+P for showing command palette, CMD+/ for toggling line comment, etc.

Thank you for reading

If you found this article helpful, do like and share this with your colleagues and friends. If you have any suggestions, please feel free to add them in the comments.

I also share tips and tricks related to web development with Javascript and React on Twitter.

Come say hi 👋 . Let us connect 😁

Observer Design Pattern in JavaScript

Shubham Khatri — Mon, 09 Aug 2021 09:46:15 +0000

While working with any language, we tend to use several reusable design solutions to commonly occurring problems. In JavaScript, too, we have a mix of well-defined patterns.

The Observer pattern is one of them.

In this article, we shall understand more about the Observer design pattern in JavaScript and implement a small example in vanilla JavaScript.

What Is the Observer Design Pattern?

The Observer pattern follows a subscription model. A subscriber (commonly referred to as the observer) subscribes to an event or an action handled by a publisher (commonly referred to as the subject) is notified when the event or action occurs.

The subject broadcasts the occurrence of the event or action to all the observers.

When the observer no longer wishes to be notified of the changes by the subject, it unsubscribes itself from the subject, and the subject then removes it from the list of subscribers.

An Observer design pattern is very similar to a Publisher/Subscriber pattern, with a small difference that a Publisher/Subscriber pattern also specifies a topic it wants to subscribe to.

For example, when detecting keyboard shortcuts, the subscriber can choose to specify a key combination that it wants to listen to in a Publisher/Subscriber model.

Implementation of the Observer Pattern

As an example of the Observer pattern, we will go about implementing a simple interaction where multiple elements listen to the mouse position on the screen and perform different actions.

Below is an example of what our interaction looks like:

Before we implement this interaction, let us analyze what is happening in this example as the mouse position changes.

The mouse position is immediately updated in the textbox at the top right corner.
The circle follows the trajectory of the mouse after a delay of 1s.

From the above description, we see that multiple components need information about the same thing but behave differently.

From the above example, we identify that the subject listens to the mouse event on the window and relays it to whoever wants it. The circle and textbox are observers in the above example.

So let us now go ahead and implement it.

Step 1. Implement a MousePositionObservable class

As a first step let us go ahead and implement the MousePositionObservable class. This class needs to do the following things:

Keep a list of observer callbacks.
Expose a subscribe method which the observers will call to subscribe to the change. The return value of this must be a function that will move the callback from the set of subscriptions when called.
Listen to mouseMove event and trigger all subscription callbacks.

The code looks like the below:

class MousePositionObservable {
  constructor() {
    this.subscriptions = [];
    window.addEventListener('mousemove',this.handleMouseMove);
  }
  handleMouseMove =  (e) => {
     this.subscriptions.forEach(sub => sub(e.clientX, e.clientY));
  }
  subscribe(callback) {
    this.subscriptions.push(callback);    

    return () => {
      this.subscriptions = this.subscriptions.filter(cb => cb !== callback);
    }
  }
}

Step 2. Create HTML elements

We now create our HTML elements for circle and textMessageBox and add styles to them.

<div class="container">
  <div class="circle" ></div>
  <div class="mouse-position">
  <h4>Mouse Position</h4>
  <div class="position"></div>
</div>
</div>

.container {
  position: relative;
  width: 100vw;
  height: 100vh;
  background-color: #f3df49;
}
.circle {
  position: absolute;
  background-color: #238643;
  width: 25px;
  height: 25px;
  border-radius: 50%;
  z-index: 2;
}

.mouse-position {
  position: fixed;
  top: 20px;
  right: 20px;
  width: 200px;
  height: 100px;
  background-color: black;
  border-radius: 4px;
  padding: 4px 16px;
  color: white;
}

.mouse-position h4 {
  color: white;
  margin: 10px 0;
}

Step 3. Add observers

The last step to make it come together is to create an instance of our MousePositionObservable class and add observers to it.

To do that we shall invoke the subscribe method on the class instance and pass on a callback.

Our code looks like the below:

const mousePositionObservable = new MousePositionObservable();

mousePositionObservable.subscribe((x, y) => {
  const circle = document.querySelector('.circle');
   window.setTimeout(() => {
     circle.style.transform = `translate(${x}px, ${y}px)`;
   }, 1000);
});

// Update the mouse positon container to show the mouse position values
mousePositionObservable.subscribe((x, y) => {
  const board = document.querySelector('.mouse-position .position');
  board.innerHTML = `
    <div>
       <div>ClientX: ${x}</div>
       <div>ClientY: ${y}</div>
    </div>
  `
})

We add two subscriptions to the MousePositionObservable instance, one for each element that needs to listen to mouse values.

The subscription callback for the circle element gets the reference of the DOM element and updates its transform property. The transform property will use hardware acceleration where possible, so using translate() over position top and left will see performance benefits if any animations or transitions are also being used on the element.

The subscription callback for the textbox element updates its HTML content by using the innerHTML property.

Note: When you want to unsubscribe the listener, all you have to do is to store the returned value from the subscribe function call and invoke it like a function

That is all we need for our demo.

You can check out the working example in the Codepen below:

Advantages and Disadvantages of the Observer Design Pattern

An Observer design pattern provides us the following benefits:

It is extremely useful when we want to perform multiple actions on a single event.
It provides a way to decouple functionalities while maintaining consistency between related objects.

The downside of this pattern stems from its benefits:

Since the Observer design pattern leads to loosely coupled code, it is sometimes hard to guarantee that other parts of the application are working as they should. For example, the subscriptions added to the subject may have code that is behaving incorrectly, but there is no way for the publisher to know that.

Real-World Applications

While working with web development we see that Redux and React Context are both examples of implementations built upon the Observer Design Pattern.

In Redux, we have a subscribe method that allows us to add observers to the redux state which acts as the subject. Whoever subscribes to the redux store is notified when any change is made to the store.

Similarly, with React Context whenever the value is updated for the ContextProvider, all components that subscribe to the Context either through the useContext hook or through Context.Consumer are re-rendered with updated context values.

Conclusion

In this article, we went through the Observer design pattern and how to use it within our application. We also implement a demo based on this pattern and learned about some of the advantages and disadvantages of following this approach to designing interactions.

Thank you for reading.

If you found this article useful and informative, please don't forget to like and share it with your friends and colleagues.

If you have any suggestions, please feel free to comment.

Follow me on Twitter for more web development content.

What is StrictMode in React

Shubham Khatri — Tue, 03 Aug 2021 06:18:52 +0000

As we gain more experience, we constantly evolve our coding practices and design patterns. This is the case with React too.

React has also gone through many transitions, and as it has progressed, certain practices that were believed to be good in the past are no longer fit for the future roadmap.

One significant change happened with the release of v16 where it went through a re-write onto React Fiber’s architecture. The major focus was on scheduling (i.e. deciding when a piece of work should be performed while keeping in mind the priorities of different tasks such as animations, UI updates, and so on).

At about the same time, a new Context API was added in React.

Also, intending to provide Concurrent Mode in future versions where the rendering phase is split into multiple parts, a lot of change has come about. The start of it saw the introduction of React Hooks, deprecation of certain lifecycle methods, and more.

This article will look at all the deprecated patterns that StrictMode in React helps us identify.

What Is React.StrictMode and How Can We Use It?

React.StrictMode is a tool for highlighting potential problems in an application. It works by rendering it as a component encapsulating either part of or your entire application. StrictMode does not render any visible element in the DOM but enables certain checks and provides warnings in development mode.

Note: StrictMode doesn’t run any checks or show warnings in production mode.

You can enable React.StrictMode for your entire application like so:

import ReactDOM from 'react-dom';
import React from 'react';
import App from './App';

ReactDOM.render(
   <React.StrictMode>
      <App />
   <React.StrictMode>,
   document.getElementById("app")
);

You can similarly enable it in part of your application by wrapping it with <React.StrictMode>.

The following functionalities are supported in StrictMode as of v17 of React:

Identifying legacy string refs.
Detecting deprecated findDOMNode method.
Detecting use of legacy Context API.
Detecting unsafe lifecycle methods that have been deprecated by React.
Detecting unexpected side effects in React components.

1. Identifying Legacy String refs

Refs in the initial versions of React were assigned using strings. However, there were many problems associated with it, as pointed out by Dan Abramov in this Github Issue:

“It requires that React keeps track of currently rendering component (since it can’t guess this). This makes React a bit slower.

It doesn’t work as most people would expect with the “render callback” pattern (e.g. <List renderRow={this.renderRow} />) because the ref would get placed on List for the above reason.

It is not composable, i.e. if a library puts a ref on the passed child, the user can’t put another ref on it. Callback refs are perfectly composable.”

For these reasons and many others, such as the issues with typing refs in TypeScript where they need to be casted, better alternatives were introduced for class components:

Callback refs
React.createRef

2. Detecting deprecated `findDOMNode` method

The ReactDOM.findDOMNode method was previously used to get the DOM node given the class instance. The usage of findDOMNode can always be avoided by adding a ref directly to the DOM element instead of the class instance.

There are two main problems with the findDOMNode API:

This would only return the first child in a class component instance. However, with the introduction of Fragments in v16, you could return multiple elements from a component instance and this could cause a problem, as you may want to target a wrapper of all the elements or a specific element from the list of elements returned.
The findDOMNode API was request-only (i.e. it would evaluate and return the result when it was called). If, for instance, the rendered element is conditionally changed in the child, the parent may not know about it.

The alternative to findDOMNode is to use React.forwardRef and pass on the ref to the desired element in the child or to pass the ref by a separate name (such as innerRef) and use it from props in the child component to set a ref on the desired element.

3. Legacy Context API

Version 16.3 of React introduced a new Context API. Before this, the old error-prone API was in use and would cause the consumers to not update if a component somewhere in the parent hierarchy stopped re-renders of the children element by implementing shouldComponentUpdate.

Even though React continues to support the old API in v16.x, StrictMode will point out the usages of the old Context API by showing warnings so that these can be moved to the latest version.

4. Detecting unsafe lifecycle methods

In v16.3.0 of React, some breakthrough changes were made to the React APIs. One of those changes was the deprecation of lifecycle methods like componentWillMount, componentWillReceiveProps, and componentWillUpdate. New lifecycles were also added, such as getDerivedStateFromProps and getSnapShotBeforeUpdate.

Although these lifecycle methods continue to be available in further versions of React and have been renamed with a prefix UNSAFE_ added to them, React may remove them altogether in future versions.

Why were these lifecycle methods deprecated?

To understand this, we must first know that React typically works in two phases:

Render phase: During this phase, React checks what changes need to be made to the DOM. React invokes a render function during this phase and compares the result with the previous render. The render phase lifecycles included componentWillMount, componentWillReceiveProps, componentWillUpdate, and render .

Commit phase: This is the phase during which React actually commits the changes to the DOM and invokes commit phase lifecycles such as componentDidMount and componentDidUpdate.

The commit phase is fast, but the render phase can be slow. To optimize it with the vision of Concurrent Mode, React decided to break the rendering into pieces and pause and resume work to avoid blocking the browser.

So when they do this, the render phase lifecycles could be called multiple times, and if these contain side effects or incorrect practices, they may cause the application to behave inconsistently. Also, some of these lifecycles encourage bad developer practices. These include:

componentWillMount
componentWillReceiveProps
componentWillUpdate

Let us look at a few of these practices.

Calling setState in componentWillMount

// Incorrect
class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {};
  }

  componentWillMount() {
    this.setState({
      selectedTheme: this.props.defaultTheme,
    })
  }

  // Rest of code
}

// Correct approach
class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
        selectedTheme: props.defaultTheme,
    };
  }

  // Rest of code
}

As you can see in the snippet above, componentWillMount was used to set a state before the initial render, but that can easily be refactored by setting the initial state in the constructor or with state as a class property.

Async request in componentWillMount

Having an async fetch request in componentWillMount is problematic for both server-side rendering as well as the upcoming Concurrent Mode. With server-side rendering, the data fetched in componentWillMount will not be used. With async rendering, the fetch request may go multiple times.

// Incorrect way to fetchData
class ExampleComponent extends React.Component {
  state = {
     data: []
  }
  componentWillMount() {
    fetchData().then(res => {
      this.setState({
        data: res.data
      });
    })
  }

  // Rest of the code
}

// Correct way to fetchData and update state
class ExampleComponent extends React.Component {
  state = {
     data: [],
     isLoading: true,
  }
  componentDidMount() {
    fetchData().then(res => {
      this.setState({
        data: res.data,
        isLoading: false
      });
    })
  }

  // Rest of the code
}

There is a common misconception that any data fetched inside componentWillMount will be available before the initial render. This is not true and you should use a loading state to avoid using the data in the initial render and make an API call to fetch data in componentDidMount.

Adding subscriptions or listeners in componentWillMount

There are two problems with adding subscriptions/listeners in componentWillMount:

With server-side rendering, the componentWillUnmount function is not called on the server and hence cleanups will not happen and may result in memory leaks.
With async rendering, multiple subscriptions may be attached, as rendering phase lifecycles may be invoked multiple times.

// Incorrect way
class ExampleComponent extends React.Component {
  componentWillMount() {
    this.unlisten = this.props.dataSource.listen(
      this.handleDataSourceChange
    );
  }

  componentWillUnmount() {
   this.unlisten();
  }

  handleDataSourceChange = data => {};
}

// Correct way
class ExampleComponent extends React.Component {
  componentDidMount() {
    this.unlisten = this.props.dataSource.listen(
      this.handleDataSourceChange
    );
  }

  componentWillUnmount() {
   this.unlisten();
  }

  handleDataSourceChange = data => {};
}

The correct way to add and remove listeners is to pair up the componentDidMount and componentWillUnmount lifecycle methods.

Updating state or calling side effects on prop change

Previously, the componentWillReceiveProps lifecycle was used for updating state or calling side effects in the children whenever parent props changed. Although there was not much wrong with it, developers had a misconception that this lifecycle was only called when props updated.

However, it was invoked whenever parent props re-rendered.

So any invocation of functions or state updates may have inconsistent behaviors if not done properly after comparing previous and current props.

Reading DOM properties before an update

Sometimes you may want to save certain DOM properties, such as scroll position before an update to revert it when the update is applied to prevent the items currently in view for the user from going out of view if new items are added or removed.

Previously, you would do so in the componentWillUpdate lifecycle method. However, with async rendering, there may be a gap between the time when componentWillUpdate is called and when componentDidUpdate is called, which may lead to inconsistencies if the user interacted with the DOM in a way that actually changed the scroll position, such as resizing the window or actually scrolling more content. getSnapshotBeforeUpdate is suggested as an alternative to componentWillUpdate for this reason since it is called just before the DOM mutations are made.

Now that we have gone through a few reasons as to why the usages were removed, let us get back to the point.

We may be tempted to think, “Why do we even need some utility to point us to the unsafe functions? We can simply search and update them with the recommended practices.”

While you are correct and can do so in your own code base, you will not be able to easily identify unsafe lifecycles within libraries that you use as dependencies in your codebase. StrictMode will help you point those out too so that you can update them (or replace them with alternatives if the latest versions are not compatible).

5. Detecting unexpected side effects

As we established in the previous section that React wanted to optimize the rendering phase in the upcoming Concurrent Mode, it decided to break down the rendering phase. As a result, rendering phase lifecycles can be called multiple times, causing unexpected behaviors if side effects are used within them.

In the latest version of React, these functions include:

constructor
getDerivedStateFromProps
shouldComponentUpdate
render
setState updater functions in both class and functional components
functions passed to useMemo, useState, useReducer

While side effects are non-deterministic, StrictMode helps by making it a little more deterministic to the developer by double-invoking the functions above. This way, if any side effect is incorrectly written in a rendering phase function, it can be in Development Mode itself due to the obvious inconsistencies presented by it.

For example, if a WebSocket connection is being established in a constructor function, a double invocation of constructor in Development Mode can help make it easier to spot, as two connections will be established.

Key Takeaways

React.StrictMode can be enabled for part of or the entire application.
It is only run in Development Mode to provide warnings for legacy ref usage, the deprecated findDOMNode method, the legacy Context API, unsafe lifecycles, and unexpected side effects.
StrictMode leads to an intentional double invocation of rendering phase lifecycles and functions to make it easier to spot unexpected side effects implemented in these functions.

Thank you for reading.

If you found this article useful and informative, please don't forget to like and share it with your friends and colleagues.

If you have any suggestions, please feel free to comment.

Follow me on Twitter for more web development content.

How to debounce and throttle functions with React hooks

Shubham Khatri — Tue, 27 Jul 2021 07:18:04 +0000

Debouncing and throttling are two very common terms that we come across when trying to optimize function calls. They can be very useful for improving the performance of user interactions.

Before jumping into the main implementation, let’s understand the basic concepts of debounce and throttle and their real-life use cases (skip ahead if you are already familiar with these concepts).

What Is debounce?

Debouncing enforces that there is a minimum time gap between two consecutive invocations of a function call.

For example, a debounce interval of 500ms means that if 500ms hasn’t passed from the previous invocation attempt, we cancel the previous invocation and schedule the next invocation of the function after 500ms.

A common application of debounce is a Typeahead.

What Is throttle?

Throttling is a technique with which a function is invoked at most once in a given time frame regardless of how many times a user tries to invoke it.

For example, given a throttle interval of 500ms, if we try to invoke a function n times within 500ms, the function is called only once when 500ms has elapsed from the beginning.

Throttle is commonly used with resize or scroll events.

Using debounce and throttle With Class Components

Before we dive into how we can use throttle/debounce in functional components with Hooks, let’s quickly see how we do it in a class component.

We define the debounced/throttled version of our function in the constructor function, and that is all we need to do.

Note: I am using lodash debounce and throttle functions in this article.

import React from "react";
export default class App extends React.Component {
  constructor(props) {
    super(props);
    this.debouncedOnChange = _.debounce(this.handleChange, 300);
    this.debouncedHandleWindowResize = _.throttle(this.handleWindowResize, 200);
  }
  handleChange = (_, property) => {
    // your logic here
  };

  handleWindowResize = (_, property) => {
    // your resize logic here
  };

  // rest of rendering code
}

Check out the sample demo in the StackBlitz below:

Using debounce and throttle in Functional Components

We shall attempt to try to convert the class-based implementation to a function-based approach.

The first thing that comes to mind is to directly define the debounced and throttled function within the functional component. So let’s try that first:

import React from "react";
import _ from "lodash";
export default function App() {

  const onChange = () => {
    // code logic here
  };
  const handleWindowResize = () => {
    // code logic here
  };
  const debouncedOnChange = _.debounce(onChange, 300);
  const throttledHandleWindowResize = _.throttle(handleWindowResize, 300);

   //rendering code here
}

When we do it this way, on every render cycle of the component, a new instance of the debounced/throttled function is created. Basically, we aren’t calling the same function after each re-render and it doesn’t work as expected, which you can see in the StackBlitz demo below:

So this is definitely not the right way of using debounce/throttle in functional components.

Refining Our Implementation Based on Our Learning

Now that we understand that we do not want multiple instances of our debounced or throttled function to get created after each render cycle, we shall try to optimize it. One way we can do that is by using the useCallback Hook.

According to the React docs on useCallback:

“Pass an inline callback and an array of dependencies. useCallback will return a memoized version of the callback that only changes if one of the dependencies has changed.”

import React, { useState, useEffect, useCallback } from "react";
import _ from "lodash";

export default function App() {
  const [inputValue, setInputValue] = useState("");

  const onChange = () => {
    console.log('inputValue', inputValue);
    // other logic here
  };
  //debounced onChange functin
  const debouncedOnChange = useCallback(_.debounce(onChange, 300), [inputValue]);

  const handleWindowResize = useCallback((_, property) => {
   // logic here
  }, []);

  const throttledHandleWindowResize = useCallback(
    _.throttle(handleWindowResize, 300),
    []
  );

  const handleChange = e => {
    setInputValue(e.target.value);
  };

  useEffect(() => {
    onChange();
    debouncedOnChange();
  }, [inputValue]);

  // other code here
}

In the snippet above, we see that the onChange handler makes use of the enclosing state inputValue. So when we create the memoized debounced function with useCallback, we pass inputValue in the dependency array of useCallback. Otherwise, the values obtained in the function call will be stale values instead of the updated ones due to closures.

We have a problem, though: A new reference of our function only gets created when inputValue changes. However, the input value changes every time we want to call the function, so we will still face the same problem of a new reference getting created. The net result is that our function still doesn’t work as expected.

The throttled function, for its part, doesn’t use any state or enclosing variable and hence works perfectly well with an empty dependency array.

The StackBlitz below shows the same behavior:

Further Optimizing the Approach

We now know that useCallback can help if we are able to create the instance of the debounced or throttled function only on the initial render, so can we solve the problem of stale closures without having to add a dependency to useCallback?

Well, you are in luck. The answer is yes.

There are at least two ways we can solve this problem.

Keeping a copy of our state in ref: Since refs are mutated, they aren’t truly affected by closures in the sense that we can still see the updated value even if the reference is old. So whenever we are updating the state, we also update the ref. We shall not go down this path unless it’s a last resort, as it is a bit hacky and involves a lot of state duplication, which isn’t ideal.
Pass values as arguments: Instead of relying on closures to use a value, we can pass all the necessary values that our function needs as arguments.

Our code looks like this:

import React, { useState, useEffect, useCallback } from "react";
import _ from "lodash";
export default function App() {
  const [inputValue, setInputValue] = useState("");
  const [debounceValues, setDebounceValues] = useState({
    nonDebouncedFuncCalls: 0,
    debouncedFuncCalls: 0
  });
  const [throttleValues, setThrottleValues] = useState({
    nonThrottledFunctionCalls: 0,
    throttledFuntionCalls: 0
  });

  const onChange = (property, inputValue) => {
    console.log(`inputValue in ${property}`, inputValue);
    setDebounceValues(prev => ({
      ...prev,
      [property]: prev[property] + 1
    }));
  };
  const handleWindowResize = useCallback((_, property) => {
    setThrottleValues(prev => ({
      ...prev,
      [property]: prev[property] + 1
    }));
  }, []);

  const debouncedOnChange = useCallback(_.debounce(onChange, 300), []);
  const throttledHandleWindowResize = useCallback(
    _.throttle(handleWindowResize, 300),
    []
  );

  const handleChange = e => {
    const value = e.target.value;
    setInputValue(value);
    onChange("nonDebouncedFuncCalls", value);
    debouncedOnChange("debouncedFuncCalls", value);
  };

  const onWindowResize = useCallback(e => {
    handleWindowResize(e, "nonThrottledFunctionCalls");
    throttledHandleWindowResize(e, "throttledFuntionCalls");
  }, []);

  useEffect(() => {
    window.addEventListener("resize", onWindowResize);
    return () => {
      window.removeEventListener("resize", onWindowResize);
    };
  }, [onWindowResize]);

  //rest of the rendering code
}

In the code above, we are passing the inputValue as an argument to the debounced function and thus ensuring that it has all the latest values it needs and works smoothly.

Note: Using functional state updates can also help to avoid passing every property — especially if it just has to update the state.

Check out the full working code in the StackBlitz below:

So there we have it. Our debounced and throttled functions now work well with functional components too, and it wasn’t as complicated as we imagined it to be.

Note: Instead of the useCallback, we can also use useMemo, but the main approach logic will remain the same.

Summary

We performed a step-by-step conversion of a class component to a functional component using debounce with React Hooks. These are the key takeaways:

We need to use the same instance of the created function as much as possible.
Use the useCallback/useMemo Hook to memoize our created functions.
To avoid closure issues and also prevent the function from getting recreated, we can pass the values needed by the function as arguments.
State updates that need previous values can be implemented using the functional form of setState.

Thank you for Reading

Please do share your suggestions in the comments below. If you liked this article share this with your friends.

Consider following me on Twitter for more tips and trips related to web development.

How to implement a Collapsible Overflow Menu in React

Shubham Khatri — Tue, 20 Jul 2021 06:04:19 +0000

The most common use cases of Intersection Observer are Lazy Loading Images and Infinite Scroll. However it highly powerful and can be used for a wide range of interactions.

Most of us have either implemented or read about implementing a Responsive Navbar through CSS in which we move elements to dropdown when there is not enough space. But what if there is another way to handle such an interaction which can be more flexible.

In this post we are going to implement a Collapsible Overflow menu, in which only the items that can take the available space will be shown upfront and rest will go inside the overflow menu.

Why Intersection Observer?

The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport. — developer.mozilla.org

For our design, IntersectionObserver can be a good fit because it can provide information about menu items that are overflowing the container (i.e. not visible within the container).

This is how our final interaction is going to look like:

Collapsible menu

Let’s start!

Let us analyse what we need based on the interaction:

We need to know all elements that are present inside the container.
We also need information of which one’s are visible and which one’s are overflowing the container on resizing.
Once we have both the information we can just control the visibility of elements with CSS and render overflowing items inside the overflow menu.

First we start with an initial block of code that renders menu items as children in a container.

For the purpose of this post, I am using Material-UI with static content but the same concept can be extended to any component library or custom components and dynamic content too.



import React from "react";
import Button from "@material-ui/core/Button";
import { makeStyles } from "@material-ui/core/styles";
import DeleteIcon from "@material-ui/icons/Delete";
import CloudUploadIcon from "@material-ui/icons/CloudUpload";
import KeyboardVoiceIcon from "@material-ui/icons/KeyboardVoice";
import Icon from "@material-ui/core/Icon";
import ArchiveIcon from "@material-ui/icons/Archive";
import StarIcon from "@material-ui/icons/Star";
import SaveIcon from "@material-ui/icons/Save";
import DownloadIcon from "@material-ui/icons/ArrowDownward";
import IntersectionObserverWrapper from "./intersection-observer-wrapper";
const useStyles = makeStyles((theme) => ({
  button: {
    margin: theme.spacing(1),
    display: "flex",
    flex: "0 0 auto"
  }
}));

export default function IconLabelButtons() {
  const classes = useStyles();
  return (
    <IntersectionObserverWrapper>
      <Button
        color="primary"
        data-targetid="save"
        className={classes.button}
        startIcon={<SaveIcon />}
      >
        Save
      </Button>
      <Button
        color="primary"
        data-targetid="upload"
        className={classes.button}
        startIcon={<CloudUploadIcon />}
      >
        Upload
      </Button>
      <Button
        color="primary"
        data-targetid="download"
        className={classes.button}
        startIcon={<DownloadIcon />}
      >
        Download
      </Button>
      <Button
        color="primary"
        data-targetid="send"
        className={classes.button}
        startIcon={<Icon>send</Icon>}
      >
        Send
      </Button>
      <Button
        color="primary"
        data-targetid="star"
        className={classes.button}
        startIcon={<StarIcon />}
      >
        Star
      </Button>
      <Button
        color="primary"
        data-targetid="archive"
        className={classes.button}
        startIcon={<ArchiveIcon />}
      >
        Archive
      </Button>
      <Button
        color="primary"
        data-targetid="delete"
        className={classes.button}
        startIcon={<DeleteIcon />}
      >
        Delete
      </Button>
    </IntersectionObserverWrapper>
  );
}

Notice that we are passing a unique prop data-targetid to each child of IntersectionObserverWrapper, which will be used later on.

Now let’s dive into the core logic where we will implement the IntersectionObserverWrapper.

Create a new instance of IntersectionObserver.
Pass root element as the container of the child elements. (navRef.current in our example)
Set the threshold to 1. This means that, at any change in 100% of the target visibility our Observers callback will be executed.
In the observer callback we will update a state map to track visibility of elements.
After creating the Observer, we need to observe our targets i.e. menu items. For this, we get all the children of ancestor node which in our case is referenced with navRef and add as target only if it has a data-targetid property.
Both the logic of creating observer and adding targets can be added inside useEffect which runs post initial render.
Remember to disconnect the observer on unmount of the component.




export default function IntersectionObserverWrapper({ children }) {
  const classes = useIntersectionStyles();
  const navRef = useRef(null);
  const [visibilityMap, setVisibilityMap] = useState({});
  const handleIntesection = () => {
    // our logic of maintaining visibility state goes here 
  }
  useEffect(() => {
    const observer = new IntersectionObserver(
      handleIntersection,
      {
        root: navRef.current,
        threshold: 1
      }
    );
    // We are addting observers to child elements of the container div
    // with ref as navRef. Notice that we are adding observers
    // only if we have the data attribute targetid on the child element
    Array.from(navRef.current.children).forEach((item) => {
      if (item.dataset.targetid) {
        observer.observe(item);
      }
    });
    return () = {
       observer.disconnect();
    }
  }, []);
  return (
    <div className={classes.toolbarWrapper} ref={navRef}>
       {children}
    </div>
  );
}

Now we are ready to handle the logic for maintaining visibility state (visibilityMap).



const handleIntersection = (entries) => {
    const updatedEntries = {};
    entries.forEach((entry) => {
      const targetid = entry.target.dataset.targetid;
      // Check if element is visibile within container 
      if (entry.isIntersecting) {
        updatedEntries[targetid] = true;
      } else {
        updatedEntries[targetid] = false;
      }
    });
    // Overwrite previous state values with current state
    setVisibilityMap((prev) => ({
      ...prev,
      ...updatedEntries
    }));
};

Now that we have visibility state of each menu item, we can control their visibility during rendering by adding additional classNames using React.cloneElement(Yes, have to use React.cloneElement, can’t do it any other way for static children).The visibility can either be controlled by setting CSS property visibility or opacity.



return (
    <div className={classes.toolbarWrapper} ref={navRef}>
      {React.Children.map(children, (child) => {
        return React.cloneElement(child, {
          className: classnames(child.props.className, {
            [classes.visible]: !!visibilityMap[child.props["data-targetid"]],
            [classes.inVisible]: !visibilityMap[child.props["data-targetid"]]
          })
        });
      })}
    </div>
  );

Our Implementation up till this point will look like this:

Hold on. Its not finished yet…

Let’s implement Overflow Menu

For overflow menu we need to pass down all menu items and their visibility state as props.

Note: We can choose to render the Overflow menu outside of our container in all conditions or inside of it so that it is right beside the last visible element instead of being at the end of container always. For this demo, I will add it inside the container since it has higher complexity than it being rendered outside of container.



return (
    <div className={classes.toolbarWrapper} ref={navRef}>
      {React.Children.map(children, (child) => {
        return React.cloneElement(child, {
          className: classnames(child.props.className, {
            [classes.visible]: !!visibilityMap[child.props["data-targetid"]],
            [classes.inVisible]: !visibilityMap[child.props["data-targetid"]]
          })
        });
      })}
      <OverflowMenu
        visibilityMap={visibilityMap}
        className={classes.overflowStyle}
      >
        {children}
      </OverflowMenu>
    </div>
  );

Note that we haven’t passed the prop data-targetid to OverflowMenu component as we do not want our IntersectionObserver to observe on it.

The rendering logic of Overflow menu is simple, we filter and render only elements that are visible inside the menu



<Menu
        id="long-menu"
        anchorEl={anchorEl}
        keepMounted
        open={open}
        onClose={handleClose}
      >
        {React.Children.map(children, (child) => {
          if (!props.visibilityMap[child.props["data-targetid"]]) {
            return (
              <MenuItem key={child} onClick={handleClose}>
                {React.cloneElement(child, {
                  className: classnames(child.className, classes.inOverflowMenu)
                })}
              </MenuItem>
            );
          }
          return null;
        })}
</Menu>

Also the key to aligning the overflow menu to the right of last visible element is using flexbox with order property. The visible elements will have an order value less than that of overflow menu and the invisible elements will have the order value higher than it.



const useIntersectionStyles = makeStyles(() => ({
  visible: {
    order: 0,
    opacity: 1
  },
  inVisible: {
    order: 100,
    opacity: 0,
    pointerEvents: "none"
  },
  toolbarWrapper: {
    display: "flex",
    overflow: "hidden",
    padding: "0 20px"
  },
  overflowStyle: {
    order: 99,
    position: "sticky",
    right: "0",
    backgroundColor: "white"
  }
}));

And that is everything you need to build a collapsible menu!

Here is a full CodeSandbox Demo

Conclusion

We successfully made a collapsible menu in react. Our application only renders items that are visible within the container and the overflowing elements are rendered inside the overflow menu.

You can find the Github repository here for the full code.

Thank you for reading...

Do let me know your feedback about the posts in the comments. You can also reach out to me via DM on Twitter and follow me for more such content.

Good luck!

Implement your own Promises in JavaScript

Shubham Khatri — Mon, 12 Jul 2021 06:18:42 +0000

Promises are one of the most fundamental concepts in JavaScript that all of us have used many times in our applications but can we implement our own Promise API?

Don’t worry it is not as complicated as it looks.

In this post, we will implement a basic Promise API ourselves.

What is a Promise?

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

It can be in one of the three states:

PENDING, initial state when an operation is in progress
FULFILLED, define that the operation was successful
REJECTED, denotes a failure in an operation

Note: A promise is said to be settled when it is either fulfilled or rejected. (we are going to use this term a lot in this article)

How do you use a Promise?

Let’s first look at its skeleton for implementing promises, essentially the input it takes, and the methods it exposes.

It has a constructor function that takes a callback, and methods like then, catch, and finally.

const promise = new Promise((resolve, reject) => {
   /*
     Your code logic goes here and you call  resolve(value)
     or reject(error) to resolve or reject the promise
   */ 
})

promise.then((value) => {
   // Code logic on success of an operation
}).catch(error => {
  // Code logic on failure of an operation
}).finally(() => {
  // Code logic to be executed after completion of operation
})

1. Defining the skeleton

We start by defining our Promise class MyPromise.

Following properties are defined in the constructor:

state: can be either be PENDING, FULFILLED or REJECTED
handlers: stores callbacks of then, catch, finally methods. (Handlers will only be executed when a promise is settled.)
value : resolve or rejected value.

Note: A promise is executed as soon as it is created, which means our promise callback function will be called inside the constructor with rejectand resolvemethods passed as parameters to it.


const STATE = {
  PENDING: 'PENDING',
  FULFILLED: 'FULFILLED',
  REJECTED: 'REJECTED',
}
class MyPromise {
    constructor(callback) {
      // Initial state of Promise is empty
      this.state = STATE.PENDING;
      this.value = undefined;
      this.handlers = [];
      // Invoke callback by passing the _resolve and the _reject function of our class
      try {
        callback(this._resolve, this._reject);
      } catch (err) {
        this._reject(err)
      }
    }

    _resolve = (value) => {}

    _reject = (error) => {}

    then(onSuccess, onFail) {
    }

    catch(onFail) {
    }

    finally(callback) {
    }
}

2. _resolve() and _reject() method implementation

_resolve()or _reject() set the state of promise to FULFILLED or REJECTED respectively, updates the value property and executes the attached handlers.

Note: Nothing happens if we try to call _resolve() or _reject() on an already settled Promise.

  _resolve = (value) => {
    this.updateResult(value, STATE.FULFILLED);
  }

  _reject = (error) => {
    this.updateResult(error, STATE.REJECTED);
  }

  updateResult(value, state) {
    // This is to make the processing async
    setTimeout(() => {
      /*
        Process the promise if it is still in a pending state. 
        An already rejected or resolved promise is not processed
      */
      if (this.state !== STATE.PENDING) {
        return;
      }

      // check is value is also a promise
      if (isThenable(value)) {
        return value.then(this._resolve, this._reject);
      }

      this.value = value;
      this.state = state;

      // execute handlers if already attached
      this.executeHandlers();
    }, 0);
  }

Wondering what is isThenable(value) in the above code?

Well for a case where a Promise is resolved/rejected with another promise, we have to wait for it to complete and then process our current Promise.

isThenable() function implementation

An isThenablefunction checks if value is an instance of MyPromise or it is an object containing a then function.

function isThenable(val) {
  return val instanceof MyPromise;
}

// or

function isThenable(value) {
  if (typeof value === "object" && value !== null && value.then && typeof value.then === "function") {
    return true;
  }
  return false;
}

3. then() method implementation

then() method takes two arguments as callbacks onSuccess and onFail. onSuccess is called if Promise was fulfilled and onFail is called if Promise was rejected.

“Remember that Promises can be chained”.
The essence of Promise chaining is that the then() method returns a new Promise object. That is how promises can be chained. This is especially useful in scenarios where we need to execute two or more asynchronous operations back to back, where each subsequent operation starts when the previous operation succeeds, with the result from the previous step.

Callbacks passed to then() are stored in handlers array using addHandlers function. A handler is an object {onSuccess, onFail} which will be executed when a promise is settled.

Our implementation of then() looks like this:

then(onSuccess, onFail) {
  return new MyPromise((res, rej) => {
      this.addHandlers({
        onSuccess: function(value) {
          // if no onSuccess provided, resolve the value for the next promise chain
          if (!onSuccess) {
            return res(value);
          }
          try {
            return res(onSuccess(value))
          } catch(err) {
            return rej(err);
          }
        },
        onFail: function(value) {
          // if no onFail provided, reject the value for the next promise chain
          if (!onFail) {
            return rej(value);
          }
          try {
            return res(onFail(value))
          } catch(err) {
            return rej(err);
          }
        }
      });
  });
}

addHandlers(handlers) {
  this.handlers.push(handlers);
  this.executeHandlers();
}

executeHandlers() {
  // Don't execute handlers if promise is not yet fulfilled or rejected
  if (this.state === STATE.PENDING) {
    return null;
  }

  // We have multiple handlers because add them for .finally block too
  this.handlers.forEach((handler) => {
    if (this.state === STATE.FULFILLED) {
      return handler.onSuccess(this.value);
    } 
    return handler.onFail(this.value);
  });
  // After processing all handlers, we reset it to empty.
  this.handlers = [];
}

4. catch() method implementation

catch() is implemented using then(). We call then() method with the onSuccess callback as null and pass onFail callback as second argument.


    /*
        Since then method take the second function as onFail, 
        we can leverage it while implementing catch
    */
    catch(onFail) {
      return this.then(null, onFail);
    }

5. finally() method implementation

Before we start implementing the finally() method, let us understand its behaviour first (Took me sometime to understand it myself).

From MDN docs:

The finally() method returns a Promise. When the promise is settled, i.e either fulfilled or rejected, the specified callback function is executed. This provides a way for code to be run whether the promise was fulfilled successfully or rejected once the Promise has been dealt with.

The finally() method is very similar to calling .then(onFinally, onFinally) however there are a couple of differences:

When creating a function inline, you can pass it once, instead of being forced to either declare it twice, or create a variable for it

Unlike Promise.resolve(2).then(() => {}, () => {}) (which will be resolved with undefined), Promise.resolve(2).finally(() => {}) will be resolved with 2.

Similarly, unlike Promise.reject(3).then(() => {}, () => {}) (which will be fulfilled with undefined), Promise.reject(3).finally(() => {}) will be rejected with 3.

finally() method returns a Promise which will be settled with previous fulfilled or rejected value.

    // Finally block returns a promise which fails or succeedes with the previous promise resove value
    finally(callback) {
      return new MyPromise((res, rej) => {
         let val;
         let wasRejected;
         this.then((value) => {
           wasRejected = false;
           val = value;
           return callback();
         }, (err) => {
           wasRejected = true;
           val = err;
           return callback();
         }).then(() => {
           // If the callback didn't have any error we resolve/reject the promise based on promise state
           if(!wasRejected) {
             return res(val);
           } 
           return rej(val);
         })
      })
    }

Check out the full code implementation in the codepen below:

Summary

We emulated the basic implementation of Promises. There is a lot more to it than then(), catch(), finally() methods which are the instance methods. There are static methods as well which I will try to cover in my future posts.

I hope you enjoyed the article.

Thank you for reading...

If you have any suggestions or questions, please feel free to comment or DM me on Twitter

Why don’t React state updates reflect immediately?

Shubham Khatri — Mon, 05 Jul 2021 16:58:47 +0000

When working with React a lot of people expect state changes to reflect immediately both in a class and functional component with React hooks.

This, however, is not the case.

State updates using this.setState or useState do not immediately mutate the state but create a pending state transition. Accessing state immediately after calling the updater method can potentially return the old value.

There is no guarantee of synchronous operation of state update calls and multiple state updates can be batched for performance reasons.

Why is State Update Async?

State updates alter the virtual DOM and cause re-rendering which may be an expensive operation. Making state updates synchronous could make the browser unresponsive due to huge number of updates.

To avoid these issues a careful choice was made to make state updates async, as well as to batch those updates.

Can I Wait for setState to be Completed Using async-await?

Now that we have established that setState is async, the next question that comes to mind is whether using async-await with setState work if we wish to access the updated state immediately after calling setState.

Before we jump to any conclusions, let’s first try it out in a code snippet:

import React, { useState } from "react";

function AppFunctional() {
  const [count, setCount] = useState(0);
  const handleClick = async () => {
    console.log("Functional:Count before update", count);
    await setCount(count + 1);
    console.log("Functional:Count post update", count);
  };
  return (
    <div className="container">
      <h1>Hello Functional Component!</h1>
      <p>Press button to see the magic :)</p>
      <button onClick={handleClick}>Increment</button>
      {!!count && (
        <div className="message">You pressed button {count} times</div>
      )}
    </div>
  );
}
class AppClassComp extends React.Component {
  state = {
    count: 0
  };
  handleClick = async () => {
    const { count } = this.state;
    console.log("Class:Count before update", count);
    await this.setState({ count: count + 1 });
    console.log("Class:Count post update", this.state.count);
  };
  render() {
    const { count } = this.state;
    return (
      <div className="container">
        <h1>Hello Class Component!</h1>
        <p>Press button to see the magic :)</p>
        <button onClick={this.handleClick}>Increment</button>
        {!!count && (
          <div className="message">You pressed button {count} times</div>
        )}
      </div>
    );
  }
}

export default function App() {
  return (
    <div className="wrapper">
      <AppFunctional />
      <AppClassComp />
    </div>
  );
}

Console output on incrementing count in functional and class component

As we can see in the console on running the above snippet, the updated state can be accessed immediately after calling setState in a Class component but for a functional component we still receive the old state, even after using async-await.

So, why do we have distinct behaviour in the above scenarios?

Well there are different answers for class and functional components. Let us try and understand the class component behaviour first.

With the current implementation of setState, the updater callback is queued ahead of the resolution of await, which basically does a Promise.resolvewith the returned value. So, it’s just a coincidence that it even works, even though setState doesn’t return a promise. Also, even though it works there’s no guarantee that a change in implementation of setState by React in future will retain the same behaviour.

Before getting to why async-await didn’t work with functional components, let’s first explore another solution.

Looking at setTimeout as a possible solution

We know that state updates are asynchronous, so they’re bound to complete at some time in the future. Now, we may think that adding a setTimeout with sufficient delay can help us get the updated value.

Again, let’s try this out before reaching any conclusions:

import React, { useState } from "react";

function AppFunctional() {
  const [count, setCount] = useState(0);
  const handleClick = () => {
    console.log("Functional:Count before update", count);
    setCount(count + 1);
    setTimeout(() => {
      console.log("Functional:Count post update in setTimeout", count);
    }, 1000);
  };
  console.log("Functional:Count in render", count);
  return (
    <div className="container">
      <h1>Hello Functional Component!</h1>
      <p>Press button to see the magic :)</p>
      <button onClick={handleClick}>Increment</button>
      {!!count && (
        <div className="message">You pressed button {count} times</div>
      )}
    </div>
  );
}
class AppClassComp extends React.Component {
  state = {
    count: 0
  };
  handleClick = () => {
    const { count } = this.state;
    console.log("Class:Count before update", count);
    this.setState({ count: count + 1 });
    setTimeout(() => {
      console.log("Class:Count post update in setTimeout", this.state.count);
    }, 1000);
  };
  render() {
    const { count } = this.state;
    return (
      <div className="container">
        <h1>Hello Class Component!</h1>
        <p>Press button to see the magic :)</p>
        <button onClick={this.handleClick}>Increment</button>
        {!!count && (
          <div className="message">You pressed button {count} times</div>
        )}
      </div>
    );
  }
}

export default function App() {
  return (
    <div className="wrapper">
      <AppFunctional />
      <AppClassComp />
    </div>
  );
}

Console output on incrementing count in functional and class component using setTimeout

We can see that for a class component the state inside setTimeout callback has the updated value but the functional component still doesn’t reflect the updated value.

However, there’s an interesting thing happening in functional component. The console.log(count) placed directly inside the component shows an updated value and even though the setTimeout callback runs after the console.log() in render, it still shows the old value.

This leads us to an the following conclusion.

While we think that state updates are asynchronous, we are only partially correct.

Understanding the Issue

It’s all about closures.

For a functional component, the state values are used within functions from their current closure and, while the state may have updated in the background, the current closures cannot reference the updated values. The updated values are reflected in the next render cycle and new closures are created for those while the current once remain unaffected.

Hence, even if you wait for a long time inside setTimeout, the updated values won’t be available inside its callback and the same reason applies to why async-await also doesn’t work for state updaters in functional components.

What Do We Do If We Want to Access the Updated Value After Calling Setstate?

The solution to this differs for both Class and Functional components.

For class components

Even though both async-await and setTimeout work, the correct way to access an updated state after calling setState is one of the following.

Access the state directly in render if you just want to log or check the updated value.
Use setState callback. `setState takes a callback as the second argument which is invoked when the state update has completed. Use this to either log or call a function with the updated state. setState(() => {}, callback)`
Use componentDidUpdate. A side-effect (an action) can also be performed in componentDidUpdate after comparing the current and the previous state.

For functional components

Functional components rely heavily on closures and to access updated values we have to break through those closures. Some of the recommended ways to access updated state are:

Access state directly inside the functional component. When the next render cycle is invoked, the updated value will be logged. This is useful if you only wish to log or check the updated state
Make use of useEffect hook. You can add your state as a dependency to useEffect and access the updated state to log or perform side-effect with the updated state values.
Use Mutation refs. This solution involves keeping a clone of state value in ref and regularly updating it. Since refs are mutated, they aren’t affected by closures and can hold updated values. This is although not directly related to accessing state after updating it but can be really useful when you want to access the updated state in an event listener or subscription callback which is only created on initial render

Check out the code snippet to understand more about the provided solution:

import React, { useState } from "react";
import "./style.scss";

export default class App extends React.Component {
  state = {
    count: 0
  };
  handleClick = () => {
    const { count } = this.state;
    console.log("Count before update", count);
    this.setState({ count: count + 1 }, () => {
      console.log("Count state in setState callback", this.state.count);
      // call an action with updated state here
    });
  };
  componentDidUpdate(_, prevState) {
    if (prevState.count !== this.state.count) {
      console.log("Count state in componentDidUpdate", this.state.count);
      // call any side-effect here
    }
  }
  render() {
    const { count } = this.state;
    console.log("Count state in render", count);
    return (
      <div className="container">
        <h1>Hello Class Component!</h1>
        <p>Press button to see the magic :)</p>
        <button onClick={this.handleClick}>Increment</button>
        {!!count && (
          <div className="message">You pressed button {count} times</div>
        )}
      </div>
    );
  }
}

That’s all that we need to know whenever we come across a case where the updated state is not available immediately after updating it.

Key Takeaways

State updates in React are asynchronous because rendering is an expensive operation and making state updates synchronous may cause the browser to become unresponsive.
this.setState provides a callback which is called when state has been updated and can be leveraged to access updated state values.
State updates in functional components are affected by closures and you only receive the updated value in the next render cycle.
For a functional component with react hooks, you can make use of useEffect or mutationRefs to access updated values.
If possible, try to pass the value used to update state directly as arguments to functions that are being called immediately after updating state.

Thank you for Reading

If you have any doubts or suggestions regarding this article, feel free to comment or DM me on Twitter

Lazy Loading Images in React

Shubham Khatri — Mon, 28 Jun 2021 16:31:02 +0000

Lazy loading is a common performance optimization technique followed by almost all asset-heavy websites. We often come across web pages where a blurred version of the image loads up and is then followed up with a high-resolution image. Although the total time taken to load up the content is long, it has a perceivable effect on user experience.

This entire interaction is a three-step process:

Wait for the content to come into the view before even starting to load the image.
Once the image is in view, a lightweight thumbnail is loaded with a blur effect and the resource fetch request for the original image is made.
Once the original image is fully loaded, the thumbnail is hidden and the original image is shown.

If you have ever used Gatsby, then you would have come across a GatsbyImage component that does the same for you. In this article, we will implement a similar custom component in React that progressively loads images as they come into the view using IntersectionObserver browser API.

Although Gatsby Image does a lot more than blur and load images, we will just focus on this part:

Let’s Build It.

The first step to building the entire thing is to create a layout of your image components.

This part is pretty straightforward. For the purpose of the article, we will dynamically iterate over a set of images and render an ImageRenderer component.

import React from 'react';
import imageData from './imageData';
import ImageRenderer from './ImageRenderer';
import './style.css';

export default function App() {
  return (
    <div>
      <h1>Lazy Load Images</h1>
      <section>
        {imageData.map(data => (
          <ImageRenderer
            key={data.id}
            url={data.url}
            thumb={data.thumbnail}
            width={data.width}
            height={data.height}
          />
        ))}
      </section>
    </div>
  );
}

The next step is to render placeholders for our images inside the ImageRenderer component.

When we render our images with a specified width, they adjust their height according to the aspect ratio, i.e., ratio of width to height of the original image.

Since we are already passing the width and height of the original image as props to the ImageRenderer component, we can easily calculate the aspect ratio and use this to calculate the height of our placeholder for the image. This is done so that when our image finally loads up, our placeholders do not update their height again.

The height of the placeholder is set by using the padding-bottom CSS property in percentages.

The size of the padding when specified in percentage is calculated as a percentage of the width of the element. Here’s the code:

import React from 'react';
import './imageRenderer.scss';

const ImageRenderer = ({ width, height }) => {
  return (
    <div
      className="image-container"
      ref={imgRef}
      style={{
        paddingBottom: `${(height / width) * 100}%`,
        width: '100%'
      }}
    />
  );
};

export default ImageRenderer;

.image-container {
  background-color: #ccc;
  overflow: hidden;
  position: relative;
  max-width: 800px;
  margin: 20px auto;
}

Until this point, our application looks like this:

Using Intersection Observer To Detect Visibility

What we need to know now is when our container for the image comes into view. Intersection Observer is the perfect tool for this task.

“The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport.

The Intersection Observer API allows you to configure a callback that is called when either of these circumstances occur:

A target element intersects either the device’s viewport or a specified element. That specified element is called the root element or root for the purposes of the Intersection Observer API.

The first time the observer is initially asked to watch a target element.”

We shall use a single global IntersectionObserver instance to observe all of our images. We will also keep a listener callback map, which will be added by the individual image component and will execute when the image comes into the viewport.

To maintain a Map of target-to-listener callbacks, we will use the WeakMap API from Javascript.

“The WeakMap object is a collection of key/value pairs in which the keys are weakly referenced. The keys must be objects and the values can be arbitrary values.”

We write a custom hook that gets the IntersectionObserver instance, adds the target element as an observer to it and also adds a listener callback to the map.

import { useEffect } from 'react';

let listenerCallbacks = new WeakMap();

let observer;

function handleIntersections(entries) {
  entries.forEach(entry => {
    if (listenerCallbacks.has(entry.target)) {
      let cb = listenerCallbacks.get(entry.target);

      if (entry.isIntersecting || entry.intersectionRatio > 0) {
        observer.unobserve(entry.target);
        listenerCallbacks.delete(entry.target);
        cb();
      }
    }
  });
}

function getIntersectionObserver() {
  if (observer === undefined) {
    observer = new IntersectionObserver(handleIntersections, {
      rootMargin: '100px',
      threshold: '0.15',
    });
  }
  return observer;
}

export function useIntersection(elem, callback) {
  useEffect(() => {
    let target = elem.current;
    let observer = getIntersectionObserver();
    listenerCallbacks.set(target, callback);
    observer.observe(target);

    return () => {
      listenerCallbacks.delete(target);
      observer.unobserve(target);
    };
  }, []);
}

If we do not specify any root element to IntersectionObserver, the default target is considered to be the document viewport.

Our IntersectionObserver callback gets the listener callback from the map and executes it if the target element intersects with the viewport. It then removes the observer since we only need to load the image once.

Using the Intersectionobserver for ImageRenderer Component

Inside our ImageRenderer component, we use our custom hook useIntersection and pass on the ref of the image container and a callback function which will set the visibility state for our image. Here’s the code:

import React, { useState, useRef } from 'react';
import classnames from 'classnames';
import { useIntersection } from './intersectionObserver';
import './imageRenderer.scss';

const ImageRenderer = ({ url, thumb, width, height }) => {
  const [isInView, setIsInView] = useState(false);
  const imgRef = useRef();
  useIntersection(imgRef, () => {
    setIsInView(true);
  });

  return (
    <div
      className="image-container"
      ref={imgRef}
      style={{
        paddingBottom: `${(height / width) * 100}%`,
        width: '100%'
      }}
    >
      {isInView && (

          <img
            className='image'
            src={url}
          />

      )}
    </div>
  );
};

export default ImageRenderer;

.image-container {
  background-color: #ccc;
  overflow: hidden;
  position: relative;
  max-width: 800px;
  margin: 20px auto;
  .image {
    position: absolute;
    width: 100%;
    height: 100%;
    opacity: 1;
  }
}

Once we have done this, our application looks like the example below:

The network request looks as follows as we scroll our page:

As you can see, our IntersectionObserver works, and our images are only loaded as they come into view. Also, what we see is that there is a slight delay as the entire image gets loaded.

Now that we have our Lazy load feature, we will move on to the last part.

Adding the Blur Effect

Adding the blur effect is achieved by trying to load a low-quality thumbnail in addition to the actual image and adding a filter: blur(10px) property to it. When the high-quality image is completely loaded, we hide the thumbnail and show the actual image. The code is below:

import React, { useState, useRef } from 'react';
import classnames from 'classnames';
import { useIntersection } from './intersectionObserver';
import './imageRenderer.scss';

const ImageRenderer = ({ url, thumb, width, height }) => {
  const [isLoaded, setIsLoaded] = useState(false);
  const [isInView, setIsInView] = useState(false);
  const imgRef = useRef();
  useIntersection(imgRef, () => {
    setIsInView(true);
  });

  const handleOnLoad = () => {
    setIsLoaded(true);
  };
  return (
    <div
      className="image-container"
      ref={imgRef}
      style={{
        paddingBottom: `${(height / width) * 100}%`,
        width: '100%'
      }}
    >
      {isInView && (
        <>
          <img
            className={classnames('image', 'thumb', {
              ['isLoaded']: !!isLoaded
            })}
            src={thumb}
          />
          <img
            className={classnames('image', {
              ['isLoaded']: !!isLoaded
            })}
            src={url}
            onLoad={handleOnLoad}
          />
        </>
      )}
    </div>
  );
};

export default ImageRenderer;

.image-container {
  background-color: #ccc;
  overflow: hidden;
  position: relative;
  max-width: 800px;
  margin: 20px auto;
}
.image {
  position: absolute;
  width: 100%;
  height: 100%;
  opacity: 0;

  &.thumb {
    opacity: 1;
    filter: blur(10px);
    transition: opacity 1s ease-in-out;
    position: absolute;
    &.isLoaded {
      opacity: 0;
    }
  }

  &.isLoaded {
    transition: opacity 1s ease-in-out;
    opacity: 1;
  }
}

The img element in HTML has a onLoad attribute which takes a callback that is fired when the image has loaded. We make use of this attribute to set the isLoaded state for the component and hide the thumbnail while showing the actual image using the opacity CSS property.

You can find the StackBlitz demo for this article here:

Conclusion

So there we have it: our custom ImageRenderer component that loads up images when they come into view and shows a blur effect to give a better user experience.

I hope you enjoyed the article. You can find the full code on my GitHub repository here.

Thank you for reading!

If you like this article, consider sharing it with your friends and colleagues

Also, if you have any suggestion or doubts regarding the article, feel free to comment or DM me on Twitter

Build a Card Memory Game with React

Shubham Khatri — Mon, 21 Jun 2021 06:58:41 +0000

Very often we come across small games and wonder how complex is it? Can we build it? More often than not we do not go beyond it. In this post however we will build a simple memory game which is easy to play and also easy to develop.

The card memory game is a simple game to test the player’s memory. In a deck of paired cards, the player needs to select a matching pair in consecutive turns. The player wins the game when all matching pairs are selected.

A simple UI of it may look like this:

Let us define the Rules of the Game

We can’t make a game unless we know the rules. So lets state them here:

We need a shuffled set of cards. There must be a pair of each card in our deck.
The game must flip the cards clicked by the player. Maximum of two cards will show at a time.
The game will handle matched and unmatched cards. Unmatched cards are flipped back after a short duration. Matched cards are removed from the deck.
Every time a player selects a pair, the game will increment the current move count
Once all pairs are found out, players sees a confirmation dialog with the score.
Game provides a functionality to restart.

So what are we waiting for... Lets get into it.

We first define our card structure. For a card we create an object with the type attribute and an image source.

{
   type: 'Pickachu',
   image: require('../images/Pickachu.png')
}

Now the next step is to shuffle the deck of cards. Ahh yes, this is the most important step. It is not really a memory game if we don’t shuffle

1. Shuffle

I will use Fisher-Yates shuffle algorithm for shuffling an array of cards.

// Fisher Yates Shuffle
function swap(array, i, j) {
   const temp = array[i];
   array[i] = array[j];
   array[j] = temp;
}
function shuffleCards(array) {
   const length = array.length;
   for (let i = length; i > 0; i--) {
      const randomIndex = Math.floor(Math.random() * i);
      const currentIndex = i - 1;
      swap(array, currIndex, randomIndex)
   }
   return array;
}

2. Render board for the deck of cards

In this example we are using 12 cards(6 pairs). After shuffling our cards, we render them as a grid of 3x4. You can either choose to split your card deck into 3 arrays of 4 items each and render using a nested map or use CSS flexbox or grid. I will be using CSS Grid to render it since it is easier to handle updates with a one dimension array.


export default function App({ uniqueCardsArray }) {
  const [cards, setCards] = useState(
    () => shuffleCards(uniqueCardsArray.concat(uniqueCardsArray))
  );

  const handleCardClick = (index) => {
    // We will handle it later
  };


  return (
    <div className="App">
      <header>
        <h3>Play the Flip card game</h3>
        <div>
          Select two cards with same content consequtively to make them vanish
        </div>
      </header>
      <div className="container">
        {cards.map((card, index) => {
          return (
            <Card
              key={index}
              card={card}
              index={index}
              onClick={handleCardClick}
            />
          );
        })}
      </div>
   </div>
  )
}

  .container {
    display: grid;
    grid-template-columns: repeat(4, 1fr);
    grid-template-rows: repeat(3, 1fr);
    justify-items: center;
    align-items: stretch;
    gap: 1rem;
  }

3. Flip Cards, evaluate match and count moves

The next step is to provide an interaction for the user to flip cards and evaluate if there is a match. For it we maintain the following states

openCards to track the cards that have been flipped by the player
clearedCards to track the cards that have matched and need to be removed from the deck
moves to keep track of the moves made by the player.

import { useEffect, useState, useRef } from "react";
import Card from "./card";
import uniqueElementsArray from './data';
import "./app.scss";

export default function App() {
  const [cards, setCards] = useState(
    () => shuffleCards(uniqueCardsArray.concat(uniqueCardsArray))
  );
  const [openCards, setOpenCards] = useState([]);
  const [clearedCards, setClearedCards] = useState({});
  const [moves, setMoves] = useState(0);
  const [showModal, setShowModal] = useState(false);
  const timeout = useRef(null);

  // Check if both the cards have same type. If they do, mark them inactive
  const evaluate = () => {
    const [first, second] = openCards;
    if (cards[first].type === cards[second].type) {
      setClearedCards((prev) => ({ ...prev, [cards[first].type]: true }));
      setOpenCards([]);
      return;
    }
    // Flip cards after a 500ms duration
    timeout.current = setTimeout(() => {
      setOpenCards([]);
    }, 500);
  };

  const handleCardClick = (index) => {
    // Have a maximum of 2 items in array at once.
    if (openCards.length === 1) {
      setOpenCards((prev) => [...prev, index]);
      // increase the moves once we opened a pair
      setMoves((moves) => moves + 1);
    } else {
      // If two cards are already open, we cancel timeout set for flipping cards back
      clearTimeout(timeout.current);
      setOpenCards([index]);
    }
  };

  useEffect(() => {
    if (openCards.length === 2) {
      setTimeout(evaluate, 500);
    }
  }, [openCards]);

  const checkIsFlipped = (index) => {
    return openCards.includes(index);
  };

  const checkIsInactive = (card) => {
    return Boolean(clearedCards[card.type]);
  };

  return (
    <div className="App">
      <header>
        <h3>Play the Flip card game</h3>
        <div>
          Select two cards with same content consequtively to make them vanish
        </div>
      </header>
      <div className="container">
        {cards.map((card, index) => {
          return (
            <Card
              key={index}
              card={card}
              index={index}
              isDisabled={shouldDisableAllCards}
              isInactive={checkIsInactive(card)}
              isFlipped={checkIsFlipped(index)}
              onClick={handleCardClick}
            />
          );
        })}
      </div>
    </div>
  );
}

At a time we shall only keep a maximum of two cards in openCards state. Since we have a static array and we aren’t actually deleting anything from our original cards array we can just store the index of the opened card in openCards state. Based on openCards and clearedCards state we pass a prop isFlipped or isInactive respectively to our Card component which it will then use to add the respective class.

Do look at this wonderful blog which explains how to handle Flip Card Animation.
Note: Since we add an animation to our cards for flipping, we evaluate a match after few seconds to allow for the flip transition.

4. Check for game completion

Every time we evaluate for a match, we check if all pairs have been found. If yes, we show the player a completion modal.

  const checkCompletion = () => {
    // We are storing clearedCards as an object since its more efficient 
    //to search in an object instead of an array
    if (Object.keys(clearedCards).length === uniqueCardsArray.length) {
      setShowModal(true);
    }
  };

5. And finally, our restart functionality

Well restarting is simple, we just reset our states and reshuffle our cards.

<Button onClick={handleRestart} color="primary" variant="contained">
    Restart
</Button>

  const handleRestart = () => {
    setClearedCards({});
    setOpenCards([]);
    setShowModal(false);
    setMoves(0);
    // set a shuffled deck of cards
    setCards(shuffleCards(uniqueCardsArray.concat(uniqueCardsArray)));
  };

Hurray! There we have our basic memory card game.

You can find the CodeSandbox Playground for the demo below

Conclusion

I am so glad we’ve reached this point. We created a shuffled deck, rendered it on a board, added a flip functionality and evaluated for a matching pair. We can extend this example to add a timer, add best score of the player and support level for higher numbers of cards as well.

You can check this Github repository for the full code.

If you liked this post do share it with your friends and if you have any suggestions or feedbacks feel free to add comments or DM me on Twitter.

Thank you for Reading

DEV Community: Shubham Khatri

15 Useful VSCode shortcuts to improve your coding speed

1. CMD + P: Opens the palette to search for a file

2. CMD + SHIFT + L: Add cursors to all matching selections

3. CMD + D: Add cursor to next matching selection

4. CMD + U: Undo last cursor operation

5. CMD + L: Select current line.

6. CTRL + G: Go to a specific line

7. CMD + K + W: Close all open editor tabs

8. SHIFT + OPTION + A : Toggle block comment

9. CMD + OPTION + [ : Fold code block

10. OPTION + UP/DOWN : Move line up or down

11. CTRL + ` : Open integrated terminal

12. CMD + \ : Split editor view

13. SHIFT + OPTION + F : Format document

14. OPTION + SHIFT + UP / DOWN : Duplicate selection up or down

15. CMD + B: Toggle Sidebar

Cherry on the cake

Summary

Observer Design Pattern in JavaScript

What Is the Observer Design Pattern?

Implementation of the Observer Pattern

Step 1. Implement a MousePositionObservable class

Step 2. Create HTML elements

Step 3. Add observers

Advantages and Disadvantages of the Observer Design Pattern

Real-World Applications

Conclusion

What is StrictMode in React

What Is React.StrictMode and How Can We Use It?

1. Identifying Legacy String refs

2. Detecting deprecated findDOMNode method

3. Legacy Context API

4. Detecting unsafe lifecycle methods

Calling setState in componentWillMount

Async request in componentWillMount

Adding subscriptions or listeners in componentWillMount

Updating state or calling side effects on prop change

Reading DOM properties before an update

5. Detecting unexpected side effects

Key Takeaways

Thank you for reading.

How to debounce and throttle functions with React hooks

What Is debounce?

What Is throttle?

Using debounce and throttle With Class Components

Using debounce and throttle in Functional Components

Refining Our Implementation Based on Our Learning

Further Optimizing the Approach

Summary

How to implement a Collapsible Overflow Menu in React

Why Intersection Observer?

Let’s start!

Hold on. Its not finished yet…

Conclusion

Implement your own Promises in JavaScript

What is a Promise?

How do you use a Promise?

1. Defining the skeleton

Following properties are defined in the constructor:

2. _resolve() and _reject() method implementation

isThenable() function implementation

3. then() method implementation

4. catch() method implementation

5. finally() method implementation

Summary

Why don’t React state updates reflect immediately?

Why is State Update Async?

Can I Wait for setState to be Completed Using async-await?

Looking at setTimeout as a possible solution

Understanding the Issue

What Do We Do If We Want to Access the Updated Value After Calling Setstate?

For class components

For functional components

Key Takeaways

Thank you for Reading

Lazy Loading Images in React

Let’s Build It.

Using Intersection Observer To Detect Visibility

Using the Intersectionobserver for ImageRenderer Component

2. Detecting deprecated `findDOMNode` method