Lately I’ve been on a Lightning component R&D kick focusing on building flexible, generic prototype components. My most recent work was building a readonly Record Display that’s configurable through a specified Field Set.
If you like what you see, try it out from my Lightning Prototypes Unmanaged Package.
The record display shows a one column display of fields from a given record using the lightning:outputField and lightning:recordViewForm components. One can declaratively use it on any record home page, specify the field set to use, and then it’ll show the fields the given user has access to. #ClicksNotCode!
- Create a field set on the object with the desired fields to display. Note: This can only be done in Classic at this time.
- Using the Lightning App Builder, add this to the desired record home page(s) and then enter the API name of the field set in the component’s “Field Set Name” attribute.
- Gives additional flexibility over the fields to display than a page layout.
- Field Level Security. If the user doesn’t have access to a field, it’s not shown and visible fields after it are still shown unlike the lightning:inputField in my Field Set Form V2 lightning component.
- Can have multiple on a record display for various use cases as needed.
- Minimal coding. Only some Apex is needed to get the field info from the field set. The recordViewForm and outputField components take care of querying the record and its fields and displaying the appropriate values.
- Prototype. Doesn’t have full styling, editing capabilities, and other expected features.
- One-Column Layout. Doesn’t support other layout types.
- More layout support. Would like to add multi-column support and possibly multi-section support too. Thought of seeing if the new UI API could be used here.
- Configuration through page layouts using the UI API for more expressive UI possibilities.
- Adding editing support.
What did you think of it?
Recently, Ryan Headley, a Salesforce MVP and a co-host of System Dot Debug, announced that System Dot Debug is accepting Lightning Components from the Salesforce developer community to share on their podcast. To submit components, one has to provide an unmanaged or managed package. View this tweet for details.
To share the components I’ve developed for learning purposes over the last year, I decided to create an unmanaged package for this. Below are the components included.
- Install the unmanaged package using either the Production / Developer Edition Installation Link or the Sandbox Installation Link
- See the Blog Posts below for configuration and other details.
Field Set Form Component
This component allows one to create a one column form of inputs for an Object whose fields are configurable via a field set. It allows one to create or edit a record and is generic enough for most objects.
See the Field Set Form Blog Post for more details.
Field Set Form V2 Component
This provides the same functionality as the Field Set Form above but was redesigned to use the new in Spring 18 lightning:inputField and lightning:recordEditForm components.
See the Field Set Form V2 Post for more details.
Lookup Dropdown Component
This component provides a dropdown of all the parent records for a specified lookup or master-detail on a child record.
See the Lookup Dropdown Post for more details.
Field Set Record Display Component
This component provides a one column readonly display of fields to shown on a record detail page. The fields and their order are configurable using a field set and this uses lightning:outputField and lightning:recordViewForm components.
See the Field Set Record Display Post for more details.
For learning purposes, I wanted to see if the new Lightning:recordEditForm component and Lightning:inputField component from the Spring 18 release can be used for a dynamic form. This leverages my previous Lightning Field Set Form work.
The Field Set Form V2 component creates a dynamic lightning form whose fields are configurable through a field set. It can be used to create or update a record and is relatively generic since it can be used for different objects and in different contexts in LEX.
For more information about the new lightning:recordEditView and lightning:inputField, see this post.
Let me know what you think in the comments below.
- The inputField component renders the appropriate input control based on the field’s underlying datatype. In the original Field Set Form, this was handled by us.
- No Apex Code for Loading and Saving the record. The recordEditForm is smart enough to automatically load the record if a record id is given for the specified fields.
- Record Type Specific Picklist Values Are Honored. When a picklist’s values are limited to a subset of the available ones for a given record type, it was very challenging to only grab these in Apex for a custom lightning component. Now, this is automatically supported.
- Dependent Picklists Supported. This is really nice because in the past this had to be implemented yourself.
- Field Level Security (Sort Of). According to the documentation, if the user doesn’t have access to the specified field, then it won’t display. This is buggy in my Dev org. When I remove access to a field, all the fields following it are not shown either despite being accessible.
- Proof-of-Concept Quality. This lacks production quality styling, test code, and user experience.
- Lightning:inputField FLS Bug. When the user doesn’t have access to a field, that field isn’t shown along with all the fields that follow it even if they are available.
- Lightning:inputField Class Bug. When I try to use different SLDS classes, they don’t seem to do anything. For example, when I try using “slds-m-top_medium” to add some spacing between the inputs, it’s not applied.
- The inputs used for a given field type are not determined by the component which is different from the original Lightning Field Set Form.
- Have to implement the various events to show a success toast, to reload the other components when saved, and have the component refresh when some other component saved the record.
Differences Between V1 and V2
- Error Handling is handled in V2 but not V1 thanks to the recordEditForm having the lightning:messages component.
- Loading and Saving the record is automatically handled by the recordEditForm.
Whenever possible, I leverage the out-of-the-box Salesforce functionality to implement the desired functionality. One Lightning development feature I’ve used recently is the e.force:editRecord event. In a Lightning component, you can fire this event with a record id and that record’s default edit page will open in a new modal.
That’s great and saves a lot of custom coding, if that’s acceptable. However, after someone edits the record successfully, you’ll want to probably take some action such as updating the display to show the latest edits.
Problem: The force:recordSaveSuccess and force:recordSave don’t fire after the record is edited successfully, at least in Winter 18.
Solution: Use the showToast event to take action after a record is edited successfully.
In the handleToastMessage function, the code is checking for a specific “object saved message” and if it’s found, some specific actions are taken.
If you have a better way of doing this, please let us know in the comments!
For learning purposes, I created a Lightning Field Set Form component that renders a one column form of inputs for a set of fields for a given SObject where the field inputs are driven by a specified field set on that object. This code was influenced by the How to use Field Sets with Lightning Stackoverflow post.
This component can be used to either update a record or create a new record.
Updating a Record
To update a record on a standard record page,
- Create a field set on the object that specifies the fields to edit.
- Place the FieldSetForm component on a record page and specify its Field Set Name on the designer tab.
To update a record from a custom component,
- Embed the <c:FieldSetForm /> in the custom component.
- Set the recordId and fieldSetName attributes with the record id and field set name to use.
Creating a Record
- Add the component to the desired location.
- In the designer, specify the object name and field set name.
- Needs to be enhanced to have better support for Relationship fields (Lookups & Master-Details), picklists, and multi-picklists, and probably other data types too.
- Needs apex test code written for it.
- Needs better error handling. It currently only shows the first error returned on save.
Notable Differences From StackOverFlow Post
- The handleValueChange method isn’t needed to bind the input values back to the record because the cmp.getReference(‘v.record’ + field.APIName) takes care of that automatically.
- There was a bug with the config where the same config was being used for the same type so if you had multiple fields with the same type, you’d see the same field multiple times. This was fixed by cloning the config for each field using the JSON.parse workaround.
- Added the ability to save the record back automatically with new and update support.
- Was able to eliminate the form attribute because all components inherit the body attribute.
This was created for learning purposes. Whenever possible, use other standard components that provide similar functionality like the force:recordEdit component that does similar functionality.
Apex Field Class