One slightly hidden gem in the Spring ’18 Release Notes is the introduction of two new Base Lightning Components—
lightning:inputField. In this blog post you’ll learn how to build your custom Lightning components even faster with these tools. But before we dig into the goodness provided by those components, let’s revisit where we’re coming from.
It took some time
When we first introduced Lightning, we provided developers with some basic components for entering and displaying fields according to data type. Those components reside in the
force namespace and are
force:outputField. Why are these components “basic”? Because you as a developer have to take care of things like field-level validation and styling these components to look like Lightning and use the Salesforce Lightning Design System (SLDS).
To address some of these gaps, we started to add Base Lightning Components to the mix. These components, which are in the
lightning namespace, automatically inherit the CSS rules of the Salesforce Lightning Design System (SLDS). They include, for example, automated input validation capabilities that can be configured via markup. With these new components, it’s possible to create and maintain Lightning applications much faster than with components from the
force namespace. Of course, you were still responsible for calling an Apex controller and handling the consumption of the data.
But that isn’t still enough…
Introducing lightning:recordEditForm and lightning:inputField
If you paid attention to the Winter ’18 Release Notes (you did, right?), you likely found the new Base Lightning Component
lightning:outputField. This component is the counterpart of the aforementioned
force:outputField but with a lot more metadata awareness and SLDS styling.
By just passing a record ID and the sObject API name as parameter values to the enclosing,
lightning:outputField automatically takes care of formatting the field values, displaying the field labels and so forth based on their sObject definitions.
And now with Spring ’18, we’re introducing
- Line 1: Instead of
lightning:recordEditFormas the encapsulating tag. This tag tells the system that editable content should be handled.
- Line 3: If you want to display error or validation messages to the end user (YES, you want to do that), you have to include
<lightning:messages />. However, you don’t have to define those messages, as the framework automatically takes care of that based on the sObject definition!
- Lines 4-8: You simply set the
fieldNameparameter for every
lightning:inputFieldand voilà—you get your SLDS-styled input field, including validation and label, derived from the field definition on the sObject.
- Line 9: For submitting the data to the backend, you have to add a button of type submit within the
This example is rather simple, but also shows the power and flexibility of
lightning:inputField. By passing only the record ID and the sObject API name, you no longer have to take care of:
- Base Lightning Component configuration
- label selection
- field level validation and error messaging
- field level security checks.
It’s all handled for you. But you may now wonder how you can combine
lightning:outputField. Let’s look at an example that pulls all this power together.
Adding Lightning Data Service to the mix
Users often need to update account information and they need to do this while on a variety of record pages. Thanks to the new Base Lightning Components, we can now build a single component to accomplish this, rather than building quick actions for objects just to use the standard Related Record component.
- Line 1: First we’re using the
force:hasRecordIdinterface on the component. This automatically adds an aura attribute recordId of type Id to the component.
- Line 16: Because we want to have a read and an edit mode for this component, we’re leveraging
aura:iffor conditional rendering.
- Line 17-21:
- Line 20: We’re passing the value provided by LDS to set the ‘recordId’ attribute for our form. No Apex needed.
ightning:recordEditFormautomatically handles the save process. In case of any errors
<lightning:messages />will take care of showing them in the UI.
Last but not least, it’s important to mention that LDS as well as
lightning:outputField are backed by our new UI API.
Where to learn more about lightning:recordEditForm and lightning:inputField
We’re investing heavily in making the Lightning development experience easier for you. By reducing the amount of code that needs to be written and focusing on metadata driven forms, you can now build custom Lightning components easier than ever before.
Here are some great resources that you should check out to get started:
- Lightning Data Service Basics on Trailhead
- Lightning Data Service documentation
- Lightning Data Service blog post
- lightning:outputField documentation
- lightning:inputField documentation
You can also find the example shown above in this GitHub repo, so feel free to install it into the Salesforce DX scratch org of your choice.
About the author
René Winkelmeyer works as Senior Developer Evangelist at Salesforce. He focuses on enterprise integrations, mobile, and security with the Lightning Platform. You can follow him on Twitter @muenzpraeger.