I have a force:inputField
field on my lightning component acting as a lookup. It is working fine:
<force:inputField aura:id="segmentid" value="{!v.campaign.Survey__c}"/>
<ui:button press="{!c.selectSurvey}">Add Survey</ui:button>
The controller looks up the record information, displays it on the page, and then the callback should clear the force:inputField
so the user can add another record. This is what I have tried:
var forceChange = cmp.get("v.campaign");
forceChange.Survey__c = "" ;
cmp.set("v.campaign", forceChange);
I have also tried clearing/setting the v.value
and v.text
of the object but that doesnt seem to work:
cmp.find("segmentid").set("v.value", "");
cmp.find("segmentid").set("v.text", "");
Out of desperation I tried to force a refresh on both methods to no effect:
$A.get('e.force:refreshView').fire();
I'm out of ideas but I need this to work.
Best Answer
Theoretically it should be possible to clear values on
force:inputField
. But in your specific case it seems not to work as expected.force:inputField
is a smart field component operating on different field types differently. For bound plain text fields the reset works while for lookups attribute updates are not rendered correctly.Known Weakpoints
There are lots of posts here and elsewhere indicating that
force:inputField
has several flaws. I personally tried it about two years ago an then gave up on it. In the meantime however it looks improved a bit. But I would definitely suggest to use it carefully.The way you are using
cmp.get()
andset()
looks correct. But my experience with Lightning is: even small typos might end up to a ignored-behaviour with no errors so debugging is a challenge.Also the Lightning Component Roadmap shows two planned components
lightning:inputField
andlightning:lookup
. Now my interpretations of that is, that Salesforce is aware of the limitations of the currentforce:inputField
and is working on a successor.Issue Isolation
I would start to isolate the issue and extract it out of your given scenario into a new puristic test compo using only stanard objects, like Contact with the AccountId lookup. Then you'll have short code to post here in full length (as @crmprogdev suggested) and at the same time ruled out a bunch of possible side effects.
I've tried this already, but the results aren't looking very promising (see below). Therefore I would recommend to search for solutions without
force:inputField
.Alternatives
Instead of
force:inputField
you could try to:I haven't tested the these examples yet.
My attempts using force:inputField
I've played around a bit using that markup
With this Apex invoked in an init-handler and the result assigned to v.Contact
My observations are
force:inputField
bound to text fields like FirstName get populatedforce:inputField
bound to Salutation (picklist) gets populatedui:input
bound to Account.Name gets populatedforce:inputField
bound to AccountId (lookup) doesn't get populatedBut you can use the UI to pick an Account:
Now back to you scenario in an onclick-handler after manually populating the Account lookup:
This inconsistent behavior looks like a bug and verifies your observation.
My idea to work around it was to dynamically create the
force:inputField
using$A.createComponent()
in a handler and then destroy and recreate the inputField when you need to clear it.https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/js_cb_dynamic_cmp_async.htm
I've tried this
Unfortunately this only brings up:
Conclusion
I looks like you have to implement your own lookup compo to get what you need. Possibly it's worth to test the W18 update for improvements.