Dreamforce 2016 has come and gone. We came, we saw, we presented. We took part in some amazing breakout sessions, put on our networking hats and even attended a happy hour or two. Another Dreamforce in the bag, but with memories uniquely 2016!

This year I was fortunate enough to host a breakout session on a relatively new feature in the Salesforce development world, Lightning Design Tokens. In case you weren’t able to attend Dreamforce this year or simply missed the session — fret not (here’s a link)! For this post contains all of the informational goodness that was in that presentation.

For those of us who can raise our hands as either managed package or highly customized full-scale web application developers on the Salesforce platform; and thus very familiar with all of the custom CSS that such an adventure entails, this post is aimed squarely at you. Even if you only find yourself occasionally writing your own CSS on the platform, having the knowledge of Lightning Design Tokens use and functionality is worthwhile!

The gist of the whole thing is low-level reusability, which itself leads to better maintainability, and less work all around. As seems the trend with just about any component-based web development framework nowadays (think React), the goal is increased reusability driven by tighter encapsulation and increased compartmentalization. Components are self-contained entities capable of describing and styling themselves, allowing them to be reused wherever their attributes are met. This is the case with Salesforce Lightning Components, and was a big highlight during my breakout session. A reasonable analogy being a Lego block. Your Lightning Component can be thought of as its own little Lego block, containing all of the functionality and styles it needs to describe itself and function as, a Lego block.

Just as we stack our Lego blocks together to make our completed Millennium Falcon of a Lego creation, we too can stack our individual Lightning Components together to form our completed Lightning Application. Our individual Lightning Components, being the self-contained entities that they are, have everything they need to exist at any point we choose to use them within our Lightning App — including their own CSS.

You can imagine then, if we had dozens, possibly even hundreds, of individual Lightning Components spread out across our Lightning Component Library…each with their own, local styles…that’s a lot of CSS to manage! Especially my low-level, reusable CSS that I’m going to include in basically everything… Enter Lightning Design Tokens.

Put simply, a Lighting Design Token is just a name-value pair. Defined in one place, your little name-value pair of a token can then be referenced in any stylesheet across your entire Lightning Component library. If the light bulb hasn’t gone off yet, it will soon.

What this allows us to do is define all of our low-level, reusable CSS properties like font families, color hex-values, pixel values for margin and spacing, etc., in a single place — our Lightning Design Token bundle. Once the token is defined inside this bundle, the name of the token can then be referenced using the token() function in any of your Lightning Component’s stylesheet resources. This is a big deal. Now, even if my Lightning Component library has thousands of components, I can style them all with the same base, low-level styles using Lightning Design Tokens. When changes come up, as they always will…I make those changes in one place! (Light bulb should have gone off by now)

The changes I make in that one token bundle will now be instantly propagated across all of the Lightning Components that are referencing my design tokens. I deploy my design token’s bundle up to Production and, as I said during my presentation, BAM! My work is done.