2

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?

  • 3
    The correct solution is to use DX. This allows you to develop using your namespace so you don't spend time doing this. – sfdcfox Jul 18 '17 at 17:29
  • Thank you @sfdcfox, I am new to packaging related stuffs . About Salesforce DX, I have seen some YouTube videos and seems interesting. l will definitely try to make use of DX going forward. – Hareesh P Mohan Jul 20 '17 at 7:50
3

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);
  • Thank you @sebastian-kessel. Your code is an awesome hack..! But, for now, I have decided to give Salesforce DX a try. I will try this if my team is not willing to go with DX. Thank you again. – Hareesh P Mohan Jul 20 '17 at 8:09
  • That's the best idea anyway. Good luck! – Sebastian Kessel Jul 20 '17 at 14:26
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.

  • Thank you @christian-szandor-knapp , we have included all those 'stubborn' labels, ( which were not willing to be a part of package) in a separate VF page and added that in the package. – Hareesh P Mohan Jul 20 '17 at 7:53

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.