microsoft / fluentui-token-pipeline

The Fluent UI token pipeline generates source code for Fluent UI libraries.
https://microsoft.github.io/fluentui-token-pipeline/
Other
41 stars 18 forks source link

WinUI export: alternate token names #4

Closed TravisSpomer closed 3 years ago

TravisSpomer commented 4 years ago

WinUI already has a variety of tokens that they refer to as lightweight styling resources, and most of these match 1:1 with a token defined in the master tokens JSON.

For example, WinUI's ButtonBackgroundPointerOver is equivalent to a FluentUI token Button.Root.Fill.Color.Hover, and when exported for WinUI, the pipeline creates a SolidColorBrush resource named ButtonRootFillColorHover. WinUI can then define ButtonBackgroundPointerOver in its own code to be equal to ButtonRootFillColorHover, but performance could be somewhat better if that extra layer weren't present at all. To achieve that, the WinUI exporter could just export the token with the WinUI-specific name. That could be managed in one of two ways:

  1. In the token JSON, add it as an additional attribute:
{ "Button": { "Root": { "Fill": { "Color": { "Hover": { "value": "#c0c0c0", "winUIKey": "ButtonBackgroundPointerOver" }}}}}}
  1. In a separate mapping file only used by the WinUI exporter:
{ "Button.Root.Fill.Color.Hover": "ButtonBackgroundPointerOver" }

I think that the second option makes more sense: it keeps lots of platform-specific properties out of the mostly-cross-platform JSON file. But more importantly than that, Button.Root.Fill.Color.Hover would typically be defined through a set assigned to Button.Root.Fill.Color so there wouldn't even be a Hover node in the JSON to add a property to. Would we then have to assign a winUIKeys property to Color with one mapping for Hover, one for Pressed, and so on? The main upsides of the first option are avoiding a second file, and reducing the possibility of typos and the mapping file getting out-of-date.

TravisSpomer commented 3 years ago

This is now finished in the platform-overrides branch, but that branch isn't quite ready for a PR yet. The final syntax is this, using fullName and a platform override:

"Width": { "aliasOf": "Set.OutlineActionControl.Stroke.Width",
    "platform": {
        "winui": {
            "fullName": "CheckBoxBorderThemeThickness"
        }
    } 
}
TravisSpomer commented 3 years ago

I'm going to merge that branch, but with the override functionality inoperable for now. You can see it in action by adding this to config.ts after inputTokenFiles.forEach(...):

tokens = resolvePlatformOverrides(tokens, "winui")

I still need to change the platform override functionality to happen only once per platform, which requires changing how we call Style Dictionary, as currently the time that we need to implement platform overrides is too early to know which platform we're building (and any changes then would affect every platform).

TravisSpomer commented 3 years ago

Oops, this is already done, and the workaround to change config.ts is no longer required either. The syntax uses fullName as described in a previous comment.

Closing.