What are the best approaches to follow when you create lightning components for managed pakage?

Question

We created lightning components -without namespaces- and tested them successfully. At the time of packaging, (when a namespace is added) we had to prefix nameSpace__ before every field name, object name, labels and other components in each and every component and that lead to lot of bugs.

Basically we ended up replacing all

• Label.c. with label.namespace.
• c:componentName with namespace:componentName
• prefix namespace__ before every fields and objects ending with __c' and '__r.

We wasted almost 2 weeks for the whole process. Now our app is ready and is under review.

We are about to start the 2nd phase of product with a different namespace (say 'namespace2'). How should we approach this? Should we have to 'replace all' namespace with namespace2? Or as this blog suggests, should we never hard code namespace in lightning components?

Or we should hard code namespaces as per the Salesforce developer guide.

Which approach is adopted at your org?

Answer 1

While @sfdcfox gave you the right answer in comments (use DX), smart use of message classes can solve a lot of problems in this scenario.

Instead of using direct objects, or labels embedded in the component, create a class that encapsulate these things and leverage the fact that Apex does handle namespaces correctly.

For example

Message Class

public class MyMessages {
  public class MyMessage {
    @AuraEnabled
    public Map<String, String> labels {get;set;}
    @AuraEnabled
    public MyWrapper myObj {get;set;}
  }

  public class MyWrapper {
    @AuraEnabled
    public String myProp1 {get;set;}
    @AuraEnabled
    public String myProp2 {get;set;}

    void MyWrapper(MyObject__c obj) {
      myProp1 = obj.myProp1__c;
      myProp2 = obj.myProp2__c;
    }
  }
}

Class

@AuraEnabled
public static MyMessages.MyMessage getPageInfo(Id recID) {
  msgClass = new MyMessages.MyMessage();

  msgClass.labels.put('label1',System.Label.Label1);  
  msgClass.labels.put('label2',System.Label.Label2);

  MyObject__c obj = [select Id, myProp1__c, myProp2__c from MyObject__c where id = :recId]; 
  msgClass.myObj = new MyMessages.MyWrapper(obj);

  return msgClass;
}

Component

<aura:attribute access="public" name="myObj" type="Object" />

{!myObj.labels.label1} <br/>
{!myObj.labels.label2} <br/>
{!myObj.myObj.myProp1} <br/>
{!myObj.myObj.myProp2} <br/>

Helper

In the helper call the remote method and then

component.set("v.myObj", <variable with Object);

Answer 2

+1 for Sebastian and sfdcfox

As for Labels - in most - not all cases those get handled correctly by the packaging engine. There is nothing to do if they are e.g. referenced in the component body like so:

<!-- my cmp body --> {!$Label.c.myCustomLabel}

Also instanceOf c:myCustomComponent will work like a charm after packaging without further editing.

Getting a label in the JS Controller though $A.getReference('$Label.c.myLabel') does not (always?) seem to work. Which means those labels must be added to the package by using some workaround (e.g.referencing them invisibly in VF or elsewhere).

Please note that JSON.serialize or just returning an sObject to the Lightning Controller will append the Namespace to each fieldname. We strip or append this namespace if need be.

Ultimately we hope namespace support will get better in time and for the actual swapping of namespace issue, there's DX for that.