DEV Community: Siddharth Singh Bhadauriya

Polling Requests to an API in JavaScript

Siddharth Singh Bhadauriya — Mon, 17 Jun 2024 20:26:19 +0000

Polling is a technique that repeatedly requests data from a server at regular intervals until a desired response is received or a timeout period elapses. In this article, we will explore how to implement a polling request method in JavaScript to repeatedly hit an API every 5 seconds for up to 300 seconds (5 minutes) or until a successful response is received.

Understanding Polling

Polling involves sending periodic requests to an API to check for an update or a specific response. This can be particularly useful in scenarios where you need to wait for a process to complete on the server and then perform actions based on the result.

Polling Logic

Here is a step-by-step breakdown of the polling logic we will implement:

Define the API endpoint and desired success response.
Set the polling interval (5 seconds) and maximum polling duration (300 seconds).
Use a loop or a recursive function to repeatedly send requests to the API at the specified interval.
Check the API response after each request.
Stop polling if a successful response is received or the maximum polling duration is reached.

Implementing Polling in JavaScript

Let's implement this logic in JavaScript:

Step 1: Define the API Endpoint and Success Response

const apiEndpoint = 'https://example.com/api/endpoint'; // Replace with your API endpoint
const successResponse = 'success'; // Define what constitutes a success response

Step 2: Set Polling Interval and Maximum Duration

const pollingInterval = 5000; // 5 seconds in milliseconds
const maxPollingDuration = 300000; // 300 seconds (5 minutes) in milliseconds

Step 3: Implement the Polling Function

We will create a function pollApi that handles the polling logic. This function will use setTimeout to schedule the next API request if necessary.

async function pollApi(apiEndpoint, successResponse, pollingInterval, maxPollingDuration) {
    const startTime = Date.now(); // Record the start time

    const makeRequest = async () => {
        try {
            const response = await fetch(apiEndpoint); // Make request
            const data = await response.json();

            if (data.status === successResponse) {
                console.log('Success response received:', data);
                return; // // Stop polling if success response
            }

            const elapsedTime = Date.now() - startTime;

            if (elapsedTime < maxPollingDuration) {
                setTimeout(makeRequest, pollingInterval); // Schedule next request
            } else {
                console.log('Maximum polling duration reached. Stopping polling.');
            }
        } catch (error) {
            console.error('Error making API request:', error);
            const elapsedTime = Date.now() - startTime;

            if (elapsedTime < maxPollingDuration) {
                setTimeout(makeRequest, pollingInterval); // Schedule next request
            } else {
                console.log('Maximum polling duration reached. Stopping polling.');
            }
        }
    };

    makeRequest(); // Start the first request
}

Step 4: Start Polling

Call the pollApi function to start polling the API.

pollApi(apiEndpoint, successResponse, pollingInterval, maxPollingDuration);

and voila-it works.

Recursive Approach over Loop

A recursive function is used in the provided solution rather than a loop. The function makeRequest calls itself using setTimeout to create the delay between API requests. This approach leverages JavaScript's asynchronous capabilities to avoid blocking the main thread while waiting for the next request to be made.

The recursive aspect comes from the makeRequest function calling itself via setTimeout, allowing it to schedule future executions without blocking the main thread. This approach ensures that the next request is only made after the specified interval, maintaining the polling cadence.

This recursive approach is effective for polling in JavaScript, ensuring that the application remains responsive while waiting for the desired API response or the maximum polling duration to be reached.

Conclusion

In this article, we demonstrated how to implement a polling request method in JavaScript to repeatedly hit an API at 5-second intervals for up to 300 seconds or until a successful response is received. Polling can be an effective way to wait for asynchronous processes on the server and react to their outcomes in real time. With this approach, you can ensure your application remains responsive and capable of handling real-world scenarios that require periodic data checks like payment status, ETA status, etc.

Beginners guide to React.js Batched Updates

Siddharth Singh Bhadauriya — Sat, 12 Feb 2022 18:04:13 +0000

Overview

A couple of months back when I was learning React and going into deep internet holes to understand every major-minor concept regarding the Why's & How's of them, I stumbled upon React Batched Updates.
I learned how this feature of React acts differently for calling the setState functions synchronously and asynchronously.

To get better understanding consider this example.
It's a simple example to interact with and understand the broader aspect of the difference in the behavior of Batching, or what it used to be recently.

Now with the onset of React 18, it improves efficiency right out of the box by handling more batching by default, eliminating the need to batch updates manually in application. This post will describe batching, how it used to function, and what has changed.

Some definitions first

Batching

Batching is when React groups multiple state updates into a single re-render for better performance.

Why Such a thing ?? Elaborating a bit..

SetState() can be used to update the states of class components, and hooks (i.e. useState()) can be used to update the states of function components. Parts of the component tree are re-rendered as a result of these changes. A simple solution would be to re-render the component after each use to setState(), however this would be inefficient when numerous calls to setState() are made within a React event handler or synchronous lifecycle method.

React implements a batched updating mechanism to reduce the number of component renders. Consequently, multiple state changes will be batched into a single update, which will eventually trigger one re-render of a component.

Again check this example for better clarity and understanding.

In just Recent-Past..

When React batches updates are done in known ways like lifecycle methods or event handlers, React batches them, but not when they are made in callbacks like SetTimeout or Promises. This means that if you make several calls to update the state, React will re-render the component after each call.

After using useState or this.setState to update your component's state, elements of the component re-render depending on the update. More importantly, if you have many calls to update the state within a React event handler like onClick, React does the updates in a batch rather than one at a time, minimizing the number of renderings the component performs.

Example

If two state updates occur inside the same click event, React will always combine them into a single re-render. If you execute the following code, you'll notice that React only renders once for each click, despite the fact that the state is set twice:


function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    setCount(c => c + 1); // Does not re-render yet
    setFlag(f => !f); // Does not re-render yet
    // React will only re-render once at the end (that's batching!)
  }

  return (
    <div>
      <button onClick={handleClick}>Click on me !!</button>
      <h1 style={{ color: flag ? "yellow" : "purple" }}>{count}</h1>
    </div>
  );
}

This is beneficial to performance because it reduces the number of unwanted re-renders. It also prevents your component from presenting "half-finished" states in which only one state variable has been changed, which could lead to issues and bugs.

Setback: However, React wasn’t consistent about when it batches updates. For example, if you need to fetch data, and then update the state in the handleClick above, then React would not batch the updates, and perform two independent updates.

We only batched updates during the React event handlers, until React 18. By default, React did not batch updates inside of promises, setTimeout, native event handlers, or any other event.

Present-Coming Days Batching Behavior..

Starting in React 18 mostly, all updates will be automatically batched, no matter where they originate from.

Automatic Batching: This means that updates in timeouts, promises, native event handlers, and any other event will batch in the same manner that updates in React events do. Anticipate that this will result in less work being rendered and, as a result, better performance in your apps.

Example

function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}

behaves the same as this:

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}, 1000);

behaves the same as this too:

fetch(/*...*/).then(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
})

and also behaves the same as this:

element.addEventListener('click', () => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
});

I hope this helps. It helped me. A programmer just like you. 🌟

Crashing gracefully while error handling using Error Boundaries.

Siddharth Singh Bhadauriya — Sat, 12 Feb 2022 17:48:47 +0000

Problem at Hand

Suppose a JavaScript error occurs within a component, it might cause React's internal state to be corrupted, resulting in cryptic errors. I ran into the same situation, just like you and many others too.
During the development of our apps, we will invariably run into unforeseen errors. It's possible that you're attempting to access a deeply nested property on an object that doesn't exist, or that it's out of your control (like a failed HTTP request to a third-party API).
Errors are bound to happen in our applications. When an issue occurs in the app, the component unmounts altogether, leaving the user with a blank HTML page. Users may become perplexed and unsure of what to do next as a result of this.

The Solution

As a result, a number of techniques have been created to prevent these problems from interfering with the user and developer experience. The use of error boundaries is one such way in React.
Error Boundaries give an elegant method to deal with these problems!

What exactly are Error Boundaries? It's not a new component or JavaScript library, contrary to popular belief. It’s more like a strategy for handling errors in React components.

Installation
Explanation
Usage
Comparison with TryCatch
Limitations

Installation

Installed as one of your project's dependencies:

npm install --save react-error-boundary

Explanation

Reason to Use:
Error boundaries are React components which catch JavaScript errors anywhere in our app, log those errors, and display a fallback UI. It does not break the whole app component tree and only renders the fallback UI whenever an error occurred in a component.
We can use Error Boundaries to give the user visual notification that something went wrong while still allowing them to engage with our programme.
So now they have the option of navigating away or contacting customer service for assistance in resolving their issue! It's a terrific technique to make up for an otherwise bad user experience.

Working Principle
Error boundaries catch errors during rendering in component lifecycle methods, and constructors of the whole tree below them. So basically, error boundaries only handle errors in the parts of our code that involve React.
Suppose an error is encountered then what happens is as soon as there is a broken JavaScript part in Rendering or Lifecycle Methods, It tries to find the nearest Error Boundaries Tag and sort the error out with a Fallback-UI.

Usage

The simplest way to use <ErrorBoundary> is to wrap it around any component that may throw an error. This will handle errors thrown by that component andits descendants too.

import {ErrorBoundary} from 'react-error-boundary'

function ErrorFallback({error, resetErrorBoundary}) {
  return (
    <div role="alert">
      <p>Something went wrong:</p>
      <pre>{error.message}</pre>
      <button onClick={resetErrorBoundary}>Try again</button>
    </div>
  )
}

const ui = (
  <ErrorBoundary
    FallbackComponent={ErrorFallback}
    onReset={() => {
      // reset the state of your app so the error doesn't happen again
      //eg. reload the page using window.location.reload()
    }}
  >
    <ComponentThatMayError />
  </ErrorBoundary>
)

You can react to errors (e.g. for logging) by providing an onError callback:

import {ErrorBoundary} from 'react-error-boundary'

const myErrorHandler = (error: Error, info: {componentStack: string}) => {
  // Do something with the error
  // E.g. log to an error logging client here
}

const ui = (
  <ErrorBoundary FallbackComponent={ErrorFallback} onError={myErrorHandler}>
    <ComponentThatMayError />
  </ErrorBoundary>,
)

Comparison with TryCatch

One question that may cross your mind is why should you learn this new concept when Error Boundaries works like Catch? Well, the answer is Try…catch is used in specific code blocks where you program the functionality of the application.

Try…Catch deals with imperative code while Error Boundaries deal with declarative code and as we know that React is declarative in nature, and Error Boundaries help in preserving the declarative nature of React.

Imperative programming is how you do something and declarative programming is what you do.

With error boundary, if there is an error, you can trigger a fallback UI; whereas, with try…catch, you can catch errors in your code and throw/re-throw/handle the error and further display it using a modal bla bla...

Error Boundaries actually aren’t in direct competition with try...catch statements as Error Boundaries are only designed for intercepting errors that originate from 3 places in a React component: During render phase, In a lifecycle method, In the constructor (Reacty Stuffs).

Limitations

There are certain limitations to Error Boundaries too.
Following are the places where Error Boundaries will not be able to catch an error:

Event handlers (e.g., onClick, onChange, etc.).
Asynchronous code(Example request Animation Frame, setTimeout)
Server-side rendering (SSR)
And errors caused by the error boundary itself (rather than its children)

So Error Boundaries don’t really impact how you use try...catch. They’re both needed as a robust strategy for handling errors in React.

I recently came across this concept and was not able to stop myself falling in love with such component-based-js-errors-catching.
I hope this helps

Combining two independent git repositories

Siddharth Singh Bhadauriya — Thu, 10 Feb 2022 22:31:16 +0000

Overview

You might be pondering why anyone would wish to combine two different git repositories into a single repository. Couple of weeks back, I came across a problem. I was working on a React JS project and for the frontend styling, I went for Material-UI.
60% of the project was done and then somehow ran into some styling and responsive issue in my project. Now I was ready to go for Chakra-UI in the same repo itself, but then again it would have messed up my central theme object, ending up only with bunch of cross frameworks error and lots of styling conflicts.
I had a few solutions on my hand, went for creating a new repository but this time the framework was Chakra-UI, so with number of logic and styling changes, I had the desired output.
I was about to rewrite/copy/paste the new code that I had written (in a new git repo) into my first original project repository, when it occurred to me that I could probably merge the two independent repositories on my machine to avoid whole editing fiasco.

Generalization

You have repository A with remote location remoteA, and repository B (which may or may not have remote location remoteB). You want to do one of two things:

Keep both repositories' commits, but replace the contents of A with the contents of B, and use remoteA as your remote location.
Use remoteA as the remote location to join the two repositories as though they were two branches that you wanted to merge.

Use Case: This may also be useful if you're working on project components in one git while working on template files in another git, and then wish to integrate the two.

Things to consider now:
Make sure your local and remote repositories are up to date with all the modifications you'll require before you begin. To unite the two master branches, the following procedures apply the general idea of altering the remote origin and renaming the local master branch of one of the repos.

Check out `git subtree`/`git submodule`. 
Before going through the steps below. 
This post is just a walkthrough of how 
I reached the solution of the stated problem.

Go on this Road

Change the remote origin of B to that of A:

$ cd someDirectory/somePath/leading/to/B
$ git remote rm origin
$ git remote add origin <url_to_remoteA>

Rename the local master branch of B:

$ git checkout master
$ git branch -m master-new-stay

Pull all the code of A from remoteA into your local B repo.

$ git fetch
$ git checkout master
$ git pull origin master

The master branch of A is now the master branch of B. master-new-stay is the old master branch of B.

Now delete all the things that you pulled from remoteA.

$ git rm -rf *
$ git commit -m "Delete all the things."

Now, merge master-new-stay into master and alongside add the --allow-unrelated-histories flag too.

git merge master-new-stay --allow-unrelated-histories

git log should show all the commits from A, the delete commit, the merge commit, and finally all the commits from B.

Push everything to remoteA

git push origin master

Voila

Your local copy of B has now become a consolidate repository, containing all of A and B's commits. The remote repository is remoteA. You don't need your local copy of A or the remote repository remoteB any longer.

I hope this has been helpful.

DEV Community: Siddharth Singh Bhadauriya

Polling Requests to an API in JavaScript

Understanding Polling

Polling Logic

Implementing Polling in JavaScript

Recursive Approach over Loop

Conclusion

Beginners guide to React.js Batched Updates

Overview

Batching

Why Such a thing ?? Elaborating a bit..

In just Recent-Past..

Example

Present-Coming Days Batching Behavior..

Example

Crashing gracefully while error handling using Error Boundaries.

Problem at Hand

The Solution

Table of Contents

Installation

Explanation

Usage

Comparison with TryCatch

Limitations

Combining two independent git repositories

Overview

Generalization

Go on this Road

Voila