In this Blog Post, learn how to get the current Object API Name in a Salesforce Lightning Web Component (LWC) dynamically without Apex. Reduce code and build reusable components.
How to Get the Object API Name in a Salesforce Lightning Web Component (LWC) Without Apex
As a Salesforce Developer, Architect, or Admin, keeping your components dynamic and reusable is a top priority. Hardcoding object names is a technical debt trap. Fortunately, Salesforce provides an elegant, native way to fetch the current object’s API name in a Lightning Web Component (LWC) without writing a single line of Apex.
In this post, we’ll look at how to leverage the @api objectApiName property to make your components context-aware on record pages.
Why Fetch Object API Names Dynamically?
When building tools like custom forms, dynamic data tables, or specialized record headers, your LWC needs to know where it is running.
- Zero Apex: No need to waste governor limits or write test classes just to get a context name.
- Reusability: You can drop the exact same component onto the Account, Contact, or a Custom Object record page, and it adapts instantly.
- Maintenance: Reduces code footprint and simplifies your deployment pipeline.
Step-by-Step Implementation
To automatically capture the object context, the LWC must be placed on a Lightning Record Page and utilize the public objectApiName property. Here is the complete code implementation.
1. The HTML Template
The template simply displays a getter value (objectNameLabel) which we will process in our JavaScript file.
<template>
<lightning-card>
<div class="slds-p-around_medium">
Object Name: {objectNameLabel}
</div>
</lightning-card>
</template>
2. The JavaScript Controller
By declaring @api objectApiName, Salesforce automatically injects the API name of the current record’s object into this variable at runtime.
import { LightningElement, api } from 'lwc';
export default class ObjectNameComponent extends LightningElement {
@api objectApiName;
get objectNameLabel() {
return this.objectApiName.replace('__c', '').replace('_', ' ');
}
}
3. The Component Configuration (js-meta.xml)
For Salesforce to pass the context automatically, the component must be explicitly targeted for record pages (lightning__RecordPage).
<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>67.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__RecordPage</target>
</targets>
</LightningComponentBundle>
How It Works Under the Hood
When an LWC is embedded in a lightning__RecordPage, the Lightning Framework treats objectApiName (and recordId) as reserved public properties. If you declare them with the @api decorator, Salesforce automatically populates them based on the record page the user is viewing.
💡 Recommendations & Code Best Practices
While the provided code snippet works perfectly for basic use cases, here are a few architectural best practices to keep in mind when moving this to production:
- Handling UI Labels Properly: The string manipulation used above (
replace('__c', '')) provides a quick fix, but it doesn’t give you the actual, translated Object Label (e.g., it turnsCustom_Object__cintoCustom Object, but won’t match a localized label). For a truly robust UI, use wire adapters likegetObjectInfofromlightning/uiObjectInfoApito pull the authentic localized label. - Case Sensitivity & Global Replacements: The
.replace('_', ' ')method will only replace the first underscore it encounters. If your custom object API name has multiple underscores (e.g.,Deep_Nested_Object__c), use a Regular Expression like.replace(/_/g, ' ')or.replaceAll('_', ' ')to catch them all. - Null Checking: When components load, there can be a tiny lifecycle fraction where
@apiproperties are undefined. Adding a safe navigation operator or an unpopulated check (e.g.,if (!this.objectApiName) return '';) prevents unexpected runtime console errors.