One slightly hidden gem in the Spring ’18 Release Notes is the introduction of two new Base Lightning Components—lightning:recordEditForm
and 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:inputField
and 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.
We addressed the aforementioned requirement of writing Apex by introducing Lightning Data Service (LDS), which went GA with our Winter ’18 release. Using LDS you are able to create, load, save, or delete a record by writing just a couple of lines of markup and a bit of JavaScript. The system automatically takes care of caching and permissions. No Apex needed. Let me repeat: no Apex needed. That also means no Apex tests needed. How cool is that?
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:recordViewForm
tag, 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 lightning:recordEditForm
and lightning:inputField
.
Code explanation:
- Line 1: Instead of
lightning:recordViewForm
we’re usinglightning:recordEditForm
as 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
fieldName
parameter for everylightning:inputField
and 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
lightning:recordEditForm
tag. This automatically updates the the database once pressed. No custom JavaScript and no Apex needed. You hear me? No custom JavaScript and no Apex needed!
This example is rather simple, but also shows the power and flexibility of lightning:recordEditForm
and 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:inputField
and 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.
Code explanation:
- Line 1: First we’re using the
force:hasRecordId
interface on the component. This automatically adds an aura attribute recordId of type Id to the component. - Lines 8-13: By using LDS in combination with the recordId attribute a lookup of the AccountId field is performed. The resulting object is stored in the aura attribute contactFields (line 5). This allows us to dynamically fetch the AccountId value from the Contact record without writing any Apex or JavaScript code!
- Line 16: Because we want to have a read and an edit mode for this component, we’re leveraging
aura:if
for conditional rendering. - Line 17-21:
lightning:recordEditForm
allows to automatically invoke custom JavaScript according to different circumstances, like when data is loaded, submitted, or after it has been saved. These calls are optional. - Line 20: We’re passing the value provided by LDS to set the ‘recordId’ attribute for our form. No Apex needed.
- Line 28: This is the button that kicks off the save process. Note that there is no onclick event defined and with that no custom JavaScript is called. By defining the type as submit, l
ightning:recordEditForm
automatically 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:inputField
and 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.