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.
- Record Type can’t be edited. Adding the record type will show a “Field: RecordTypeId is not a valid lookup field.” error.
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.