Understanding the Lifecycle Hooks in LWC

In web development, a component’s lifecycle represents the various stages it undergoes, from creation to removal from the DOM. Lifecycle hooks allow developers to interact with a component at specific points, making it possible to perform tasks like initializing data, making API calls, and cleaning up resources. For Salesforce developers working with Lightning Web Components (LWC), understanding these hooks is essential to creating optimized components, especially when dealing with complex parent-child relationships.

Table of Content

• Detailed Breakdown of Lifecycle Hooks in LWC
  • constructor
    • Code Example of Using constructor() Correctly
    • Example of What Not to Do in constructor()
  • connectedCallback
    • What Should Be Inside connectedCallback()
    • What Should NOT Be Inside connectedCallback()
  • renderedCallback
    • What Should Be in renderedCallback
    • What Should Not Be in renderedCallback()
    • Common Mistake Example: Infinite Loop in renderedCallback()
  • disconnectedCallback
    • What Should Be Inside disconnectedCallback()
    • What Should Not Be Inside disconnectedCallback()
  • errorCallback
    • What Should Be Inside errorCallback
    • What Should Not Be Inside errorCallback
    • Example of What Not to Do in errorCallback

Detailed Breakdown of Lifecycle Hooks in LWC

Each lifecycle hooks in LWC serves a unique purpose and is triggered at specific points. Below, we’ll cover each hook, explain its usage, explore its behaviour in parent-child contexts, and provide examples and best practices.

1. constructor()

The constructor() method is the first function executed when a component instance is created. It initializes the component and sets up its internal state.

In LWC, the constructor() is mainly used for initializing component properties that do not rely on the DOM or external data.

You should avoid any DOM manipulations, asynchronous operations, or data fetching in the constructor(); these actions should be deferred to lifecycle methods like connectedCallback() or renderedCallback().

The constructor is called from parent to child and the first statement within a constructor should be super() with no parameters.

Code Example of Using constructor() Correctly

• Assign initial values for properties.
• Initialize state that doesn’t rely on DOM.
• Basic setup that doesn’t involve external dependencies or async calls.

Let’s say you have a component that needs to initialize some local state variables and set up some initial values for reactive properties. Here’s how to properly use the constructor():

import { LightningElement, track } from 'lwc';

export default class MyComponent extends LightningElement {
    @track statusMessage;     // Reactive property
    @track itemList = [];     // Initial state setup for an empty array

    constructor() {
        super();
        this.statusMessage = 'Component initialized';  // Setting initial value
        this.initializeValues();                        // Calling a local method
    }

    initializeValues() {
        // Setting default values or state without needing the DOM
        this.itemList = [
            { id: 1, name: 'Item 1' },
            { id: 2, name: 'Item 2' },
            { id: 3, name: 'Item 3' }
        ];
    }
}

Explanation

In this example:

• Initializing Properties: statusMessage and itemList are initialized with default values.
• Calling Local Methods: The constructor() can call internal methods that do not require access to the DOM, like initializeValues().

Example of What Not to Do in constructor()

As the component is not yet connected to the DOM you won’t be able to perform the below operations as it might result in unexpected results.

• Don’t add attributes to the host element in the constructor. This is because, during constructor() execution, the component is not yet fully connected to the DOM, and modifying the host element at this stage can lead to unexpected behaviour or errors.
• Don’t use a return statement inside the constructor body, unless it is a simple early return (return or return this).
• Don’t use the document.write() or document.open() methods.
• Don’t inspect the element’s attributes and children, because they don’t exist yet.
• Don’t inspect the element’s public properties, because they’re set after the component is created.

constructor() {
    super();
    // Bad practice: DOM access in constructor
    // this.template.querySelector('.some-element').textContent = 'Updated text';  // Avoid this!

    // Bad practice: Fetching data in constructor
    // fetch('https://api.example.com/data')   // Avoid this!
    //     .then(response => response.json())
    //     .then(data => {
    //         this.itemList = data;
    //     });

}

2. connectedCallback()

The connectedCallback() method in LWC is called when the component is inserted into the DOM, making it amongst the first lwc lifecycle hooks where you can safely interact with the DOM.

This is an ideal place to set up anything that requires the component to be in the DOM, such as fetching data, adding event listeners, or initializing values that depend on DOM availability.

• Note: To check if a component is connected to the DOM use this.isConnected.

What Should Be Inside connectedCallback()

Setting up an event listener

connectedCallback() is a good place to add event listeners, especially those that need to be cleaned up later in disconnectedCallback().

connectedCallback() {
    this.addEventListener('customEvent', this.handleCustomEvent);
}

Fetching Data from an API

Since connectedCallback() is triggered when the component is in the DOM, it’s the right place to perform asynchronous operations like fetching data from an API.

connectedCallback() {
    fetch('https://api.example.com/data')
        .then(response => response.json())
        .then(data => {
            this.data = data;
        })
        .catch(error => {
            console.error('Error fetching data:', error);
        });
}

Initializing Values that Depend on DOM Presence

For properties or calculations that depend on the component being in the DOM, like dimensions, connectedCallback() is the right place to initialize them.

connectedCallback() {
    this.elementWidth = this.template.querySelector('.my-element').offsetWidth;
}

Triggering Observers

This is where you can set up observers, such as an IntersectionObserver to watch the visibility of the component or elements within it.

connectedCallback() {
    this.observer = new IntersectionObserver(entries => {
        entries.forEach(entry => {
            if (entry.isIntersecting) {
                console.log('Element is visible');
            }
        });
    });
    this.observer.observe(this.template.querySelector('.observed-element'));
}

disconnectedCallback() {
    this.observer.disconnect();
}

What Should NOT Be Inside connectedCallback()

Direct DOM Manipulation

Avoid directly manipulating the DOM of the component in connectedCallback(). LWC handles DOM updates, so direct manipulation can lead to unexpected behavior.

// BAD practice: Directly manipulating DOM
connectedCallback() {
    this.template.querySelector('.my-element').textContent = 'Updated Text';  // Avoid this!
}

Updating Reactive Properties Without Condition

Avoid directly updating reactive properties or tracked properties within connectedCallback() if it will cause a re-render. This can lead to multiple render cycles, which can be inefficient.

// BAD practice: Directly updating reactive properties
connectedCallback() {
    this.someTrackedProperty = 'New Value';  // Avoid this if not needed immediately
}

Calling setTimeout or setInterval Without Cleanup

Using timers can cause memory leaks if not properly cleaned up in disconnectedCallback(). Avoid using setTimeout or setInterval unless you handle them correctly.

connectedCallback() {
    this.intervalId = setInterval(() => {
        console.log('Running interval task');
    }, 1000);
}

disconnectedCallback() {
    clearInterval(this.intervalId);
}

Heavy Computations

Avoid running heavy computations or synchronous blocking code in connectedCallback(). Doing so can slow down the component’s loading. Defer heavy tasks to asynchronous calls or other lifecycle hooks if possible.

Full Code Example

Here’s a sample component demonstrating best practices in connectedCallback():

import { LightningElement, track } from 'lwc';

export default class MyComponent extends LightningElement {
    @track data;
    intervalId;

    connectedCallback() {
        // Example 1: Setting up event listener
        this.addEventListener('customEvent', this.handleCustomEvent);

        // Example 2: Fetching data
        this.fetchData();

        // Example 3: Initializing a property dependent on DOM presence
        this.elementWidth = this.template.querySelector('.my-element').offsetWidth;

        // Example 4: Setting up an observer
        this.observer = new IntersectionObserver(entries => {
            entries.forEach(entry => {
                if (entry.isIntersecting) {
                    console.log('Element is visible');
                }
            });
        });
        this.observer.observe(this.template.querySelector('.observed-element'));

        // Example 5: Timer setup (with cleanup in disconnectedCallback)
        this.intervalId = setInterval(() => {
            console.log('Running interval task');
        }, 1000);
    }

    disconnectedCallback() {
        // Clean up event listener
        this.removeEventListener('customEvent', this.handleCustomEvent);

        // Disconnect observer
        this.observer.disconnect();

        // Clear the timer
        clearInterval(this.intervalId);
    }

    fetchData() {
        fetch('https://api.example.com/data')
            .then(response => response.json())
            .then(data => {
                this.data = data;
            })
            .catch(error => {
                console.error('Error fetching data:', error);
            });
    }

    handleCustomEvent(event) {
        console.log('Custom event handled:', event.detail);
    }
}

Summary of Best Practices

• Do use connectedCallback() for adding event listeners, fetching data, and initializing properties that depend on the DOM.
• Do Not manipulate the DOM directly, set reactive properties unnecessarily, or run heavy synchronous tasks.
• Clean up resources such as timers, observers, or event listeners in disconnectedCallback() to avoid memory leaks.

3. renderedCallback()

The renderedCallback() is an LWC lifecycle hook that runs every time a component renders in the DOM. This includes the initial render and any subsequent re-renders triggered by changes to the component’s reactive properties or attributes.

While this lifecycle hook of lwc is helpful for performing DOM-dependent operations, it’s important to use it carefully to avoid performance issues, especially since renderedCallback() can be called multiple times.

Here’s a guide on what should and should not be included inside renderedCallback().

What Should Be in renderedCallback()

1. DOM Manipulations Dependent on Full Render
   renderedCallback() is the appropriate place to perform actions that need the DOM structure to be complete. This could include initializing a third-party library, measuring or manipulating specific elements, or making adjustments that depend on the component’s layout.
2. One-Time Setup Using a Flag
   If you only need to perform a setup action once, use a flag to check if the action has already been completed. This prevents renderedCallback() from running the same code on every re-render, which could lead to performance issues.
3. Non-Data-Binding-Related Logic
   Use renderedCallback() for operations that aren’t part of the component’s reactivity, such as setting up a custom scroll position or applying CSS animations.

Code Example: Proper Use of renderedCallback()

import { LightningElement, track } from 'lwc';

export default class RenderedCallbackExample extends LightningElement {
    @track message = 'Initial message';
    hasRendered = false; // Flag to prevent multiple executions

    renderedCallback() {
        if (this.hasRendered) {
            return; // Exit if this has already been run
        }
        this.hasRendered = true; // Set flag to avoid future executions

        // DOM manipulation that depends on fully rendered DOM
        const element = this.template.querySelector('.some-element');
        if (element) {
            element.style.color = 'blue';
        }

        // Initializing a third-party library (hypothetical example)
        this.initializeLibrary();
    }

    initializeLibrary() {
        // Hypothetical library that depends on DOM elements being present
        console.log('Library initialized');
    }
}

In this example:

• The hasRendered flag ensures the code only runs once, even if the component re-renders.
• initializeLibrary() represents a setup for a third-party library that depends on the DOM.

What Should Not Be in renderedCallback()

Setting Reactive Properties Without Conditions
Avoid setting reactive properties inside renderedCallback() unless it’s conditional. Changing reactive properties here can cause an infinite loop, as each update triggers a re-render, calling renderedCallback() again.

renderedCallback() {
    // This will cause an infinite loop as the @track property changes each time
    this.someReactiveProperty = 'Updated value';
}

API Calls or Data Fetching
Avoid initiating asynchronous calls like fetching data inside renderedCallback(), as this hook can run multiple times. Use connectedCallback() for such tasks instead.

Expensive Operations
Since renderedCallback() may run multiple times, avoid putting complex or heavy operations here, like large loops, significant calculations, or expensive DOM manipulations. If unavoidable, wrap the logic in a conditional block that ensures it only runs when necessary.

Common Mistake Example: Infinite Loop in renderedCallback()

import { LightningElement, track } from 'lwc';

export default class InfiniteLoopExample extends LightningElement {
    @track someProperty;

    renderedCallback() {
        // Updating a reactive property without any condition causes a loop
        this.someProperty = 'Updated on render';  //Infinite loop warning!
    }
}

In this example, the component re-renders every time renderedCallback() updates someProperty, leading to an infinite loop.

Summary of Best Practices for renderedCallback()

• Use flags to prevent code from executing on every re-render if you only need it to run once.
• Avoid updating reactive properties unless the update is conditional.
• Use connectedCallback() for data fetching and setting up asynchronous processes.
• Avoid heavy computations or extensive DOM operations, as renderedCallback() is designed for quick, DOM-related tasks.

By carefully structuring renderedCallback() to avoid infinite loops and performance issues, you can make sure your LWC component behaves efficiently and predictably.

4. disconnectedCallback()

The disconnectedCallback() method in lwc lifecycle hook is triggered when a component is removed from the DOM. This lifecycle hook is ideal for cleanup tasks, as it helps free up resources and avoid potential memory leaks. Here’s an overview of what you should and should not do in disconnectedCallback().

What Should Be Inside disconnectedCallback()

disconnectedCallback() is meant for cleanup tasks, including:

1. Removing Event Listeners
   • If you’ve attached event listeners in connectedCallback() (or elsewhere), you should remove them in disconnectedCallback() to prevent memory leaks.
2. Clearing Intervals and Timeouts
   • If you used setInterval or setTimeout within the component, clear these intervals or timeouts in disconnectedCallback() to prevent unintended execution after the component is removed.
3. Canceling Subscriptions or API Calls
   • If your component subscribes to any external data streams or long-running processes, make sure to unsubscribe or abort these in disconnectedCallback().
4. Releasing Resources
   • Any resources that the component acquired (e.g., references to large data structures or open WebSocket connections) should be released in disconnectedCallback().

What Should Not Be Inside disconnectedCallback()

Avoid tasks that:

1. Modify the DOM
   • Since the component is being removed, DOM manipulations in disconnectedCallback() are ineffective or may result in unexpected errors.
2. Make API Calls or Asynchronous Operations
   • Starting new asynchronous tasks or API calls here is counterproductive, as the component is no longer active and won’t be able to process responses.
3. Initialize New Variables or State
   • This is not a place for initialization logic; avoid setting up new variables or state changes as they won’t be useful.

Code Sample

Below is a sample component that sets up an event listener and an interval in connectedCallback() and properly cleans them up in disconnectedCallback().

import { LightningElement } from 'lwc';

export default class MyComponent extends LightningElement {
    intervalId;
    eventHandler;

    connectedCallback() {
        // Setting up an event listener
        this.eventHandler = this.handleEvent.bind(this);
        window.addEventListener('resize', this.eventHandler);

        // Setting up an interval
        this.intervalId = setInterval(() => {
            console.log('Interval running');
        }, 1000);
    }

    disconnectedCallback() {
        // Remove the event listener
        window.removeEventListener('resize', this.eventHandler);

        // Clear the interval
        if (this.intervalId) {
            clearInterval(this.intervalId);
            this.intervalId = null;  // Optionally reset the interval ID
        }
        console.log('Component cleaned up');
    }

    handleEvent() {
        console.log('Window resized');
    }
}

Explanation

• In connectedCallback():
  • An event listener is added to the window object for resize events.
  • An interval is set up to log a message every second.
• In disconnectedCallback():
  • The event listener is removed using window.removeEventListener to prevent memory leaks.
  • The interval is cleared with clearInterval to stop the recurring task after the component is removed.

Following this pattern ensures that your component behaves predictably and does not retain unnecessary resources when it’s no longer in the DOM.

5. errorCallback(error, stack)

The errorCallback(error, stack) is the only among the other lifecycle hooks in lwc specifically designed to handle errors that occur in the component’s subtree (the component itself and its child components). This method helps catch errors gracefully and can be used to manage error handling strategies, such as logging errors, displaying fallback UI, or preventing crashes.

However, certain actions and considerations should be avoided in errorCallback to ensure efficient and predictable error handling.

What Should Be Inside errorCallback

1. Error Logging
   • Log the error details or stack trace to an external service or console for debugging. This can help track issues during development or in production without interrupting the user experience.
2. Fallback UI Handling
   • Display a user-friendly error message or fallback content to notify the user that something went wrong without disrupting the entire page.
3. Event Dispatching for Global Error Handling
   • Dispatch a custom event to communicate the error to a parent component or global error handler if you want centralized error management in a larger application.
4. Simple State Management
   • Update component state to reflect the error (e.g., setting an error message property) to re-render the component with appropriate fallback content.

Example of errorCallback Usage

Here’s an example of using errorCallback to handle and log an error, display a friendly message to the user, and dispatch an event for further handling:

import { LightningElement, api, track } from 'lwc';

export default class ErrorHandlingComponent extends LightningElement {
    @track errorMessage;

    // API property that might throw an error in child component
    @api someProperty;

    errorCallback(error, stack) {
        // Log the error for debugging
        console.error('Error:', error);
        console.error('Stack:', stack);

        // Display a user-friendly error message
        this.errorMessage = 'Oops! Something went wrong. Please try again later.';

        // Dispatch an error event for further handling by a parent component
        this.dispatchEvent(new CustomEvent('error', {
            detail: { message: error.message, stack: stack }
        }));
    }
}

In this example:

• Error Logging: The console.error() logs the error and stack trace, which helps developers identify and troubleshoot issues.
• Fallback UI Handling: A user-friendly message is displayed by setting errorMessage, which can be shown in the template when errorMessage is not empty.
• Event Dispatching: A custom error event is dispatched, allowing the parent component to listen for errors and respond appropriately.

What Should Not Be Inside errorCallback

1. Error-Prone Code
   • Avoid any code that might throw another error, as this could result in recursive error handling and may cause performance issues or crashes.
2. DOM Manipulation
   • Avoid direct DOM manipulation, such as querying or modifying the DOM. Instead, update reactive properties to reflect changes in the UI.
3. Asynchronous Operations
   • Avoid starting asynchronous operations (like setTimeout, fetch, or Promise calls) in errorCallback. These operations can create unintended side effects and make debugging harder.
4. Complex Logic or State Changes
   • Avoid making complex state changes that might trigger re-renders or impact the overall stability of the component. Keep errorCallback simple and focused on error handling.

Example of What Not to Do in errorCallback

Here’s an example of an anti-pattern, where errorCallback includes error-prone logic, asynchronous calls, and DOM manipulation:

errorCallback(error, stack) {
    try {
        // Avoid performing async operations
        fetch('https://example.com/logError', {
            method: 'POST',
            body: JSON.stringify({ error: error.message, stack })
        });

        // Avoid directly manipulating the DOM
        this.template.querySelector('.error-text').textContent = 'Error occurred!';

        // Do not add code that might throw another error
        this.someUndefinedFunction();  // This will throw another error
    } catch (e) {
        console.error('Additional error occurred in errorCallback:', e);
    }
}

In this anti-pattern:

• Async Calls: fetch is used to send a log request. This may create unintended side effects, such as multiple logs for the same error.
• Direct DOM Manipulation: this.template.querySelector('.error-text').textContent tries to access the DOM directly, which could lead to issues if the .error-text element doesn’t exist.
• Additional Error-Prone Code: Calling this.someUndefinedFunction() could result in another error, potentially creating an infinite loop if errorCallback keeps handling errors.

Summary of Best Practices for errorCallback

• Use errorCallback for Logging: Log the error details to help with debugging.
• Display Fallback UI: Provide a user-friendly error message, avoiding any complex UI manipulations.
• Notify Parent Components if Needed: Use a custom event to allow a parent component to manage global error handling.
• Keep it Simple: Avoid asynchronous actions, additional error-prone logic, or complex state changes in errorCallback.

Following these guidelines ensures that errorCallback is used effectively for error handling without risking further errors or performance issues.

Direction of LWC lifecycle flow

Event	Direction
Constructor	Parent to Child
ConnectedCallback	Parent to Child
DisconnectedCallback	Parent to Child
RenderedCallback	Child to Parent

Read the complete Salesforce documentation on LWC Lifecycle Hook here.

Conclusion

Understanding lifecycle hooks in LWC goes far beyond memorizing when each one is triggered. By gaining a deep insight into each hook’s purpose, best practices, and appropriate use cases, you’ll not only be well-prepared for interviews but also equipped to create more efficient, reliable, and maintainable components in your projects. Remember, hooks like constructor(), connectedCallback(), and renderedCallback() each serve unique roles in a component’s lifecycle. Mastering these will enable you to optimize how your components interact with the DOM, manage state, and handle complex parent-child relationships.

Instead of simply recalling which hook to use, aim to understand why and how each one fits into your component’s lifecycle. With this foundational knowledge, you’ll be ready to tackle real-world development challenges and impress in your next Salesforce interview!

If you find this blog useful, do share it with your friends as well and don’t forget to subscribe to our newsletter to receive such content right into your inbox.