while I'm going through the tutorial on Lightning Data Service, I can see that they use force:record data to perform all the CRUD operation and eliminate the need to write apex controller. but I did not understand the following syntax they use for it.

Please look at this link


 <aura:attribute name="newContact" type="Object"/>
<aura:attribute name="simpleNewContact" type="Object"/>
<aura:attribute name="newContactError" type="String"/>

<aura:handler name="init" value="{!this}" action="{!c.doInit}"/>

<force:recordData aura:id="contactRecordCreator" 
                  targetError="{!v.newContactError}" />

My question is: why are we defining two attributes namely newContact and simpleNewContact of type "Object" and assigning newContact in targetRecord and and simpleNewContact in targetField and why not use a single attribute named simpleNewContact alone.what is the purpose of newContact. also I'm searching for the definition targetRecord,targetFields,targetError please provide any link that explains in detail.

  • 2
    This change was introduced when the Dataservice was out from pilot .Using the targetRecord the syntax was too longer and the targetFields simplified it further .Recommend using targetFields and you can drop the tragetRecord . – Mohith Shrivastava Jan 8 '18 at 13:42
  • Hi Mohith Shrivastava, Thank you. So we can ignore the attribute target Record and we not create the attribute called newContact. Please confirm. – Prasanth Srinivasan Jan 9 '18 at 4:36
  • 1
    @MohithShrivastava I think your comment is better than my answer so would be worth posting as an answer that can be accepted... – Keith C Jan 9 '18 at 8:28

There is some description of targetFields in the Lightning Data Service (Beta) release notes:

force:recordData includes a new attribute called targetFields, which is populated with a simplified view of the record’s fields. targetFields is automatically updated whenever Lightning Data Service detects a record change. v.targetFields.Name is equivalent to v.targetRecord.fields.Name.value. A simple way to update force:recordPreview usage to force:recordData is to change references from targetRecord to targetFields.

So its worth setting up this attribute so you have a more convenient way to reference the fields in your component e.g.:


instead of:


so getting rid of .fields and .value that would otherwise have to be present in every reference in the markup. Essentially force:recordData is keeping two JavaScript data structures in sync for you, where the targetFields one is generally easier and cleaner to use in the component markup.

(And it also makes replacing force:recordPreview with force:recordData simple.)


Mohith's comment on your question contains a key point that I didn't know that makes things clearer: "Recommend using targetFields and you can drop the targetRecord". So the point is that targetRecord is only there for backward compatibility and new code is best written using targetFields only. Suggest you prompt him to post that as an answer and accept that answer instead.

  • Hi Keith C, Thank you.But what is the purpose of this target fields. Since I can only see they have assigned a value to it but they haven't used it anywhere.Is it mandatory to assign targetFields when using force:recordData. Please clarify my question. – Prasanth Srinivasan Jan 9 '18 at 4:45
  • @PrasanthSrinivasan See the "PS" in the answer. – Keith C Jan 9 '18 at 8:27
  • @MohithShrivastava +1 from me. – Keith C Jan 9 '18 at 9:52

This change was introduced when the Dataservice was out from pilot .Using the targetRecord the syntax was too longer and the targetFields simplified it further .Recommend using targetFields and you can drop the tragetRecord .targetRecord is kept only for backward compatibility reasons .

  • Thank You. now I understood clearly. I have also tried removing targetRecord from my code and it works good. – Prasanth Srinivasan Jan 9 '18 at 10:42

I was really interested in this question and finally found another valid answer while solving a problem.

I found one major difference between targetRecord and targetFields that just saved me a couple hours and additional coding:

targetRecord contains the objects api name.

var myRecord= cmp.get("v.targetRecord");
var sObjectType = myRecord.apiName;

What makes it possible to get the SObjectType for any Id in Lightning. This is so useful and helps to stay away from additional code and apex controllers while writing generic components, especially when implements="force:hasSObjectName" is not an option.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.