Introduction

The main concept included in this recipe is to showcase the lightning-record-edit-form component, allowing the creation of a form to insert or update fields in an existing record.

The component displays the fields with their labels and current values and enables the user to edit those values.

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

</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> 📁 You can find this LWC in this relative path: force-app\\main\\default\\lwc\\recordEditFormStaticContact and force-app\\main\\default\\lwc\\recordEditFormDynamicContact

</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.

Be aware that lightning-record-edit-formdoes not support all objects.

Static vs Dynamic

There are 2 LWCs:

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.
2. In the template file every field is referenced individually inside the <lightning-record-edit-form :
```
<lightning-record-edit-form object-api-name={objectApiName} record-id={recordId}>
		<lightning-input-field field-name={accountField}></lightning-input-field>
		<lightning-input-field field-name={nameField} ></lightning-input-field>
		...
```

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

In the Javascript file, the fields are not individually imported.
In the template the name of the fields is used:

<lightning-record-edit-form object-api-name={objectApiName} record-id={recordId}>
      <lightning-input-field field-name="AccountId"></lightning-input-field>
      <lightning-input-field field-name="Name"></lightning-input-field>
      ...

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 lightning-input-field component is used in the lightning-record-edit-form to capture an editable input for a field on a Salesforce object.

The component submits changes only if the record Id agrees with the specified object API name. If there's a mismatch, and the component includes lightning:messages, users see an error indicating the API name is invalid.

You must inform the objectApiName properties and optionally the recordIdand the list of fieldsto be displayed. As the recordId property is declared as public using the @api decorator, it is taken from the page where the LWC is placed.

The lightning-record-edit-form renders the fields within the HTML form element and uses a button for form submission.

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

</aside>

Also, a lightning:button component is included with an attribute of type="submit". When you press the Enter key or click the button, it validates the fields and submits the values.