LWC, SVGs and Slots
Let’s talk about Lightning Web Components, SVG’s and slots! If you’ve read my earlier post about the use of SVG’s in LWC, you know that it’s pretty great to finally get some vector based images as part of your Salesforce implementation. We will bring it to another level with slots though; one of many ways to gain more control on image loading.
First off, let me get this out of the way: at the time of writing this piece, slots are not supported inside Lightning Web Components. Yes, I’d love it as well, but unfortunately that’s not how the internet works at the moment. To give an example, this…
…is not supported. If you happened to be looking for that, sorry to disappoint you. Pretty much everything within the <svg> tag needs to be a known tag, native to the SVG container. SVGs are pretty dynamic in nature, but they don’t let them manipulate so easy through crude HTML. However, if you’re really that eager, in for a challenge and don’t shy away from some true vector effort, I suggest you take a look at this great blog explaining SVG handling from javascript. A great read, but probably a little extreme for your average Salesforce LWC implementation.
Now that that’s out of the way — let’s talk about using slots for dynamically injecting SVG’s to your application.
A slot is a placeholder in your component, which is available for a parent component to populate with content. it requires a name attribute, which is used for identification, and often comes with default content for when no content injection takes place.
The bare component itself holds no SVG, no image whatsoever. If we would place this component without context in our application, it would only say “Sorry, no image defined”
Something you might immediately notice, is that nothing about this component and the slot tag actually dictates that an SVG is required. The parent is free to inject in the slot whatever it wants.
However, SVG’s are amazing enough not to let that happen! Let’s take a look at how the parent deals with it.
In the parent component, we embed the child component as we would normally, and as part of its body, we specify that for the slot parentControlledSVG we would like to render a component called <c-svg-provider> . In addition, we specify the name of the SVG we would like to render as well, either with a literal value, or in this case, with a tracked value that we populate in javascript.
Well, that’s incredibly clean-looking! And all of this ties in with some foundational patterns.
- The child component is better maintainable, as any non-essential clutter is decoupled;
- It is not responsible for determining what image to show, and leaves that to any component that it embeds;
- It is cut from any image dependencies!
Cherry on top — let’s control this from the Salesforce Setup!
Imagine having a Custom Metadata Type Branding Service , which, among having other branding-related properties, points to a list of available SVG’s which are stored in another Custom Metadata Type SVG Image .
What you see here, is a metadata record that let’s you determine what SVG name you’d like to use for a particular branding state. So in the above example, you would have a state in your application where there is no content. The SVG you would like to show, is called ‘svgShowEmpty’. Any time you would switch that image to something else, you would only have to update the metadata record and voila!
Now, the SVG that you load on your page is not only decoupled from a child component, but also controllable from the Salesforce Setup!
Of course, you need to retrieve the appropriate metadata record from you web components, and there are also several ways of doing that. More on that in another piece, but to give a small peek:
Now, get in the flow and light up your applications with SVG’s!
