DEV Community: Shibly Noman

Implementation Mistakes by Devs: How you should not use useEffect

Shibly Noman — Thu, 08 Jan 2026 06:35:16 +0000

The straightforward answer to the question is, We often find ourselves writing brute force code. Sometimes we are tempted to copy codes without understanding the fundamentals.

I think, instead of asking “Why we should not….” it is more proper to ask “How we should not…” or “Where we should not….”

What is an Effect?

React documentation literature says, Effects are an escape hatch from the React paradigm. Well, what do they mean by that? Effects in React let you connect your components with things outside React. Like non-React widgets or the browser. Generally we use useEffect either for transforming data for rendering or handling user events.

We don’t have non-React widgets on the server. And that's why we don’t have useEffect in the server component. Does that ring a bell?

If you're just updating a component based on its own state or props, you don't need an Effect. useEffect introduces additional computations and overhead to your component lifecycle. Interesting thing is, useEffect is not inherently slower. Improper usage of useEffect can potentially introduce performance issues.

And as the rule of state- management-101, “Do not replicate!”

So let's have some implementation details where we can avoid useEffect.

Updating state based on props or state:

When something can be calculated from the existing props or state, don’t put it in state. Instead, calculate it during rendering.

function Form() {
 const [firstName, setFirstName] = useState('Taylor');
 const [lastName, setLastName] = useState('Swift');

 // 🔴 Avoid: redundant state and unnecessary Effect
 const [fullName, setFullName] = useState('');
 useEffect(() => {
   setFullName(firstName + ' ' + lastName);
 }, [firstName, lastName]);
 // ...
}

This is more complicated than necessary. It is inefficient too: it does an entire render pass with a stale value for fullName, then immediately re-renders with the updated value. Instead this can be done,

// ✅ this is calculated during rendering
 const fullName = firstName + ' ' + lastName;

Or we can give the values to the dom

// ✅ Will re-render
 <>{firstName} {lastName}</>

Child component always re-renders if the prop value is changed. So what if we have to reset all component states depending on prop value, how do we do that?

For example we want to clear out the comment state variable (or refetch from state) whenever the userId changes:

export default function ProfilePage({ userId }) {
 const [comment, setComment] = useState('');

 // 🔴 Avoid: Resetting state on prop change in an Effect
 useEffect(() => {
   setComment(''); // or have a selector
 }, [userId]);
 // ...
}

Instead of doing this, we can split the component and pass a unique key prop to the Profile component,

export default function ProfilePage({ userId }) {
 return (
   <Profile
     userId={userId}
     key={userId}
   />
 );
}

function Profile({ userId }) {
 // ✅ This and any other state below will reset on key change automatically
 const [comment, setComment] = useState('');
 // ...
}

Again, why do this? Because by passing userId as a key to the Profile component, you’re asking React to treat two Profile components with different userId as two different components that should not share any state. Whenever the key (which you’ve set to userId) changes, React will recreate the DOM and reset the state of the Profile component and all of its children. Now the comment field will clear out automatically when navigating between profiles.

What if we want to adjust some of the state depending on props value but not all of it.
For example we might tempted to do this,

function List({ items }) {
 const [isReverse, setIsReverse] = useState(false);
 const [selection, setSelection] = useState(null);

 // 🔴 Avoid: Adjusting state on prop change in an Effect
 useEffect(() => {
   setSelection(null);
 }, [items]);
 // ...
}

Again, this is not ideal. Every time the items change, the List and its child components will render with a stale selection value at first.

Instead we can do this,

function List({ items }) {
 const [isReverse, setIsReverse] = useState(false);
 const [selection, setSelection] = useState(null);

 // Better: Adjust the state while rendering
 const [prevItems, setPrevItems] = useState(items);
 if (items !== prevItems) {
   setPrevItems(items);
   setSelection(null);
 }
 // ...
}

Storing information from previous renders like this can be hard to understand, but it’s better than updating the same state in an Effect. Although this pattern is more efficient than an Effect, most components shouldn’t need it either. It’s better to check whether we can reset all states with a key or calculate everything during rendering instead.

function List({ items }) {
 const [isReverse, setIsReverse] = useState(false);
 const [selectedId, setSelectedId] = useState(null);
 // ✅ Best: Calculate everything during rendering
 const selection = items.find(item => item.id === selectedId) ?? null;
 // ...
}

Sharing logic between event handlers:
Let’s say you have a product page with two buttons (Buy and Checkout) that both let you buy that product. You want to show a notification whenever the user puts the product in the cart. Calling showNotification() in both buttons’ click handlers feels repetitive so you might be tempted to place this logic in an Effect:

function ProductPage({ product, addToCart }) {
 // 🔴 Avoid: Event-specific logic inside an Effect
 useEffect(() => {
   if (product.isInCart) {
     showNotification(`Added ${product.name} to the shopping cart!`);
   }
 }, [product]);

 function handleBuyClick() {
   addToCart(product);
 }

 function handleCheckoutClick() {
   addToCart(product);
   navigateTo('/checkout');
 }
 // ...
}

This Effect is unnecessary. It will also most likely cause bugs. For example, let’s say that your app “remembers” the shopping cart between the page reloads. If you add a product to the cart once and refresh the page, the notification will appear again.
Better we can write event specific methods

function ProductPage({ product, addToCart }) {
 // ✅ Good: Event-specific logic is called from event handlers
 function buyProduct() {
   addToCart(product);
   showNotification(`Added ${product.name} to the shopping cart!`);
 }

 function handleBuyClick() {
   buyProduct();
 }

 function handleCheckoutClick() {
   buyProduct();
   navigateTo('/checkout');
 }
 // ...
}

This both removes the unnecessary Effect and fixes the bug.

Chains of computations

This is one of the most common mistakes we make. Sometimes there can be a case where we need to change one state depending on the other state in the component.

function Game() {
 const [card, setCard] = useState(null);
 const [goldCardCount, setGoldCardCount] = useState(0);
 const [round, setRound] = useState(1);
 const [isGameOver, setIsGameOver] = useState(false);

 // 🔴 Avoid: Chains of Effects that adjust the state solely to trigger each other
 useEffect(() => {
   if (card !== null && card.gold) {
     setGoldCardCount(c => c + 1);
   }
 }, [card]);

 useEffect(() => {
   if (goldCardCount > 3) {
     setRound(r => r + 1)
     setGoldCardCount(0);
   }
 }, [goldCardCount]);

 useEffect(() => {
   if (round > 5) {
     setIsGameOver(true);
   }
 }, [round]);

 useEffect(() => {
   alert('Good game!');
 }, [isGameOver]);

 function handlePlaceCard(nextCard) {
   if (isGameOver) {
     throw Error('Game already ended.');
   } else {
     setCard(nextCard);
   }
 }

the component (and its children) have to re-render between each set call in the chain. In the example above, in the worst case (setCard → render → setGoldCardCount → render → setRound → render → setIsGameOver → render) there are three unnecessary re-renders of the tree below.
Even if performance is not the case, as our code evolves, it gets harder and harder to maintain and add new requirements to the code.

function Game() {
 const [card, setCard] = useState(null);
 const [goldCardCount, setGoldCardCount] = useState(0);
 const [round, setRound] = useState(1);

 // ✅ Calculate what you can during rendering
 const isGameOver = round > 5;

 function handlePlaceCard(nextCard) {
   if (isGameOver) {
     throw Error('Game already ended.');
   }

   // ✅ Calculate all the next state in the event handler
   setCard(nextCard);
   if (nextCard.gold) {
     if (goldCardCount <= 3) {
       setGoldCardCount(goldCardCount + 1);
     } else {
       setGoldCardCount(0);
       setRound(round + 1);
       if (round === 5) {
         alert('Good game!');
       }
     }
   }
 }

 // ...

Caching expensive calculations:

They are recommending to use useMemo instead of useEffect. But from React 19, they do not suggest useMemo anymore. Not sure how to solve it another way. No worries, we will see (If you know, please share).

Notifying parent components about state changes or passing data to the parent:
Passing data to higher order components is the root of all EVIL. So let’s not think about ‘passing data to the parent’ at all. For your own sake use state management libraries.

Footnote:

So the elephant in the room, Why follow these approaches?

In my opinion all the actions, interactions, dependencies, lifecycle, and all possible approaches to solve a particular problem, breaks down to one or another data structure.

So why is it that some of the data structure is faster and some are slower, why is that?

Honestly. I don’t know.

There is something called time space trade off. This problem is as old as computer engineering itself. This is something all programmers have to deal with. So it is important to follow standard norms by understanding the underlying mechanism of our code.

But we are talking about useEffect here, Aren’t we? We do not think about memories while writing. We don’t manage garbage values, and don't have to think about abstract stuff. React does all the heavy lifting.

But do you know, React does not even understand “jsx”? 🙂

MongoBleed: A Heartbleed-Class Memory Disclosure in MongoDB

Shibly Noman — Tue, 30 Dec 2025 07:32:08 +0000

MongoBleed is a recently disclosed pre-authentication memory disclosure vulnerability in MongoDB Server, formally tracked as CVE-2025-14847. The flaw resides in the zlib-based network message compression logic, where incorrect handling of client-supplied length metadata can cause the server to return uninitialized heap memory to remote attackers without requiring authentication. This class of defect has been widely compared to the infamous Heartbleed memory leak in OpenSSL- therefore the name "MongoBleed" - because both arise from a mistrust of length/size metadata that leads to silent memory exposure.

Background: MongoDB Wire Protocol and Compression:

Modern MongoDB servers communicate with clients using the OP_MSG wire protocol. To reduce bandwidth and latency, MongoDB supports optional message compression using algorithms such as zlib, snappy, zstd.

MongoDB network flow (simplified):

The bug occurs before authentication, specifically inside message decompression & buffer handling.

The Core Bug: Length Trust Violation:

The vulnerability stems from improper length validation within the MongoDB OP_COMPRESSED handler. When a client sends a compressed message, the server trusts the user-provided uncompressed_size value and uses it to allocate a memory buffer on the heap.

The exploit occurs when an attacker specifies an uncompressed_size that is intentionally much larger than the actual decompressed data. While the decompression process fills the start of the buffer, the remaining "slack space" is left untouched and uninitialized. Because this memory is not zeroed out, it still contains "stale" data from previous heap allocations such as session tokens, credentials, or TLS keys. When the server reflects the full buffer back to the client, it inadvertently leaks this sensitive internal memory.

Step-by-Step Memory Timeline

Step 1: Malicious packet arrives

Attacker sends

Compressed Payload:
- Declared uncompressed size: 64 KB
- Real decompressed size: 120 bytes

Step 2: Server allocates heap memory

char* buf = malloc(65536); // based on uncompressed_size
// ** malloc does NOT zero memory

Heap may contain

[ valid data | leftover heap | sensitive fragments ]

Step 3: Decompression happens

actual_len = inflate(zlib_stream, buf);

Result:

buf[0..119]     → valid decompressed data
buf[120..65535] → untouched memory

Step 4: Fatal mistake wrong length used (This is the bug)

Instead of sending:

send(socket, buf, actual_len);

The server sends:

send(socket, buf, declared_uncompressed_size);

The attacker receives raw heap memory returned by the system, which may include data from other users’ queries, credentials still resident in memory, internal data structures, and occasionally readable secrets that were never intended to be exposed.

Understanding BSON in the Context

When a compressed OP_MSG is received, MongoDB first parses the compression header, then invokes the zlib inflate algorithm to expand the payload into a heap buffer sized according to the client-supplied uncompressed length. The BSON parser is subsequently invoked on this buffer and relies on BSON’s self-describing structure to traverse the data. If zlib inflation produces fewer bytes than the declared size, the remaining portion of the buffer contains uninitialized heap memory. Because the parser and subsequent response handling operate on the full allocated buffer rather than the actual number of bytes produced by zlib, adjacent heap data from prior requests may be inadvertently exposed.

Why This Is Pre-Authentication

This vulnerability manifests before authentication because MongoDB must process and decompress incoming network messages prior to understanding their semantic intent. Compression handling occurs ahead of message parsing, meaning the server is required to decompress the payload in order to determine what command the client is attempting to execute, including authentication commands themselves. As a result, the decompression logic is invoked without any prior trust boundary enforcement. Compounding this issue, authentication credentials and related security material may already be present in heap memory from previous connections or internal operations, making them susceptible to exposure when uninitialized heap buffers are inadvertently returned to the client.

Why the Server Does Not Crash

MongoBleed does not cause the server to crash because it is not a memory corruption vulnerability, but rather a buffer over-read. Unlike buffer overflows, use-after-free conditions, or double-free bugs, which typically result in process termination or exploitable control-flow corruption, this flaw merely causes the server to read and transmit memory that it should not. Since the accessed memory is still valid heap space and no illegal writes occur, MongoDB continues operating normally. This silent failure mode allows the server to leak sensitive data without triggering crashes, alerts, or obvious instability, significantly complicating detection and incident response.

Affected Versions

Version	Affected Range	Fixed Version
8.2.x	8.2.0–8.2.2	8.2.3
8.0.x	8.0.0–8.0.16	8.0.17
7.0.x	7.0.0–7.0.27	7.0.28
6.0.x	6.0.0–6.0.26	6.0.27
5.0.x	5.0.0–5.0.31	5.0.32

Recommended Actions for Security Teams

Upgrade immediately to a patched MongoDB version: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30
If patching is not possible, disable zlib compression and use snappy, zstd, or disable compression entirely
Restrict network exposure by removing MongoDB from the public internet and enforcing firewall or private network access
Monitor MongoDB logs for anomalous pre-authentication behavior or suspicious connection patterns

How a Serialization Flaw in React 19 Server Components Led to Remote Code Execution

Shibly Noman — Wed, 24 Dec 2025 06:12:43 +0000

A critical security incident in early December 2025 drew widespread attention when the React ecosystem was found to contain a maximum-severity remote code execution vulnerability, tracked as CVE-2025-55182 and colloquially dubbed “React2Shell.” This flaw, which affects React Server Components (RSC) and frameworks built on top of them, could allow an unauthenticated attacker to execute arbitrary code on vulnerable servers with a single crafted HTTP request.

What Was the Vulnerability?

To understand the vulnerability, it is necessary to first examine how React 19 Server Components exchange data between the server and the client.

React Server Components do not transmit plain JSON. Instead, they rely on a specialized serialization format known as the Flight protocol, which is capable of encoding complex JavaScript constructs such as references, deferred values, and asynchronous boundaries. Within this protocol, a serialized payload can represent unresolved asynchronous data effectively indicating that a particular value is a Promise whose resolution will be provided at a later stage.

This bidirectional communication model allows the client to send references back to the server to complete the rendering process. While this design enables efficient streaming and incremental rendering, it also introduces significant complexity and expands the attack surface.

At the core of the vulnerability is the server-side logic responsible for parsing and reconstructing these serialized values. Specifically, the method responsible for parsing model strings within React Server Components defines how incoming Flight payloads are deserialized into executable JavaScript structures on the server. Insufficient validation during this reconstruction process ultimately enabled the exploitation of the serialization pipeline.

function parseModelString(
    response: Response,
    obj: Object,
    key: string,
    value: string,
    reference: void | string,
) : any {
    switch (value[1]) {
        ...
            case 'B': {
                // Blob
                const id = parseInt(value.slice(2), 16);
                const prefix = response._prefix;
                const blobKey = prefix + id;
                // We should have this backingEntry in the store already because we emitted
                // it before referencing it. It should be a Blob.
                const backingEntry: Blob = (response._formData.get(blobKey): any);
                return backingEntry;
            }
    }
}

How the Serialization Vulnerability Works

The vulnerability stems from how React Server Components reconstruct complex JavaScript objects from serialized Flight payloads. During deserialization, the server failed to enforce strict validation on property access paths, allowing crafted payloads to reference inherited and magic properties such as constructor, __proto__, or prototype. By injecting a malicious then property, an attacker could create a thenable object, which the JavaScript runtime automatically attempts to resolve as a Promise. Through chained references (for example, resolving then via the prototype chain), the deserialization logic could be coerced into invoking the JavaScript Function constructor, resulting in arbitrary code execution. This exploit was possible because the server implicitly trusted the payload structure and did not differentiate between own properties and inherited properties during model reconstruction.

Example of a Crafted Flight Payload (Simplified):

const _payload = {
...
    1 : {
        status: “resolve_model”,
        reason: 0,
        _response: {
            _prefix: “console.log('Hello World!')”,
            _fromData: {
                 get: “$1: then:constructor”,
                }
        },
        then: “$1:then”,
        value:’{”then”: “$B”}’
    },
    2: “$@1”
};

Why this works (at a high level):

The payload introduces a fake then property, making the object appear promise-like.
The de-serializer resolves references without restricting prototype traversal.
Reference chaining allows access to inherited constructors.
Implicit Promise resolution triggers execution during model reconstruction.

Mitigation & Fix Overview

Following the disclosure of CVE-2025-55182, the React core team, in coordination with platform and infrastructure providers, implemented a series of layered mitigations to neutralize the immediate exploitation vector and to strengthen the overall security posture of React Server Components.

These remediation efforts focus on robust deserialization safeguards, reduced protocol expressiveness, and the removal of implicit execution semantics that previously enabled unsafe behavior.

The key mitigation measures include:

Strict Property Validation During Deserialization

Enforcement of explicit property allow-lists and ownership checks to prevent access to inherited or magic properties during model reconstruction.
Prototype-less Object Reconstruction

Use of objects without prototype chains to eliminate unintended access to JavaScript runtime primitives and inherited behavior.
Explicit Promise Handling (Elimination of Implicit Thenables)

Removal of reliance on JavaScript’s automatic thenable resolution in favor of explicit and controlled async handling.
Constrained Flight Protocol Grammar

Reduction of permissible reference paths, indirection depth, and token combinations to limit the protocol’s attack surface.
Defense-in-Depth Runtime Guards

Introduction of runtime assertions, depth limits, and fail-fast mechanisms to prevent unsafe execution even in the presence of malformed payloads.

Collectively, these measures eliminate the known remote code execution vector and significantly raise the barrier for similar classes of deserialization-based vulnerabilities in future releases.

Guidance for Application Developers

While the vulnerability was in React itself, developers should still adopt the following best practices:

Keep React and framework dependencies fully up to date
Avoid exposing Server Component endpoints to untrusted clients
Apply authentication and CSRF protections to RSC routes
Monitor for abnormal payload sizes or resolution patterns
Treat framework serialization as untrusted input