Lightning Universal Lookup Component Version 2.0

As always, our company does not wish to stop even for a second and trying to improve productsand services constantly. Here is the latest update, and we would like to introduce you a new version of the Lookup Field component. The new version has many interesting features and additional features for development.

First of all let us say a huge thank you for your feedbacks and propositions. According to our customers’ reviews we were able to determine specific requirements to the product and enhance it. Many of those who downloaded our Lightning Universal Lookup Component were anticipating a new version where we would include all requests and there it is.

The latest version has already passed a security review and is available on the AppExchange.
But let’s see what new you can spot there:

1. Handle Event from Lookup Component and execute your actions
Catch events and selected values changes when focus appears or goes. Execute your methods meanwhile.
In one of the feedbacks, one developer wrote that he needs to capture the event of changing the selected value in the link and perform his actions at the same time. Now it’s easy to implement.
In all three events there is a parameter cmpId — it returns aura:id specified in the component (after all, you can have several lookups in one component and this will allow to identify the field).
Similarly, the onChange event returns an additional attribute oldValue, which returns the previous value of the lookup.

Example of the onFocus event

Code to handle event:

<aura:handler name=”onblur”
event=”l_lookup:OnFocus”
action=”{!c.handleFocus}”/>

Attribute for selected value and lookup:

<aura:attribute name=”mySelectedId”
type=”String” />
<l_lookup:Lookup aura:id=”uniqueLookupId”
objectType=”Account”
selectedRecordId=”{!v.mySelectedId}” />

Action in controller:

handleFocus : function(cmp, event, helper) {
console.log(‘Lookup component Id: ‘ + event.getParam(“cmpId”));
}

Additional examples you may find in the documentation.

2. Ability to change selected value by code

This is very useful when you have to specify a default value for a particular action or condition. Sometimes there are such requirements that it becomes necessary to manipulate the value in the component through the code. Now it is possible. A new attribute and method has been added to the component.
Note: to use this feature, you need to specify aura:id, without it you can not evoke the method.
Attribute for changing value is setTo.
We have to check the validation of the selected value in Lookup before it will be changed.

For instance, there is an attribute queryCondition (described as a filter) where you can write a condition for filtering. In this case you can only select users with a profile * System Administrator *. At the same time, it is possible to change the selected value by coding (for example, there is a button, when you click it, the field is filled with the value *Name*)

If we have specified in the queryCondition that we can choose only the System Administrators and *Name* is not such — the value will not change, because (Name) does not fit the condition.
To change value by controller you need to add attribute setTo and execute method from lookup fireChanging(). Also for this you need to define aura:id.

E.g.:
Component:

<aura:attribute name=”selectedId”
type=”String”/>
<aura:attribute name=”changeTo”
type=”String” />
<l_lookup:Lookup aura:id=”lookupId”
objectType=”User”
setTo=”{!v.changeTo}”
selectedRecordId=”{!v.selectedId}” />

Action in controller to change record Id:

changeIt : function(cmp, event, helper) {
var newVal = cmp.get(“v.changeTo”);
cmp.set(“v.changeTo”, newVal);
cmp.find(“lookupId”).fireChanging();
}

Notice also:

• value will be not set if readOnly is true
• value will be not set if new value is invalid​
• value will be not set if you use queryCondition attribute and new value do not match criteria

3. Customizable additional field
Specify your additional field, which will be displayed under the name and used as an additional field for searching.
Previously, it used to work only for standard objects in accordance with how the standard lookup works in Salesforce.
Now you can specify your own field, which will be displayed under the name and be used as an additional field for searching.

For more information about limitations and opportunities, read the documentation.

4. Additional filter
You may easily select users of a specific profile or accounts with a certain record type.
Also, you may need to add a filter to the lookup.
For example, you can choose users of only a specific profile or cases of only a certain status and so on.
To do this, a new queryCondition attribute has been added, in which you can specify an additional search term.
Be careful when adding a condition and make sure that it does not contain syntax errors.

Example:

<l_lookup:Lookup aura:id=”uniqueLookupId”
objectType=”User”
selectedRecordId=”{!v.selectedUserId}”
queryCondition=”www.profile.name = ‘System Administrator‘“ />

Additional examples you may find in the documentation.

5. Exception handling
Avoid small mistakes. Now you can see the catch in the developer’s browser console where you will find a problem description and a solution hint.
When writing the code, there is a possibility to make some mistakes, for example, indicating not valid values in the attributes or to missing the required attribute.
In the new version, the component will tell you what’s going on. If there is an error interfering with the correct operation of the component, it will look like this:

In order to make an error description less intrusive was not interfering with the structure of the page, it is displayed in the developer’s browser console.
For example, an invalid value is specified in the additionalField:

<l_lookup:Lookup aura:id=”lookupId”
objectType=”Contact”
additionalField=”Emaiil”
selectedRecordId=”{!v.selectedId}”/>

A few less global, but also interesting innovations:

• Attribute isRequired includes red star by the label

• Attribute styleClass allows to add style grades to inputs

For more information you may read the documentation.

This article was originally published here by Anastasia Kovalchuk.

Editor: Anna Kryvulya