Data Synchronization in LWC with RefreshView

Say goodbye to stale data and full page reloads. Learn how to use the standard lightning/refresh module to synchronize your LWC components and standard page elements seamlessly.

Index / Table of Contents

1. Introduction
2. The Problem: “Why didn’t that list update?”
3. The Solution: lightning/refresh
4. Step 1: Understanding the Architecture
5. Step 2: Triggering a Refresh (The Emitter)
6. Step 3: Receiving a Refresh (The Listener)
7. Real-World Scenario: Updating a Related Record
8. Best Practices & Comparison
9. Conclusion

Introduction

In the world of Single Page Applications (SPAs) like Salesforce Lightning, “refreshing” is tricky. If you update a record in one component, other components on the screen don’t automatically know about it.

Historically, developers used the Aura event force:refreshView or messy message channels to fix this. But now, LWC has a modern, standard solution: the RefreshView API.

The Problem: “Why didn’t that list update?”

Imagine a standard Record Page for an Account.

• On the left, you have a custom LWC form to add a new Contact.
• On the right, you have the standard Related List showing Contacts.

When you save the new Contact in your LWC, the database updates. But the standard Related List on the right sits there, unchanging. The user has to manually refresh the browser to see their new data. That is a bad user experience.

The Solution: lightning/refresh

The lightning/refresh module provides a standard way for components to communicate that data has changed and the view needs to be refreshed.

It replaces the legacy eval("$A.get('e.force:refreshView').fire()") hack with clean, native LWC code.

Step 1: Understanding the Architecture

The RefreshView API works on a Handler and Container model.

1. The Container: The parent scope (like a Lightning Record Page or a custom app) that manages the refresh process. Standard Salesforce pages are already configured as containers.
2. The Handler: A component that registers itself to participate in refreshes.
3. The Event: The signal sent to tell the container to start the process.

Step 2: Triggering a Refresh (The Emitter)

This is the most common use case. You have performed a DML operation (Create, Update, Delete), and you want the rest of the page to know.

You simply dispatch a RefreshEvent.

Code Example:

import { LightningElement } from 'lwc';
import { RefreshEvent } from 'lightning/refresh';
import updateAccount from '@salesforce/apex/AccountController.updateAccount';

export default class AccountEditor extends LightningElement {
    
    handleSave() {
        // 1. Perform your data operation
        updateAccount({ ... })
            .then(() => {
                // 2. Dispatch the RefreshEvent
                // This tells the page: "Data changed, please refresh everyone!"
                this.dispatchEvent(new RefreshEvent());
            })
            .catch(error => {
                console.error('Error updating record', error);
            });
    }
}

What happens next? When you fire this event on a standard Record Page, Salesforce automatically refreshes standard components (like Related Lists and Details panels) without reloading the browser.

Step 3: Receiving a Refresh (The Listener)

If you have a custom component that displays data, it won’t automatically refresh unless you tell it how. You need to register a refresh handler.

Code Example:

import { LightningElement, wire } from 'lwc';
import { registerRefreshHandler, unregisterRefreshHandler } from 'lightning/refresh';
import getRecentAccounts from '@salesforce/apex/AccountController.getRecentAccounts';
import { refreshApex } from '@salesforce/apex';

export default class AccountList extends LightningElement {
    refreshHandlerID;
    
    @wire(getRecentAccounts)
    accounts;

    connectedCallback() {
        // 1. Register this component to listen for refresh requests
        this.refreshHandlerID = registerRefreshHandler(this, this.refreshHandler);
    }

    disconnectedCallback() {
        // 2. Clean up when component is destroyed
        unregisterRefreshHandler(this.refreshHandlerID);
    }

    // 3. Define what happens when a refresh is requested
    refreshHandler() {
        // Using refreshApex to update wired data
        return refreshApex(this.accounts);
    }
}

Real-World Scenario: Updating a Related Record

Scenario: You have a custom “Quick Add Opportunity” LWC on an Account Page.

1. User Action: User fills out the form and clicks “Save”.
2. LWC Logic: Calls Apex to insert the Opportunity.
3. LWC Logic: Dispatches new RefreshEvent().
4. Result: The standard “Opportunities” Related List on the page immediately updates to show the new record.

Best Practices & Comparison

Conclusion

The lightning/refresh module is a vital tool for creating responsive, integrated Lightning pages. By implementing RefreshEvent, you ensure your custom components play nicely with the standard Salesforce ecosystem, providing a seamless experience for your users.

Next time you write a “Save” function, don’t forget to dispatch the refresh!