Closed TravisSpomer closed 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"
}
}
}
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).
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.
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 tokenButton.Root.Fill.Color.Hover
, and when exported for WinUI, the pipeline creates aSolidColorBrush
resource namedButtonRootFillColorHover
. WinUI can then defineButtonBackgroundPointerOver
in its own code to be equal toButtonRootFillColorHover
, 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: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 toButton.Root.Fill.Color
so there wouldn't even be aHover
node in the JSON to add a property to. Would we then have to assign awinUIKeys
property toColor
with one mapping forHover
, one forPressed
, 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.