force:hasRecordId cascade?
up vote
2
down vote
favorite
I am looking for verification/documentation on force:hasRecordId. It appears from my experience that recordId is only provided to the "container" component, and it does not feed down to any child components without explicitly passing the value.
Is that right?
BTW, I've read the docs here. They don't address my question.
lightning-components
add a comment |
up vote
2
down vote
favorite
I am looking for verification/documentation on force:hasRecordId. It appears from my experience that recordId is only provided to the "container" component, and it does not feed down to any child components without explicitly passing the value.
Is that right?
BTW, I've read the docs here. They don't address my question.
lightning-components
Can you clarify with a snippet what you think it needs vs what you hope it does?
– Sebastian Kessel
Dec 4 at 18:38
@SebastianKessel, I have a component that is the 3rd great-grandchild (3gg.cmp) of my container component. I need 3gg.cmp to be aware of the recordId of the page it's on. Using force:hasRecordId doesn't work in this context. Instead, I have to put force:hasRecordId in the outermost component, and cascade the recordId value to each child component all the way down to 3gg.cmp. (I'm going to be explaining this to a group soon, and I wanted complete clarity so I'm not spewing BS.)
– PatMcClellan__c
Dec 5 at 19:11
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am looking for verification/documentation on force:hasRecordId. It appears from my experience that recordId is only provided to the "container" component, and it does not feed down to any child components without explicitly passing the value.
Is that right?
BTW, I've read the docs here. They don't address my question.
lightning-components
I am looking for verification/documentation on force:hasRecordId. It appears from my experience that recordId is only provided to the "container" component, and it does not feed down to any child components without explicitly passing the value.
Is that right?
BTW, I've read the docs here. They don't address my question.
lightning-components
lightning-components
asked Dec 4 at 18:36
PatMcClellan__c
659217
659217
Can you clarify with a snippet what you think it needs vs what you hope it does?
– Sebastian Kessel
Dec 4 at 18:38
@SebastianKessel, I have a component that is the 3rd great-grandchild (3gg.cmp) of my container component. I need 3gg.cmp to be aware of the recordId of the page it's on. Using force:hasRecordId doesn't work in this context. Instead, I have to put force:hasRecordId in the outermost component, and cascade the recordId value to each child component all the way down to 3gg.cmp. (I'm going to be explaining this to a group soon, and I wanted complete clarity so I'm not spewing BS.)
– PatMcClellan__c
Dec 5 at 19:11
add a comment |
Can you clarify with a snippet what you think it needs vs what you hope it does?
– Sebastian Kessel
Dec 4 at 18:38
@SebastianKessel, I have a component that is the 3rd great-grandchild (3gg.cmp) of my container component. I need 3gg.cmp to be aware of the recordId of the page it's on. Using force:hasRecordId doesn't work in this context. Instead, I have to put force:hasRecordId in the outermost component, and cascade the recordId value to each child component all the way down to 3gg.cmp. (I'm going to be explaining this to a group soon, and I wanted complete clarity so I'm not spewing BS.)
– PatMcClellan__c
Dec 5 at 19:11
Can you clarify with a snippet what you think it needs vs what you hope it does?
– Sebastian Kessel
Dec 4 at 18:38
Can you clarify with a snippet what you think it needs vs what you hope it does?
– Sebastian Kessel
Dec 4 at 18:38
@SebastianKessel, I have a component that is the 3rd great-grandchild (3gg.cmp) of my container component. I need 3gg.cmp to be aware of the recordId of the page it's on. Using force:hasRecordId doesn't work in this context. Instead, I have to put force:hasRecordId in the outermost component, and cascade the recordId value to each child component all the way down to 3gg.cmp. (I'm going to be explaining this to a group soon, and I wanted complete clarity so I'm not spewing BS.)
– PatMcClellan__c
Dec 5 at 19:11
@SebastianKessel, I have a component that is the 3rd great-grandchild (3gg.cmp) of my container component. I need 3gg.cmp to be aware of the recordId of the page it's on. Using force:hasRecordId doesn't work in this context. Instead, I have to put force:hasRecordId in the outermost component, and cascade the recordId value to each child component all the way down to 3gg.cmp. (I'm going to be explaining this to a group soon, and I wanted complete clarity so I'm not spewing BS.)
– PatMcClellan__c
Dec 5 at 19:11
add a comment |
1 Answer
1
active
oldest
votes
up vote
6
down vote
accepted
I think the documentation covers it, but it's not very explicit and relies on us to read into a couple of key words that aren't obviously key words.
A marker interface is a signal to the component’s container to add the interface’s behavior to the component
Emphasis mine. Later,
Important The
recordId
attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home.
Emphasis again mine.
So if we have Components A and B, here:
componentA.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB />
</aura:component>
componentB.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
{! v.recordId }
</aura:component>
You get no output if you place this on a record page. (I did validate this directly).
But if componentA
, which is componentB
's container, supplies the record Id:
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB recordId="{! v.recordId }" />
</aura:component>
You will indeed observe the output.
Only componentA
is in an "explicit record context", which the documentation implicitly defines for us as a record page container or use as an object-specific action.
componentB
is not in an explicit record context (it could be anywhere) and requires its container, componentA
, to provide the recordId
.
Another wonderful answer, David. I wish I had grokked what the OP needed with as little input as you did
– Sebastian Kessel
Dec 4 at 23:29
@David Reed, thanks for the clarity. So there's really no point in adding force:hasRecordId to child components, as you have to explicitly pass the recordId from the parent anyway. And in that context, recordId isn't a magic word, it's just an attribute name. Correct?
– PatMcClellan__c
Dec 5 at 19:07
@PatMcClellan__c I agree in the sense that it is not magic. I could see adding the interface to a reusable component that might be used both within some custom container (which would explicitly supply the record Id) or be placed directly on a record page. At worst, it does no harm; I think it's case-specific whether you'd want to use it.
– David Reed
Dec 5 at 19:12
@DavidReed, good point on reusability. Thanks again for your clarity on this.
– PatMcClellan__c
Dec 5 at 19:14
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
I think the documentation covers it, but it's not very explicit and relies on us to read into a couple of key words that aren't obviously key words.
A marker interface is a signal to the component’s container to add the interface’s behavior to the component
Emphasis mine. Later,
Important The
recordId
attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home.
Emphasis again mine.
So if we have Components A and B, here:
componentA.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB />
</aura:component>
componentB.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
{! v.recordId }
</aura:component>
You get no output if you place this on a record page. (I did validate this directly).
But if componentA
, which is componentB
's container, supplies the record Id:
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB recordId="{! v.recordId }" />
</aura:component>
You will indeed observe the output.
Only componentA
is in an "explicit record context", which the documentation implicitly defines for us as a record page container or use as an object-specific action.
componentB
is not in an explicit record context (it could be anywhere) and requires its container, componentA
, to provide the recordId
.
Another wonderful answer, David. I wish I had grokked what the OP needed with as little input as you did
– Sebastian Kessel
Dec 4 at 23:29
@David Reed, thanks for the clarity. So there's really no point in adding force:hasRecordId to child components, as you have to explicitly pass the recordId from the parent anyway. And in that context, recordId isn't a magic word, it's just an attribute name. Correct?
– PatMcClellan__c
Dec 5 at 19:07
@PatMcClellan__c I agree in the sense that it is not magic. I could see adding the interface to a reusable component that might be used both within some custom container (which would explicitly supply the record Id) or be placed directly on a record page. At worst, it does no harm; I think it's case-specific whether you'd want to use it.
– David Reed
Dec 5 at 19:12
@DavidReed, good point on reusability. Thanks again for your clarity on this.
– PatMcClellan__c
Dec 5 at 19:14
add a comment |
up vote
6
down vote
accepted
I think the documentation covers it, but it's not very explicit and relies on us to read into a couple of key words that aren't obviously key words.
A marker interface is a signal to the component’s container to add the interface’s behavior to the component
Emphasis mine. Later,
Important The
recordId
attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home.
Emphasis again mine.
So if we have Components A and B, here:
componentA.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB />
</aura:component>
componentB.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
{! v.recordId }
</aura:component>
You get no output if you place this on a record page. (I did validate this directly).
But if componentA
, which is componentB
's container, supplies the record Id:
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB recordId="{! v.recordId }" />
</aura:component>
You will indeed observe the output.
Only componentA
is in an "explicit record context", which the documentation implicitly defines for us as a record page container or use as an object-specific action.
componentB
is not in an explicit record context (it could be anywhere) and requires its container, componentA
, to provide the recordId
.
Another wonderful answer, David. I wish I had grokked what the OP needed with as little input as you did
– Sebastian Kessel
Dec 4 at 23:29
@David Reed, thanks for the clarity. So there's really no point in adding force:hasRecordId to child components, as you have to explicitly pass the recordId from the parent anyway. And in that context, recordId isn't a magic word, it's just an attribute name. Correct?
– PatMcClellan__c
Dec 5 at 19:07
@PatMcClellan__c I agree in the sense that it is not magic. I could see adding the interface to a reusable component that might be used both within some custom container (which would explicitly supply the record Id) or be placed directly on a record page. At worst, it does no harm; I think it's case-specific whether you'd want to use it.
– David Reed
Dec 5 at 19:12
@DavidReed, good point on reusability. Thanks again for your clarity on this.
– PatMcClellan__c
Dec 5 at 19:14
add a comment |
up vote
6
down vote
accepted
up vote
6
down vote
accepted
I think the documentation covers it, but it's not very explicit and relies on us to read into a couple of key words that aren't obviously key words.
A marker interface is a signal to the component’s container to add the interface’s behavior to the component
Emphasis mine. Later,
Important The
recordId
attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home.
Emphasis again mine.
So if we have Components A and B, here:
componentA.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB />
</aura:component>
componentB.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
{! v.recordId }
</aura:component>
You get no output if you place this on a record page. (I did validate this directly).
But if componentA
, which is componentB
's container, supplies the record Id:
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB recordId="{! v.recordId }" />
</aura:component>
You will indeed observe the output.
Only componentA
is in an "explicit record context", which the documentation implicitly defines for us as a record page container or use as an object-specific action.
componentB
is not in an explicit record context (it could be anywhere) and requires its container, componentA
, to provide the recordId
.
I think the documentation covers it, but it's not very explicit and relies on us to read into a couple of key words that aren't obviously key words.
A marker interface is a signal to the component’s container to add the interface’s behavior to the component
Emphasis mine. Later,
Important The
recordId
attribute is set only when you place or invoke the component in an explicit record context. For example, when you place the component directly on a record page layout, or invoke it as an object-specific action from a record page or object home.
Emphasis again mine.
So if we have Components A and B, here:
componentA.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB />
</aura:component>
componentB.cmp
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
{! v.recordId }
</aura:component>
You get no output if you place this on a record page. (I did validate this directly).
But if componentA
, which is componentB
's container, supplies the record Id:
<aura:component implements="flexipage:availableForRecordHome,force:hasRecordId" access="global" >
<c:componentB recordId="{! v.recordId }" />
</aura:component>
You will indeed observe the output.
Only componentA
is in an "explicit record context", which the documentation implicitly defines for us as a record page container or use as an object-specific action.
componentB
is not in an explicit record context (it could be anywhere) and requires its container, componentA
, to provide the recordId
.
edited Dec 4 at 19:47
answered Dec 4 at 19:00
David Reed
27.8k61746
27.8k61746
Another wonderful answer, David. I wish I had grokked what the OP needed with as little input as you did
– Sebastian Kessel
Dec 4 at 23:29
@David Reed, thanks for the clarity. So there's really no point in adding force:hasRecordId to child components, as you have to explicitly pass the recordId from the parent anyway. And in that context, recordId isn't a magic word, it's just an attribute name. Correct?
– PatMcClellan__c
Dec 5 at 19:07
@PatMcClellan__c I agree in the sense that it is not magic. I could see adding the interface to a reusable component that might be used both within some custom container (which would explicitly supply the record Id) or be placed directly on a record page. At worst, it does no harm; I think it's case-specific whether you'd want to use it.
– David Reed
Dec 5 at 19:12
@DavidReed, good point on reusability. Thanks again for your clarity on this.
– PatMcClellan__c
Dec 5 at 19:14
add a comment |
Another wonderful answer, David. I wish I had grokked what the OP needed with as little input as you did
– Sebastian Kessel
Dec 4 at 23:29
@David Reed, thanks for the clarity. So there's really no point in adding force:hasRecordId to child components, as you have to explicitly pass the recordId from the parent anyway. And in that context, recordId isn't a magic word, it's just an attribute name. Correct?
– PatMcClellan__c
Dec 5 at 19:07
@PatMcClellan__c I agree in the sense that it is not magic. I could see adding the interface to a reusable component that might be used both within some custom container (which would explicitly supply the record Id) or be placed directly on a record page. At worst, it does no harm; I think it's case-specific whether you'd want to use it.
– David Reed
Dec 5 at 19:12
@DavidReed, good point on reusability. Thanks again for your clarity on this.
– PatMcClellan__c
Dec 5 at 19:14
Another wonderful answer, David. I wish I had grokked what the OP needed with as little input as you did
– Sebastian Kessel
Dec 4 at 23:29
Another wonderful answer, David. I wish I had grokked what the OP needed with as little input as you did
– Sebastian Kessel
Dec 4 at 23:29
@David Reed, thanks for the clarity. So there's really no point in adding force:hasRecordId to child components, as you have to explicitly pass the recordId from the parent anyway. And in that context, recordId isn't a magic word, it's just an attribute name. Correct?
– PatMcClellan__c
Dec 5 at 19:07
@David Reed, thanks for the clarity. So there's really no point in adding force:hasRecordId to child components, as you have to explicitly pass the recordId from the parent anyway. And in that context, recordId isn't a magic word, it's just an attribute name. Correct?
– PatMcClellan__c
Dec 5 at 19:07
@PatMcClellan__c I agree in the sense that it is not magic. I could see adding the interface to a reusable component that might be used both within some custom container (which would explicitly supply the record Id) or be placed directly on a record page. At worst, it does no harm; I think it's case-specific whether you'd want to use it.
– David Reed
Dec 5 at 19:12
@PatMcClellan__c I agree in the sense that it is not magic. I could see adding the interface to a reusable component that might be used both within some custom container (which would explicitly supply the record Id) or be placed directly on a record page. At worst, it does no harm; I think it's case-specific whether you'd want to use it.
– David Reed
Dec 5 at 19:12
@DavidReed, good point on reusability. Thanks again for your clarity on this.
– PatMcClellan__c
Dec 5 at 19:14
@DavidReed, good point on reusability. Thanks again for your clarity on this.
– PatMcClellan__c
Dec 5 at 19:14
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f241412%2fforcehasrecordid-cascade%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Can you clarify with a snippet what you think it needs vs what you hope it does?
– Sebastian Kessel
Dec 4 at 18:38
@SebastianKessel, I have a component that is the 3rd great-grandchild (3gg.cmp) of my container component. I need 3gg.cmp to be aware of the recordId of the page it's on. Using force:hasRecordId doesn't work in this context. Instead, I have to put force:hasRecordId in the outermost component, and cascade the recordId value to each child component all the way down to 3gg.cmp. (I'm going to be explaining this to a group soon, and I wanted complete clarity so I'm not spewing BS.)
– PatMcClellan__c
Dec 5 at 19:11