0

Aura Component and JS Controller and Helper files are not resolving the API names of custom object and custom fields

In one of our Partner Dev Org, I am working on an application, after development and testing, I created a managed package

The steps I followed:

  • Developed code(Aura components, Apex Controllers) and created custom objects
  • After testing, Created unmanaged package and deployed in sandboxes and tested and working fine.
  • Observed that Lightning component with lightning datatable is displaying data in all columns
  • Created managed released package by defining namespace and also choosing the above already tested unmanaged package. It created managed package successfully
  • Observed Lightning component with lightning datatable is not displaying data in non of columns. It even didn't work in Package Development Org(Partner Dev Org). It didnt work in subscriber org

I am able to locate and find the root cause of the issue after spending 4 hours today:

The root cause is: Aura Component and JS Controller and Helper files are not resolving the API names of custom object and custom fields

Sample Code blocks from Application Code:

Component

<lightning:datatable data="{!v.filteredAddrList}"                              
                         class="slds-m-top_medium"    
                         columns="{!v.columns}"                             
                         keyField="addressUniqueNumber__c"  
                         selectedRows="{!v.existingAddresses}"
                         sortedBy="{!v.sortedBy}"
                         sortedDirection="{!v.sortedDirection}"
                         onrowaction="{!c.navToMap}"
                         onrowselection="{!c.rowSelection}"
                         onsort="{!c.updateColumnSorting}" />

Javascript Controller and Helper code:

var actions = [
        { label: 'Details', name: 'show_details' }
    ]; 
    component.set('v.columns', [    
        {label:'Street', fieldName: 'Street__c', sortable : true, type:'text', initialWidth: 300, sortable: true},            
        {label:'City', fieldName: 'City__c', type: 'text', initialWidth: 300, sortable : true}
    ]);

var selectedRows = component.get("v.existingItems");
    selectedRows.forEach(function(item){            
        var newRequest = {
            Street__c: item
        };
        newRequest.sobjectType  = 'Account_Address__c';
        items.push(newRequest);
    });

Above code snippets refer below custom objects and custom fields:

Custom Object: Account_Address__c Custom Fields: addressUniqueNumber__c, Street__c, City__c

Workaround: I did the changes and added package namespace prfix to all above custom object and fields names. Then the issue got resolved and the data is displayed in table.

addrverifyx__Account_Address__c addrverifyx__addressUniqueNumber__c, addrverifyx__Street__c, addrverifyx__City__c

It worked fine in both Package dev org and subcriber org. I dont this is the correct solution. There may be some other reason it is not working.

I searched many salesforce expert developer community forums and I didnt find the similar issues.

Is this the correct solution? Why it is failing to resolve the api names?

4

The "Organizations with a Namespace Prefix" section of Namespace Usage Examples and Reference confirms that you do need to include the namespace.

As sfdcfox says, one advantage of using Scratch Orgs is that you can develop with the namespace defined from day one, rather than having to add it at the end to package. (In Apex code, the namespace is injected by the platform when not specified so this problem is somewhat hidden in that case.)

  • 2
    If you are having to develop against dev orgs rather than scratch orgs and you happen to be using IntelliJ IDEA with Illuminated Cloud 2, this already has a namespace mapping mechanism which means you write the code with your target namespace but can deploy to dev orgs with different namespaces. (You would, of course, be much better off using SFDX.) – Phil W Jan 14 at 8:00
  • Thank you Keith and Phil clarifying and explaining more details – Anil Jan 15 at 18:58
3

That's not a workaround, that's the intended pattern for designing in LWC. It is for this reason that Scratch Orgs can be registered to a Namespace so that you don't have to keep adding/removing namespaces while developing your package.

  • Thank you sfdcfox clarifying and explaining more details – Anil Jan 15 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.