DEV Community: Ayo Ashiru

Serialization and Deserialization

Ayo Ashiru — Mon, 26 Jan 2026 15:08:07 +0000

In the world of modern software development especially when building distributed systems like microservices or web applications, data is constantly on the move. However, your application's in-memory data (like a complex JavaScript object or a Python dictionary) cannot simply "fly" over the network.
To bridge this gap, we use Serialization and Deserialization.

What are they?

Think of serialization as packing a suitcase for a trip, and deserialization as unpacking it once you arrive at your destination.

Serialization: The process of converting a complex data object (held in your computer's RAM) into a "transportable" format, such as JSON, XML, Binary formats

Example
In-memory object (JavaScript / Python-like):

const user = { name: "Alex", age: 21 };

Serialized to JSON:

{"name":"Alex","age":21}

Once serialized, this data can be:

Sent over HTTP
Stored in a database
Published to a message queue (Kafka, RabbitMQ)
Written to a file
Deserialization:
Deserialization is the reverse process.
It converts serialized data (JSON, XML, binary) back into an in-memory object that a program can work with.

Example
Incoming JSON:

{"name":"Alex","age":21}

Deserialized in JavaScript:

const user = JSON.parse(jsonString);

user.name; // "Alex"
user.age;  // 21

Now the backend can validate, process, or store the data.

Why Are Serialization and Deserialization Necessary?

They exist because different systems:

Don’t share memory
Use different programming languages
Have different object representations
Serialization creates a common language between systems.

Without it:

APIs couldn’t exist
Microservices couldn’t communicate
Databases couldn’t store complex objects
Distributed systems would break

Serialization in API Communication

A typical API request/response cycle looks like this:

Client
Serializes data (e.g. JSON)
Sends it over HTTP
Server
Deserializes the request
Processes the data
Serializes the response
Client
Deserializes the response
Displays or uses the data

Example: Login Request

Client serializes login credentials to JSON
Server deserializes JSON into a LoginRequest object
Server validates credentials
Server serializes response (success, token)
Client deserializes response

Serialization in Node.js

Serialization (Object → String)

const user = { name: "Muhammed Ali", role: "Developer" };

// Converting the object to a JSON string
const serializedUser = JSON.stringify(user); 

console.log(serializedUser); // '{"name":"Muhammed Ali","role":"Developer"}'

Deserialization (String → Object)

const incomingData = '{"name":"Muhammed Ali","role":"Developer"}';

// Reconstructing the object
const userObject = JSON.parse(incomingData);

console.log(userObject.name); // Muhammed Ali

Best Practices:

Serialization

Prefer standard formats (JSON, Protobuf)
Serialize only what you need
Version your schemas
Avoid circular references

Deserialization

Never trust incoming data
Validate and sanitize inputs
Handle errors gracefully
Beware of insecure deserialization vulnerabilities

Summary
Serialization and deserialization are the "bridges" that allow data to flow between different languages, servers, and storage systems. By choosing the right format—JSON for ease of use or Binary for high performance—you ensure your application stays fast, scalable, and compatible with the rest of the tech world.

Understanding HTTP: The Backbone of Today’s Internet

Ayo Ashiru — Tue, 25 Nov 2025 14:40:01 +0000

If you’ve ever built anything for the web either frontend, backend, APIs, mobile apps or even blockchain dApps, you’ve already interacted with HTTP. It’s the invisible glue that allows devices to talk to each other over the internet.

This is my first article in a while and I’m excited to get back to writing again. Work and projects kept me away for a bit but I’m restarting with one of the most fundamental topics in backend development

In this article, we’ll break down what HTTP really is, how it works, why it’s stateless and how its versions evolved from HTTP/0.9 all the way to HTTP/3.

What is HTTP?

HTTP (HyperText Transfer Protocol) is a communication protocol used for transferring data between a client (usually the browser) and a server.

Every time you open a website, submit a form, fetch API data or load images, HTTP is working behind the scenes.

Why is HTTP Important in Today’s Internet?

The modern web relies heavily on HTTP for:

Web pages (HTML, CSS, JS)
REST APIs
GraphQL APIs
Mobile app → server communication
Blockchain explorers and RPC endpoints
IoT device communication HTTP powers nearly everything connected to the internet.

The Client–Server Model

HTTP follows the client–server architecture, which simply means:

Client → Makes requests
Server → Sends responses

Examples:

Browser requesting the LinkedIn homepage
Postman making an API call
Your React frontend hitting a Node.js backend

Example HTTP request format

GET /api/users HTTP/1.1
Host: example.com
Accept: application/json

This simple structure defines:

The method (GET)
The path (/api/users)
The protocol version (HTTP/1.1)
Additional metadata (Accept, Host, etc.)

HTTP is Stateless — What Does That Mean?

HTTP does not remember anything between two requests i.e every request stands alone.
This means if you send 10 HTTP requests, the server processes them as if you’re a new user each time.

Example:
If you send 10 requests, the server treats them as if it’s meeting you for the first time every time.

Why is this useful?

Scalability
Simplicity
No need for the server to store user state The Problem Websites need to remember users (authentication, shopping carts, sessions).

How the Web Solves This

Cookies
Sessions
JWT tokens
LocalStorage These tools add state on top of a stateless protocol.

Alternatives to HTTP

Although HTTP dominates the web, other communication protocols exist:

WebSockets
Full-duplex communication (both sides can send data anytime).
Used for chats, real-time dashboards, crypto price tickers.
gRPC
High-performance protocol built on HTTP/2.
Used in microservices and backend-to-backend communication.
MQTT
Lightweight protocol for IoT devices.
FTP / SFTP
Designed for file transfer.
But for most web apps, browsers and APIs, HTTP remains the king.

Evolution of HTTP(From 0.9 → 3.0)

HTTP/0.9 — The Beginning (1991)

Only supported GET
Only transferred raw HTML
No headers, no status codes Super basic, but it started the web revolution.

HTTP/1.0 — More Capabilities (1996)

Added headers
Added status codes
Introduced new methods (POST, HEAD) But… connections closed after each request (slow!)

HTTP/1.1 — The Workhorse (1997)

Persistent connections (keep-alive)
Pipelining (send multiple requests)
Better caching
Chunked responses Most websites still rely on it today.

HTTP/2 — Faster and More Efficient (2015)

Binary protocol (not text-based)
Multiplexing: multiple requests over same connection
Header compression
Server push Great for modern APIs and performance-heavy apps.

HTTP/3 — The Future (2020+)

Reduced latency
Handles poor network conditions better
Faster page loads
Built for mobile and global traffic Most modern browsers & CDNs already support HTTP/3.

Conclusion

HTTP is one of the most fundamental technologies powering the internet.
Whether you're building frontend interfaces, backend APIs, mobile apps, cloud services or even blockchain-based systems, you are relying on HTTP every single day.

Understanding how HTTP works, why it’s stateless and how it evolved gives you a strong foundation as a backend or full-stack engineer.

Follow for for more

The delegatecall Function in Solidity

Ayo Ashiru — Mon, 18 Nov 2024 11:00:08 +0000

The delegatecall method is a powerful low-level function that enables one contract (the "Caller") to execute code in another contract (the "Callee") while preserving the storage and context of the Caller. Unlike the call method, which executes code in a different contract but does not retain the Caller’s state, delegatecall maintains the context of the Caller’s storage, allowing for more flexible contract design. However, as with any low-level operation, improper use of delegatecall can introduce significant security risks. For a deeper understanding of the call method, be sure to check out my previous article, The call Function in Solidity.

What is delegatecall?

The delegatecall function in Solidity enables a contract to call another contract’s function but retain its own storage, sender, and msg.value. This is useful when you want to separate logic from storage, allowing the Caller to use the Callee’s logic while maintaining its own state.

Common Use Cases:

Upgradeable Contracts: The Proxy pattern uses delegatecall to upgrade contract logic without affecting stored data.
Modular Contracts: Break down complex functionality into separate contracts to improve code reusability and maintainability.

Basic Example of delegatecall

In this example, the Caller contract calls setNum in the Callee contract to set a number. The state change happens in the Caller’s storage rather than the Callee’s.

Callee Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Callee {
    uint public num;

    function setNum(uint _num) public {
        num = _num;
    }
}

Caller Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Caller {
    uint public num;
    address public calleeAddress;

    uint public num; // State variable that MUST be in storage slot 0 to matche the storage layout of the Callee contract

    function setCalleeAddress(address _calleeAddress) public {
        calleeAddress = _calleeAddress;
    }

        /**
     * @dev Calls the setNum function of the Callee contract using delegatecall.
     * The logic of the Callee's setNum function is executed in the context of the Caller contract.
     * This updates the `num` variable in the Caller contract's storage, NOT the Callee's.
     * 
     * NOTE: The `num` variable in both the Caller and Callee contracts MUST occupy the same storage slot.
     * In this case, `num` is the first declared state variable in both contracts, which means it is in slot 0.
     * 
     * @param _num The value to set the Caller contract's `num` variable to.
     */
    function delegateSetNum(uint _num) public {
        (bool success, ) = calleeAddress.delegatecall(
            abi.encodeWithSignature("setNum(uint256)", _num)
        );
        require(success, "delegatecall failed");
    }
}

Explanation:

The setCalleeAddress function stores the address of the Callee contract.
delegateSetNum uses delegatecall to execute setNum in Callee, but any state changes are applied in Caller’s storage.

Risks and Best Practices of Using `delegatecall`

While delegatecall is powerful, improper use can introduce serious security risks. Here’s what to consider:

Storage Layout Consistency
- The storage layout between the Caller and Callee must match exactly. Any mismatch can cause unexpected behavior and data corruption.
Reentrancy Attacks
- Using delegatecall with untrusted contracts can expose vulnerabilities, such as reentrancy attacks. Apply the checks-effects-interactions pattern to minimize risk.
Avoid Unauthorized Access
- Ensure delegatecall does not inadvertently expose sensitive functions. Use access control to limit function calls as needed.

Example of a Security Vulnerability

In the following example, HackMe calls Lib's pwn function with delegatecall, allowing anyone to take over the HackMe contract by changing the owner.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Lib {
    address public owner;

    function pwn() public {
        owner = msg.sender;
    }
}

contract HackMe {
    address public owner;
    Lib public lib;

    constructor(Lib _lib) {
        owner = msg.sender;
        lib = Lib(_lib);
    }

    // Delegate all external calls to Lib contract, including unauthorized access to pwn
    fallback() external payable {
        address(lib).delegatecall(msg.data);
    }
}

Explanation:

Anyone calling pwn can change the owner of HackMe because HackMe uses Lib’s storage layout, unintentionally exposing its owner variable.

Practical Tips for Using `delegatecall` Safely

To maximize the benefits of delegatecall while minimizing risks, follow these tips:

Check Storage Compatibility: Ensure that the Caller and Callee contracts have matching storage layouts to avoid corruption.
Validate delegatecall Targets: Only use trusted contracts as targets for delegatecall.
Use Access Control: Restrict access to functions that use delegatecall to avoid unauthorized actions.

Conclusion

The delegatecall function in Solidity provides flexibility for modular and upgradeable smart contracts. However, due to its powerful nature, it’s essential to use delegatecall with caution, carefully managing storage layouts and implementing security checks. Proper use of delegatecall can open up many possibilities for flexible contract development, but with poor implementation, it can introduce serious vulnerabilities.

The delegatecall Function in Solidity

Ayo Ashiru — Mon, 18 Nov 2024 11:00:08 +0000

What is delegatecall?

Common Use Cases:

Upgradeable Contracts: The Proxy pattern uses delegatecall to upgrade contract logic without affecting stored data.
Modular Contracts: Break down complex functionality into separate contracts to improve code reusability and maintainability.

Basic Example of delegatecall

In this example, the Caller contract calls setNum in the Callee contract to set a number. The state change happens in the Caller’s storage rather than the Callee’s.

Callee Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Callee {
    uint public num;

    function setNum(uint _num) public {
        num = _num;
    }
}

Caller Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Caller {
    uint public num;
    address public calleeAddress;

    uint public num; // State variable that MUST be in storage slot 0 to matche the storage layout of the Callee contract

    function setCalleeAddress(address _calleeAddress) public {
        calleeAddress = _calleeAddress;
    }

        /**
     * @dev Calls the setNum function of the Callee contract using delegatecall.
     * The logic of the Callee's setNum function is executed in the context of the Caller contract.
     * This updates the `num` variable in the Caller contract's storage, NOT the Callee's.
     * 
     * NOTE: The `num` variable in both the Caller and Callee contracts MUST occupy the same storage slot.
     * In this case, `num` is the first declared state variable in both contracts, which means it is in slot 0.
     * 
     * @param _num The value to set the Caller contract's `num` variable to.
     */
    function delegateSetNum(uint _num) public {
        (bool success, ) = calleeAddress.delegatecall(
            abi.encodeWithSignature("setNum(uint256)", _num)
        );
        require(success, "delegatecall failed");
    }
}

Explanation:

The setCalleeAddress function stores the address of the Callee contract.
delegateSetNum uses delegatecall to execute setNum in Callee, but any state changes are applied in Caller’s storage.

Risks and Best Practices of Using `delegatecall`

While delegatecall is powerful, improper use can introduce serious security risks. Here’s what to consider:

Storage Layout Consistency
- The storage layout between the Caller and Callee must match exactly. Any mismatch can cause unexpected behavior and data corruption.
Reentrancy Attacks
- Using delegatecall with untrusted contracts can expose vulnerabilities, such as reentrancy attacks. Apply the checks-effects-interactions pattern to minimize risk.
Avoid Unauthorized Access
- Ensure delegatecall does not inadvertently expose sensitive functions. Use access control to limit function calls as needed.

Example of a Security Vulnerability

In the following example, HackMe calls Lib's pwn function with delegatecall, allowing anyone to take over the HackMe contract by changing the owner.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Lib {
    address public owner;

    function pwn() public {
        owner = msg.sender;
    }
}

contract HackMe {
    address public owner;
    Lib public lib;

    constructor(Lib _lib) {
        owner = msg.sender;
        lib = Lib(_lib);
    }

    // Delegate all external calls to Lib contract, including unauthorized access to pwn
    fallback() external payable {
        address(lib).delegatecall(msg.data);
    }
}

Explanation:

Anyone calling pwn can change the owner of HackMe because HackMe uses Lib’s storage layout, unintentionally exposing its owner variable.

Practical Tips for Using `delegatecall` Safely

To maximize the benefits of delegatecall while minimizing risks, follow these tips:

Check Storage Compatibility: Ensure that the Caller and Callee contracts have matching storage layouts to avoid corruption.
Validate delegatecall Targets: Only use trusted contracts as targets for delegatecall.
Use Access Control: Restrict access to functions that use delegatecall to avoid unauthorized actions.

Conclusion

The call Function in Solidity

Ayo Ashiru — Mon, 11 Nov 2024 10:57:49 +0000

In Solidity, function calls are the main way contracts communicate with each other. While high-level calls (like directly calling a function on a contract) are generally safer, sometimes low-level calls are necessary to have more control or interact with unknown contract interfaces. This article will provide a detailed, beginner-friendly look at one such low-level function: call.

What is `call` in Solidity?

The call function in Solidity is a low-level function that allows you to interact with other contracts and addresses. Unlike high-level function calls, call provides no type safety, lacks automatic revert handling, and requires more care in usage. Despite these challenges, call is powerful because it can be used even if you don’t have the ABI of the other contract. It’s commonly used to:

Send Ether to a contract or address.
Call functions that may or may not exist on the target contract.
Call a contract’s fallback or receive function directly.

When Should You Use `call`?

You should use call mainly in these scenarios:

Sending Ether: call is recommended for transferring Ether to another contract or account, as it enables specifying a custom gas amount.
Fallback/Receive Function Calls: When calling a function that might not exist or is unknown, using call allows you to handle it gracefully if the function is missing.

Reasons to Avoid `call` for Regular Function Calls

For calling specific functions, high-level calls (direct function calls or using interfaces) are generally better. Using call is not recommended unless you need it, for the following reasons:

No Revert Propagation: call does not automatically bubble up reverts from the called contract, which can lead to silent failures.
No Type Safety: Solidity skips type checks with call, making it easier to call functions with incorrect parameters.
No Existence Check: call won’t verify that a function exists before executing, which can trigger a fallback function if one is present.

The Syntax of `call`

Here's the basic syntax of call in Solidity:

(bool success, bytes memory data) = address.call{value: msg.value, gas: 5000}(abi.encodeWithSignature("functionName(arguments)", args));

success: Boolean value that indicates if the call was successful.
data: Contains any returned data from the called contract.
address.call: Specifies the address being called.
abi.encodeWithSignature: Encodes the function signature and arguments.

Example of call Usage

Below is an example that demonstrates the usage of call between two contracts, Caller and Receiver. Receiver has a function foo that emits an event, and a fallback function to handle calls that don’t match any existing functions.

Receiver contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

contract Receiver {
    event Received(address caller, uint256 amount, string message);

    fallback() external payable {
        emit Received(msg.sender, msg.value, "Fallback was called");
    }

    function foo(string memory _message, uint256 _x) public payable returns (uint256) {
        emit Received(msg.sender, msg.value, _message);
        return _x + 1;
    }
}

Caller contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

contract Caller {
    event Response(bool success, bytes data);

    function testCallFoo(address payable _addr) public payable {
        (bool success, bytes memory data) = _addr.call{
            value: msg.value,
            gas: 5000
        }(abi.encodeWithSignature("foo(string,uint256)", "call foo", 123));

        emit Response(success, data);
    }

    function testCallDoesNotExist(address payable _addr) public payable {
        (bool success, bytes memory data) = _addr.call{value: msg.value}(
            abi.encodeWithSignature("doesNotExist()")
        );

        emit Response(success, data);
    }
}

Explanation

testCallFoo: Calls the foo function on Receiver using call, passing "call foo" and 123 as arguments.
testCallDoesNotExist: Attempts to call a non-existent function. Since Receiver doesn’t have a doesNotExist function, the fallback function is triggered instead, which emits a fallback event.

The following image shows the logs generated when testCallFoo is called on Receiver:

The next image shows the logs produced when testCallDoesNotExist is called on Receiver, triggering its fallback function:

Practical Tips and Caveats

Error Handling in call Unlike high-level calls, call does not automatically revert if it fails. You must manually check the success boolean. If success is false, handle the error appropriately, either by reverting or logging an error.

(bool success, bytes memory data) = address.call(...);
if (!success) {
    revert("Call failed");
}

Beware of Reentrancy Attacks
Reentrancy is a vulnerability where an external contract repeatedly calls back into the calling contract before the initial execution is complete. Mitigate this risk by using the checks-effects-interactions pattern, where external calls are placed last.
Empty Addresses
Unlike high-level calls, call does not check if an address has deployed code. If you call an address with no code, it may succeed without doing anything. To avoid this, add a check before calling:

require(_addr.code.length > 0, "Target address is not a contract");

Advanced Usage: Using call for Fund Transfers

Another common use of call is sending Ether. In the example below, ContractTwo sends Ether to ContractOne, which increments the sender's balance.

ContractOne and ContractTwo Example

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.15;

contract ContractOne {
    mapping(address => uint) public addressBalances;

    receive() external payable {
        addressBalances[msg.sender] += msg.value;
    }
}

contract ContractTwo {
    function depositOnContractOne(address _contractOne) public payable {
        (bool success, ) = _contractOne.call{value: 10, gas: 100000}("");
        require(success, "Transfer failed");
    }
}

In this example:

ContractOne has a receive function to accept Ether and record it in addressBalances.
ContractTwo sends 10 wei to ContractOne using call.

Conclusion

The call function in Solidity is a powerful low-level tool that allows for flexible interaction between contracts. However, it should be used with caution due to the lack of type checking, revert handling, and existence checks. When used correctly and with proper error handling, call can be invaluable for tasks like Ether transfers and dynamic function calls.

To minimize risks, always:

Check the success flag.
Use the checks-effects-interactions pattern.
Validate contract addresses before calling.

Follow me for more insights on Solidity, EVM, and blockchain development!👨‍💻

Understanding Fallback and Receive Functions in Solidity

Ayo Ashiru — Mon, 04 Nov 2024 12:50:48 +0000

Quick Overview

In Solidity, smart contracts interact with Ether in various ways. When Ether is sent to a contract, the contract requires methods to handle it. The fallback() and receive() functions serve as safety nets to manage incoming Ether and unexpected function calls. They are essential for building reliable and responsive contracts.

The Role of `receive()` and `fallback()` Functions

The receive Function The receive function was introduced to make handling plain Ether transfers more efficient and readable. It’s purpose-built to handle Ether transfers without data.

receive() external payable {
    // Handles plain Ether transfers
}

When is receive() Triggered?

The receive function is executed when the contract receives Ether without any data attached.
It must be marked as external and payable to allow Ether transfers.
Because it handles simple Ether transfers, receive() is more gas-efficient than fallback().

If receive() is absent and the contract receives plain Ether, Solidity will check for a fallback() function. If neither exists, the transaction is rejected.

The fallback Function The fallback function is a broader, catch-all function that handles:

Incoming Ether with data that doesn’t match any available function signature.
Calls to functions that do not exist within the contract.
Ether transfers if there is no receive() function defined in the contract.

fallback() external payable {
    // Handles everything else
}

When is `fallback()` Triggered?

When Ether is sent to the contract with data that does not match any existing function.
When a function is called that does not exist within the contract.
When the contract has no receive() function, but plain Ether is sent.

How `receive()` and `fallback()` Work Together

These two functions act as safety mechanisms, triggered based on whether the contract receives Ether with or without accompanying data.

Here's a simple decision flow:

Is Ether sent with data?
- Yes → fallback() is triggered.
- No → receive() is triggered if it exists; otherwise, fallback() is used.
Neither receive() nor fallback() exists? The transaction is
rejected and the Ether is sent back.

Practical Example of `receive()` and `fallback()`

Let's look at a basic contract that implements both receive and fallback functions, capturing details on each interaction for better tracking:

contract EtherHandler {
    event Received(address sender, uint amount);
    event FallbackCalled(address sender, uint amount, bytes data);

    // Handles plain Ether transfers
    receive() external payable {
        emit Received(msg.sender, msg.value);
    }

    // Handles everything else
    fallback() external payable {
        emit FallbackCalled(msg.sender, msg.value, msg.data);
    }
}

In this contract:

The receive function logs each Ether transfer without data, while the fallback function records any transfers or calls that include data or fail to match an existing function signature.

Best Practices for Using `receive()` and `fallback()`

To make the best use of these functions:

Use receive() when you want to handle simple Ether transfers only.
Use fallback() to manage calls with data or implement custom error handling.
Always emit events for receive() and fallback() to track interactions and manage logs effectively.
Keep the functions lightweight and gas-efficient to avoid unnecessary costs.

Conclusion

The receive() and fallback() functions are foundational in Solidity, providing flexibility and security for handling Ether transfers and function calls. They are key tools for developers aiming to build efficient, error-resistant smart contracts. By understanding these functions, Solidity developers can manage incoming transactions effectively, ensuring the reliability of their decentralized applications on the Ethereum blockchain.

Throttling and Debouncing in Web Development

Ayo Ashiru — Tue, 29 Oct 2024 13:54:11 +0000

Events like scrolling, resizing, or typing often trigger functions repeatedly, sometimes hundreds of times within seconds. Imagine a search bar fetching suggestions from a server as a user types or a resize handler constantly adjusting the layout as the browser window changes. Without control, these functions can overload the browser, slow down user experience, and even increase server costs due to excessive API requests.

This is where throttling and debouncing come into play. These two techniques help manage how often a function is executed in response to frequent events, making applications smoother, more efficient, and responsive. In this guide, we’ll explore these concepts, examine their differences, and see how each can optimize performance in specific use cases.

Understanding Throttling and Debouncing

Throttling is a technique that enforces a controlled, regular interval for a function's execution, regardless of how frequently the triggering event occurs. By limiting calls over a specified period, throttling ensures the function is invoked predictably—steady and consistent—rather than as often as the event occurs. This is ideal for cases where regular function execution improves user experience without overwhelming the system.

Debouncing, on the other hand, delays a function's execution until a set period has passed without further triggering events. Essentially, it waits for a "pause" in activity before invoking the function, making it useful in situations where actions should only occur after user activity subsides. For instance, waiting until a user finishes typing before making an API call in a search field prevents unnecessary requests and optimizes performance.

Key Characteristics

Key Characteristics of Throttling

Execution Frequency: Throttling enforces a maximum execution rate. For example, if an event is triggered continuously, like window resizing, throttling ensures the function runs only once per defined interval.
Consistent Rate: This technique maintains a steady, controlled execution pace, avoiding an overwhelming number of function calls and allowing for predictability in function behavior.

Key Characteristics of Debouncing

Delay-Based Execution: A function only executes after a certain delay following the last event, helping avoid excessive executions.
Single Execution After Events Cease: If an event continues, the function call is delayed repeatedly, only executing once activity stops—ideal for inputs where actions should occur only after a user completes an action, like typing.

Throttling and Debouncing Use Cases

These techniques shine in distinct scenarios:

Throttling Use Cases:
- Scroll Events: Throttling is effective for actions triggered by scrolling, such as content loading, which can occur predictably and continuously without overwhelming the interface.
- Resize Events: Frequent calls triggered by window resizing are controlled by throttling, allowing for adjustments at intervals rather than on every single resize change.
Debouncing Use Cases:
- Search Input: For search fields, debouncing prevents unnecessary API requests by waiting until the user stops typing, only executing after a period of inactivity.
- Resize Events: Similar to throttling, debouncing resize events is helpful to ensure layout adjustments occur only once, after resizing finishes.

Practical Examples

Throttling in JavaScript
Here’s how throttling can be implemented to limit the frequency of function execution:

function throttle(func, delay) {
  let lastCall = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastCall >= delay) {
      func(...args);
      lastCall = now;
    }
  };
}

const throttledScrollHandler = throttle(() => {
  console.log("Handling scroll event...");
}, 1000);

window.addEventListener("scroll", throttledScrollHandler);

In this example, the throttle function ensures that throttledScrollHandler is called only once every 1000 milliseconds (1 second), even if the user scrolls quickly. This conserves system resources and smooths user experience.

Debouncing in JavaScript
For debouncing, here’s a way to delay function execution until events cease:

function debounce(func, delay) {
  let timeoutId;
  return function (...args) {
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => func(...args), delay);
  };
}

const debouncedSearch = debounce((query) => {
  console.log(`Searching for: ${query}`);
}, 300);

const searchInput = document.getElementById("search-input");
searchInput.addEventListener("input", (event) => {
  debouncedSearch(event.target.value);
});

In this case, the debouncedSearch function only executes 300 milliseconds after typing stops. Each keystroke resets the delay timer, so the function waits until the user is done typing, optimizing both performance and user experience.

Conclusion

Throttling and debouncing are essential techniques for optimizing high-frequency events, leading to smoother user experiences and efficient resource use. By understanding these techniques and applying them thoughtfully, developers can control function execution rates, enhancing both front-end performance and system responsiveness.

Follow me for more insights on React, TypeScript, and modern web development practices!👨‍💻

Code Splitting with React.lazy and Suspense

Ayo Ashiru — Fri, 11 Oct 2024 12:06:51 +0000

In modern web development, performance is paramount. Users expect fast-loading applications, and one of the most effective strategies to achieve this is through code splitting. Code splitting allows you to break your application into smaller chunks, loading only the necessary code when needed. This article explores how to implement code splitting in React using React.lazy and Suspense.

Understanding Code Splitting

Code splitting is the process of dividing your application into smaller bundles that can be loaded on demand. This is particularly important for large applications, where shipping a single, massive JavaScript bundle can lead to slow load times and a poor user experience. By splitting your code, you can ensure that users only download the code they need, when they need it.

The Role of Bundling

Most React applications use bundlers like Webpack, Rollup, or Browserify to combine files into a single bundle. While bundling is efficient, it can lead to large file sizes as your application grows. Code splitting helps mitigate this issue by allowing you to load only the necessary parts of your application.

Dynamic Imports

The dynamic import() syntax is the foundation of code splitting in JavaScript. It allows you to load modules asynchronously, which is crucial for implementing code splitting in React.

// Before code splitting
import { add } from './math';

console.log(add(16, 26));

// After code splitting
import("./math").then(math => {
  console.log(math.add(16, 26));
});

When using import(), the bundler automatically creates separate chunks for the imported modules.

Using React.lazy

React provides a built-in way to implement code splitting at the component level through React.lazy. This function allows you to define a component that will be loaded dynamically.

Example:

import React, { lazy } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));

const DetailsComponent = () => (
  <div>
    <AvatarComponent />
  </div>
);

In this example, AvatarComponent will only be loaded when DetailsComponent is rendered, reducing the initial load time.

Introducing Suspense

While React.lazy handles the loading of components, it does not manage the loading state. This is where Suspense comes in. Suspense allows you to define a fallback UI that will be displayed while the lazy-loaded component is being fetched.

Example:

import React, { lazy, Suspense } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));

const renderLoader = () => <p>Loading...</p>;

const DetailsComponent = () => (
  <Suspense fallback={renderLoader()}>
    <AvatarComponent />
  </Suspense>
);

In this example, while AvatarComponent is loading, the user will see a "Loading..." message. This enhances the user experience by providing feedback during the loading process.

Handling Multiple Components

Suspense can also manage multiple lazy-loaded components simultaneously. This is useful for reducing the number of loading indicators displayed to the user.

Example:

import React, { lazy, Suspense } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));
const InfoComponent = lazy(() => import('./InfoComponent'));

const renderLoader = () => <p>Loading...</p>;

const DetailsComponent = () => (
  <Suspense fallback={renderLoader()}>
    <AvatarComponent />
    <InfoComponent />
  </Suspense>
);

In this case, both components will be loaded together, and the user will see a single loading indicator until both are ready.

Error Boundaries

When dealing with lazy-loaded components, it's essential to handle potential loading failures. React provides a pattern for this through error boundaries. An error boundary can catch errors during rendering and display a fallback UI.

Example:

import React, { lazy, Suspense } from 'react';

const AvatarComponent = lazy(() => import('./AvatarComponent'));

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      return <p>Loading failed! Please reload.</p>;
    }
    return this.props.children;
  }
}

const DetailsComponent = () => (
  <ErrorBoundary>
    <Suspense fallback={<p>Loading...</p>}>
      <AvatarComponent />
    </Suspense>
  </ErrorBoundary>
);

In this example, if AvatarComponent fails to load, the user will see a friendly error message instead of a broken UI.

Route-Based Code Splitting

One of the most effective places to implement code splitting is at the route level. This is particularly useful in single-page applications (SPAs) where different routes can load different components.

Example:

import React, { Suspense, lazy } from 'react';
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';

const Home = lazy(() => import('./routes/Home'));
const About = lazy(() => import('./routes/About'));

const App = () => (
  <Router>
    <Suspense fallback={<div>Loading...</div>}>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </Suspense>
  </Router>
);

In this example, the Home and About components are loaded only when their respective routes are accessed, optimizing the initial load time.

Conclusion

Code splitting is a powerful technique that can significantly enhance the performance of your React applications. By using React.lazy and Suspense, you can easily implement code splitting at the component level, ensuring that users only download the code they need. This not only improves load times but also enhances the overall user experience.

As you develop your React applications, consider where you can apply code splitting to optimize performance. Start with route-based splitting and identify large components that can be loaded on demand. With these strategies, you can create fast, efficient applications that delight your users.

Follow me for more insights on React, TypeScript, and modern web development practices!👨‍💻

React CRUD Operations with Axios and React Query

Ayo Ashiru — Tue, 24 Sep 2024 12:16:02 +0000

In the previous article, Simplifying HTTP Requests in React with Custom Hooks 🎣, we explored how to simplify HTTP requests using custom hooks. While effective for smaller applications, this approach may become harder to maintain as your React app scales. In this article, we'll dive into how to handle CRUD (Create, Read, Update, Delete) operations in a scalable way using Axios and React Query.

Why Axios and React Query?

Axios: A promise-based HTTP client for the browser and Node.js, Axios simplifies sending asynchronous HTTP requests to REST endpoints with clean, readable code.
React Query: A powerful data-fetching library that enhances data synchronization, caching, and state management in React. React Query automates data fetching while providing better control over loading and error states.

Setting Up Axios and React Query

First, install the necessary packages:

npm install axios react-query react-router-dom

Setting Up React Query in Your App

Next, configure React Query in your entry file (App.tsx) to manage your application's global query settings.

// src/App.tsx
import { QueryClient, QueryClientProvider } from 'react-query';
import { CustomRouter } from './Router';

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      refetchOnWindowFocus: false,  // Prevent refetch on tab/window switch
      retry: 1,                     // Retry failed queries once
    },
  },
});

const App: React.FC = () => (
  <QueryClientProvider client={queryClient}>
    <CustomRouter />
  </QueryClientProvider>
);

export default App;

Setting Up Axios with Interceptors

To handle authentication globally, we can create an Axios instance and use interceptors to attach the Authorization header for authenticated requests.

// src/config/axiosApi.ts
import axios from 'axios';

const authenticatedApi = axios.create({
  baseURL: import.meta.env.VITE_BASE_URL,  // Environment-specific base URL
  headers: {
    'Content-Type': 'application/json',
  },
});

// Attach Authorization token to requests if present
authenticatedApi.interceptors.request.use((config) => {
  const token = localStorage.getItem('crud-app-auth-token');
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

export { authenticatedApi };

Creating API Functions for CRUD Operations

Let's define functions that interact with our API to perform CRUD operations using Axios:

// src/data/api/post.ts
import { authenticatedApi } from '../../config/axiosApi';

// Error handler function to standardize error messages
export const handleApiError = (error: any): never => {
  if (error.message === 'Network Error') {
    throw new Error('Network Error. Please try again later.');
  } else if (error.response?.data?.error) {
    throw new Error(error.response.data.error);
  } else if (error.response) {
    throw new Error('A server error occurred.');
  } else {
    throw new Error(error.message || 'An unknown error occurred.');
  }
};

// General function to handle API requests
export const apiCall = async <T>(
  method: 'get' | 'post' | 'put' | 'delete',
  url: string,
  data?: any,
): Promise<T> => {
  try {
    const response = await authenticatedApi[method](url, data);
    return response.data;
  } catch (error) {
    throw handleApiError(error);
  }
};

// CRUD functions for the post feed
export const createPostApi = (post: any) => apiCall<any>('post', 'posts', post);
export const getPostsApi = () => apiCall<any>('get', 'posts');
export const updatePostApi = (id: string, post: any) => apiCall<any>('put', `posts/${id}`, post);
export const deletePostApi = (id: string) => apiCall<any>('delete', `posts/${id}`);

Using React Query Hooks for CRUD Operations

Now that we have API functions, we can use React Query to handle state management and data fetching for these operations.

// src/data/hooks/post.ts
import { useMutation, useQuery, useQueryClient } from 'react-query';
import { createPostApi, getPostsApi, updatePostApi, deletePostApi } from '../api/post';

// Custom hooks for CRUD operations
export const useCreatePostApi = () => {
  const queryClient = useQueryClient();
  return useMutation(createPostApi, {
    onSuccess: () => queryClient.invalidateQueries(['posts']), // Refetch posts after a new post is created
  });
};

export const useGetPostsApi = () => useQuery(['posts'], getPostsApi);

export const useUpdatePostApi = () => {
  const queryClient = useQueryClient();
  return useMutation(updatePostApi, {
    onSuccess: () => queryClient.invalidateQueries(['posts']), // Refetch posts after an update
  });
};

export const useDeletePostApi = () => {
  const queryClient = useQueryClient();
  return useMutation(deletePostApi, {
    onSuccess: () => queryClient.invalidateQueries(['posts']), // Refetch posts after deletion
  });
};

Consuming CRUD Hooks in a Component

Finally, we can build a simple component that consumes the custom hooks and allows users to create, edit, and delete posts.

// src/components/PostCard.tsx
import React, { useState } from 'react';
import { useGetPostsApi, useDeletePostApi, useUpdatePostApi, useCreatePostApi } from '../data/hooks/post';
import { toast } from '../components/Toast';  // Assume a toast component exists

const PostCard: React.FC = () => {
  const { data: posts, isLoading, error } = useGetPostsApi();
  const deletePost = useDeletePostApi();
  const updatePost = useUpdatePostApi();
  const createPost = useCreatePostApi();
  const [newPost, setNewPost] = useState({ title: '', content: '' });

  const handleCreate = async () => {
    try {
      await createPost.mutateAsync(newPost);
      setNewPost({ title: '', content: '' });
      toast.success('Post created successfully');
    } catch (error) {
      toast.error(error.message);
    }
  };

  const handleDelete = async (id: string) => {
    try {
      await deletePost.mutateAsync(id);
      toast.success('Post deleted successfully');
    } catch (error) {
      toast.error(error.message);
    }
  };

  const handleEdit = async (id: string, updatedPost: any) => {
    try {
      await updatePost.mutateAsync({ id, ...updatedPost });
      toast.success('Post updated successfully');
    } catch (error) {
      toast.error(error.message);
    }
  };

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      <div>
        <input
          type="text"
          value={newPost.title}
          onChange={(e) => setNewPost({ ...newPost, title: e.target.value })}
          placeholder="Title"
        />
        <input
          type="text"
          value={newPost.content}
          onChange={(e) => setNewPost({ ...newPost, content: e.target.value })}
          placeholder="Content"
        />
        <button onClick={handleCreate} disabled={createPost.isLoading}>
          {createPost.isLoading ? 'Creating...' : 'Create Post'}
        </button>
      </div>

      {posts?.map((post: any) => (
        <div key={post.id}>
          <h3>{post.title}</h3>
          <p>{post.content}</p>
          <button onClick={() => handleEdit(post.id, { title: 'Updated Title', content: 'Updated Content' })}>
            Edit
          </button>
          <button onClick={() => handleDelete(post.id)}>
            Delete
          </button>
        </div>
      ))}
    </div>
  );
};

export default PostCard;

Conclusion

By using Axios and React Query, you can streamline CRUD operations in your React applications. This combination results in clean, maintainable code, improving scalability and performance. Use these tools to simplify state management and data fetching as your app grows.

For more insights on React, TypeScript, and modern web development practices, follow me on Dev.to! 👨‍💻

React CRUD Operations with Axios and React Query

Ayo Ashiru — Tue, 24 Sep 2024 12:16:01 +0000

Why Axios and React Query?

Axios: A promise-based HTTP client for the browser and Node.js, Axios simplifies sending asynchronous HTTP requests to REST endpoints with clean, readable code.
React Query: A powerful data-fetching library that enhances data synchronization, caching, and state management in React. React Query automates data fetching while providing better control over loading and error states.

Setting Up Axios and React Query

First, install the necessary packages:

npm install axios react-query react-router-dom

Setting Up React Query in Your App

Next, configure React Query in your entry file (App.tsx) to manage your application's global query settings.

// src/App.tsx
import { QueryClient, QueryClientProvider } from 'react-query';
import { CustomRouter } from './Router';

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      refetchOnWindowFocus: false,  // Prevent refetch on tab/window switch
      retry: 1,                     // Retry failed queries once
    },
  },
});

const App: React.FC = () => (
  <QueryClientProvider client={queryClient}>
    <CustomRouter />
  </QueryClientProvider>
);

export default App;

Setting Up Axios with Interceptors

To handle authentication globally, we can create an Axios instance and use interceptors to attach the Authorization header for authenticated requests.

// src/config/axiosApi.ts
import axios from 'axios';

const authenticatedApi = axios.create({
  baseURL: import.meta.env.VITE_BASE_URL,  // Environment-specific base URL
  headers: {
    'Content-Type': 'application/json',
  },
});

// Attach Authorization token to requests if present
authenticatedApi.interceptors.request.use((config) => {
  const token = localStorage.getItem('crud-app-auth-token');
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

export { authenticatedApi };

Creating API Functions for CRUD Operations

Let's define functions that interact with our API to perform CRUD operations using Axios:

// src/data/api/post.ts
import { authenticatedApi } from '../../config/axiosApi';

// Error handler function to standardize error messages
export const handleApiError = (error: any): never => {
  if (error.message === 'Network Error') {
    throw new Error('Network Error. Please try again later.');
  } else if (error.response?.data?.error) {
    throw new Error(error.response.data.error);
  } else if (error.response) {
    throw new Error('A server error occurred.');
  } else {
    throw new Error(error.message || 'An unknown error occurred.');
  }
};

// General function to handle API requests
export const apiCall = async <T>(
  method: 'get' | 'post' | 'put' | 'delete',
  url: string,
  data?: any,
): Promise<T> => {
  try {
    const response = await authenticatedApi[method](url, data);
    return response.data;
  } catch (error) {
    throw handleApiError(error);
  }
};

// CRUD functions for the post feed
export const createPostApi = (post: any) => apiCall<any>('post', 'posts', post);
export const getPostsApi = () => apiCall<any>('get', 'posts');
export const updatePostApi = (id: string, post: any) => apiCall<any>('put', `posts/${id}`, post);
export const deletePostApi = (id: string) => apiCall<any>('delete', `posts/${id}`);

Using React Query Hooks for CRUD Operations

Now that we have API functions, we can use React Query to handle state management and data fetching for these operations.

// src/data/hooks/post.ts
import { useMutation, useQuery, useQueryClient } from 'react-query';
import { createPostApi, getPostsApi, updatePostApi, deletePostApi } from '../api/post';

// Custom hooks for CRUD operations
export const useCreatePostApi = () => {
  const queryClient = useQueryClient();
  return useMutation(createPostApi, {
    onSuccess: () => queryClient.invalidateQueries(['posts']), // Refetch posts after a new post is created
  });
};

export const useGetPostsApi = () => useQuery(['posts'], getPostsApi);

export const useUpdatePostApi = () => {
  const queryClient = useQueryClient();
  return useMutation(updatePostApi, {
    onSuccess: () => queryClient.invalidateQueries(['posts']), // Refetch posts after an update
  });
};

export const useDeletePostApi = () => {
  const queryClient = useQueryClient();
  return useMutation(deletePostApi, {
    onSuccess: () => queryClient.invalidateQueries(['posts']), // Refetch posts after deletion
  });
};

Consuming CRUD Hooks in a Component

Finally, we can build a simple component that consumes the custom hooks and allows users to create, edit, and delete posts.

// src/components/PostCard.tsx
import React, { useState } from 'react';
import { useGetPostsApi, useDeletePostApi, useUpdatePostApi, useCreatePostApi } from '../data/hooks/post';
import { toast } from '../components/Toast';  // Assume a toast component exists

const PostCard: React.FC = () => {
  const { data: posts, isLoading, error } = useGetPostsApi();
  const deletePost = useDeletePostApi();
  const updatePost = useUpdatePostApi();
  const createPost = useCreatePostApi();
  const [newPost, setNewPost] = useState({ title: '', content: '' });

  const handleCreate = async () => {
    try {
      await createPost.mutateAsync(newPost);
      setNewPost({ title: '', content: '' });
      toast.success('Post created successfully');
    } catch (error) {
      toast.error(error.message);
    }
  };

  const handleDelete = async (id: string) => {
    try {
      await deletePost.mutateAsync(id);
      toast.success('Post deleted successfully');
    } catch (error) {
      toast.error(error.message);
    }
  };

  const handleEdit = async (id: string, updatedPost: any) => {
    try {
      await updatePost.mutateAsync({ id, ...updatedPost });
      toast.success('Post updated successfully');
    } catch (error) {
      toast.error(error.message);
    }
  };

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      <div>
        <input
          type="text"
          value={newPost.title}
          onChange={(e) => setNewPost({ ...newPost, title: e.target.value })}
          placeholder="Title"
        />
        <input
          type="text"
          value={newPost.content}
          onChange={(e) => setNewPost({ ...newPost, content: e.target.value })}
          placeholder="Content"
        />
        <button onClick={handleCreate} disabled={createPost.isLoading}>
          {createPost.isLoading ? 'Creating...' : 'Create Post'}
        </button>
      </div>

      {posts?.map((post: any) => (
        <div key={post.id}>
          <h3>{post.title}</h3>
          <p>{post.content}</p>
          <button onClick={() => handleEdit(post.id, { title: 'Updated Title', content: 'Updated Content' })}>
            Edit
          </button>
          <button onClick={() => handleDelete(post.id)}>
            Delete
          </button>
        </div>
      ))}
    </div>
  );
};

export default PostCard;

Conclusion

For more insights on React, TypeScript, and modern web development practices, follow me on Dev.to! 👨‍💻

Simplifying HTTP Requests in React with Custom Hooks 🎣

Ayo Ashiru — Tue, 17 Sep 2024 12:50:06 +0000

When building React applications, dealing with HTTP requests is inevitable. A common challenge developers face is managing the complexity of making API calls, handling loading states, errors, and displaying fetched data efficiently.

This article is going to cover how to simplify HTTP requests using custom hooks in React. We’ll cover:

Creating a reusable custom hook
Managing loading, error, and data states
Implementing the hook in a React component

By the end, you’ll have a cleaner and more reusable approach for handling data fetching in your applications!

Why Custom Hooks?

Custom hooks allow you to encapsulate logic that can be reused across different components. Instead of cluttering each component with API calls, state management, and error handling, we can centralize that logic inside a hook.

This separation leads to:

Cleaner components
Easier maintenance
Reusability across multiple components

Here's What We’ll Build

We’re going to create a useData custom hook that can fetch data from any API, manage loading and error states, and then display that data in a React component.

Step 1: Creating the `useData` Hook

Let’s start by creating the hook. We’ll use the useState and useCallback hooks from React to manage data, loading, and errors.

import { useState, useCallback } from 'react';

export function useData<T>() {
  const [data, setData] = useState<T | null>(null);
  const [isLoading, setIsLoading] = useState<boolean>(false);
  const [error, setError] = useState<string | null>(null);

  const fetchData = useCallback(async (url: string) => {
    setIsLoading(true);
    setError(null);
    try {
      const response = await fetch(url);
      if (!response.ok) throw new Error('Network response was not ok');
      const result: T = await response.json();
      setData(result);
    } catch (error) {
      setError(
        error instanceof Error ? error.message : 'An unknown error occurred'
      );
    } finally {
      setIsLoading(false);
    }
  }, []);

  return { data, isLoading, error, fetchData };
}

How It Works:

State Management:
- data: Stores the fetched data.
- isLoading: Tracks whether the request is in progress.
- error: Stores any error messages if something goes wrong.
fetchData Function:
- This function uses the fetch API to make the HTTP request.
- It handles successful responses and errors by updating the relevant state variables.
Type Safety with Generics:
- By passing <T> as a generic, we allow the hook to work with any type of data (array, object, etc.).

Step 2: Using the Hook in a Component

Now that we have the useData hook, let’s integrate it into a React component. This component will call our hook to fetch data from a sample API and handle the loading and error states.

import React, { useEffect } from 'react';
import { useData } from './useData'; // Import the custom hook

const DataFetcher: React.FC = () => {
  const { data, isLoading, error, fetchData } = useData<any>();

  useEffect(() => {
    fetchData('https://api.example.com/data');
  }, [fetchData]);

  if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <div>
      <h2>Data Fetched:</h2>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default DataFetcher;

Key Points:

Fetching Data on Component Mount:
- We’re using the useEffect hook to call fetchData when the component mounts.
Loading and Error Handling:
- While the data is being fetched, a loading message is shown. If an error occurs, an error message is displayed.
Rendering Data:
- Once the data is fetched, it’s displayed in a pre tag to maintain formatting.

Step 3: Enhancing the User Experience

Let’s make the UI a bit more user-friendly. We’ll add some basic styles and enhance the user experience by disabling the submit button when the form is loading.

Here’s an example of how the final component would look:

const DataFetcher: React.FC = () => {
  const { data, isLoading, error, fetchData } = useData<any>();

  useEffect(() => {
    fetchData('https://api.example.com/data');
  }, [fetchData]);

  return (
    <div className="data-fetcher-container">
      <h1>Fetch Data Example</h1>

      {isLoading && <p>Loading data...</p>}
      {error && <p style={{ color: 'red' }}>Error: {error}</p>}

      {!isLoading && data && (
        <div>
          <h2>Data:</h2>
          <pre>{JSON.stringify(data, null, 2)}</pre>
        </div>
      )}
    </div>
  );
};

Why This Approach?

Separation of Concerns: The useData hook abstracts away the HTTP request logic, keeping your components clean and focused on rendering.
Reusability: Since the hook is generic, you can use it to fetch different types of data across your application.
Improved UX: The hook manages loading and error states efficiently, ensuring that users have feedback throughout the data fetching process.

Key Takeaways

Custom Hooks are a great way to encapsulate logic and keep your components clean.
Handling HTTP requests in React becomes much simpler when using hooks like useData.
The fetch API provides a powerful and flexible way to handle HTTP requests in JavaScript.

By adopting this pattern, your components will stay focused on rendering logic while the custom hook handles data fetching, loading, and error handling.

Want more insights? Follow me here for tips on React, TypeScript, and modern web development practices! 👨‍💻

Exploring React's useCallback Hook: A Deep Dive

Ayo Ashiru — Wed, 11 Sep 2024 09:30:03 +0000

React applications require peak performance, especially as they grow in size and complexity. In our previous article, we explore useMemo, a key hook for memoizing computed values and avoiding unnecessary recalculations. If you are not familiar with useMemo or looking to refresh your understanding, "Understanding React's useMemo" offers valuable insights to enhance your grasp and optimize application efficiency. Checking out this article can provide a solid foundation and practical tips for improving performance.

In this article, we'll focus on useCallback, a sibling hook to useMemo, and explore how it contributes to optimizing your React components. While useMemo is typically used for memoizing function results, useCallback is designed to memoize entire functions. Let's delve into its functionality and how it differs from useMemo.

What is useCallback?

At its core, useCallback is a React hook that memoizes a function so that the same instance of the function is returned on every render, as long as its dependencies don't change. This can prevent unnecessary function re-creation, which is particularly useful when passing functions as props to child components.

Here’s a basic example:

import React, { useState, useCallback } from 'react';

function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    console.log("Button clicked!");
  }, []);

  return (
    <div>
      <button onClick={handleClick}>Click me</button>
      <p>You've clicked {count} times</p>
    </div>
  );
}

In this example, handleClick is memoized. With no dependencies, it won't be re-created unless the component unmounts. Without useCallback, this function would be recreated on every render, even if its logic remains unchanged.

How is `useCallback` Different from `useMemo`?

While useCallback memoizes a function, useMemo memoizes the result of a function's execution. So if you're only concerned with avoiding unnecessary calculations or operations, useMemo might be a better fit. However, if you want to avoid passing a new function reference on every render, useCallback is the tool to use.

Use Cases for `useCallback`

Avoiding Unnecessary Re-Rendering of Child Components A common scenario for useCallback is when you pass functions as props to child components. React re-renders child components if any prop changes, including when a new function reference is passed. Using useCallback ensures that the same function instance is passed unless its dependencies change.

import React, { useState, useCallback } from 'react';

function Child({ onClick }) {
  console.log("Child component rendered");
  return <button onClick={onClick}>Click me</button>;
}

export default function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    console.log("Button clicked!");
  }, []);

  return (
    <div>
      <Child onClick={handleClick} />
      <button onClick={() => setCount(count + 1)}>Increase count</button>
    </div>
  );
}

Here, the handleClick function is memoized, which prevents the Child component from re-rendering unnecessarily when the parent component's state changes. Without useCallback, the Child component would re-render on every change in the parent, as a new function reference would be passed each time.

How is this Different from useMemo?

In a similar scenario, useMemo would be used if the result of some function logic (not the function itself) needed to be passed to the child. For example, memoizing an expensive calculation to avoid recomputing on every render.

Handling Event Handlers in Lists When rendering lists of components, useCallback is useful to prevent React from creating new event handlers on every render.

import React, { useState, useCallback } from 'react';

function ListItem({ value, onClick }) {
  return <li onClick={() => onClick(value)}>{value}</li>;
}

export default function ItemList() {
  const [items] = useState([1, 2, 3, 4, 5]);

  const handleItemClick = useCallback((value) => {
    console.log("Item clicked:", value);
  }, []);

  return (
    <ul>
      {items.map(item => (
        <ListItem key={item} value={item} onClick={handleItemClick} />
      ))}
    </ul>
  );
}

In this scenario, useCallback ensures that the handleItemClick function remains the same across renders, preventing unnecessary re-creation of the function for each list item.

How is this Different from `useMemo`?

If, instead of passing an event handler, we were calculating the result based on the items (e.g., sum of values in the list), useMemo would be a better fit. useMemo is used to memoize a computed value, while useCallback is strictly for functions.

Best Practices for `useCallback`

Only Use It When Necessary One of the biggest pitfalls of useCallback is overusing it. If a function is simple and doesn't depend on external variables, it might not need to be memoized. Using useCallback unnecessarily adds complexity without providing a significant performance benefit.

// Unnecessary use of useCallback
const simpleFunction = useCallback(() => {
  console.log("Simple log");
}, []);

In cases like this, there's no need to memoize the function because there's no dependency or computational overhead.

Keep Dependencies Accurate Just like useMemo, useCallback relies on a dependency array to determine when the memoized function should be updated. Always make sure that the dependencies accurately reflect the values used inside the function.

const handleClick = useCallback(() => {
  console.log("Clicked with count:", count);
}, [count]); // `count` is a dependency here

The memoized function will use stale values if necessary dependencies are omitted, leading to potential bugs.

Conclusion

Both useCallback and useMemo are invaluable tools for performance optimization in React, but they serve different purposes. Use useMemo when you need to memoize the result of an expensive computation, and use useCallback when you need to ensure that a function reference remains stable between renders. By understanding the distinctions and use cases for each, you can optimize your React applications effectively.

For a deeper dive into useMemo, be sure to visit the full article here: Understanding React's useMemo.

DEV Community: Ayo Ashiru

Serialization and Deserialization

What are they?

Why Are Serialization and Deserialization Necessary?

Serialization in API Communication

Serialization in Node.js

Best Practices:

Understanding HTTP: The Backbone of Today’s Internet

What is HTTP?

Why is HTTP Important in Today’s Internet?

The Client–Server Model

Example HTTP request format

HTTP is Stateless — What Does That Mean?

Alternatives to HTTP

Evolution of HTTP(From 0.9 → 3.0)

Conclusion

The delegatecall Function in Solidity

What is delegatecall?

Common Use Cases:

Basic Example of delegatecall

Risks and Best Practices of Using delegatecall

Example of a Security Vulnerability

Practical Tips for Using delegatecall Safely

Conclusion

The delegatecall Function in Solidity

What is delegatecall?

Common Use Cases:

Basic Example of delegatecall

Risks and Best Practices of Using delegatecall

Example of a Security Vulnerability

Practical Tips for Using delegatecall Safely

Conclusion

The call Function in Solidity

What is call in Solidity?

When Should You Use call?

Reasons to Avoid call for Regular Function Calls

The Syntax of call

Example of call Usage

Explanation

Practical Tips and Caveats

Advanced Usage: Using call for Fund Transfers

Conclusion

Understanding Fallback and Receive Functions in Solidity

Quick Overview

The Role of receive() and fallback() Functions

When is fallback() Triggered?

How receive() and fallback() Work Together

Practical Example of receive() and fallback()

Best Practices for Using receive() and fallback()

Conclusion

Throttling and Debouncing in Web Development

Understanding Throttling and Debouncing

Key Characteristics

Throttling and Debouncing Use Cases

Practical Examples

Conclusion

Code Splitting with React.lazy and Suspense

Understanding Code Splitting

The Role of Bundling

Dynamic Imports

Using React.lazy

Introducing Suspense

Handling Multiple Components

Error Boundaries

Route-Based Code Splitting

Conclusion

React CRUD Operations with Axios and React Query

Why Axios and React Query?

Setting Up Axios and React Query

Setting Up React Query in Your App

Setting Up Axios with Interceptors

Creating API Functions for CRUD Operations

Using React Query Hooks for CRUD Operations

Consuming CRUD Hooks in a Component

Conclusion

React CRUD Operations with Axios and React Query

Why Axios and React Query?

Setting Up Axios and React Query

Setting Up React Query in Your App

Setting Up Axios with Interceptors

Risks and Best Practices of Using `delegatecall`

Practical Tips for Using `delegatecall` Safely

Risks and Best Practices of Using `delegatecall`

Practical Tips for Using `delegatecall` Safely

What is `call` in Solidity?

When Should You Use `call`?

Reasons to Avoid `call` for Regular Function Calls

The Syntax of `call`

The Role of `receive()` and `fallback()` Functions

When is `fallback()` Triggered?

How `receive()` and `fallback()` Work Together

Practical Example of `receive()` and `fallback()`

Best Practices for Using `receive()` and `fallback()`

Step 1: Creating the `useData` Hook

How is `useCallback` Different from `useMemo`?

Use Cases for `useCallback`

How is this Different from `useMemo`?

Best Practices for `useCallback`