DEV Community: Idris Gadi

10X Developer and the POC Trap

Idris Gadi — Thu, 04 Dec 2025 15:48:07 +0000

A tale of POCs, tech debt, and working with rockstars who moved too fast

Meeting the 10X Dev

In my web development career, I've so far worked with three quote and quote "10X" (or "cracked") developers across three different projects.

They are amazing at work, complete more tickets per sprint than the rest of the team combined, work 12+ hours a day, skip weekends, rarely take any leave, and most importantly, they can get you a POC in less than a week or two (a bond they might be cursed with forever).

POC Hero

A 10X developer’s relationship with POCs often begins with an ambitious feature request.

The lead proposes that we first make a POC, do some feasibility analysis, and run user acceptance tests. "But we don't have much time", says the product manager. They look at the 10X developer and ask, "We can do this in two weeks, right?".

The 10X developer grinds for two weeks and delivers a prototype that's “good enough.” It goes into testing and passes with flying colours. The prototype is merged into the main project. Success.

A new feature request comes in. The POC is assigned to the 10X developer. This time, the prototype didn't pass testing, and the feature is marked not feasible, saving us months of development time. Success again.

Over time (sprint after sprint), the 10X developer gets assigned more and more POC work. Eventually, they stop doing any bug fixing, enhancements, upgrades, or maintenance. All they do now is create POCs.

Every big and small feature now needs a POC, and who handles that? Correct: the 10X developer.

From Hero to Bottleneck

As more and more POC work gets assigned, they get less and less time to actually work on it.

The prototype quality drops from good enough to barely functional, and they start writing clever but garbage code that's hard to understand and a nightmare to maintain. Once the prototype is merged, they don't have time to continue working on that feature, as they have five more POCs to work on. That work is assigned to someone else in the team (yes, sometimes it's you).

You realise the prototype that was “supposedly” built to handle edge cases barely works even on the happy path. Product believes the prototype accounts for the future specs (developed by the 10X developer), but you only know that it barely covers the current ones.

They grow out of touch with actual, real-world project work. They now live in the POC world, where everything is a green field project. Their system never breaks; it's always someone else's faulty code. Anyways, they don't have time to fix it. They’ve already got ten more POCs to work on. And now it’s your responsibility to fix it.

They start shipping more features in a quarter than the rest of the team combined in a year. Meanwhile, you get less and less time to stabilise the prototype and get it into production. The 10X developer assures you it's already “production-ready.” You just need to iron out the cloth, the only issue being, the cloth has multiple holes.

Team Fatigue and Burnout

Eventually, everyone on the team starts resenting having to pick up the pieces from the 10X developer's prototypes. No one wants to work with them anymore.

What was once an outlier becomes the baseline. People start burning out, start leaving the project, and with each departure, the project slips from bearable to broken.

What was once a thriving codebase and a colourful team becomes a barren, forgotten land.

How Scope and Closures Work Together in JavaScript: A Classic Interview Question Explained

Idris Gadi — Wed, 18 Jun 2025 18:17:00 +0000

Scope and Closures are two fundamental concepts in JavaScript that often elude even experienced developers, and what’s frequently overlooked is that these two concepts don’t operate in isolation; they usually work hand in hand in real-world JavaScript code.

In this article, we’ll explore how Scope and Closures come into play by breaking down a classic for loop interview question.

Prerequisite

Before diving in, you should have a basic understanding of:

What is Scope
What is Closure

The Interview Question

Here’s that classic for loop interview question that often trips developers up:

Question: What will be the output of the following code?

for (var i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000);
}

A developer unfamiliar with how scope and closures work together might say it will log 0, 1, 2. Those who understand the behaviour correctly will answer that it logs 3, 3, 3.

Follow-up Question: How would you fix this bug?

The Solution

The most common solution is to replace the var keyword with let:

for (let i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000);
}

This change works, but do you understand why it works? That’s where Scope and Closures come into play.

Understanding the Scope

To fully understand why this happens, we need to take a step back and consider where the for loop lives. In real-world code, a for loop almost always exists inside a function.

The key point in the original snippet is that var is function-scoped. Even though i is declared in the for loop declaration, it’s scoped to the entire function, not to each iteration of the loop.

We can rewrite the code like this, and the behaviour remains exactly the same:

function main() {
  var i = 0;
  {
    setTimeout(() => {
      console.log("value", i);
    }, 100);

    i++;
  }

  {
    setTimeout(() => {
      console.log("value", i);
    }, 100);

    i++;
  }

  {
    setTimeout(() => {
      console.log("value", i);
    }, 100);

    i++;
  }
}

main();

Here, you can see that every setTimeout callback closes over the same i variable. In JavaScript, closures don’t copy the value of a variable. Instead, they keep a reference to the original variable. So when the callbacks eventually run, they all see whatever value i has at that moment.

Since the loop has already completed by the time the setTimeout callbacks fire, i has been incremented to 3. That’s why you see 3 printed three times.

How `let` Solves the Problem

When we replace var with let, we’re essentially changing how the variable is scoped and initialised during each iteration of the loop.

Unlike var, let is block-scoped. The for loop creates a new block for each iteration, and let creates a new binding of i every time. This is roughly equivalent to writing:

function main() {
  {
    let i = 0;
    setTimeout(() => {
      console.log("value", i);
    }, 100);
  }

  {
    let i = 1;
    setTimeout(() => {
      console.log("value", i);
    }, 100);
  }

  {
    let i = 2;
    setTimeout(() => {
      console.log("value", i);
    }, 100);
  }
}

main();

If you look closely, each setTimeout still closes over i, but now i is a different variable in each block, initialised with the correct value for that iteration. That’s why we get the expected output: 0, 1, 2.

How Closure and Scope Work Together

At the heart of this problem is how Scope and Closures interact.

Scope determines where a variable is accessible in the code. With var, the variable is function-scoped, meaning there's only one shared variable throughout the loop. With let, a new block-scope variable is created for each iteration.
Closures happen when a function "remembers" variables from its surrounding scope, even after that scope has finished executing. In this example, each setTimeout callback forms a closure over i.

When using var, all the closures refer to the same i, and since the loop finishes before the timeouts execute, they all log 3.

When using let, a new i is created for each iteration, so each closure captures its own distinct copy of i. That’s why the output becomes 0, 1, 2.

Acknowledgements

This article is heavily inspired by Kyle Simpson's "Scope & Closures" from the "You Don’t Know JS" (YDKJS) series.

Even though I technically knew the answer to this interview question, I struggled to explain why it works that way. That struggle made me realise I didn’t fully understand what was actually happening. The book helped me finally connect the dots.

Conclusion

Understanding how Scope and Closures work together is a crucial part of JavaScript, and struggling with interview questions like this one is a great nudge in the right direction to deepen that understanding.

If you enjoyed this article, feel free to connect with me on LinkedIn, follow me on X/Twitter, or find me on Bluesky. I regularly share posts like this and share lessons from my learning journey.

Building Efficient Node.js Workflows in GitHub Actions: Leveraging Caching and Modular Job Structures

Idris Gadi — Fri, 08 Nov 2024 08:28:48 +0000

As Software Developers, we love automation, be it automating tasks or using that automation. One such automation is CI/CD pipelines, and one of the most widely used platforms is GitHub Actions.

It is crucial to learn the platform that we are using and the features that it offers to build efficient and reliable automation.

One of the most common automation workflows used in Git-based Software Development is PR/MR checks, these checks have become an essential part of modern CI pipelines, as they help maintain the source code and improve PR/MR reviews.

In this article, we will focus on creating a PR-checks workflow for a Node.js application using GitHub Actions, and how we can improve the Developer Experience(DX) and make it even more efficient using modular jobs, and caching.

Prerequisite

What is GitHub Actions
How to create a Github Actions workflow. GitHub Actions Docs Dev.to Article
What is actions/checkout and actions/setup-node

Task

Create a GitHub Actions workflow that runs whenever a PR is opened or updated, we want to check for three things in this workflow:

Check if the linting rules are followed.
Check the formatting of the code.
Check all the test cases.

This helps maintain the quality of the source code and PR reviews, as the reviewer doesn't have to worry about whether this PR will break any existing(tested) functionality or cause lint and formatting issues.

Creating a PR-Check Workflow

Let's create a workflow file called pr-check.yaml that triggers a pipeline whenever a PR is opened or updated against the main branch.

Note: For this article we will use the ubuntu-latest runner but you can use whichever runner you want.

Now, let's check-out the repository, setup node, and install dependencies:

After the project has been setup and all the dependencies installed, let's run our PR-check scripts to check for lint, formatting, and tests:

Voila!, we have a nice workflow automation that will benefit our development process.

Or is it?

The Issues

You see this automation looks fine at first, however, it has some issues:

All our tasks are crammed into one job.
On the GitHub Actions dashboard, the workflow diagram will look something like this:
If one of our tasks fails, we have to look into the logs to determine which one failed. This might not look like an issue, but logs expire after some time, and if we have more tasks or long-running tasks, it can be hard to read logs. (I mean c'mon, don't pretend you love reading logs)
As a reviewer whenever there is a failing pipeline, you have to look into the logs and then tell the PR owner that 'this' check is failing in their PR. (Yeah, I don't like that either)

A Better Approach

One of our main issues is that all tasks are crammed into a single job, with no clear separation between them. So, let’s start by defining a separate job for each task. This will help keep things organized and make it easier to track each task individually!

This solves all our issues! Each task runs in a separate job, so we don’t have to dig through logs to figure out where things went wrong. Plus, we get a nice diagram on the dashboard showing exactly which task failed. From there, we can dive right into the logs of the specific task to investigate further.

However, it has a huge issue.

The Issue

Since each job runs in an isolated environment, it needs to make separate network calls for repeated actions, such as actions/checkout, actions/setup-node, and Installing Dependencies.

Caching

The extra network calls issue can be solved by caching the actions and their output.

actions/checkout

actions/checkout is globally cached by GitHub Actions and doesn't require any network calls to setup, it also automatically caches the checked-out repository for the whole workflow run and will only need to make a network call to check-out the repository during the first job run and then it uses the workflow cache to check-out the repository in subsequent jobs.

actions/setup-node

actions/setup-node is also globally cached by GitHub Actions and doesn't require any network calls to setup. It will first check the local cache to install the specified version of Node.js and only when it can't find that version in the cache, it will fall back to downloading the specified version and cache it for the workflow run.

GitHub Actions hosted runners provide locally cached Node.js versions based on the Runner Image, you can also access this cache in your self-hosted runner if it has access to github.com or you can setup tool cache on self-hosted runners to cache the required Node.js versions locally.

Installing Dependencies

To install dependencies, we need to download packages from the NPM registry. Since GitHub can't cache every package available on NPM, each job run has to download these packages directly from NPM. This results in network calls for each job, which not only increases the execution time for each job (and subsequently the overall workflow runtime) but also eats the runner quota—especially for private repositories.

Yikes! That's a bummer, isn't it?

We can use another amazing action provided by GitHub, actions/cache to cache our dependencies from our first job run and use that for subsequent jobs.

However, we have something even better. actions/setup-node has built-in support for caching global packages data and restoring dependencies from the cache (if available) using actions/cache under the hood. All we have to do is use the optional cache option and pass in the name of the package manager (supported package managers are npm, yarn, and pnpm (v6.10+)).

It gets even better, actions/setup-node defaults to searching for the dependency file (package-lock.json, npm-shrinkwrap.json, or yarn.lock) in the repository root, and uses its hash as a part of the cache key, which means any subsequent workflow runs will use the same global packages cache if the lock file is unchanged (i.e. no changes in the dependencies) or till the cache is alive.

The Better Workflow

Now, let’s put our caching knowledge into the workflow by creating a separate job for each task(check).

Conclusion

Using the actions, modularity, and caching features in GitHub Actions, we developed an effective and efficient workflow to automate our pr-checks. Similarly, we can utilize these features in other CI/CD operations and contribute towards improving project workflow.

If you enjoyed this article and want to connect, feel free to reach out on LinkedIn and X/Twitter.

How TypeScript Makes React Better: Smoother Developer Experience, Fewer Bugs (With a useState Example)

Idris Gadi — Sun, 27 Oct 2024 15:51:53 +0000

Let's start with a scenario and a task associated with it.

We have a messaging application with a status bar that shows the user's current status and allows them to update it. We have to add a dropdown from which the user can change their status and use useState() to show and update the user's current status in the UI.

For simplicity, we will only focus on the useState implementation in this article, and by the end of the article, you will understand how even for a simple example TypeScript is a much more powerful option.

The Task

We have to define a useState() that stores and updates userStatus and is initialized with one of the five possible status options (let's say active).

All the possible options are:

Active (active)
Away (away)
Do Not Disturb (dnd)
On Leave (leave)
Out Of Office (OOO)

JSX/JS

This is a very straightforward task, right? All we have to do is define a useState and initialize it to active and then use the set function to update the status and we are done.

But wait! What happens when someone is reviewing my code or visits this piece of code later (say after 1 week, 2 weeks, 1 month, 6 months, or whatever), how will they know what are all the possible/valid options?

Ahh! Yes, we can add a comment next to the useState to let them know that these are all the possible options.

But, this isn't a good solution, right? So, how can we improve it?

Object Lookup

Object lookup is a really nice solution to our problem. So, let's start with defining an object lookup called UserStatus and use it to set our userStatus value.

Now, let's update our useState definition.

Now, let's try to update the status.

Ohh! Look at that, now we get autocomplete in our editor and can check all the possible/valid values of userStatus by looking at the definition of UserStatus.

The Issues with Object Lookup

Even though the object lookup method has seemingly solved our problem and is definitely a far better solution than just adding comments, it still has two major issues:

For anyone visiting our piece of code later, they have to know that we are using an object lookup to set our state. This might seem trivial but imagine as our component grows and becomes more complex, then it becomes very easy for someone to be unaware of our implementation.
It still doesn't prevent anyone from setting any random value to our state, even when they are aware of the object lookup.

So, how can we solve these issues?
Answer: Typescript

TSX/TS

Let's start again with our solution, but this time in a .tsx or a Typescript file. We can start by defining a useState() function and initializing it with the value: active.

Nothing seems different right now, but it is. Let's update the userStatus value.

Ahh! As you can see it is giving us that dreaded red squiggly error line around some set functions but not on ones where we are setting a string value. This is because Typescript is inferring the type of our state from its initial value (i.e. type string).

Yes, this will prevent us from setting any non-string values to our userStatus state, but it still doesn't prevent us from setting any random string value and we still have to use the object lookup for documenting all the possible options, you may ask.

Let's do some "One Stone, Two Birds".

Explicit Types and Generics

In Typescript we can create custom types and it also has support for generics which can be used in React for its hook definitions, in our case the useState() hook.

Let's create a new UserStatus type in our React component.

Now, let's use this type in our useState definition.

Till now, everything looks similar to how we were doing it in the object lookup method, but the magic of Typescript is when we start using our set function and the state value.

Getting the type definition of userStatus.
Autocomplete for the setUserStatus function.
Getting proper validation for valid and invalid values.

Look at that,

We can get the documentation of all the valid values by simply hovering over the userStatus and looking up its type definition.
However, we don't need to look at the type definition of our state value when using the set function, as it automatically gives us the autocomplete for all the valid options.
Now it not only gives us the error when setting a non-string value, but it also gives us the error for using invalid string values (i.e. it will always give errors for invalid inputs).

Conclusion

By now, you probably have got a good feel for how TypeScript can really enhance our development experience. We have only scratched the surface with a simple example here, but just think about the real-world applications we’re building, using TypeScript could mean way fewer bugs and a way better developer experience overall.

I hope this article encourages you to start using Typescript in all your React applications and build awesome web experiences.

If you liked this article and would like to connect, then you can connect with me on Linked and X/Twitter

Beyond Basics: Handling Numeric Inputs Like a Pro with ``

Idris Gadi — Mon, 09 Sep 2024 07:40:16 +0000

What is `<input type="number">`

According to MDN Docs Definition: <input> elements of type number are used to let the user enter a number. They include built-in validation to reject non-numerical entries.

So basically, it is a feature for enhancing User Experience on our crappy websites and web apps. While it is a nice feature for simplifying numeric inputs, it has a couple of behaviors that might not be obvious at first but we should be aware of as a web developer.

These behaviors are related to:

Virtual Keyboard
Scientific Notations

Virtual Keyboard

A virtual keyboard is a keyboard that appears on your screen, usually in touch input devices like mobile phones, tablets/ipads and some assistive technologies.

<input id="numeric-input" type="number" >

Just using the type="number" might seem all right at first, but it has an issue when using a virtual keyboard. It might open a full-key keyboard instead of a numeric keyboard, which can hurt user experience and input accuracy.

Solution `inputmode`

While the virtual keyboard issue might not occur on newer OS and browser versions, it is still a good idea to use the inputmode attribute as it hints at the type of data that might be entered by the user while editing the element or its contents.
This allows browsers to display an appropriate virtual keyboard for all versions and devices, improving the application's overall user experience (UX).

inputmode can have many values, but for our use case with numeric inputs we should use one of these two values:
1.numeric

<input id="numeric-input" type="number" inputmode="numeric" >

The input type number accepts any rational value. If you are not accepting fractional values and only accepting whole numbers, using a numeric value should be preferred for such scenarios.

2.decimal

<input id="numeric-input" type="number" inputmode="decimal" >

If you are accepting fractional numbers, use decimal value as it will show a virtual keyboard containing the digits and decimal separator for the user's locale.

Always prefer using decimal value in your input unless you are not accepting fractional values.

Scientific Notations

Many of us might have forgotten or not know that e or E are valid numeric values in scientific notations.

Yes, e or E means "exponent of ten" in scientific notations, and is used to represent very large or small values. e.g.

1e5 = 100000 
     or 
1e-5 = 0.00001

The HTML input type number was designed with flexibility in mind, and it supports this scientific notation, allowing for the entry of exponents (e.g., 1e5). While this is not an issue in itself and can be useful in some contexts, it can become problematic when the input should only consist of basic numbers.

There are two ways to restrict the input to only numbers and not allow the scientific notations.

Using Regex 🤮 pattern.
Using Javascript (my preferred method).

Preventing Default Behaviour Using Javascript

In most scenarios, I don't want the users to enter the 'e' or 'E' notations, as they aren't needed, and allowing them can cause some unexpected issues.

There are many ways of achieving this, but my favorite method is to prevent the 'e' or 'E' key from being registered. We can achieve this using the keydown event and preventDefault.

 element.addEventListener("keydown", (e) => {
    if (["e", "E"].includes(e.key)) {
      // you can also add "+" and "-" if you want to prevent them from being registered.
      e.preventDefault();
    }
  });

I particularly like this method because of three reasons:

It provides a clear message to anyone reading our code later that we don't want to register the e or E keys.
It also allows for a better UX because instead of changing the values we are not registering the key itself.
The type of keydown event is KeyboardEvent which gives us direct access to the key values improving the overall DX of the solution.

Not All Numeric Input Needs to be Input Type Number

Sometimes we can instinctively reach for an input type number if we see an input requirement that accepts numeric input but sometimes input type number is not the right solution for such scenarios.

A few examples of such scenarios are:

Credit Card/Debit Card: When we have an input field for Credit/Debit Card, instead of using input type number it is better to use input type text with input mode of numeric and validation using your preferred method, as a credit card can have leading zero values and some browsers might not allow that, also we might want to add some card specific validations or allow spacing between a group of four numbers (as it is printed on the card).
Postal Code: While most countries have numeric postal codes, some countries like Canada could have alphanumeric codes, it is important to use solutions according to your need, it could be of input type number or input type text.
Mobile Numbers: You should always use the input type of input="tel" with a regex pattern suitable for your use case.

Conclusion

Since modern HTML provides some really nice utilities, some things might feel very trivial to implement like input type number, however as developers, we should always pay attention to these utilities and how we can utilize them to create even better user experiences.

If you liked this article please leave a reaction and if you disliked something you can leave your feedback in the comments.

I like to connect and talk with people about tech and the events surrounding it. You can connect with me on Twitter/X and LinkedIn.

You can also follow me on Dev.to to get a notification whenever I publish a new article.

Why is Math.min() Greater-Than Math.max() in JavaScript

Idris Gadi — Sat, 31 Aug 2024 13:51:15 +0000

Expression Breakdown

Let's start by breaking down the expression. It essentially has three parts, two static methods, and a greater than operator between them.

I don't want to read through the article, give me TLDR;

Greater than operator `>`

The greater-than (>) operator returns true if the left operand is greater than the right operand and false otherwise. This is very straightforward.

Now, let's look at the two method calls.

`Math.min()` and `Math.max()`

Math.min() and Math.max() are static methods of the Math class that takes in a set of numbers as input arguments and returns the smallest or the largest number from the set respectively.

Let's look at some examples.

/* Math.min() */
console.log(Math.min(5, 2, 9, 1, 7)); // Output: 1
console.log(Math.min(-3, -10, -7, -8)); // Output: -10
console.log(Math.min(-5, -2, 8, 10, 6)); // Output: -5

/* Math.max() */
console.log(Math.max(5, 2, 9, 1, 7)); // Output: 9
console.log(Math.max(-3, -10, -7, -8)); // Output: -3
console.log(Math.max(-5, -2, 8, 10, 6)); // Output: 10

What If We Pass Only One Argument

In the examples, we saw that min() and max() methods are basically comparing the values present in the set and returning the smallest or the largest value respectively. Now, what if we pass a set with only a single value.

/* Math.min() */
console.log(Math.min(7)); // Output: 7
/* Math.max() */
console.log(Math.max(7)); // Output: 7

Both method returns the input value, that is because they have an implicit argument that they use in the comparison set, and when only a single value is passed in that set, it compares that value against the implicit argument.

What Are These Implicit Arguments

min() and max() both use different implicit arguments.

`Math.min()`

As min() returns the smallest number from the input set, it uses the largest number as the implicit argument. That is the Infinity, as no number can be larger than the infinity, a comparison against it will always return the other value.

`Math.max()`

Similarly max() returns the largest number from the input set, it uses the smallest number as the implicit argument. That is the -Infinity, as no number can be smaller than the negative infinity, a comparison against it will always return the other value.

The Expression `Math.min() > Math.max()`

We saw that if we pass only a single value in the input set, both the min() and max() methods will return the value and why it does that.

Now, what if we don't pass any input arguments?

/* Math.min() */
console.log(Math.min()); // Output: Infinity
/* Math.max() */
console.log(Math.max()); // Output: -Infinity

Both methods returns their implicit arguments that is, Infinity and -Infinity respectively.

Now, we know the return values of Math.min() and Math.max(), and we also know that the greater-than > operator compares the values and not the function expression.

So what if we compare the return values of Math.min() and Math.max()?

console.log(Infinity > -Infinity) // Output: true

Therefore.

console.log(Math.min() > Math.max()); // Output: true

Hence, why Math.min() > Math.max().

It is not only true for the Math.min() > Math.max() expression, but any expression where the return value of min() is greater than the value of max(). e.g.

console.log(Math.min(5, 2, 9, 1, 7) > Math.max(-3, -10, -7, -8)); // Output: true
console.log(Math.min(-5, -2, 8, 10, 6) > Math.max(-9, -10, -7, -8)); // Output: true
console.log(Math.min(-5, -2, 8, 10, 6) > Math.max(-3, -10, -7, -8)); // Output: false

Conclusion

Sometimes we fall victim to the logical fallacies and Math.min() > Math.max() is a nice example for that, it doesn't feel weird when we have sets of numbers where the return value of min() is greater than the return value of max() as in the example above.

However, when we see an empty set of arguments, we start comparing the meaning of min() (minimum) and max() (maximum) instead of comparing their return values and it leads to falling for the logical fallacy that Math.min() shouldn't be greater than Math.max() and hence it should be a quirk of Javascript, but as we saw in this article, it makes complete sense why it is true and why it would be absurd if it wasn't.

I hope you enjoyed this article and learned something new or refreshed your knowledge and I also hope that it makes you like Javascript a little bit more :).

I like to connect and talk with people about tech in general and the events surrounding it. You can connect with me on Twitter/X and LinkedIn. You can also follow me on dev.to.

Why and How to Migrate Your React App from CRA to Vite

Idris Gadi — Mon, 10 Jun 2024 07:19:59 +0000

Updates

February 2025: CRA is officially on a path for full deprecation, there is already a deprecation warning added to the project's readme and open PRs to deprecate the docs website and the CLI installation.

You can track the status of this issue: Umbrella: CRA breaks with React 19, and CRA needs deprecation notices

As of the time of writing this article (10/06/2024), CRA has been effectively semi-dead for the past two years. It has not received any commits since last year, or any important ones for the past two years in CRA commit history. Issues have been piling up, and none are being addressed in CRA issues.

So why is it in a semi-dead state but not dead? The React team has not deprecated it. If it's not deprecated, then it might have reached a certain level of maturity and might not need any new changes. Thus, it is not in a semi-dead state but has reached a certain level of maturity.

Here is the tricky situation and that's why CRA is in a semi-dead state, it has not been deprecated but isn't receiving any updates not even security updates, along with the new React.dev documentation doesn't mention CRA but suggests using React meta-frameworks like Next and Remix for new projects. You can read more about React's reasoning for it in this GitHub issue discussion.

So React suggests using meta-frameworks for new projects, which means it should be fine to use CRA in the existing projects. you may ask. The issue with it is that it lacks many of the modern build tools features that we need in production applications and it might not be possible or you might not want to migrate to a meta-framework, which means either you have to eject out of CRA and maintain your webpack configuration or you can use another brilliant frontend build tool call Vite.

Vite

Vite is a modern frontend build tool created by Evan You (creator of Vue.js). Vite is framework agnostic and works on a plugin-based approach.

For this article, we will specifically focus on migrating a React App from CRA to Vite.

Why Vite?

Vite's plugin-based approach allows us to configure the project that best suits our use case by exposing low-level APIs as much as possible without needing to configure the underlying bundler.
Vite is not a bundler but a frontend tool that intelligently uses ESBuild and Rollup for their best use cases.
Vite servers Native ESM code in the dev server mode for better start/reload times and HMR (Hot Module Replacement).
Using ESBuilt, Vite creates a highly optimized prod bundle with support for better code splitting and tree shaking.
Using plugins for configuring the project means that we can pick and choose what we want to use for certain things.
We can effectively create our meta-framework using Vite, as it even supports things like SSR and SSG.

There are many more benefits of using Vite as discussed by the Vite team here Why Vite?

Now, let's see how to migrate our existing CRA project to Vite.

NOTE:
I will be providing overview implementations and pseudo code and commands in this article since my aim is not to give you a template but to guide you toward migrating your app that fits your needs. I will provide the necessary and important references throughout the article for your help.

Getting Started

Install Vite

We can start by installing Vite in our current project.

npm install vite --save-dev

Install React Plugin

As Vite works on a plugin-based approach, we will have to install one of the two official React plugins. You can read more about them and choose the one that suits your needs from here @vitejs/plugin-react and @vitejs/plugin-react-swc

npm install @vitejs/plugin-react --save-dev

index.html

During development, Vite is a server and it uses index.html as the entry point. Therefore we need to make a few changes to the index.html file.

Move index.html file to the root of the project.
URLs inside index.html are automatically rebased so there's no need for special %PUBLIC_URL% placeholders and they can be removed.
Add below script tag that allows it to reference the Javascript source code. (preferably at the end of the body tag, as that's where a fresh Vite project puts it)

<script type="module" src="/src/index.tsx"> </script>

Configuration

Config file

Next, we will have to create a vite.config.js or vite.config.ts file at the root of the project based on whether if its a Javascript or a Typescript project.

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  base: '/',
  plugins: [react()]
})

You can read more about all the configuration options at Config

Typescript

To resolve imports using TypeScript's path mapping you will have to use one of the community plugins for Vite. You can read more about it here vite-tsconfig-paths

Environment Variables

Vite exposes env variables on the special import.meta.env object, which are statically replaced at build time. To prevent accidentally leaking env variables to the client, only variables prefixed with VITE_ are exposed.

Therefore, we will have to replace all the process.env. with import.meta.env. and replace the REACT_APP_ prefix with VITE_.

# CRA env variable
REACT_APP_MY_ENV = 'some value'
process.env.REACT_APP_MY_ENV

# Vite env variable
VITE_MY_ENV = 'some value'
import.meta.env.VITE_MY_ENV

SVGs

To use SVGs and SVGs as a React component in our Vite project, we will have to use another awesome community plugin called svgr().

You can check out vite-plugin-svgr to learn more about how to install and use svgr() and all the configuration options that it exposes.

JSX in JS

By default, Vite will not resolve any JSX file with .js extension, even though there are workarounds to resolve this, it would be better to migrate all the JSX files with .js or .ts extension to .jsx or .tsx as this is the official recommendation from the Vite team.

To learn more about the reasoning behind this decision you can read this Twitter/X thread by Evan You.

Browserslist

For a production build, you are likely using Browserslist, by default Vite targets browsers that support native ES Modules, native ESM dynamic import, and import.meta.

In Vite, legacy browsers can be supported via the official @vitejs/plugin-legacy plugin, it also provides Browselist-like configuration.

Build File

For the production build, Vite creates a dist directory while CRA creates a build directory, if you have a CI/CD pipeline you might have to make changes in it to look for a dist directory or you can change the output directory name in the build options. You can read more about all the available build options.

Update Scripts

Now, as most of our configuration part is done, we can move on to updating scripts in our package.json file.

Dev Server

First, we will have to update our start script or dev server script.
Change your start script.
From:

 "start": "react-scripts start",

To:

 "start": "vite",

Now, we can also remove the eject command as it is no longer applicable.
Remove:

"eject": "react-scripts eject" <-- remove this

Build

Before updating build scripts we will look into one more thing, for a production application you might be using something like env-cmd for managing multiple env files for multiple environments such as development, staging, and production.
Vite has a first-class support for something called modes, we can utilize this to remove dependency on env-cmd for managing multiple environments. You can read more about it in Env Variables and Modes.

Now, let's update our build scripts.
From:

"start": "vite",
"build:dev": "env-cmd -f .env.dev react-scripts build",
"build:staging": "env-cmd -f .env.staging react-scripts build",
"build:prod": "env-cmd -f .env.prod react-scripts build",

To:

"start": "vite",
"build:dev": "vite build --mode dev",
"build:staging": "vite build --mode staging",
"build:prod": "vite build --mode prod",

Typescript

For Typescript we will have to prefix build scripts with tsc &&.

Unit Test

As you may have noticed, unit tests in CRA also depend on react-scripts

"test": "react-scripts test"

There are two main ways in which you keep your existing unit tests, one is using jest directly as react-scripts uses it under the hood and another one is using vitest (this might require some migration but shouldn't be much work).

I will not go into detail about migrating your unit tests, as every project has its own test setup, and generalizing it would be very difficult. You can read and learn more about both of them in JEST docs and Vitest docs.

Testing

Now, as all configurations and scripts have been updated, we will have to do thorough testing of all the commands, features, and pages to make sure everything is working fine and fix any issues that might arise.

Once all the testing is done and we have verified that everything is working fine, we can finally remove the CRA dependency from our project.

npm uninstall react-scripts

Also, remove env-cmd or similar utility that we might not be using anymore.

npm uninstall env-cmd

Extra

Absolute Imports

Absolute import allows us to import components, utilities, and files using their absolute path with respect to the root of the project rather than a relative path from the current file, this makes imports more readable, easy to refactor, and overall improvement in DX as you don't have to wonder from where the file is being imported.

You can read more about how to implement absolute imports by googling it or you can read another great dev article How To Create Absolute Imports In Vite React App: A step-by-step Guide by Andrew Ezeani.

OpenSauced Interview with Evan You on Vite

If you are interested in how, when, and why Vite was created, how it became a dominant frontend building tool, and other interesting bits from Evan You. You can watch this Why is Vite Everywhere? | Evan You interview by OpenSauced.

Like, Follow and Discuss

If you liked this article you can leave a reaction and if you disliked something you can leave your feedback in the comments.

If you think I missed any important point or want to discuss something more in detail, we can discuss it in the comments, as it will help others who will read it in the future and maybe that person could be our future self when we need to migrate another React App from CRA to Vite.

I like to connect and talk with people about tech in general and the events surrounding it. You can connect with me on Twitter/X and LinkedIn. You can also follow me on dev.to.

Think Twice Before Using setInterval() for API Polling – It Might Not Be Ideal

Idris Gadi — Sun, 19 May 2024 07:40:01 +0000

Before We Start

Data fetching is a very simple task until it becomes complicated. Therefore I recommend that you use powerful data fetching libraries like TanStack Query, SWR, RTK Query.
This post assumes that you are aware about what is API polling in RESTful architecture.
All the code described is sort of a pseudo code, it's main purpose is to provide higher level understanding. The implementation might depend on the framework that you use.

With that said, let's get into it.

Polling (The Task)

So let's say that we have a requirement where the client(UI) requires frequent updates for a certain section but it doesn't necessarily need to be in real time, for that case we can utilise API polling.

setInterval() (The Intuitive Solution)

So we need a way to call an API endpoint repeatedly after a certain amount of interval(delay).
Which JavaScript function can we use for this? "psst...it's setInterval()"

API polling

We can achieve API polling by utilising setInterval() to repeatedly call fetch function.

async function getData() {
  try {
      const response = await fetch(/*api endpoint*/);
      /* handle response here */
    } catch (error) {
      /* handle error case here */
    }
}

function apiPolling() {
  setInterval(getData, delay);
}

/* Start Polling */
apiPolling();

the client will repeatedly call the endpoint after a delay between each call where the delay is equal to the desired polling interval.

Stop or Cancel polling

When we have to stop the polling at a certain condition or cancel the polling on user's request, we have to take care of two things.

Clear the setInterval function from queue.
Cancel any ongoing HTTP request that hasn't responded yet.

We can achieve this using clearInterval and AbortController.

let intervalId;
let controller;
async function getData() {
  controller = new AbortController();
  const signal = controller.signal;
  try {
      const response = await fetch(/*api endpoint*/,
       { signal }
       );
      /* handle response here */
    } catch (error) {
      /* handle error case here */
    }
}

function apiPolling() {
  intervalId = setInterval(getData, delay);
}

/* Start Polling */
apiPolling();

function clearPolling() {
  clearInterval(intervalId);
  if (controller) {
    controller.abort();
  }
}

/* To stop or cancel polling */
clearPolling()

we clear the polling queue by calling the clearInterval function and making sure that any in-progress request is cancelled using AbortController. You can read more about AbortController

Issues with setInterval()

Intuitively setInterval might look like the best solution for polling until you stop and think about how it works. It always calls the function repeatedly after a fixed delay. This is might and will cause a host of issues, since polling in never just about calling the endpoint again again but requires careful consideration on how to handle error cases and when to poll for the next request.
Some of the issues are:

Network latency or Unresponsive server can cause the actual time to response to be greater than the polling interval, this can lead to network congestion and increased traffic on already struggling client or server.
Variations in response time in conjunction with the above issue can cause multiple queued up requests that won't necessarily return in order, leading to a host of request handling and UX problems.
Since setInterval isn't aware of the error case or stop condition, we have to manually stop the polling for every case and with the queued up request issue it might not be simple or even possible to cancel all those requests.

setTimeout() (The Proper Solution)

Intuitively setTimeout might not look like a solution for the polling at first. After all it only calls the function once after the delay and done.
How can we use setTimeout for a task that requires a function to be called repeatedly? "Ahh...the answer is recursion".

We can recursively call setTimeout to achieve polling and just by the virtue of how this solution works, we can improve upon the issues encountered while using setInterval and improve user experience as well as the developer experience (talking about DX, such an original of me).

Let's start with creating a recursive setTimeout function that loops over itself and is invoked immediately.

(function loop() {
  setTimeout(() => {
   /* Function logic here */

    loop();
  }, delay);
})();

Now we can extract the function logic as a named function out of setTimeout.

function loopingLogic() {
  /* Function logic here */
  loop();
}

(function loop() {
  setTimeout(loopingLogic, delay);
})();

Let's look at what's happening here, at first the loop() is called, it invokes a setTimeout which waits for the delay and calls the loopingLogic(), once all the tasks in that function are performed, at the end loop() function is called again, creating a recursion which calls the loop() after every execution of loopingLogic()

Now let's say we only want to loop over the function if a certain condition is met or to stop looping when that condition is not met. We can achieve that by checking if that condition is true and only then continue to loop.

function loopingLogic() {
  /* Function logic here */
  if (/* Condition is true */) {
    loop();
  }
}

(function loop() {
  setTimeout(loopingLogic, delay);
})();

Now, as we have the base logic setup, let's look at how we can achieve API polling using this pattern.

async function getData() {
  try {
    const response = await fetch(/*api endpoint*/);
    /* handle response here */
    if (/* Condition is true */) {
      apiPolling();
    }
  } catch (error) {
    /* handle error case here */
  }
}

function apiPolling() {
  setTimeout(getData, delay);
}

/* Start Polling */
apiPolling();

Let's walkthrough the code. We can start polling by calling the apiPolling() function, it invokes a setTimeout which waits for the delay before calling the getData() function.

In getData() function we are handling the data fetching logic. We are doing few things in that function:

We are hitting the api endpoint using fetch.
We wait for the response and handle the response accordingly.
We check if certain condition is met before calling the apiPolling() function to recursively hit the api endpoint for polling.
We catch any errors and handle those errors accordingly.

Now let's look at how this pattern of polling improves over setInterval.

We only poll for the next request when the response from the current request is received. This solves the problem of network latency and unresponsive server causing a network congestion, reduced overall traffic and mitigates the issue of race conditions caused by requests that won't necessarily return in order.
By checking for the base case or guard clause in the if statement, we can make sure the polling continues only if that condition is met, making it very easy to automatically stop polling and preventing other issues that might arise when something errors out and helps in better error handling.

We can expand over our new polling pattern to allow users to gracefully stop or cancel polling.

let intervalId;
let controller;

async function getData() {
  controller = new AbortController();
  const signal = controller.signal;
  try {
    const response = await fetch(/*api endpoint*/,
    { signal }
    );
    /* handle response here */
    if (/* Condition is true */) {
      apiPolling();
    }
  } catch (error) {
    /* handle error case here */
  }
}

function apiPolling() {
  intervalId = setTimeout(getData, delay);
}

function clearPolling() {
  clearInterval(intervalId);
  if (controller) {
    controller.abort();
  }
}

/* To stop or cancel polling */
clearPolling()

Conclusion

When presented with a task to create API polling, setInterval might intuitively seem like the best option for this task. However as discussed above we can see that it is not the best option and can lead to some nasty issues and complicated code as we progress. Instead we can utilise the recursive setTimeout pattern to create better a solution and prevent or even improve upon the issues that might arise by using setInterval.

Remember, whenever you have to poll an API on a remote server, always go for recursive setTimeout pattern.

Let me know in the comments below if you found this post helpful, any points that I missed and discuss what are the different ways you like to do API polling.

I like to talk about tech in general and events surrounding it. You can connect with me on Twitter/X and LinkedIn

DEV Community: Idris Gadi

10X Developer and the POC Trap

A tale of POCs, tech debt, and working with rockstars who moved too fast

Meeting the 10X Dev

POC Hero

From Hero to Bottleneck

Team Fatigue and Burnout

How Scope and Closures Work Together in JavaScript: A Classic Interview Question Explained

Prerequisite

The Interview Question

The Solution

Understanding the Scope

How let Solves the Problem

How Closure and Scope Work Together

Acknowledgements

Conclusion

Building Efficient Node.js Workflows in GitHub Actions: Leveraging Caching and Modular Job Structures

Prerequisite

Task

Creating a PR-Check Workflow

The Issues

A Better Approach

The Issue

Caching

actions/checkout

actions/setup-node

Installing Dependencies

The Better Workflow

Conclusion

How TypeScript Makes React Better: Smoother Developer Experience, Fewer Bugs (With a useState Example)

The Task

JSX/JS

Object Lookup

The Issues with Object Lookup

TSX/TS

Explicit Types and Generics

Conclusion

Beyond Basics: Handling Numeric Inputs Like a Pro with ``

What is <input type="number">

Virtual Keyboard

Solution inputmode

Scientific Notations

Preventing Default Behaviour Using Javascript

Not All Numeric Input Needs to be Input Type Number

Conclusion

Why is Math.min() Greater-Than Math.max() in JavaScript

Expression Breakdown

Greater than operator >

Math.min() and Math.max()

What If We Pass Only One Argument

What Are These Implicit Arguments

Math.min()

Math.max()

The Expression Math.min() > Math.max()

Conclusion

Why and How to Migrate Your React App from CRA to Vite

Updates

Vite

Why Vite?

Getting Started

Install Vite

Install React Plugin

index.html

Configuration

Config file

Typescript

Environment Variables

SVGs

JSX in JS

Browserslist

Build File

Update Scripts

Dev Server

Build

Typescript

Unit Test

Testing

Extra

Absolute Imports

OpenSauced Interview with Evan You on Vite

How `let` Solves the Problem

What is `<input type="number">`

Solution `inputmode`

Greater than operator `>`

`Math.min()` and `Math.max()`

`Math.min()`

`Math.max()`

The Expression `Math.min() > Math.max()`