Listening to events on frontend in Blockchain / Solidity - Deep Dive

Overview - Listening to events on frontend

What is it?

Listening to events on the frontend means watching for messages or signals that come from the blockchain or smart contracts. These events tell the frontend when something important happens, like a transaction completing or a value changing. The frontend can then react, like updating the screen or showing a message. This helps keep the user interface in sync with the blockchain state.

Why it matters

Without listening to events, the frontend would have to keep asking the blockchain if something changed, which is slow and inefficient. Events let the frontend know instantly when to update, making apps faster and more user-friendly. This is crucial for real-time experiences like games, marketplaces, or finance apps on blockchain.

Where it fits

Before this, you should understand basic blockchain concepts like smart contracts and transactions. You also need to know how frontend apps work with JavaScript. After learning this, you can explore advanced topics like event filtering, handling multiple events, and optimizing frontend performance with event-driven design.

Mental Model

Core Idea

Listening to events on the frontend is like tuning a radio to hear important broadcasts from the blockchain and react immediately.

Think of it like...

Imagine you are waiting for a package delivery. Instead of constantly checking the mailbox, you get a text message when the package arrives. This message is like an event, and your phone is the frontend listening and reacting.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Smart Contract│──────▶│ Blockchain    │──────▶│ Frontend App  │
│ emits event   │       │ records event │       │ listens event │
└───────────────┘       └───────────────┘       └───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding blockchain events basics

Concept: Events are special signals emitted by smart contracts to announce something happened.

Smart contracts can emit events during execution. These events are stored on the blockchain and can be read by external apps. They contain data about what happened, like who sent tokens or what value changed.

Result

You know that events are messages from smart contracts that describe actions or changes.

Understanding that events are blockchain messages helps you see how external apps can track contract activity without scanning all transactions.

2

Foundation

Frontend role in blockchain apps

Concept: The frontend is the user interface that shows blockchain data and reacts to changes.

Frontend apps use JavaScript libraries like web3.js or ethers.js to connect to blockchain nodes. They can read data, send transactions, and listen for events to update the UI dynamically.

Result

You understand the frontend is the bridge between users and blockchain data.

Knowing the frontend listens to blockchain events explains how apps stay updated without manual refresh.

3

Intermediate

Using JavaScript to listen for events

🤔Before reading on: do you think the frontend must constantly ask the blockchain for updates, or can it wait for events? Commit to your answer.

Concept: JavaScript libraries provide methods to subscribe to smart contract events and react when they happen.

Using ethers.js, you can create a contract object and call contract.on('EventName', callback) to listen. The callback runs when the event fires, giving you event data to update the UI.

Result

The frontend automatically reacts to blockchain events without polling.

Knowing how to subscribe to events lets you build responsive apps that feel instant to users.

4

Intermediate

Filtering and handling multiple events

🤔Before reading on: do you think you can listen to all events at once, or must you filter specific ones? Commit to your answer.

Concept: You can filter events by parameters or listen to multiple event types to handle complex app logic.

Ethers.js allows filtering by event arguments, like listening only for transfers to a specific address. You can also set up multiple listeners for different events to update different parts of the UI.

Result

Your app listens only to relevant events, improving efficiency and clarity.

Filtering events prevents unnecessary updates and keeps the app focused on what matters.

5

Advanced

Handling event reorgs and confirmations

🤔Before reading on: do you think blockchain events are final immediately, or can they change? Commit to your answer.

Concept: Blockchain events can be reversed if blocks reorganize, so apps must handle confirmations to avoid showing wrong info.

Events come from blocks that may be replaced by longer chains. Frontends often wait for several block confirmations before trusting events. This avoids showing temporary or incorrect data.

Result

Your app shows reliable data and avoids confusing users with false updates.

Understanding blockchain finality helps you build trustworthy frontend experiences.

6

Expert

Optimizing event listening for scalability

🤔Before reading on: do you think listening to all events on the blockchain is cheap and easy, or can it cause problems? Commit to your answer.

Concept: Listening to many events can overload the frontend or node, so advanced techniques optimize event subscriptions and data handling.

Techniques include using indexed event filters, batching updates, caching event data, and using specialized event indexing services. This reduces load and improves app speed.

Result

Your app scales well even with many users and events.

Knowing optimization strategies prevents performance bottlenecks in real-world blockchain apps.

Under the Hood

When a smart contract executes a transaction, it can emit events that are recorded in the transaction receipt on the blockchain. These events are stored as logs with indexed topics and data. Frontend libraries connect to blockchain nodes via JSON-RPC or WebSocket and subscribe to these logs. When a new block arrives, the node sends matching event logs to the frontend, triggering callbacks.

Why designed this way?

Events were designed to provide a lightweight, efficient way to communicate contract state changes without storing large amounts of data on-chain. Logs are cheaper than storage and allow external apps to track contract activity without scanning every transaction. This design balances blockchain cost and usability.

┌───────────────┐
│ Smart Contract│
│ emits event   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Blockchain    │
│ stores logs   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Node (RPC/WS) │
│ sends events  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Frontend App  │
│ listens event │
└───────────────┘

Myth Busters - 3 Common Misconceptions

Quick: Do you think frontend event listeners get notified instantly and never miss events? Commit to yes or no.

Common Belief: Frontend event listeners always get every event immediately and reliably.

Reality: Network delays, node restarts, or dropped connections can cause missed events. Frontends must handle reconnections and event replay.

Why it matters: Missing events can cause the UI to show outdated or incorrect data, confusing users and breaking app logic.

Quick: Do you think blockchain events are stored as normal contract data? Commit to yes or no.

Common Belief: Events are stored like regular contract variables and can be read anytime on-chain.

Reality: Events are stored as logs, which are cheaper but not accessible by contracts themselves, only by external apps.

Why it matters: Misunderstanding this leads to wrong assumptions about contract logic and data availability.

Quick: Do you think events are final as soon as they appear on the blockchain? Commit to yes or no.

Common Belief: Once an event appears, it is permanent and cannot be changed.

Reality: Events can be reversed if the blockchain reorganizes, so apps should wait for confirmations.

Why it matters: Ignoring this can cause apps to show false information that later disappears, harming user trust.

Expert Zone

1

Event topics are indexed to allow efficient filtering, but only up to 3 indexed parameters per event can be used.

2

Listening via WebSocket is more efficient and real-time than polling, but requires handling connection drops gracefully.

3

Some blockchains or nodes may not support all event features uniformly, requiring fallback strategies.

When NOT to use

Listening to events is not suitable for reading historical data at scale; instead, use dedicated indexing services or subgraphs. For very simple apps, polling might be simpler. Also, if the blockchain or node does not support event subscriptions, alternative methods are needed.

Production Patterns

In production, apps use event batching, debounce UI updates, and combine event listening with state caching. They also handle edge cases like chain reorganizations and use third-party indexing APIs for scalability.

Connections

Observer Pattern

Listening to events on frontend is an implementation of the Observer design pattern.

Understanding this pattern clarifies how the frontend subscribes and reacts to blockchain events as observers.

Publish-Subscribe Messaging

Blockchain events act like published messages that subscribers (frontends) listen to and react upon.

Knowing pub-sub systems helps grasp event-driven architectures common in blockchain apps.

Real-time Notification Systems

Listening to blockchain events is similar to real-time notifications in apps like chat or email.

This connection shows how event listening improves user experience by providing instant updates.

Common Pitfalls

#1 Not handling dropped connections causes missed events.

Wrong approach:

contract.on('Transfer', (from, to, amount) => { updateUI(); }); // no reconnection logic

Correct approach:

function listen() {
contract.on('Transfer', (from, to, amount) => { updateUI(); });
provider._websocket.on('close', () => { listen(); });
}
listen();

Root cause:

Assuming event listeners stay connected forever without network issues.

#2 Reacting to events immediately without waiting for confirmations.

Wrong approach:

contract.on('Event', () => { showSuccess(); }); // no confirmation wait

Correct approach:

provider.waitForTransaction(txHash, 12).then(() => { showSuccess(); });

Root cause:

Not understanding blockchain finality and risk of reorgs.

#3 Listening to all events without filters causes performance issues.

Wrong approach:

contract.on('*', () => { updateUI(); });

Correct approach:

contract.on(contract.filters.Transfer(userAddress), () => { updateUI(); });

Root cause:

Not using event filters to limit data and updates.

Key Takeaways

Listening to events on the frontend lets apps react instantly to blockchain changes without slow polling.

Events are special logs emitted by smart contracts and stored on the blockchain for external apps to read.

Frontend libraries like ethers.js provide easy ways to subscribe to and filter these events.

Handling blockchain specifics like event finality and connection reliability is crucial for correct and smooth user experiences.

Advanced apps optimize event listening with filters, batching, and indexing to scale efficiently.

Practice

1. What is the main purpose of listening to blockchain events on the frontend?

easy

A. To compile smart contracts

B. To send transactions to the blockchain

C. To react instantly to changes happening on the blockchain

D. To mine new blocks

Solution

1. Step 1: Understand what events represent

   Events are signals emitted by smart contracts when something important happens.

2. Step 2: Connect event listening to frontend behavior

   Listening to these events lets the frontend update immediately without waiting for manual refresh.

3. Final Answer:

   To react instantly to changes happening on the blockchain -> Option C

4. Quick Check:

   Listening to events = instant frontend updates [OK]

Hint: Events notify frontend about blockchain changes instantly [OK]

Common Mistakes:

• Confusing event listening with sending transactions
• Thinking events compile contracts
• Believing events mine blocks

2. Which of the following is the correct way to start listening to an event named Transfer using ethers.js?

easy

A. contract.subscribe('Transfer', (from, to, amount) => { console.log(from, to, amount); });

B. contract.listen('Transfer', (from, to, amount) => { console.log(from, to, amount); });

C. contract.addEventListener('Transfer', (from, to, amount) => { console.log(from, to, amount); });

D. contract.on('Transfer', (from, to, amount) => { console.log(from, to, amount); });

Solution

1. Step 1: Recall ethers.js event listening syntax

   In ethers.js, the method to listen to events is on.

2. Step 2: Match the correct method with parameters

   The correct syntax is contract.on(eventName, callback).

3. Final Answer:

   contract.on('Transfer', (from, to, amount) => { console.log(from, to, amount); }); -> Option D

4. Quick Check:

   ethers.js uses .on() for events [OK]

Hint: Use .on() method to listen to events in ethers.js [OK]

Common Mistakes:

• Using .listen() which does not exist in ethers.js
• Using .addEventListener() which is DOM method, not ethers.js
• Using .subscribe() which is not ethers.js syntax

3. Given the following code snippet, what will be logged when the Deposit event is emitted with arguments user='0x123' and amount=100?

contract.on('Deposit', (user, amount) => {
  console.log(`User ${user} deposited ${amount} tokens`);
});

medium

A. User undefined deposited undefined tokens

B. User 0x123 deposited 100 tokens

C. User [object Object] deposited 100 tokens

D. SyntaxError: Unexpected token

Solution

1. Step 1: Understand event callback parameters

   The callback receives event arguments in order: user and amount.

2. Step 2: Check the console.log output format

   The template string inserts user and amount correctly into the message.

3. Final Answer:

   User 0x123 deposited 100 tokens -> Option B

4. Quick Check:

   Event args used correctly = correct message [OK]

Hint: Event callback parameters match emitted event arguments [OK]

Common Mistakes:

• Assuming parameters are undefined if not destructured
• Confusing objects with strings in output
• Expecting syntax errors from correct code

4. Identify the error in this code snippet that listens to an event and suggest the fix:

contract.on('Approval', (owner, spender, value) => {
  console.log(owner, spender, value);
});

// Later in the code
contract.off('Approval');

medium

A. The off method requires the same callback function to remove the listener

B. The event name should be lowercase 'approval' instead of 'Approval'

C. The callback function must be async to listen to events

D. The off method does not exist in ethers.js

Solution

1. Step 1: Understand how to remove event listeners in ethers.js

   To remove a listener, you must pass the exact callback function used when adding it.

2. Step 2: Check the code's off usage

   The code calls contract.off('Approval') without the callback, so it won't remove the listener.

3. Final Answer:

   The off method requires the same callback function to remove the listener -> Option A

4. Quick Check:

   Remove listener = same callback needed [OK]

Hint: Pass same callback to .off() to remove listener [OK]

Common Mistakes:

• Calling .off() without callback removes nothing
• Changing event name case incorrectly
• Thinking callback must be async

5. You want to listen to a MessageSent event on your frontend and update the UI only for messages sent by the current user. Which approach correctly filters events before updating the UI?

hard

A. Listen to all MessageSent events and inside the callback check if sender === currentUser before updating UI

B. Use contract.on('MessageSent', callback, { filter: sender === currentUser }) to filter events automatically

C. Filter events by modifying the contract ABI to include only currentUser events

D. Listen to events only once using contract.once and update UI

Solution

1. Step 1: Understand event filtering on frontend

   ethers.js does not support filtering events by passing filter objects in on method directly.

2. Step 2: Use callback logic to filter events

   Listen to all events, then check inside the callback if the sender matches the current user before updating UI.

3. Final Answer:

   Listen to all MessageSent events and inside the callback check if sender === currentUser before updating UI -> Option A

4. Quick Check:

   Filter inside callback = correct approach [OK]

Hint: Filter events inside callback, not in .on() parameters [OK]

Common Mistakes:

• Trying to filter events via .on() parameters
• Modifying ABI to filter events (not possible)
• Using .once() which listens only once, not continuously