2

I am building the form where I have 1-n object structure. For a sake of simplicity lets say I have an Invoice__c Custom Object and Item__c. If its only Invoice__c, it would be

<lightning:recordEditForm aura:id="recordViewForm" 
                                  objectApiName="Invoice__c">
    <lightning:messages />
    <!--Other fields here-->
    <lightning:inputField fieldName="InvoiceNumber__c" />
    <lightning:inputField fieldName="InvoiceAmount__c" />
    <lightning:button aura:id="submit" type="submit" label="Update record" class="slds-m-top_medium"/>
</lightning:recordEditForm>

However, if I want to be able to have an iteration with multiple Items how would I do that? Am I missing something fundamentally about lightning:recordEditForm so it is suppose to work only with one object? And if yes, should I in this case totally abandon recordEditForm and inputField and use other options that are more manual approach?

| improve this question | |
2

If you want to use them to automatically render the UI, feel free, but do not attempt to call the submit method on all of them at once, or you'll have some serious performance issues. If you expect a decent number of records in your items list, you'll need to write a slightly more complicated UI with lightning:input, lightning:input, etc.

| improve this answer | |
  • They have to be submitted together because they are in one transaction. So, if I understood correctly, in this case if I use recordEditForm I should intercept submits by implementing onsubmit and then with event.preventDefault() prevent built in submit. Then, I should manually read values (recordEditForm does not do 2 way binding, right?) with var fields = event.getParam("fields"); fields["fieldName"]... and create objects to pass to my custom developed apex controller? – Marko Tomic Jul 16 '18 at 7:21
  • @MarkoTomic I forgot that it has a save button. I don't know if you can actually cancel the submit action anyways, but it's probably not what you want to do anyways, since the UI would be confusing. – sfdcfox Jul 16 '18 at 9:51
  • I keep getting new findings. So, with event.preventDefault() you can cancel the submit, however, it will suspend the submit button completely so next time you click it will not initiate submit at all. What I also confirmed is that lightning:inputField has one way binding, so if you do model.field = 'test' it will update the UI, however, value change in UI will not update model automatically. I tried to completely move away from recordEditForm and lightning:inputField but then I discovered that force:inputField has a bug with initiating Lookup fields. Slowly running out of ideas... – Marko Tomic Jul 16 '18 at 11:38
  • @MarkoTomic force:inputField should be just fine. I really think you're over-engineering things. Worst case scenario, there's an open source lookup component you could use (plus other cool components). – sfdcfox Jul 16 '18 at 12:15
  • Maybe I am missing something but I can not get force:inputField to work when lookup field has to be initialized. There is this issue help.salesforce.com/… but suggested workaround doesn't work either. Other open source lookup components don't have create new option which is in my case essential. At least I didn't find them. – Marko Tomic Jul 16 '18 at 13:37

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.