| Tweet |
Introduction
This week I've been experimenting with decoupled Lightning Web Components in app builder pages, now that we have the Lightning Message Service to allow them to communicate with each other without being nested.
A number of the components are intended for use in record home and app pages, which can present challenges, in my case around initialisation. Some of my components need to initialise by making a callout to the server, but if they are part of a record home page then I want to wait until the record id has been supplied. Ideally I want my component to know what type of page it is currently being displayed in and take appropriate action.
Inspecting the URL
One way to achieve this is to inspect the URL of the current page, but this is a pretty brittle approach as if Salesforce change the URL scheme then it stands a good chance of breaking. I could use the navigation mixin to generate URLs from page references and compare those with the current URL, but that seems a little clunky and adds a delay while I wait for the promises to resolve.
targetConfig Properties
The solution I found with the least impact was to use targetConfig stanzas in the component's js-meta.xml configuration file. From the docs, these allow you to:
Configure the component for different page types and define component properties. For example, a component could have different properties on a record home page than on the Salesforce Home page or on an app page.
It was this paragraph that gave me the clue - different properties depending on the page type!
You can define the same property across multiple page types, but define different default values depending on the specific page type. In my case, I define a pageType property and default to the type of page that I am targeting:
<targetConfigs>
<targetConfig targets="lightning__RecordPage">
<property label="pageType" name="pageType" type="String" default="record" required="true"/>
</targetConfig>
<targetConfig targets="lightning__AppPage">
<property label="pageType" name="pageType" type="String" default="app" required="true"/>
</targetConfig>
<targetConfig targets="lightning__HomePage">
<property label="pageType" name="pageType" type="String" default="home" required="true"/>
</targetConfig>
</targetConfigs>
so for a record page, the pageType property is set as 'record' and so on.
In my component, I expose page type as a public property with getter and setter methods (you only need the @api decorator on one of the methods, and convention right now seems to be the getter) :
@api get pageType() {
return this._pageType;
}
set pageType(value) {
this._pageType=value;
this.details+='I am in a(n) ' + this._pageType + ' page\n';
switch (this._pageType) {
case 'record' :
this.details+='Initialisation will happen when the record id is set (which may already have happened)\n';
break;
;;
case 'app' :
case 'home' :
this.details+='Initialising\n';
break;
}
}
and similar for the record id, so that I can take some action when that is set:
@api get recordId() {
return this._recordId;
}
set recordId(value) {
this._recordId=value;
this.details+='I have received record id ' + this._recordId + ' - initialising\n';
}
then I can add the component to the record page for Accounts:
and in each case the component knows what type of page it has been added to.
Of course this isn't foolproof - my Evil Co-Worker could edit the pages and change the values in the app builder, leading to all manner of hilarity as my components wait forlornly for the record id that never comes. I could probably extend my Org Documentor to process the flexipage metadata and check the values haven't been changed, but in reality this is fairly low impact sabotage and probably better that the Evil Co-Worker focuses on this rather than something more damaging.
Show Me The Code!
You can find the code at the Github repo.
No comments:
Post a Comment