Forem: TusharShahi

React Hooks: Default Export vs Named Export

TusharShahi — Sun, 25 Jan 2026 07:32:19 +0000

Both default and named exports have their pros and cons. In Javascript codebases, it mostly comes down to personal choice and consistency. I also never felt strongly about one over the other - until I saw this one error.

Problem

The error was minified error #310 - React detected more hooks in a render than the previous one. This usually happens when React hooks are called conditionally.

Example:

const Component = () => {
....
if(someCondition)
 return <p>Testing</p>;
const value = useHook(); //breaks one of React's rules. ESLint gives an error
}

Usually, ESLint throws an error for such hook invocations, courtesy of the plugin - eslint-plugin-hooks-rules. So this code would be caught before it can be committed to main.

But in this failing scenario, it did not happen. The reason is that hook was imported like this:

import getItemConfig from '../config/hooks/item';

The default export from the file is a hook. But it was named something else and imported. If getItemConfig is used conditionally, ESLint rules cannot flag it. The rules rely on the use prefix. That is why it is important to create custom hooks that start with the prefix use.

Fix

Fixing the issue is straightforward. Ensure that the hook is never called conditionally. In this case, move it above the return statement.

If your hook makes a network call that you wanted to prevent and hence it was after the return statement, then consider breaking the component into two.

The rule of React enforcing the number and order of hooks to be called to be the same is only within a React component boundary.

Preventing future occurences

As next steps, we should ensure that hooks are always imported as hooks - functions with prefix use.

We can try to ensure that in our code reviews, but that might not be fool proof as the hook might be committed separately and the usage might be committed in a different commit.

There is no direct advantage of using a default export, and the one advantage we have - renaming an import to anything the developer wants - ended up becoming a disadvantage for us.

We decided to follow the approach for disabling default exports, only for hook files. Note that this does not completely solve the problem. Because even in named exports, one can do the below:

import { useGetConfig as getItemConfig } from '../config/hooks/item';

But this is more intentional and easier to catch in code reviews.

HTML Text Fragments 🪄

TusharShahi — Tue, 17 Jun 2025 15:51:59 +0000

In HTML, every anchor link acts as a bookmark on the page. Besides acting as a link to another page, it also acts as a checkpoint on that particular page.

Given a page, one can automatically jump to a particular section of the page, like this.

This has been a feature as long as I can remember and has been a convenient way to share resources and engage in conversations.

Text Fragments

Today, I discovered text fragments (available since 2020 in some browsers). With Text Fragments, you can directly link to any portion of text in another web document. The biggest advantage is that it does not matter if the author of the document has annotated it with an ID. All you need to add in the URL is the text.

No more anchors ⚓.

This flexibility is amazing and would be a game changer in many fields of work. Here is an example.

The specification mentions that the browser is supposed to highlight the text to make for easy detection.

Popular use cases

Google has embraced the text fragment standard in its search page. The feature is right there. In hindsight, it seems obvious that something like this always existed.

For example, the first result of a search like When did google go ipo always takes you to the exact text with answer.

The search results page:

When you click on the first result, you land here:

Syntax

The link is supposed to be of this format:

https://example.com#:~:text=[prefix-,]textStart[,textEnd][,-suffix]

This #:~:text= is slightly different than #, which is for a document fragment.

The support is quite extensive. One can check for textStart, textEnd, and even the prefix & suffix of the text. So it becomes easier to link to a substring when there are multiple instances. Here is an example(pun intended).

Of course, one has the option to decide what the style of a text target looks like with:

::target-text {
background-color: yellow;
}

While the feature is great for website developers, I believe it is as important if you are not a developer and just share/save online documents. Now that 92% of browsers support it, we might see more usage soon.

Transient Activation: Why the copy button did not work on iPhone

TusharShahi — Fri, 23 May 2025 21:27:54 +0000

Introduction

We recently faced a weird bug at my previous company: our app's copy button decided to take a vacation, but only on iPhones. If you're aware of Safari's quirky ways with the Clipboard API, feel free to skip. Otherwise carry on, this write-up might save you some time in the future.

The Feature: A Simple "Save and Copy"

Let's set the scene. We'd introduced a handy modal where users could update a setting and then instantly copy a generated link. Think Google Sheets' share functionality: you tweak sharing permissions, then grab the link.

Our process was straightforward:

A server call to update the setting.
A copy operation to grab the shiny new link.

A dumbed-down version of the code for our CTA handler looked like:

const handleUpdateSetting = async () => {
  const updatedLink = await saveSetting(updateValue); // Save the setting and get the link
  if (window.navigator.clipboard) {
    await window.navigator.clipboard.writeText(updatedLink); // Attempt to copy
  }
};

"Easy peasy," I thought. I figured I had a solid grasp of both operations. Boy, was I wrong.

The Problem: "Settings Saved, But Link Could Not Be Copied"

During testing, iPhones consistently failed to copy the link. Thankfully, our toast messages were on point: "Settings saved but link could not be copied." Our logs also showed a NotAllowedError for the copy operation.

Most of our development and testing happened in Chrome. I did not test on Safari, as it was just the clipboard the API, which I already knew right? While browsers adopted the Clipboard API, they did so with a keen eye on user security, aiming to prevent scripts from copying text without explicit user intent. The weird thing was, this wasn't an unprompted copy, and we had dozens of other places where this exact writeText call worked perfectly.

The Culprit: Transient User Activation

A glance into the Clipboard API documentation quickly unearthed the root cause. Different browsers, it turns out, have varying security requirements for this API:

Secure Contexts Only: (Universal) The API needs a secure context.
clipboard-write Permission: (Chromium specific) Browsers like Chrome require explicit permission.
Transient Activation: (Firefox, Safari – BINGO!) This was our problem.

So, what exactly is transient activation? Imagine a quick window of opportunity after a user directly interacts with your page – a button click, a mouse movement, a menu selection. Certain features, like Element.requestFullscreen() and our problematic Clipboard.writeText(), are "gated" by this transient activation. They'll only work if executed within that brief window.

Every user agent has a property transient activation duration – a short, fixed period after a user interaction during which this "activation" is valid. In our case, Clipboard.writeText was being executed after a Promise resolved (the saveSetting call). Depending on network conditions, this delay could be anywhere from a hundred milliseconds to a few seconds - well past Safari's transient activation window it seems.

The Fix and the Takeaways

Honestly, this was a fundamental user agent limitation, and there was no clever code trick to bypass it. While navigation.userActivation.isActive() can tell you if transient activation is present, you can't update it.

Our most appropriate solution was to separate the "save" and "copy" actions. We implemented a separate "Copy Link" button that remained disabled while the save operation was in progress. Once the settings were saved, and the link was ready, the "Copy Link" button would become enabled again, allowing the user to explicitly click it to copy.

Nevertheless, this small bug provided some valuable lessons:

Cross-browser testing is non-negotiable. Never assume an API behaves identically across all browsers, even if you think you know it.
Robust E2E tests need broad coverage. We had Playwright tests, but they were only running against Chromium. A major miss!
Logging never hurts. Our detailed logs quickly pointed us to the correct error, even before I had to grab an iPhone.

Have you ever encountered a similar browser-specific gotcha? Share your war stories in the comments!

🧠 JS Pop Quiz: ⚡️Faster iterations

TusharShahi — Sat, 12 Apr 2025 18:53:50 +0000

Can you make a one-liner change to the below to ~100x its performance?

  const ans = hugeArray
    .filter((item) => item.isEven)
    .map((item) => calculateSumOfDigits(item.id))
    .some((item) => {
      return item > 20;
    });

If you have the answer feel free to skip the rest of the article. If not, then the below write-up might help you.

Array methods: declarative and descriptive

Array methods like Array.protoype.map(), Array.protoype.filter() were introduced more than 10 years back in JavaScript and have found great adoption. In this last decade, these friendly helpers have slowly and surely become integral to our JS codebases. Not just because they improve code readability, but also because they align with functional programming paradigm where the guideline is to be more declarative than iterative.

The above code can be easily written with a for loop. Some folks might even point out that a for loop would be more performant. But given how well code these methods have integrated into our daily life as JS developers, it would not be surprising to find. Even if not in practicality, it is crucial to know how the above is non-performant when compared to its alternative.

What's the problem?

Methods like Array.protoype.map(), Array.protoype.filter() etc. return new arrays without modifying the existing ones. That is one of the biggest advantages they come with. It seems clear that in the above code snippet, we are creating 2 intermediary arrays. Given we are working with a huge array (with 100000 elements), this might not be ideal. Why do something that's not needed? That is precisely why a simple for loop would be much more efficient above.

But is there a way we can still have declarative behavior, while not losing out on performance?

Using iterables

Converting the array to an iterator object and then iterating on it gives us a huge performance boost.

  const ans = hugeArray
    .values() 
    .filter((item) => item.isEven)
    .map((item) => calculateSumOfDigits(item.id))
    .some((item) => {
      return item > 20;
    });

Array.prototype.values() returns an iterator object that iterates the values of each item in the array.

So instead of calling array methods like Array.protoype.map() and Array.protoype.filter(), we will call Iterator.protoype.map() and Iterator.protoype.filter().

The biggest difference between Array.protoype.filter() and Iterator.protoype.filter() is that the latter does not create an array at all.

The difference is staggering both in terms of performance and memory usage. Below is a dry run for a 100000 records.

Without .values() it takes 4ms, and with .values() it takes just 0.06ms. The memory footprint is also lower since we are not creating new arrays. The gap widens even more when the array has even more elements.

The above Iterator methods are new addition to Javascript and are supported in recent versions of both Node and Browsers. For example, I ran the above on Node 22. This addition might also promote the adoption of generators.

Generator Usage

A Generator object (returned from generator functions) is just another type of iterator object. The key feature has always been the fact that the values yielded from a generator object are not evaluated until used. One of the major reasons for low adoption of generators was cited to be the lack of declarative helper methods like map(), filter() etc. Now, that these methods are available, it becomes easier to replace existing array implementations with generators. As seen above this reduces both an operations processing time and its memory footprint.

[Boost]

TusharShahi — Sat, 05 Apr 2025 06:18:46 +0000

TusharShahi

Apr 4 '25

Understanding CVE-2025-29927 - The Next.js Vulnerability

#webdev #programming #javascript #security

Comments

3 min read

Understanding CVE-2025-29927 - The Next.js Vulnerability

TusharShahi — Fri, 04 Apr 2025 19:01:29 +0000

I love working with Next.js and have used it in projects since version 10 came out. The release of middleware in version 12 was exciting as it moved the framework closer to a full-stack framework.

Recently, a vulnerability in the middleware layer took the world by storm. The issue existed for around 3 years, back until version 12 of Next.js. With this post, I aim to summarize the vulnerability.

The vulnerability - CVE-2025-29927

Internally, Next.js uses a function that determines whether the middleware function should be run. The code was such that if a specific header is passed in with the request, the middleware would be skipped and the request would directly hit the server.

The header's name was x-middleware-subrequest. The idea was to it as an internal header that would help identify if a middleware has been run before, and based on that prevent the triggering of infinite loops due to recursive requests.

This intentional implementation is a vulnerability specifically for apps where authentication logic relies solely on this middleware layer. Since, once a request gets past the middleware there is no further check.

Code breakdown

In the newer version of Next.js (before the vulnerability was fixed) the code looks like this:

While the complete implementation is not something I dived into: It seems like we are trying to limit the recursive depth of Next.js middleware invocation to 5. Once that happens, we will return with the response without running the rest of the logic.

It is even more apparent in one of the earlier versions. This is a code snippet from Dec 2021.

Here it seems we are simply skipping the middleware logic if the array of subrequests includes the middleware name. We execute the run function with the following parameters where the argument name corresponds to the middleware name.

The header

So, it seems given the right value of this header we can prevent the logic of middleware from running. In Next.js, middlewares are supposed to be named middleware.ts or middleware.js. Depending on the version of Next.js, they might be placed in different sub-folders but even then a middleware's path can be guessed. That is why this vulnerability is easier to take advantage of.

The header x-middleware-subrequest is supposed to be an internal header that is supposed to be set from the middleware and its value be modified at the middleware level itself. But by sending specific values in this header a middleware can be bypassed.

The exact value of this header is different for different versions of Next.js. For example:

For versions before 12.2: pages/_middleware or pages/dashboard/_middleware based on the route on which the middleware is placed.

For versions starting 12.2: middleware

For version starting 14: middleware:middleware:middleware:middleware:middleware

There are other nuances such as the existence of a src folder, but the overall gist is that the value can be guessed in a few attempts.

Learnings

There is a lot to learn from this whole incident. Below are some of the key learnings I will take with me:

Do not use Next.js middlewares as the sole method for protecting the App. Even Next.js recommends against it. They do suggest using the middleware for optimistic redirecting, for example: missing cookie.
Every security issue should be treated as P0. Next.js team was notified of this issue in Feb, but at the time it seemed to only exist in older versions and that is why it was not acted upon immediately. Later it turned out to be an issue in even the newer versions of Next.js which have middleware.
Auth is hard. For production-grade apps, it does not make sense to reinvent the wheel.
Never trust the client. Technically anyone can manipulate request headers, and they should not be critical to such important logic.

Bonus

For folks interested in watching a demo of the video. Please watch it here: https://youtu.be/5j8aJiKrbgU

Note: For folks interested in understanding the complete issue, please visit this blog from Rachid A. which serves as an inspiration for this one too.

The convenience of CSS's new @position-try

TusharShahi — Wed, 16 Oct 2024 13:32:30 +0000

CSS anchor positioning came out some time ago. If you, like me, do not like writing CSS, this new API would definitely improve things.

Anchor Positioning

The CSS Anchor Positioning API allows developers to easily position elements relative to others (known as anchors), without needing extra libraries or complex JavaScript. This feature is perfect for creating menus, tooltips, dialogs, and other layered interfaces.

With this API, you can ensure that an element's size/position adapts based on its anchor. This eliminates the need for manual adjustments and provides a smoother, more responsive experience when building dynamic, interactive layouts.

What is position-try?

Anchor CSS also came out with a new CSS at-rule called position-try. It allows you to define fallback positions for anchored elements when they don’t fit within the screen or container. If an element overflows, the browser automatically chooses the next alternative position, ensuring it stays fully visible and functional. The position-try-fallbacks property can be used to define multiple fallback positions for the browser to try. Earlier this would have been achieved by running a listener that checks after every viewport change if things are going.

This could prevent a lot of headaches while working with dropdowns, tooltips etc. as now we do not have to write custom logic to check for overflow conditions.

A demo

Here is a quick demo of the code I wrote using the above CSS properties:

The submenu in my horrible-looking nav bar changes its position based on the width of the view port.

The code is written in React. Earlier I would have had to use an effect to do this. In my effect, I would have checked if the submenu element is crossing the viewport's boundary. If yes, I would have triggered another re-render to update the styles of the submenu. Since useEffect runs after the paint, and we don't want the user to see the submenu in the wrong location, I would have had to use useLayoutEffect for this.

Now all I have to do is write a CSS like this:

.button-anchor {
  anchor-name: --anchorButton;
}

@position-try --bottom {
  position-area: bottom;
}

.menu-list {
  position-anchor: --anchorButton;
  border: 1px solid #000;
  font-family: sans-serif;
  width: 60px;
  font-size: 12px;
  display: flex;
  flex-direction: column;
  row-gap: 4px;
  padding: 8px;
  position: fixed;
  position-area: right span-y-end;
  position-try-fallbacks: --bottom;
}

@position-try - creates the rule called --bottom.
anchor-name - sets the button as an anchor element.
position-anchor - lets menu-list use --anchorButton as the anchor element.
position-try-fallbacks - helps list the multiple fallbacks to try. This means there can be more positions even if --bottom fails.

Summary

Anchor CSS has come and solved some very interesting use cases for a developer. In addition to the above, tethered positioning becomes very easy. Everything is purely on CSS, so performance is also great. Right now the browser support is not great, but I hope it sees more adoption soon.

UI Blocking behaviour: microtasks vs macrotasks

TusharShahi — Fri, 30 Aug 2024 14:48:53 +0000

Can you find the difference between the two code snippets below:

function handleClick1() {
     setTimeout(handleClick1, 0);
}

function handleClick2() {
     Promise.resolve().then(handleClick2);
}

If you are not able to identify the implications of choosing one over the other, then this blog post will teach you something new.

Background

setTimeout is for scheduling a callback after a certain amount of time. Promise.resolve().then will do the same thing effectively, but internally both are different. The latter returns a promise, that is already resolved. Calling then(callback) on that promise will schedule callback to be executed.

So both the above functions call themselves recursively with minimal delay. The difference is that callback from setTimeout is placed in macrotask queue and a callback from a promise.then() is placed in microtask queue. How the event loop treats items from these two queues is what makes the above 2 code snippets the difference.

Event loop treatment of microtask vs macrotask

All an event loop does is while there are tasks to perform, it performs them and then sleeps and waits for other tasks.

Macrotasks (or simply tasks) include functions responsible for work such as:

Parsing
Reacting to DOM,

among others...

After the execution of a task picked from the task queue, the event loop performs a microtask checkpoint. The algo for which is something like:

While microtask queue is not empty, pick the oldest task from microtask queue and execute it.

What this means is that if a microtask enqueues another microtask that task will be executed before the next macrotask. And since UI rendering is a macrotask, it will never be executed by the event loop.

Here is a demo for the above: JS Bin demo. An infinite animation is running. If we trigger handleClick1 then we add some processing to the main thread, but the animation still renders correctly. But if we trigger handleClick2 the animation stops.

I have added the variable totalCount, so we can break before the page crashes. But what is noticeable is that once the microTask loop is started, the UI becomes unresponsive for some time.. Because tasks like rendering, reacting to DOM etc. will only be executed after the microtask queue is empty.

This makes handleClick1 from the above code snippet a safer choice. Hope the blog helped explain one fundamental difference between microtasks and macrotasks.

TypeScript Tip #3: Folder-wise config

TusharShahi — Thu, 25 Apr 2024 06:05:59 +0000

The file tsconfig.json indicates that the project is using typescript. It specifies the different options required to compile the project.

There are situations when you are working on a huge project and migrating it from JavaScript to TypeScript. While new code is well-typed the older code is in a state where type-checking can not be as strict.

The need arises for different levels of type strictness in different sub-folders of the same project. This can be achieved using multiple config files.

Example: You do not allow the type any in your new subfolder. But the rest of your project being much legacy, still uses any here and there.

You can have "noImplicitAny": false in your main config file.

Inside the new subfolder, you can have another tsconfig.json file, which extends the main tsconfig.

{
  "extends": "../../../tsconfig.json",
  "compilerOptions": {
    "noImplicitAny": true
  },
  "include": ["*"]
}

This is a game changer for huge projects and allows for agile development.

TypeScript Tip #2: valueof

TusharShahi — Tue, 16 Apr 2024 13:35:13 +0000

While working on a TypeScript project, it is a common ask to restrict a type of variable to the value of the keys of an object.

Suppose we have an object like the below:

const statusMap = {
    pending : 'PENDING',
    finished : 'FINISHED',
    notStarted : 'NOT_STARTED'
};

When we want to have a related status variable, it can only have three values - PENDING, FINISHED and NOT_STARTED.

The way to go about it is usually by narrowing the type of our object first:

const statusMap = {
    pending : 'PENDING',
    finished : 'FINISHED',
    notStarted : 'NOT_STARTED'
} as const;

Using as const or const assertion,

we make statusMap read-only, eg: statusMap.pending cannot be modified.
no literal types are widened. eg: type PENDING does not become string

So given the above we usually end up creating a type like:

We use keyof and typeof provided by Typescript and Javascript respectively to help us make the suitable type.

This works well. But I would like to avoid writing the variable statusMap twice. Imagine us having multiple variables like that and our code starts looking like this:

It would be great if we could simplify it and reduce the duplication.
To do that it is easy to create a type like below:

type valueof<X> = X[keyof X];

We have created a generic called valueof. We extract the values of the keys of type X and use them to make a template literal type.

Now it works like the below and still works.

valueOf seems so convenient that I am surprised it is not available in TypeScript out-of-the-box. I hope you guys also find use of it.

TypeScript Tip #1: forEach vs for loop

TusharShahi — Sun, 14 Apr 2024 02:41:01 +0000

While working on a typescript project, it is recommended to enable noUncheckedIndexedAccess for safer object access.

The difference it makes can be summarised below:

const obj : Record<string,number[]> = {};

obj.nonExistentKey.push(2);

Without enabling the flag the above will not throw an error. Above is a trivial example but I hope it shows the importance of this flag.

Enabling this flag leads to another hurdle though:

The error says: Type 'undefined' is not assignable to type 'number'

arr[i] is inferred as undefined inside the for loop. Why though?

Because the length of the above array can be changed like this:

arr[15]=2;

Now, arr.length is 16. The array is sparse and has "holes" or "empty slots" in it. Accessing these elements will give undefined. Hence TypeScript complains.

So how to fix it?

We can use an array method like forEach. Looking at the documentation:

callbackFn is invoked only for array indexes which have assigned values. It is not invoked for empty slots in sparse arrays.

Here is the typescript playground for you to play around with.

Cost of unnecessary Optional Chaining (and Nullish coalescing operator)

TusharShahi — Sat, 06 Apr 2024 14:51:14 +0000

If you are a developer who has worked with JavaScript in recent years, I am sure you are well aware of the below syntax:

const a = obj1?.x; 
const b = obj2.c ?? '2'

We see them all around us, making our lives easier.

The first one is optional chaining and the other one is the nullish coalescing operator.

Both of them are so easy to use that they have a huge adoption in a lot of code bases. They help protect us from the embarrassing situation of our webapp breaking in production. But there is a cost to their overuse which will make one debate their pros and cons.

Background

As we can see from the docs, both are recent additions to the language. This means to get them to work on older browsers, they need polyfills.

We can open our dev tools and write something like window?.testing and it will not complain. But if we do the same on an older browser, it will throw us an error.

For our nice new syntax to work on old outdated browsers, it is converted into (probably) longer and more primitive code. This whole logic is what a polyfill is. It is a script that updates/adds new functions.

Babel

So, how is this working out in the case of our React apps. We never have to worry about writing some polyfill. The reason for that is Babel. Babel, a transpiler, converts modern JavaScipt code to make it easily understandable to most browsers. We get to decide the target browsers we plan on supporting and Babel does the conversion.

Your code might not use Babel but some other transpiler like SWC, but the funda is common. Convert new-fashioned code into code that most browsers can understand.

All this is part of the bundling process, with the final aim of converting our React code into a group of JS, CSS and HTML files.

Being extra cautious

Coming to the topic that encouraged me to write this blog. I was reviewing a code and saw something like below:

      if (cityName) {
        if (location === cityName)
          res.writeHead(301, {
            Location: `/somegibberish/${cityName?.toLowerCase()}/`,
          });
        else
          res.writeHead(301, {
            Location: `/somegibberish/${cityName?.toLowerCase()}/${localitySlug}`,
          });
      }

I pointed out the problem: cityName is checked once at the top level, and inside the if branch, optional chaining is used to check the (somewhat) same thing.

The response: Although unnecessary, there is no harm in doing that.

The first harm I could see was in setting the wrong expectations. If the above code block became much larger with multiple contexts like function calls, it would be hard to track whether cityName can be falsy. (This is a problem, more specific to JS-only code bases)

The second is something I found out only when looking at the bundle output.

Transpiling

The code written above will not go as it is into our bundle. As already established, it will get converted into old-school JS so we can target as many browsers (in turn as many users) as possible.

Here is the screenshot of what optional chaining and nullish coalescing operator code gets converted into.

Let us pick any one of them.

Nullish Coalescing Operator: a logical operator that returns its right-hand side operand when its left-hand side operand is null or undefined, and otherwise returns its left-hand side operand.

Something like x ?? '2' gets converted into x !== null && x !== void 0 ? x : '2'.

void 0 is not something you see every day. It is the old way of writing undefined. It is favored over directly writing undefined for 2 reasons:

In older JS specifications, undefined was not a reserved word. One could literally do var undefined = 'defined'. (This is no longer a problem)
undefined takes more bits than void 0. Which definitely is a good enough reason to use it, when our bundle will be filled with it.

Cost to the bundle

Here is how the above code snippet, sat in our code bundle:

The above gives a sense of the problem with using optional chaining and NCO (in short :P) blindly, even more so in situations where they are not required. The bundle size can increase massively, even after modification.

I would still use the above two features, but I strongly advise not to use them unnecessarily now that I have seen the bundle output.

Bonus: Here is an es-lint rule that might help: no-unnecessary-condition in pruning out all those unnecessary checks.