---
tags: theming
---
# Design to Token to Code Workflow

This is an attempt to capture the discussion about how the Fluent design system will allow token authoring and consumption across a number of endpoints.

The overall idea is that there should be a separation of concerns between the design system and consumption of that design system. This will be achieved by having an intermediate format, capturing the output of the design system.

- **Design Responsibility** - mapping a variety of outputs from design focused authoring tools into the intermediate format.
- **Framework Author Responsibility** - providing a workflow and tooling to turn the intermediate format into a consumable format.

I'll walk through how this might work for the react-native control set as that's where I have the most familiarity. This should apply elsewhere as well.

## Intermediate Format

A critical part of this is having an intermediate format.

### Requirements

- **Structured & Standardized** - this should be some form of standard structured data such that it is easy to parse with existing tools on any platform. __Proposal:__ YAML or JSON
- **Contains Global Theme Info** - this should have a section that contains global theme info, which can be referenced by tokens. __Proposal:__ This should be structured to match theme definitions, but be referencable by the text paths as a flat dictionary.
- **Contains Component Token Defaults** - should contain default token values for each component. Where possible this should reference the theme information. This allows encoding that relationship in a way that reduces the overall code size.
- **Contains All Information** - don't be smart, just be simple. Tooling should optimize for code and for platform, but once information is omitted it limits advanced decision making.
- **Allows Per Platform Forking** - we need a way to author per-platform information. This could be a fork at the root, or could even just be a reserved keyword. **Proposal**: treat `Platform` as a platform selector that overrides the tree at that point. Can exist at any level.
- **Include Platform Defaults** - it is not sufficient to match platform values in the output. If it needs to also include a marker such as `System`. This allows ensuring system values take precedence where they should, it also allows for downstream optimizations.

### Possible implementations

{
  theme: {
    palette: {
      neutralPrimary: 'blue',
      accentPrimary: ''
      Platform: {
        ios: {
          neutralPrimary: { 
            system: 'neutral', 
            color: 'green' 
          }
        },
        win32: {
          neutralPrimary: 'purple'
        }
      }
    }
  },
  components: {
    Button: {
      backgroundColor: 'theme.palette.neutralPrimary',
      backgroundColorHovered: 'theme.palette.neutralTertiary',
      cornerRadius: 2,
      Platform: {
        android: {
          cornerRadius: 4
        }
      }
    }
  }
}

## Usage in fluentui-react-native

The plan would look something like this:

### Publish `@fluentui-react-native/design-tools` package

This would include functionality for the following:

1. **Convert IF to Theme** - This would take the YAML/JSON output and convert it to a theme definition that can be consumed by native. Ideally this has enough information to only author the divergences from the base. Used by design tools.
2. **Convert IF to Component Tokens** - Take the YAML/JSON output, spit out a single component's default tokens. If the tokens are a reference to a theme then that can be encoded in the definition.

### Consume `@fluentui-react-native/design-tools` in repo

The published package should be dual-purpose and drive behaviors inside the repo as well so that there is only one toolchain for conversion.

#### Create Demo Themes for Each Platform

This would pull in the most recent published Fluent design system, parse it into a Win32/Mac/Windows/ios/android/web theme, using the design-tools package.

- Consumed in demo code for RN-Web
- Would not be part of real bundles

#### Pull Control Definitions Directly

Ideally each control would use the tool to build up its settings from the base definition directly. This has the advantage of still containing the token definition in each component.

#### Create baseline theme for each platform

Create the baseline theme that will be used if the native module is not available.

- Could be put in its own package to not add weight
- Would be filtered to only include one package