How can we expose inherited properties from a super component’s class in a lightning Web Components through...












8















Is there currently a way of exposing properties inherited from super classes in Lightning Web Components, as design attributes (targetConfigs), or is this a gap? I’m inheriting base classes which themselves ultimately inherit from LightningElement but those which I’ve configured to display as design time attributes in the sub most class aren’t showing up in the editors.










share|improve this question

























  • Please could you edit your question and provide a code example of what your doing and what you'd like to achieve?

    – Robs
    Jan 28 at 15:03













  • Welcome Dafydd! Does your sub class component have a meta file or are you expecting the meta file for the super component to be read?

    – citizen conn
    Jan 28 at 15:18
















8















Is there currently a way of exposing properties inherited from super classes in Lightning Web Components, as design attributes (targetConfigs), or is this a gap? I’m inheriting base classes which themselves ultimately inherit from LightningElement but those which I’ve configured to display as design time attributes in the sub most class aren’t showing up in the editors.










share|improve this question

























  • Please could you edit your question and provide a code example of what your doing and what you'd like to achieve?

    – Robs
    Jan 28 at 15:03













  • Welcome Dafydd! Does your sub class component have a meta file or are you expecting the meta file for the super component to be read?

    – citizen conn
    Jan 28 at 15:18














8












8








8


2






Is there currently a way of exposing properties inherited from super classes in Lightning Web Components, as design attributes (targetConfigs), or is this a gap? I’m inheriting base classes which themselves ultimately inherit from LightningElement but those which I’ve configured to display as design time attributes in the sub most class aren’t showing up in the editors.










share|improve this question
















Is there currently a way of exposing properties inherited from super classes in Lightning Web Components, as design attributes (targetConfigs), or is this a gap? I’m inheriting base classes which themselves ultimately inherit from LightningElement but those which I’ve configured to display as design time attributes in the sub most class aren’t showing up in the editors.







lightning-web-components inheritance design-attributes






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 28 at 13:37







Dafydd Johns

















asked Jan 28 at 12:17









Dafydd JohnsDafydd Johns

586




586













  • Please could you edit your question and provide a code example of what your doing and what you'd like to achieve?

    – Robs
    Jan 28 at 15:03













  • Welcome Dafydd! Does your sub class component have a meta file or are you expecting the meta file for the super component to be read?

    – citizen conn
    Jan 28 at 15:18



















  • Please could you edit your question and provide a code example of what your doing and what you'd like to achieve?

    – Robs
    Jan 28 at 15:03













  • Welcome Dafydd! Does your sub class component have a meta file or are you expecting the meta file for the super component to be read?

    – citizen conn
    Jan 28 at 15:18

















Please could you edit your question and provide a code example of what your doing and what you'd like to achieve?

– Robs
Jan 28 at 15:03







Please could you edit your question and provide a code example of what your doing and what you'd like to achieve?

– Robs
Jan 28 at 15:03















Welcome Dafydd! Does your sub class component have a meta file or are you expecting the meta file for the super component to be read?

– citizen conn
Jan 28 at 15:18





Welcome Dafydd! Does your sub class component have a meta file or are you expecting the meta file for the super component to be read?

– citizen conn
Jan 28 at 15:18










1 Answer
1






active

oldest

votes


















5














tl;dr:
Currently, this is currently a gap.



From the pure perspective of accessibility, @api enabled properties of a LWC are inherited from parent to child. This is standard JS prototype inheritance at work.



You've probably found this. But when setting the config for design attribute in the metadata file to be connected to an inherited property, you get the following error:




The 'propName' property doesn't exist on the component.




Here's a test case to try:



A parent LWC module, and for sake of simplicity, an empty template/markup file.



//parentInheritance.js
import { LightningElement, api } from 'lwc';

export default class ParentInheritance extends LightningElement {

@api parentProp;

}


A child LWC extending the parent component with a template referencing both its own prop, and the child.



//childInheritance.js
import { api } from 'lwc';
import ParentInheritance from 'c/parentInheritance';

export default class ChildInheritance extends ParentInheritance {

@api childProp;

}

//childInheritance.html
<template>
<lightning-card>
<p>{childProp}</p>
<p>{parentProp}</p>
</lightning-card>
</template>


Then we compose some UI on another component by sticking c/childInheritance component there, it works fine:



<template>
<c-child-inheritance
child-prop="Child Value 1"
parent-prop="Parent Value 2">
</c-child-inheritance>
</template>


But when I attempt to add it to the app builder config section of my metadata file, I get the "property does not exist" error above. Here's what that would look like.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


As a workaround, you could create a kind of proxy @api exposed property that you map to the meta config file.



export default class ChildInheritance extends ParentInheritance {

@api childProp;
@api parentProxyProp;

connectedCallback(){
if (!this.parentProp) {
this.parentProp = this.parentProxyProp;
}
}

}


Then you reference parentProxyProp in metadata.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProxyProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


This has a side-effect, though: you now have a new property that's only meant as a pass-through to connect up the child to the parent prop. Someone could attempt to use it, so not perfect, and you'd need to plan for that accordingly.



This gap is known by the LWC team, but roadmap for when it will be addressed has not been announced.






share|improve this answer
























  • Thank you for the detailed answer Peter!

    – Dafydd Johns
    Jan 28 at 17:37











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f248180%2fhow-can-we-expose-inherited-properties-from-a-super-component-s-class-in-a-light%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









5














tl;dr:
Currently, this is currently a gap.



From the pure perspective of accessibility, @api enabled properties of a LWC are inherited from parent to child. This is standard JS prototype inheritance at work.



You've probably found this. But when setting the config for design attribute in the metadata file to be connected to an inherited property, you get the following error:




The 'propName' property doesn't exist on the component.




Here's a test case to try:



A parent LWC module, and for sake of simplicity, an empty template/markup file.



//parentInheritance.js
import { LightningElement, api } from 'lwc';

export default class ParentInheritance extends LightningElement {

@api parentProp;

}


A child LWC extending the parent component with a template referencing both its own prop, and the child.



//childInheritance.js
import { api } from 'lwc';
import ParentInheritance from 'c/parentInheritance';

export default class ChildInheritance extends ParentInheritance {

@api childProp;

}

//childInheritance.html
<template>
<lightning-card>
<p>{childProp}</p>
<p>{parentProp}</p>
</lightning-card>
</template>


Then we compose some UI on another component by sticking c/childInheritance component there, it works fine:



<template>
<c-child-inheritance
child-prop="Child Value 1"
parent-prop="Parent Value 2">
</c-child-inheritance>
</template>


But when I attempt to add it to the app builder config section of my metadata file, I get the "property does not exist" error above. Here's what that would look like.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


As a workaround, you could create a kind of proxy @api exposed property that you map to the meta config file.



export default class ChildInheritance extends ParentInheritance {

@api childProp;
@api parentProxyProp;

connectedCallback(){
if (!this.parentProp) {
this.parentProp = this.parentProxyProp;
}
}

}


Then you reference parentProxyProp in metadata.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProxyProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


This has a side-effect, though: you now have a new property that's only meant as a pass-through to connect up the child to the parent prop. Someone could attempt to use it, so not perfect, and you'd need to plan for that accordingly.



This gap is known by the LWC team, but roadmap for when it will be addressed has not been announced.






share|improve this answer
























  • Thank you for the detailed answer Peter!

    – Dafydd Johns
    Jan 28 at 17:37
















5














tl;dr:
Currently, this is currently a gap.



From the pure perspective of accessibility, @api enabled properties of a LWC are inherited from parent to child. This is standard JS prototype inheritance at work.



You've probably found this. But when setting the config for design attribute in the metadata file to be connected to an inherited property, you get the following error:




The 'propName' property doesn't exist on the component.




Here's a test case to try:



A parent LWC module, and for sake of simplicity, an empty template/markup file.



//parentInheritance.js
import { LightningElement, api } from 'lwc';

export default class ParentInheritance extends LightningElement {

@api parentProp;

}


A child LWC extending the parent component with a template referencing both its own prop, and the child.



//childInheritance.js
import { api } from 'lwc';
import ParentInheritance from 'c/parentInheritance';

export default class ChildInheritance extends ParentInheritance {

@api childProp;

}

//childInheritance.html
<template>
<lightning-card>
<p>{childProp}</p>
<p>{parentProp}</p>
</lightning-card>
</template>


Then we compose some UI on another component by sticking c/childInheritance component there, it works fine:



<template>
<c-child-inheritance
child-prop="Child Value 1"
parent-prop="Parent Value 2">
</c-child-inheritance>
</template>


But when I attempt to add it to the app builder config section of my metadata file, I get the "property does not exist" error above. Here's what that would look like.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


As a workaround, you could create a kind of proxy @api exposed property that you map to the meta config file.



export default class ChildInheritance extends ParentInheritance {

@api childProp;
@api parentProxyProp;

connectedCallback(){
if (!this.parentProp) {
this.parentProp = this.parentProxyProp;
}
}

}


Then you reference parentProxyProp in metadata.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProxyProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


This has a side-effect, though: you now have a new property that's only meant as a pass-through to connect up the child to the parent prop. Someone could attempt to use it, so not perfect, and you'd need to plan for that accordingly.



This gap is known by the LWC team, but roadmap for when it will be addressed has not been announced.






share|improve this answer
























  • Thank you for the detailed answer Peter!

    – Dafydd Johns
    Jan 28 at 17:37














5












5








5







tl;dr:
Currently, this is currently a gap.



From the pure perspective of accessibility, @api enabled properties of a LWC are inherited from parent to child. This is standard JS prototype inheritance at work.



You've probably found this. But when setting the config for design attribute in the metadata file to be connected to an inherited property, you get the following error:




The 'propName' property doesn't exist on the component.




Here's a test case to try:



A parent LWC module, and for sake of simplicity, an empty template/markup file.



//parentInheritance.js
import { LightningElement, api } from 'lwc';

export default class ParentInheritance extends LightningElement {

@api parentProp;

}


A child LWC extending the parent component with a template referencing both its own prop, and the child.



//childInheritance.js
import { api } from 'lwc';
import ParentInheritance from 'c/parentInheritance';

export default class ChildInheritance extends ParentInheritance {

@api childProp;

}

//childInheritance.html
<template>
<lightning-card>
<p>{childProp}</p>
<p>{parentProp}</p>
</lightning-card>
</template>


Then we compose some UI on another component by sticking c/childInheritance component there, it works fine:



<template>
<c-child-inheritance
child-prop="Child Value 1"
parent-prop="Parent Value 2">
</c-child-inheritance>
</template>


But when I attempt to add it to the app builder config section of my metadata file, I get the "property does not exist" error above. Here's what that would look like.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


As a workaround, you could create a kind of proxy @api exposed property that you map to the meta config file.



export default class ChildInheritance extends ParentInheritance {

@api childProp;
@api parentProxyProp;

connectedCallback(){
if (!this.parentProp) {
this.parentProp = this.parentProxyProp;
}
}

}


Then you reference parentProxyProp in metadata.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProxyProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


This has a side-effect, though: you now have a new property that's only meant as a pass-through to connect up the child to the parent prop. Someone could attempt to use it, so not perfect, and you'd need to plan for that accordingly.



This gap is known by the LWC team, but roadmap for when it will be addressed has not been announced.






share|improve this answer













tl;dr:
Currently, this is currently a gap.



From the pure perspective of accessibility, @api enabled properties of a LWC are inherited from parent to child. This is standard JS prototype inheritance at work.



You've probably found this. But when setting the config for design attribute in the metadata file to be connected to an inherited property, you get the following error:




The 'propName' property doesn't exist on the component.




Here's a test case to try:



A parent LWC module, and for sake of simplicity, an empty template/markup file.



//parentInheritance.js
import { LightningElement, api } from 'lwc';

export default class ParentInheritance extends LightningElement {

@api parentProp;

}


A child LWC extending the parent component with a template referencing both its own prop, and the child.



//childInheritance.js
import { api } from 'lwc';
import ParentInheritance from 'c/parentInheritance';

export default class ChildInheritance extends ParentInheritance {

@api childProp;

}

//childInheritance.html
<template>
<lightning-card>
<p>{childProp}</p>
<p>{parentProp}</p>
</lightning-card>
</template>


Then we compose some UI on another component by sticking c/childInheritance component there, it works fine:



<template>
<c-child-inheritance
child-prop="Child Value 1"
parent-prop="Parent Value 2">
</c-child-inheritance>
</template>


But when I attempt to add it to the app builder config section of my metadata file, I get the "property does not exist" error above. Here's what that would look like.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


As a workaround, you could create a kind of proxy @api exposed property that you map to the meta config file.



export default class ChildInheritance extends ParentInheritance {

@api childProp;
@api parentProxyProp;

connectedCallback(){
if (!this.parentProp) {
this.parentProp = this.parentProxyProp;
}
}

}


Then you reference parentProxyProp in metadata.



<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="childInheritance">
<apiVersion>45.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__AppPage</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__AppPage">
<property name="parentProxyProp" type="String"/>
</targetConfig>
</targetConfigs>
</LightningComponentBundle>


This has a side-effect, though: you now have a new property that's only meant as a pass-through to connect up the child to the parent prop. Someone could attempt to use it, so not perfect, and you'd need to plan for that accordingly.



This gap is known by the LWC team, but roadmap for when it will be addressed has not been announced.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 28 at 17:12









pchittumpchittum

14.8k33782




14.8k33782













  • Thank you for the detailed answer Peter!

    – Dafydd Johns
    Jan 28 at 17:37



















  • Thank you for the detailed answer Peter!

    – Dafydd Johns
    Jan 28 at 17:37

















Thank you for the detailed answer Peter!

– Dafydd Johns
Jan 28 at 17:37





Thank you for the detailed answer Peter!

– Dafydd Johns
Jan 28 at 17:37


















draft saved

draft discarded




















































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.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f248180%2fhow-can-we-expose-inherited-properties-from-a-super-component-s-class-in-a-light%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

is 'sed' thread safe

How to make a Squid Proxy server?