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.
In Salesforce, a custom permission allows one to define whether or not a user has access to some custom feature declaratively through profiles and permission sets.
When custom permissions originally came out, one could only “easily” check if a user had access through Visualforce, Formula Fields, or Validation Rules. One could check in Apex through querying some system Objects but that was not as “easy”. Andy Fawcett’s Native Apex support for Custom Permissions idea show’s the exact usage and why he requested that it be easier.
Recently, I discovered that Salesforce did provide an easier way through the native “FeatureManagement” Apex API and it’s as easy as calling the “checkPermission” function.
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.