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?
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.
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
Salesforce has a feature known as field sets. A field set is a group of fields on an object that is declaratively defined by a user. The field set’s common purpose is to decide which fields to display on a web page for editing on a form or for read only.
Salesforce documentation covers getting started with field sets. We’ll cover the good, the bad, and the ugly of field sets here.
- Ease-of-Use. Salesforce makes it easy to use within VisualForce.
- An object can have multiple field sets that can be used for various purposes.
- Objects can have as many field sets as needed.
- Adding or removing a field to be edited or displayed is as easy as adding or removing it from the field set. This allows easier maintenance of the application as requirements change over time.
- Parent Fields Supported. One can include fields from parent objects. For example, a Contact field set may include fields from the Account.
- Required Fields. Fields can be marked as required so one must fill them out on a form.
- Only One Level of Parent Fields Supported. In SOQL, up to 5 parent levels are supported. It would be nice to have that level of flexibility with field sets. One workaround is to create one or more formula fields on the given object or parent object to grab the additional information and then use the formula field in the field set.
- Easy To Break. Its flexibility is also a weakness. It allows one to remove fields that may be always needed in order for functionality to work. One workaround for this is to have a separate list of always required fields that are merged with the field set’s fields to ensure they aren’t removed.
As an architect, I have to know the capabilities as well as the limitations of the technologies available. Here are the limitations as I see them:
- Read-Only Fields. It’s nice to mark fields as Required. Having the ability to mark a field as read-only would be great so that one can more easily have a mixture of editable and read-only fields on a section of a page. Upvote the Specify a field as readonly in a fieldset idea and hopefully, Salesforce will implement this much needed feature.
- Can’t Add Attributes. One can’t add additional data attributes to the field sets. For example, I may want to add layout information or custom labels that may differ for the same field across field sets. One way to workaround this is to create your own metadata, associate it to a given field in a field set, and have the application combine the metadata at runtime to do the desired behavior.
What’s the good, the bad, and the ugly of field sets for you?