First, review the Lightning Web Component; each section shows the following use case:

• Use Case A shows the use of lightning-input-field.
• Use Case B shows the use of lightning-output-field.
• Use Case C shows the use of lightning-input.
• Use Case D shows the use of lightning-formatted-text.
• Use Case E shows the use of an SObject field expression.
• Use Case F shows the use of a controller property expression.

The following code fragments show the HTML used by the following Lightning Web Component (the controller code is also included in this chapter, but is not shown here for brevity). Each code fragment illustrates different ways to expose field values.

For Use Case A, the field references look like this:

<lightning-input-field 
  field-name={statusField}></lightning-input-field>
<lightning-input-field 
  field-name={fastestLapByField}></lightning-input-field>

For Use Case B, the field references look like this:

<lightning-output-field 
  field-name={statusField}></lightning-output-field>
<lightning-output-field 
  field-name={fastestLapByField}></lightning-output-field>

<lightning-input 
  type="text" value={race.Status__c} label='Status'>
</lightning-input>
<lightning-input 
  type="text" value={race.FastestLapBy__c} label='Fastest Lap By'
</lightning-input>

For Use Case D, the field references look like this:

<p>Status <lightning-formatted-text value={race.Status__c}></lightning-formatted-text></p>
<p>Fastest Lap By <lightning-formatted-text value={race.FastestLapBy__c}></lightning-formatted-text></p>

For Use Case E, the field references look like this:

<p>The value of Status__c is '{race.Status__c}'</p>
<p>The value of FastestLapBy__c is '{race.FastestLapBy__c}'</p>

For Use Case F, the field references look like this:

<p>The value of Status__c is '{status}'</p>
<p>The value of FastestLapBy__c is '{fastestLapBy}'</p>

To make it easier to understand the effects of field-level security, the component outputs debug text at the top of the component to confirm the current field access configured for the user. As you can see, in each case, the visibility and editability for both of the fields aligns with the current user's field-level security, as they have full read and write access to the field values. The following screenshot shows how the UI reacts when the user has full access:

In contrast to the preceding scenario, the following screenshot and explanations confirm how the same component code reacts and displays to a user who has reduced field access; it shows that in some cases, the Fastest Lap By field has been hidden and that the Status field is read-only. Notice that this is not the case for all use cases shown:

• For Use Case C, the field is read only, so its value is accessible and placed in the input field. As it is a lightning-input field, it does not honor the field-level security status of the field and the field is editable when it should not be.
• For Use Case E and Use Case F, the FastedLapBy__c field value is shown because neither SObject field bindings or bindings to controller properties will enforce field-level security. In this case, the responsibility lies with the developer to check the field-level security in the controller code.

The following screenshot shows how the UI reacts for a user with reduced field access:

Using the lightning-input-field and lightning-output-field components is not only the best way to ensure that field-level security is enforced without any code, but they also bring with them additional features, such as formatting field values such as currency values, translating record IDs to record names, and showing drop-down lists for picklist fields.