Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicit data types #8

Closed
TravisSpomer opened this issue Aug 25, 2020 · 1 comment
Closed

Explicit data types #8

TravisSpomer opened this issue Aug 25, 2020 · 1 comment
Labels
feature New feature or request question Further information is requested wontfix This will not be worked on

Comments

@TravisSpomer
Copy link
Member

The group is leaning toward relaxing some of the restrictions that are in place about how tokens are named. It's a requirement that the pipeline have some way of deterministically knowing what data type a token is—for example, if one token has the value "transparent", it needs to know that it refers to a color and not a font family, so that it produces the correct output. Today, the code in fluentui-shared.js handles this by analyzing the full name of the token, and our system's rules make it straightforward. That's also the way that a base Style Dictionary installation does it (but they have their own naming scheme that we don't use, CTI).

But, if the pipeline were to support other, potentially wildly different, design systems, that would no longer be true, so we'd need an alternate way of specifying that information. I'd recommend just adding a type property right next to value:

"Global": {
  "Color": {
    "Red": { "value": "#ff0000", "type": "color" }
  }
}

It would add a lot of extra information to the JSON, but it's straightforward, and would be simple enough to use. The existing code in fluentui-shared.js would just need to check that type property instead of looking through the full name. The rest of the formatters and export code would need no changes, or at most minimal changes.

@TravisSpomer TravisSpomer added feature New feature or request question Further information is requested labels Aug 25, 2020
@TravisSpomer
Copy link
Member Author

Closing since this currently isn't a requirement for anything.

@TravisSpomer TravisSpomer added the wontfix This will not be worked on label Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request question Further information is requested wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant