I'm working on a lightning component that should be modular in the sense that it works with many sObject types. I want to be able to drop the component into different sObject record detail pages. For example, the component could be added to the record detail pages for custom_object_A__c, custom_object_B__c, custom_object_C__c and custom_object_D__c. The ID of the record would be used to identify the sObject type by taking the key prefix of the ID and using describe to return the sObject type. The component itself would have some input fields that would filter against a lookup table and return specific values for a picklist field that would then update a custom text field on the custom object that the component has been added for that record detail page.

I'm wondering about how the best approach to structure the component. Should I have a container component that takes the record ID, gets the sObject Type and then passes that down into another component that that can then use the generic sObject type and cast to the appropriate type. Or, should I just use one component for all the logic?

  • Be aware that in the contexts where you receive the recordId value you can also receive the objectApiName in most cases. See this documentation for details. This is LWC documentation, though I understand much the same happens for Aura ones too.
    – Phil W
    Sep 10, 2020 at 16:25

1 Answer 1


You only need one component. You can use force:hasRecordId and force:hasSObjectName to get the record Id and even the type, which you can then use force:recordData to load whichever fields you need. You can also do this for LWC. If you really want to, you could use more than one component, but that's really not necessary.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .