Introduction

The main concept showcased in this recipe is the lightning-record-view-form component, allowing the creation of a form that displays read-only fields associated with a record using their labels in the language of the user.

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

</aside>

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

</aside>

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

</aside>

Static vs Dynamic

There are 2 LWCs:

1. The statically imported version uses the full import ACCOUNT_FIELD from '@salesforce/schema/Contact.AccountId' path referenced to the Salesforce schema in the Javascript file and then in the template is included like this <lightning-output-field field-name={accountField}> .
2. The dynamically imported version**:** there is no import as such in the Javascript file, and in the template file the field is included using its name directly <lightning-output-field field-name="AccountId"> .

For both:

• You must inform the object-api-name variable and the record.id.
• lightning-output-field must be a child of lightning-record-view-form.
• You can't nest it in another component like lightning-layout though you can nest it in a <div> container within lightning-record-view-form.

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.

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

Several  lightning-output-field components are used inside the lightning-record-view-form to display the value of a record field.

<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-view-form
        object-api-name={objectApiName}
        record-id={recordId}>

        <lightning-output-field field-name={accountField}></lightning-output-field>
        <lightning-output-field field-name={nameField}></lightning-output-field>
        ...
    </lightning-record-view-form>
</div>

Javascript file for the static version