Reading Design Data

Exporters have direct and easy access to the design system data for the design system you provide. In VSCode, you select the design system directly from the extension interface:

Currently active design system that is providing the data

With the design system selected, all your means of getting and reading the data inside exporters will fetch the data from that specific design system. This means that the exporter always runs against a specific design system, but its exporter code is design system agnostic (meaning you can use it with any design system you have and the result will differ based on the data contained inside the design system).

Using Pulsar Functions

You can use pre-defined functions to access any element inside your design system. At any point in the blueprint execution, simply call one of many pre-defined functions and the data will be loaded to your declared property.

All Pulsar function calls start with @. Specifically for design system read functions, all functions are additionally prefixed with ds., so you will always get the full list of functionality in your autocomplete - and you can just select one. Here are some function examples:

{[ const allTokens = @ds.allTokens() /]} // Fetch all available tokens of all types

{[ const allColorTokens = @ds.allColorTokens() /]} // Fetch all color tokens

{[ const allColorTokens = @ds.allComponents() /]} // Fetch all components

Some functions also require arguments, always obtained from a different fetch function:

{[ const tokenDetail = @ds.tokenById(tokenId) /]}

Function library

Please refer to Supernova Universal Data Model to see all the functionality available to you.

Behind the scenes: We have designed the exporter functions so we can grow the library of the data available without breaking the existing store exporters.

For example, if we decide to add sounds to design system repositories as well, your previous functionality will be kept intact because we likely just add a new function called ds.allSounds(). However, if the structure of data coming from any @ds function would change heavily, it could potentially make the exporter code invalid.

The configuration key inside exporter.json called engine.supernova is what will allow you to the specific version of the function library going forward, so even if we make breaking changes, older exporters will not break. For now, all exporters must use version 1.0 of the engine, which will be configured for you when you create a new exporter package.

With the data you are interested in at your disposal, it is time to learn how to structure the file output and how to write design system code content to it.