Sample Student App revisited with Lightning:recordForm

by | Sep 21, 2018 | Lightning | 0 comments

In this post, I am gonna show how we can implement our sample student app in an easier way. I know using Lightning Data Service (LDS) was easy enough but this is even easier and a faster way to implement simple forms for your standard as well as custom objects. We are gonna do that using lightning:recordForm

Using LDS, retrieving or saving data was a piece of cake. You just needed to tell the LDS what information (fields) you would like to retrieve and it would do all the heavy lifting for you. You didn’t even have to bat an eye (NO APEX controller). But LDS has a an elder cousin, the lightning:recordForm, which goes an extra mile by taking care of the form design as well. What it means is, in LDS you had to bind your LDS information with the input controls like textbox, checkbox etc., but now you dont need to do even that. Let’s see how.

This is how our lightning component looks like in the markup. And that’s the end of it. Yes. No helper.js, no controller.js. Though you can have it if you want a bit of customisation. But trust me, this is enough to get your work done. Looks similar to LDS right? That’s because it is. This base component is built on top of the force:recordData base component. But in addition to handling your data, it also takes care of your UI. Wanna see how it looks in action? You won’t be able to tell the difference from your default record view. Here it goes.

See how simple that was? It even does a bit of validation as well. A single component to view as well as edit the record. What more do you want?

Now lets dissect this markup (even though it is so simple!)

1. objectApiName: Isn’t it obvious enough? whatever record it is, you need to specify the object api name of the record. In this case, it is Student__c but we have made this component generic by implementing force:hasSobjectName interface. This interface provides us with an attribute sObjectName which gives us the API name of the object.

2. recordId: This is needed in case you want to show the record or update the record. If you wanna create a new record then just like what you did in LDS, dont use this attribute.

3. fields: This is where you mention which fields you would like to display on the form. Here I have used an attribute for this purpose. It is a list.

4. mode: Now this is what decides how the form will behave. Here we have used the view mode. So it lets us see the record but it also allows us to edit it. The other two modes are edit and readonly. edit mode lets you edit the data and it is visible in an editable view. readonly mode only allows you to see the record. You cant edit it.

5. layoutType: I haven’t used it here but this is similar to LDS. It has two values Full and Compact and it essentially does the same thing as LDS. It displays fields from Full page layout and Compact layout respectively. This can be used in conjunction with fields

6. Columns: contains an integer value specifying the number of columns you want your fields to be divided in. default is 1.

7. onload, onsubmit, onerror, onsuccess: These attributes let you specify handlers for these events respectively. Usually we can display messages or can perform additional functions if required.

8. recordTypeId: If your object has multiple record types then you need to mention it otherwise the default recordType will be used.

 

That’s it folks! Now you know how to create an editable form in minutes without sweating! Let me know your thoughts and/or questions.

 

Bishwambhar Sen
Bishwambhar Sen is an IT professional with over 10 years of industry experience. He is a Salesforce certified developer and admin. When he is not configuring and customising, he loves photography, traveling and blogging.
Subscribe To Our Newsletter

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

You have Successfully Subscribed!

Share This