If you've ever used Salesforce Experience Cloud, you're familiar with the concept of crafting your site utilizing both out of the box components and creating new LWC's that can be used on a page in a variety of ways.
When building new LWC's for your site, if you're not careful you can make the experience extremely challenging and confusing for your admin and likely your self.
Creating a realistic preview state with new components for Experience Cloud makes it easier & quicker to build sites
Let's talk a bit about the preview state when it comes to Experience Cloud.
Building a LWC for a site or storefront on Experience Cloud is different then building one for the standard Salesforce experience.
As an admin or developer you spend quite a bit of time in Experience Cloud adjusting the layout, spacing, colors, components to get it to look just right and if all the components look like this example Results Grid below you really have no idea what you're publishing.
This is what that component looks like on the actual site after it's been published. It looks nothing like that blank square.
Now if you've watched any of my youtube channel, you've seen and heard me talk about component attributes. They are a great thing that makes your component more flexible and configurable for future adjustments. As you notice, this component has some great attributes that allow us to change it without any customization! The problem is that, we can't see those changes and understand what they look like without publishing the site.
If you have components that are just blank in the Experience Cloud, how do you see what they'll look like when they're published? Well, the only way would be to publish it and make it live... which as you can image isn't recommended. Not only does this mean you have to wait for your site to publish but you're also testing it 'live'.
Now granted, this isn't as big of an issue in a sandbox, but what happens when you finally do go live and your admin wants to use those attributes to make changes to the text, color or layout?
One more example before we get into how we can accomplish a great preview state with custom components!
This cart summary component is a great example of what a good preview state standard would be. It has the following:
Attributes for configuration (not in the screenshot but they are there!)
Utilizes mock data to populate what the component potentially would look like
Utilizes slots to allow further adjustment if the future user desires
Crafting a Great Preview State in Experience Cloud
Now, let's outline the 3 pieces to making a great preview state.
#1 Attributes
I won't go into a ton of detail in this post since attributes are a fairly common practice. I will comment that it's important to have the right level of attributes. Not enough and you can't make many changes without changing the code, too much and you have attribute overload and it's hard to tell what is for what. Find the goldilocks zone!
#2 Slots
Slots allow you to create sections in your custom component where a user can drop any other standard or custom component. I have a video that walks through an example you can check out if this concept is new to you.
Official Documentation: https://developer.salesforce.com/docs/platform/lwc/guide/create-components-slots.html
#3 Preview Detection and Data
This is where we take the concept of a good preview to a 'great' level. We will introduce a new function that will allow us to detect if the site is in preview and we'll utilize that function to insert mock data into the component so the preview looks as though it's loading real data.
isInPreview Function
/**
*
* helper class that checks if we are in site preview mode
*
*/
isInSitePreview() {
let url = document.URL;
return (url.indexOf('sitepreview') > 0
|| url.indexOf('livepreview') > 0
|| url.indexOf('live-preview') > 0
|| url.indexOf('live.') > 0
|| url.indexOf('.builder.') > 0);
}Mock Data
The concept behind mock data is that we're setting up data that we'll use to load when the user is in the experience cloud. This allows us to make this data load dynamically between the live loading and the experience cloud without a ton of overhead in the html.
In your LWC you'll have a new file called mockData.js (or whatever you'd like to call it), this is the mock data that should match the data that would come from a live component call.
const mockData = {
attribute: "sample",
attribute2: "sample2"
}
export {
mockData
};In our LWC's javascript file this is an example of how you'd utilize this in a wire, but the same approach could be taken in any function or invoked call.
The essence of this is that you want to mock the data that would be returned to your component if it were pulling live data. Take a look at the code comments below for an example of how you could do this.
import { mockData } from './mockData';
@wire(XXX, {})
async XXX({ error, data }) {
this.isPreview = this.isInSitePreview();
if(!this.isPreview){
// if the component loads not in preview mode we will
// execute the production code
this.exampleVariable = data
} else {
// if the component loads in preview, we'll push the mock
// object into the variable
this.exampleVariable.push(mockData)
}
}If you've gotten to this point in the article, you're obviously as passionate about a good experience and configurability as I am!
Take a look at my youtube channel for more content like this!