DEV Community: chioma

Mastering Solidity Design Patterns: Building Secure and Scalable Smart Contracts

chioma — Mon, 28 Jul 2025 15:29:39 +0000

Smart contracts are the backbone of decentralized applications, executing irreversible transactions on the blockchain. Because their code is immutable and often handles significant financial value, writing them demands a high degree of precision and foresight.
This is where design patterns come in—acting as the architect’s toolkit for building applications that are secure, efficient, and reliable.

Why Design Patterns Matter in Smart Contracts

Solidity smart contracts are prone to several vulnerabilities that can lead to major financial losses or reputational damage. Common examples include:

Reentrancy attacks
Integer overflows and underflows
Access control flaws
Denial-of-Service (DoS) attacks
Unchecked external calls

Understanding these vulnerabilities and implementing secure design patterns is crucial. These patterns offer proven, reusable solutions to common issues and help improve security, gas efficiency, and maintainability.

What Are Solidity Design Patterns?

Solidity design patterns are standardized programming solutions for recurring challenges in smart contract development. They help developers write clean, secure, and scalable code.

Key Solidity Design Patterns by Category

Access Control Patterns

Control who can call sensitive functions.

1. Ownable Pattern

The Ownable pattern is like giving one person the keys to a house.

Purpose: Restrict access to specific functions to the contract owner.

Use Case: Administrative control—e.g., pausing the contract or withdrawing funds.

2. Role-Based Access Control (RBAC)

Assign different roles (or "hats") with specific permissions.

Example:

Admin – Can hire, fire, or manage settings

Performer – Can perform on stage

Audience – Can only watch

Purpose: Enable modular permissions across multiple roles (e.g., admin, minter).

Use Case: Decentralized governance and flexible access.

3. Multisig Pattern

Requires multiple people to agree before executing sensitive actions.

Real-life analogy: A treasure chest with three locks—two or more keys must be used to open it.

Purpose: Shared control over critical operations.

Use Case: Secure treasury or protocol upgrades.

🛡️ Security & Safety Patterns

Protect against malicious behavior and unexpected failures.

4. Checks-Effects-Interactions Pattern

Follow this order to avoid reentrancy:

✅ Checks – Validate permissions or balances
✍️ Effects – Update contract state
🔁 Interactions – Call external contracts

Purpose: Prevent reentrancy attacks through structured logic flow.

5. Pull Payment Pattern

Let users withdraw funds themselves rather than sending funds directly.

Analogy:

"You won a prize. Come and claim it!"

Instead of "Here’s your money right now."

Purpose: Safer fund transfer, reduces reentrancy risks.

Use Case: Refund systems or payment queues.

6. Emergency Stop (Pausable)

A “panic button” to halt certain functions in emergencies (e.g., bugs, hacks).

Purpose: Temporarily disable contract operations.

Use Case: Market crashes, vulnerabilities, etc.

7. Rate Limiting (Throttle)

⏳ You can’t spam this function—wait your turn.
Purpose: Restrict how often users can call a function.

Use Case: Games, faucets, rewards, on-chain APIs.

8. Reentrancy Guard

Prevents functions from being re-entered before they finish executing.

Analogy: You give a refund but someone interrupts before you log it, tricking you into paying again.

Purpose: Protect against repeated execution from malicious fallback calls.

Upgradability Patterns

Make smart contracts upgradeable despite their immutability.

9. Proxy Pattern

Acts as a middleman that forwards calls to a logic (implementation) contract.

Purpose: Upgrade logic without changing contract address or state

Creation Patterns

10. Factory Pattern

Dynamically deploy new contracts from a parent contract.

Purpose: Enable mass deployment of similar contracts.

Use Case: NFT drops, DAOs, or user-owned contracts.

Behavioral Patterns

Define when and how functions can execute based on time, state, or conditions.

11. State Machine Pattern

Enforce that certain actions only occur in specific states.

Purpose: Prevent invalid transitions.

Use Case: Auctions, token vesting, governance voting.

12. Iterator Pattern

Loop over mappings using a helper array (since mappings aren’t iterable by default).

Purpose: Enable iteration in a gas-efficient way.

13. Time Lock Pattern

Delay sensitive operations for a set period.

Purpose: Give time for review or intervention before critical actions are executed.

Use Case: Protocol upgrades, treasury withdrawals.

These patterns are distinct from blockchain design systems, which operate at a much broader architectural level. (See comparison below.)

Blockchain Design Systems (Theory)

A blockchain design system is a high-level framework that defines how a blockchain network operates. It establishes the rules, logic, and governance mechanisms for all participants.

Core Concepts

Consensus Mechanism – How blocks are verified (e.g., PoW, PoS)
Tokenomics – Incentive structures, supply logic
Governance – DAO voting, protocol changes
Permissions – Public, private, or consortium access
Finality – When a transaction becomes irreversible

Design Systems vs. Solidity Design Patterns

Feature	Blockchain Design System	Solidity Design Pattern
Scope	Entire blockchain network	Individual smart contract
Level	High-level (architecture)	Low-level (implementation)
Purpose	Define network-wide behavior	Solve contract-specific coding problems
Example	Proof-of-Stake mechanism	`Pausable` emergency stop

Conclusion

For Web3 developers, both design systems and design patterns are essential:

Blockchain Design Systems define the rules of the world you're building in.
Solidity Design Patterns are your tools for building in that world.

By mastering these patterns, you don’t just write code—you architect secure, trustworthy, and upgradeable decentralized applications.

Understanding Blockchain: Key Characteristics And The Layers That Make It Work.

chioma — Thu, 17 Jul 2025 15:25:16 +0000

You’ve probably heard the buzz: Blockchain will change the world.😁
But beneath all the hype and headlines—what does it actually do? And more importantly, how does it work?

Let’s forget the complex whitepapers for a moment.

Instead, picture a simple story:

Solene wants to send a digital coin to Me 😁😁.

No banks. No middlemen. Just her, her wallet, and a decentralized system she trusts.

But here’s the twist — this system is run by thousands of strangers across the world.

None of them know Solene, yet they’ll verify her transaction, protect it from tampering, and ensure it lives forever on a public ledger.

Sounds like magic?

It’s not. It’s blockchain.

In this article, we’ll follow Solene’s transaction from start to finish—layer by layer—unpacking how blockchain really works.

What Are Blockchain Protocols?

Before we follow Solene's journey, let's quickly understand what blockchain protocols are.

A blockchain protocol is like a recipe that all computers in the network must follow.

Just like a recipe ensures everyone can make the same cake, protocols ensure all computers handle transactions the same way.

Different blockchain networks have their own protocols—just like different families might have slightly different cake recipes.

Some examples include:

Bitcoin Protocol (for Bitcoin)
Ethereum Protocol (for Ethereum)
Polkadot, Solana, Avalanche, and so on...

Blockchain protocols determine:

How transactions are structured and validated
How computers (nodes) communicate
How blocks are added
How consensus is reached

The 5-Layer Journey of a Digital Coin

1. 💻 Application Layer

Solene clicks send on her phone

What happens:

Solene opens her digital wallet app, enters my address (a long string like ox78gc7...), inputs “1 coin,” and hits Send. Her private key signs the transaction like a digital signature, proving she owns the coin and authorizes the transfer.

Why it matters:

This is the user interface—where people interact with the blockchain without needing to understand the complex mechanics. It translates human intent into machine-readable actions.

Real-world analogy: Like writing and signing a check—easy to use but backed by a serious system underneath.

Key Functions:

Contains DApps (decentralized apps)
Wallets and APIs for interaction
Governance and voting mechanisms

This is where users and developers engage with the blockchain.

2. 🌐 Network Layer

The message spreads like wildfire

What happens:

Solene’s transaction is sent to nearby computers (nodes), which then broadcast it to others in the network. It spreads rapidly across the globe using a peer-to-peer (P2P) communication system.

Why it matters:

This layer ensures everyone in the network gets the same message. It's completely decentralized—no central server or authority decides what happens next.

Real-world analogy: Like gossip in a small town. One person tells three others, who each tell more, until everyone knows.

Key Functions:
This layer ensures that all nodes in the system can:

Discover each other
Communicate securely
Share blockchain data (new transactions and blocks)

3. 🗳️ Consensus Layer

The network votes on what's true

What happens:

Validators (or miners, depending on the protocol) gather pending transactions—including Solene’s—into a new block. They then either solve a puzzle (Proof of Work) or prove they have a stake (Proof of Stake) to propose the block. The rest of the network checks and agrees (or not).

Why it matters:

This is how the blockchain reaches agreement without a central judge. Fraudulent or duplicate transactions are rejected. Only valid blocks are accepted by the majority.

Real-world analogy: Like a jury trial where a majority must agree on the verdict before moving forward.

Key Functions:

Validates new blocks
Prevents double spending
Handles forks and selects the canonical chain

Common consensus algorithms:

Proof of Work (Bitcoin)

Proof of Stake (Ethereum 2.0, Cardano)

Delegated Proof of Stake (EOS)

Byzantine Fault Tolerance variants (Tendermint, HotStuff)

4. 🔗 Data Layer

Creating an unbreakable chain

What happens:

Once validated, the block is added to the chain. Each block contains:

The hash of the previous block
A list of transactions (including Solene’s)
A timestamp
Its own unique hash

This hash links each block tightly to the one before it.

Why it matters:

This is what makes blockchain immutable. If you try to change a single transaction, the hash breaks—and everyone notices.

Real-world analogy: Like a diary where each page is numbered and references the last. Tear a page out, and the whole book becomes suspicious.

Key Functions:

Organizes data in a block-chain format
Links blocks cryptographically (via hashes)
Makes past records immutable

5. 🖥️ Hardware Layer

Thousands of computers keeping it alive

What happens:

The entire blockchain system runs on thousands of independent computers (nodes) across the world. These machines store full copies of the blockchain, validate transactions, and maintain uptime—even if others fail.

Why it matters:

This physical layer ensures decentralization. It eliminates single points of failure and makes the system highly resilient to attacks or outages.

Real-world analogy: Like having thousands of identical backups of an important document stored in different places.

Computers (called nodes) that participate in the network
Internet connectivity that allows communication
Storage systems to keep a copy of the blockchain data

In the Ethereum network, each full node stores a complete copy of the Ethereum blockchain.

The Key Characteristics Explained

From Solene's transaction, we can observe the core blockchain properties:

Decentralized – No central control
Transparent – Everyone can verify
Immutable – Tamper-proof
Secure – Cryptography ensures it
Trustless – Runs on rules, not humans

How the Layers Work Together

Decentralization

Unlike banks, blockchains are owned by no one—and run by everyone.

Transparency

Anyone can check if:

Solene had the coin
The signature was valid
The transaction reached Me

Immutability

Once it’s recorded, it’s permanent.

Consensus

Accepted only if most nodes agree.

📋 Recap: Solene's Transaction, Layer by Layer

Layer	Role in Solene’s Story
Application	Lets her send and track the coin via an app
Network	Broadcasts her transaction to the blockchain
Consensus	Gets agreement from the network that it's valid
Data	Records it permanently in an unchangeable block
Hardware	Ensures the blockchain keeps running worldwide

Bonus: What Are the Components of a Blockchain?

Before we wrap up, it’s helpful to understand that every blockchain — including Ethereum, Bitcoin, and others — is made up of core components. These are the building blocks that allow it to work securely, just like the layers we saw in Solene’s story.

While many blockchains share similar components, they can vary depending on their design, use case, and consensus mechanism.

Common Components of a Blockchain System

Component	What It Does	Related Layer(s)
Node	A computer that participates in the network and verifies transactions	Hardware, Network
Ledger	The database that stores all transactions and blocks	Data Layer
Smart Contracts	Code that runs on the blockchain to automate agreements	Application Layer
Consensus Mechanism	Rules for how nodes agree on the state of the blockchain	Consensus Layer
Wallet	Interface for users to send, receive, and store digital assets	Application Layer
Cryptographic Hash	Converts data into a fixed-length fingerprint to ensure integrity	Data Layer
Token or Coin	The digital currency used for transactions and incentives	Application, Protocol

💡 Fun Fact:

Ethereum and Bitcoin both have nodes, wallets, and ledgers—but Ethereum also supports smart contracts, while Bitcoin focuses mostly on simple payments.

So yes — blockchains can have different components or prioritize some over others, but they all share the same fundamental goal: ensuring secure, trustless, decentralized value exchange.

✅ Conclusion: Solene’s One Coin, Secured by Layers

Solene’s one click went through five powerful layers
Application → Network → Consensus → Data → Hardware

All of them working behind the scenes to make it secure, valid, and permanent.

Blockchain isn’t just tech.

It’s rules + trust + global cooperation, baked into one system.

Thanks for reading 🤗

Feel free to drop your thoughts or questions in the comments!

JavaScript vs. TypeScript: Choosing the Right Tool for Your Project

chioma — Fri, 28 Jun 2024 09:55:24 +0000

Are you curious about what makes TypeScript unique and whether it offers significant advantages over JavaScript? As web development evolves, developers constantly seek the best tools to enhance productivity and code quality. JavaScript, the long-time favorite for creating dynamic and interactive user interfaces, remains widely used. However, TypeScript, with its type safety and modern features, is gaining popularity and sparking discussions in the development community.

In this article, we'll compare JavaScript and TypeScript, examining their key features and strengths. Whether you're an experienced developer looking to improve your workflow or a newcomer deciding which language to learn, understanding the differences between JavaScript and TypeScript will help you make an informed choice. Let's explore these two powerful technologies and see how they stack up against each other.

JavaScript: The Ubiquitous Web Language

JavaScript is a versatile, high-level programming language that runs in the browser and on the server (via Node.js). It's the standard language for web development, enabling developers to create dynamic and interactive user interfaces.

Key Features of JavaScript:

Dynamic Typing: Variables in JavaScript can hold values of any type, providing flexibility but also potential for runtime errors.
Prototype-Based Inheritance: JavaScript uses prototypes for inheritance, allowing objects to inherit properties and methods from other objects.
First-Class Functions: Functions in JavaScript are treated as first-class citizens, enabling higher-order functions and functional programming techniques.
Asynchronous Programming: JavaScript supports asynchronous programming with callbacks, promises, and async/await, making it suitable for handling I/O operations efficiently.
Wide Adoption and Community: JavaScript has a vast ecosystem of libraries and frameworks, such as React, Angular, and Vue.js, supported by a large and active community.

TypeScript: JavaScript with Superpowers

TypeScript is a superset of JavaScript that adds static typing and other features to the language. It transpiles to plain JavaScript, making it compatible with any environment that supports JavaScript.

Key Features of TypeScript:

Static Typing: TypeScript introduces static types, enabling developers to catch type-related errors at compile time rather than at runtime.
Type Inference: TypeScript can automatically infer types, reducing the need for explicit type annotations while still providing type safety.
Modern JavaScript Features: TypeScript supports the latest ECMAScript features and proposals, allowing developers to use cutting-edge language features.
Enhanced IDE Support: TypeScript's static types provide better tooling support, including code completion, refactoring, and navigation in IDEs.
Gradual Adoption: TypeScript can be incrementally adopted in existing JavaScript projects, allowing teams to gradually add types to their codebase.

Comparing JavaScript and TypeScript

Type Safety:

JavaScript: Dynamic typing can lead to runtime errors that are hard to debug.
TypeScript: Static typing helps catch errors at compile time, improving code reliability and maintainability.

Development Experience:

JavaScript: Flexible and easy to start with, but larger projects can become harder to manage.
TypeScript: Enhanced tooling and IDE support provide a smoother development experience, especially for large codebases.

Learning Curve:

JavaScript: Easier for beginners to pick up due to its simplicity and flexibility.
TypeScript: Steeper learning curve due to static typing and additional language features, but offers long-term benefits for maintainability.

Ecosystem and Compatibility:

JavaScript: Vast ecosystem with numerous libraries and frameworks; universally supported in all browsers and environments.
TypeScript: Compatible with all JavaScript libraries and frameworks; gaining rapid adoption with strong community support.

JavaScript and TypeScript each have their strengths. JavaScript is flexible, beginner-friendly, and widely supported, making it great for dynamic web applications. TypeScript adds static typing and enhanced tooling, improving error detection and maintainability, especially for large projects. Your choice depends on your project needs and development goals, but understanding both can help you make the best decision for your work.

The HNG Internship

The HNG Internship is a remote internship program designed to help software developers improve their skills and gain real-world experience. It is a highly competitive and intensive program that runs for a few months, during which interns work on various projects, often for real clients. The program is divided into multiple stages, with each stage presenting more challenging tasks.

Participants receive mentorship from experienced developers, collaborate with peers, and have the opportunity to build a portfolio of projects. The HNG Internship covers various aspects of software development, including frontend and backend development, mobile app development, and more. The program aims to bridge the gap between learning and practical application, making it a valuable experience for aspiring developers looking to kickstart their careers.

How I Feel About ReactJS

I am enrolled in the Frontend Development Track and I am particularly excited to work with ReactJS during the HNG Internship.

React, a JavaScript framework, features a component-based architecture and declarative syntax, making it an excellent tool for creating complex, interactive UIs efficiently. I believe that mastering React will greatly enhance my frontend development skills, enabling me to build dynamic, high-performance web applications.

The opportunity to learn and apply React in real-world projects, under the guidance of experienced mentors, is something I am looking forward to with great enthusiasm. Wish me luck as I aim to reach the final stage of the HNG Internship and make the most out of this incredible learning journey!

For those interested in learning more about the HNG Internship program, check out these links:
HNG-INTERNSHIP
Hire HNG Interns

Understanding React's useMemo and useCallback Hooks: A Comprehensive Guide

chioma — Mon, 01 Apr 2024 21:38:32 +0000

In React development, optimizing performance is vital for delivering seamless user experiences. Two essential hooks, useMemo and useCallback, play a crucial role in achieving this by memoizing values and functions. Let's explore these hooks and their impact on React application efficiency.

Understanding the Problem

In React, components re-render whenever their state or props change. When a component in React re-renders, everything inside it, including objects and functions, gets recreated. Due to JavaScript's nature, even identical objects or functions are treated as separate instances. Consequently, React's memo function fails to prevent unnecessary re-renders in such scenarios.

Memoization Challenge

Memoization, a technique to cache results, faces challenges when dealing with objects or functions passed as props. Passing objects or functions as props to child components results in the child component viewing them as new props upon re-rendering, thereby impeding the effectiveness of memo.

Introducing useMemo and useCallback

To address this issue, React offers useMemo and useCallback hooks. These hooks enable developers to stabilize objects and functions, preserving them between renders.

useMemo: Memoizes any value to be preserved across renders.
useCallback: Memoizes functions to prevent recreation on each render.

How Memoization Works

Memoization involves storing a computed value in memory and returning it on subsequent renders if the inputs (dependencies) remain unchanged. Both useMemo and useCallback accept a dependency array, similar to useEffect, to specify when to recompute the value or function. If one dependency changes , the value is re-created.

Common Use Cases

Optimizing memo Function: The primary use case involves stabilizing props (objects or functions) to prevent wasteful renders, thus maximizing the efficiency of the memo function.

Avoiding Expensive Recalculations: Use useMemo to cache results of computationally intensive operations, such as deriving state from large datasets, to eliminate redundant calculations on every render.

Preventing Infinite useEffect Loops: Memoize values used in dependency arrays of other hooks, like useEffect, to prevent unintended re-renders and avoid infinite loops.

Best Practices

While useMemo and useCallback offer significant performance improvements, it's essential not to misuse them. Reserve their usage for specific use cases rather than applying them indiscriminately. Overusing these hooks can lead to unnecessary complexity and hinder code maintainability.

Conclusion

By mastering useMemo and useCallback, React developers can optimize performance and enhance the responsiveness of their applications. These hooks provide a powerful mechanism for memoization, enabling efficient management of values and functions across renders. With careful implementation and adherence to best practices, React applications can achieve optimal performance and responsiveness.

How rendering works: The commit phase

chioma — Tue, 13 Feb 2024 12:54:12 +0000

Day 29 of 100days of code❤

A quick recap of the render phase:

The end result of the reconciliation process is an updated fiber tree and a list of DOM updates that need to be performed in the next phase. React has still not written anything to the DOM yet but has figured out the list of effects. This is the final result of the render phase, which includes the DOM operations that will be made in the commit phase.

How rendering works: The commit phase

The commit phase and Browser paint.

The commit phase:

In the commit phase, React finally writes to the DOM. This phase involves executing the list of DOM updates, which includes insertions, deletions, and updates of DOM elements. React flushes these updates to the DOM, applying them one by one to the actual DOM elements that already exist in the DOM tree. Unlike the render phase, committing is synchronous, meaning it occurs in one go without interruption. This ensures that the DOM never displays partial results, maintaining a consistent UI that remains in sync with the application state at all times.
Once the commit phase concludes, the work-in-progress fiber tree transitions to become the current tree for the subsequent render cycle.

Browser paint:

After changes are detected in the DOM, the browser repaints the screen to reflect the updated UI. This process is handled internally by the browser and is independent of React.
While the render phase is managed by React, the commit phase involves a separate library called ReactDOM, which is responsible for writing to the DOM. This is why we import both React and ReactDOM.

It's important to note that React itself doesn't directly manipulate the DOM; its primary function is to render components. React doesn't determine where the render result will be applied.
React was intentionally designed to be platform-agnostic, allowing it to be used across various platforms or hosts. For example, React Native enables building native mobile applications for iOS and Android using React components. This showcases React's versatility and its ability to adapt to different environments.

Putting it all together:

The process of rendering and displaying a React application on the screen begins with a trigger, such as the initial render or a state update. This trigger initiates the render phase, during which no visual output is produced. In this phase, all component instances requiring a re-render are rendered, meaning their respective component functions are called. This results in the creation of updated React elements, which are placed in a new virtual DOM - a tree structure of React elements.

It's important to note that rendering a component also renders all of its child components, regardless of whether their props have changed or not. This is because React cannot determine if the children were affected by the parent rendering.

The newly created virtual DOM needs to be reconciled with the current fiber tree before the state update can occur. This reconciliation process is essential to avoid the inefficiency of destroying and rebuilding the entire DOM tree with every update. Reconciliation aims to reuse as much of the DOM as possible by identifying the smallest number of DOM updates needed to reflect the latest state update.

The reconciliation process is facilitated by a reconciler called the Fiber, which operates with a mutable data structure known as the fiber tree. Each React element and DOM element in the fiber tree is associated with a fiber that holds the actual component state, props, and a queue of work.
After reconciliation, the queue of work contains the necessary DOM updates for the element.
The computation of DOM updates is performed by an algorithm called the diffing algorithm, which systematically compares elements in the new virtual DOM with elements in the current fiber tree to identify changes. The result of the reconciliation and diffing process is an updated fiber tree and a list of all the necessary DOM updates.

Note: The render phase in React is asynchronous, allowing fibers to split, prioritize, pause, and resume work. This asynchronous behavior is crucial in preventing the JavaScript engine from being blocked by complex rendering processes.
In the commit phase, the list of DOM updates generated during the render phase is applied to the DOM. This phase is handled by a renderer like ReactDOM, which performs operations such as editing, deleting, and updating DOM elements to reflect the new state of the application.
Unlike the render phase, the commit phase is synchronous. This means that all DOM updates are executed in one go, ensuring a consistent UI over time.

Finally, once the browser detects that the DOM has been updated, it initiates a new browser paint to visually update the user interface on the screen. This completes the process of rendering and displaying the React application.

Diffing

Diffing in React is based on two fundamental assumptions:

Elements of different types will produce different trees.
Elements with a stable key will stay the same across renders.

These assumptions enable the diffing algorithm to be significantly faster, reducing the number of operations required from potentially billions to just thousands.

Diffing involves comparing elements step-by-step between two renders based on their positions in the tree.
There are two primary situations to consider:

When two different elements are found at the same position in the tree between two renders.
When the same element is found at the same position in the tree between two renders.

In the first situation, if an element changes type (e.g., from a

to a ), React assumes that the element and all its children are no longer valid. Therefore, they are destroyed and removed from the DOM. This includes their state. The tree is rebuilt with brand new elements, meaning any components with state will have their state effectively reset.
In the second situation, if the same element is found at the same position in the tree between two renders, it will simply be kept in the DOM. This includes all child elements and preserves the component's state.

React efficiently updates the DOM by mutating element attributes or passing in new props for React elements, rather than removing and recreating elements unnecessarily. However, sometimes it may be desirable to create a brand new component instance with new state instead of preserving the existing state.

Thank you for reading.❤💪

How React works behind the scene -React render phase

chioma — Sun, 11 Feb 2024 21:19:05 +0000

How React works

This is day 28 of my 100 Days of code challenge.

And let’s start with just a tiny recap👇👇

When we create an application, what we are really doing is building a collection of components. Component instances are created when we use components in our application. These component instances are the actual physical components that exist in our application and hold state and props. As React calls each component instance, JSX will produce a series of React.createElement function calls, which in turn will create a React element for each component instance. These React elements are then transformed into DOM elements and displayed as the user interface on the screen.

How components are displayed on the screen

This process begins when a render is triggered. By updating state somewhere, a render is triggered, and the next phase is the render phase. In the render phase, React calls component functions and determines how the DOM should be updated to reflect the latest state change.

Note: The DOM is not updated in the render phase, unlike what we usually understand as rendering. React's definition of rendering is different, which can be confusing. In React, rendering does not directly update the DOM or display elements on the screen. Rendering happens internally inside React and does not produce any visual changes.

After the render phase comes the commit phase, where React actually writes to the DOM by updating, inserting, and deleting elements.

Note: The render and commit phases combined are what we traditionally call rendering. Finally, the browser notices that the DOM has been updated, and it repaints the screen. The browser repaint is what produces the visual change.

How renders are triggered

There are two situations that trigger render:

The first is the very first time the application runs, which is the initial render of the application.

Then, a state update in one or more component instances triggers a re-render.

Note: It is important to note that the render process is triggered for the entire application, not just for one single component. However, this doesn't mean that the entire DOM is updated. In React, rendering involves calling the component function and figuring out what needs to change. In practice, it may appear that React only re-renders the component where the state update happens, but behind the scenes, React determines the minimal set of changes needed to update the DOM efficiently.

Also, note that renders are not triggered immediately when a state update happens but are scheduled for when the JavaScript engine has some free time. This scheduling typically occurs within a few milliseconds, so it's not noticeable to the user.

How rendering works:The render phase

At the beginning of the render phase, React goes through the entire component tree and takes all the component instances that triggered a re-render, then renders them by calling the corresponding component function.

This process generates updated React elements, which together make up the virtual DOM.

During the initial render, React takes the component tree and transforms it into one large React element tree. This is what we refer to as the virtual DOM.

Virtual DOM

The virtual DOM is indeed a tree of all React elements created from all instances in the component tree. It's important to note that the virtual DOM is separate from the Shadow DOM, which is a separate concept used by web components.

Consider the component tree above. When updating the state in component N, it triggers a re-render, causing React to call the function of component N and place the new React element in a new React element tree, which is the virtual DOM.

Rendering a component also causes all of its child components to be re-rendered, regardless of whether their props have changed or not. So, if a state update happens in component M, components H, I, J, K, and L will also be re-rendered. Similarly, if we update the highest component, which is component O, then the entire application will be re-rendered. React employs this strategy because it doesn't know in advance whether children will be affected by the state change.

Note: This does not mean that the entire DOM is updated; rather, a new virtual DOM is recreated.

The new virtual DOM created will be reconciled with the current Fiber tree as it exists before the state is updated. This reconciliation process is performed in React's reconciler, which is called Fiber. The result of the reconciliation process is an updated Fiber tree(work in progress tree), which will then be used to write to the DOM.

what is reconciliation and why do we need it

The reason why React doesn't update the DOM whenever state changes somewhere in the app directly is because creating a virtual DOM is cheap and fast, as it's just a JavaScript object. On the other hand, writing to the actual DOM is relatively slow and would be inefficient and wasteful to do each time the render is triggered.

Usually, when state changes somewhere in the app, only a small part of the DOM needs to be updated, and the rest of the DOM can be reused.

To achieve efficiency, whenever a render is triggered, React tries to use as much of the existing DOM as possible. It does this through a process called reconciliation. Reconciliation involves deciding which DOM elements actually need to be inserted, deleted, or updated in order to reflect the latest state change. The result of reconciliation is a list of DOM operations necessary to update the current DOM with the new state.

Reconciliation is processed by a reconciler, which is the engine or heart of React. This is what allows React to never directly touch the DOM and instead tell React what the next snapshot of the UI should look like based on the state.

The Reconciler : Fiber

During the initial render of the component, Fiber takes the entire virtual DOM and builds another tree known as the Fiber tree. The Fiber tree is a special internal tree that contains a Fiber node for each component instance and DOM element.

Unlike React elements in the virtual DOM, the Fibers are not recreated on every render. Instead, the Fiber tree is never destroyed; But once created during the initial render, it is mutated over and over again in future reconciliation steps. This makes Fiber the perfect place for keeping track of things like the current component state, props, side effects, and a list of used hooks. The actual state and props of any component instance are internally stored inside the corresponding Fiber in the Fiber tree.

Fiber is also defined as the unit of work. Unlike the normal React element tree, Fiber nodes are structured in a linked list manner. The first child has a link to the parent, and all the other children have links to their previous siblings. This structure is known as a linked list, making it easier for React to process the work associated with each Fiber.

One characteristic of the Fiber reconciler is that work can be done asynchronously. This means that the rendering process, which is what the reconciler does, can be split into chunks. Tasks can be prioritized, and work can be paused, reused, or thrown away as needed. This allows for more efficient and responsive rendering in React application.