Custom Metadata and LWC (and SOC)

If you’ve followed the recent pieces on applying SVG’s successfully in LWC, you might wonder how organizing different pieces of branding could be done.

A little recap; now that LWC actually supports SVG’s natively (as opposed to the Aura framework) it should always be a consideration to apply them when you want to show an image or animation. Although not all types of images are convenient, most slick, funny, quirky, smooth and fluid illustrations we see on the net are SVG’s. In addition, Salesforce themselves provide the resources to use their commonly seen SVG’s as part of their Lightning Design System.

By organizing your SVG’s in separate html resources within you Lightning Web Component, you can very easily control the visibility of each illustration through javascript:

From here, it’s just a matter of calling the right svgname in a parent component to load the SVG:

As you can see, the component that we see here is not so much just passing in a hard value to load the SVG. In his turn it is using a variable that is set in a controller function. Note how the name of the variable is brandingSvgName .

Separation of concerns (SOC)

In the world of enterprise application, we typically hear the term “Separation of Concerns” often — and with good reason. It is a design pattern that pretty much prescribes that separate sections of an application should be concerned with their own responsibility. This should also apply to the branding of your application! (btw, a nice draft on separation within coding can be read here)

Of course, if you’re 100% sure that your piece of code can live with handling its own branding (let’s say, an obscure component on a little-used Record page of a trivial object called “Collaboration Entry”) you will probably be fine with that. But otherwise it is good practice to separate the branding of your work from the functionality it provides. That’s what we’re going to do with Custom Metadata records!

Custom Metadata control

Specifically for Salesforce, Custom Metadata is the way to control application behavior from a administrative point of view — rather than from a technical one. This means that it caters for customization and governance of your components from the Salesforce setup, instead of only through code.

Let’s take a look at the javascript controller of that Paren Web Component that we saw earlier:

In this (overly simple) example, we see that during the connectedCallback() lifecycle hook, the component asks the brandingService for the SVG name that it needs for an “empty state” illustration. The brandingService is an imported Web Component concerned with managing the retrieval and dispatching of branding-related properties (in this case, only the retrieval of the SVG for empty states:

As you can see, this makes it incredibly easy for other components to ask for an “empty state” SVG.

Now one thing you could ask is,

“Why not just return the term you need to load the SVG — like svgShowEmpty “?

And that’s valid. But the point here is that the term you need is not sourced from your code, but Custom Metadata. And beyond that, what if the SVG you want to show is actually dependent on a value on a field on the User record, like Audience__c ?

We will use Custom Metadata to control what term is returned by the branding service:

Here we haveBranding_Service metadata records, all pointing to both an Audience and SVG_Image record:

As you can see, for most audiences we get a term returned svgShowEmpty , except for the painters visiting our application, they will see a different SVG, based on a different term svgShowEmptyArtistic .

The only missing piece here, is of course our Apex controller that selects the appropriate metadata records. I guess we can all dream that, but for the purposes of completeness, here it goes:

Imagine how easy it is to change the ‘empty state’ SVG for any given audience, and imagine how easy it is to add a new audience! What an absolute breeze!

For the purposes of this write-up, we’ve been focusing only on applying SVG’s; but branding of course encompasses way more than that. Depending on what type of application you’re working on, it could range from controlling the visibility of simple illustrations to full blown control over CSS, imagery, labels, headers, ambiance and

And, looking broader than only branding — what we’ve seen here can be applied to many domains within your code. I guess in the end we should strife for that optimized separation, which will undoubtedly lead to better readable, maintainable and higher quality code!

Good luck!