Introduction

The main concept included in this recipe is to showcase the lightning-record-form component that allows to display of a record form and also editing the fields.

<aside> 📚 Official documentation https://developer.salesforce.com/docs/component-library/bundle/lightning-record-form/specification.

</aside>

<aside> ☝ Review this page recordId and objectApiName special properties and Accessing Data with LWC, which are the basics for understanding this LWC.

</aside>

<aside> 📁 Find this LWC in this folder: force-app\\main\\default\\lwc\\recordFormStaticContact and force-app\\main\\default\\lwc\\recordFormDynamicContact

</aside>

This LWC can be placed on a page where a contact record is displayed, and this is the reason we need to go to the Contacts Tab.

Static vs Dynamic

There are 2 LWCs:

1. The statically imported version:

   1. In the Javascript file the fields are imported as import ACCOUNT_FIELD from '@salesforce/schema/Contact.AccountId' with the path referenced to the Salesforce schema and then declaring the fieldsarray fields = [ACCOUNT_FIELD, NAME_FIELD, TITLE_FIELD, PHONE_FIELD, EMAIL_FIELD].
   2. In the template file every field is not referenced individually, but a only one <lightning-record-form element is used:

   <lightning-record-form
         object-api-name={objectApiName}
         record-id={recordId}
         fields={fields}
   ></lightning-record-form>
   

2. In the dynamically imported version, a similar approach is followed:

   1. In the Javascript file, the fields are not individually imported but instead only the fieldsarray is declared but using the name of the fields as fields = ['AccountId', 'Name', 'Title', 'Phone', 'Email'].
   2. In the template the exact same code is used as per the static version.

Advantages of static vs dynamic

In the static LWC, the field names are specified individually, which provides error checking during development time but is less flexible:

• If you try to delete a field on the Org that is statically imported, it will be detected and you will be prompted to fix the issue.
• By importing the references, Salesforce verifies that the objects and fields exist, prevents objects and fields from being deleted, and cascades any renamed objects and fields into your component's source code.
• But if you dynamically import the field, this error checking is not available, even though you gain a lot of flexibility as you can build the fieldsarray dynamically.

Template file for the static version

• The LWC retrieves the fields values for the record that is informed using the recordId property.
• You must inform the object-api-name and record-id variables and optionally the list of fieldsto be displayed.

<aside> 💡 Read more about the recordId and objectApiName variables here: recordId and objectApiName special properties

</aside>

...
<div class="slds-var-m-around_medium">
    <lightning-record-form
        object-api-name={objectApiName}
        record-id={recordId}
        fields={fields}
    ></lightning-record-form>
</div>
...

Javascript file for the static version

In the following code extract, it is clear why this LWC is named recordFormstaticContact, as there is a bunch of importstatements to import the fields and assign them to the fieldsarray statically.

...
import ACCOUNT_FIELD from '@salesforce/schema/Contact.AccountId';
import NAME_FIELD from '@salesforce/schema/Contact.Name';
import TITLE_FIELD from '@salesforce/schema/Contact.Title';
import PHONE_FIELD from '@salesforce/schema/Contact.Phone';
import EMAIL_FIELD from '@salesforce/schema/Contact.Email';

export default class RecordFormStaticContact extends LightningElement {
    // Flexipage provides recordId and objectApiName
    @api recordId;
    @api objectApiName;

    fields = [ACCOUNT_FIELD, NAME_FIELD, TITLE_FIELD, PHONE_FIELD, EMAIL_FIELD];
}
...

In the following screenshot, you can see the LWC in action, after the Department field was added.