Custom transformers and formatters to support Swift outpout.
- Follow the QuickStart to get Style-Dictionary Setup: https://amzn.github.io/style-dictionary/#/quick_start
- Get Dependencies:
npm install - Build:
npm run build
- color/swift: Generates a UIColor object from a hex string.
- Note 1: I wasn't able to get the tranformer recently merged into Style-Dictionary's master branch to work so I wrote my own.
- Note 2: Since we don't specify alpha values in our color tokens the transformer assumes an alpha of 1.
- font/swift: Generates a UIFont with size in points. The point value is converted from the incoming value which is assumed to be specified in rems.
Note: Formatters created with Lodash
- swift-styleservice.template: Struct-based approach that exposes all tokens from a unified interface.
- swift-uicolor-extension.template: Extension-based approach that exposes colors via UIColor class.
- swift-uifont-extension.template: Extension-based approach that exposes fonts via UIFont class.
There are lots of different approaches for standing up a styling framework in Swift. The exact implementation will depend upon the conventions of a given developer or organization. This solution provides two different examples...
I prefer using a service-based approach for my software architecture. Sources of business logic and data are all treated atomically and are owned by a discrete services. Consumers of a service (views, other services, etc.) can only affect the data exposed by a given service through that service's interface. There is no direct manipulation of the data by a consumer, instead the service makes changes on the consumer's behalf. This convention makes it easier to debug complex systems since there is only one point of failure...the service that owns the data.
The StyleService class takes this approach.
Class extensions are another option that naturally follow Swift idioms - or is it Swift conventions? By exposing colors and fonts through extensions developers can instantiate these objects in the same way they instantiate all other color and font objects.
My argument against using extensions to create a style framework is that this approach is opaque and it's difficult to derive available options and usage intent. A UIFont is not a stlye framework, neither is a UIColor...they are components of a style framework. If there's nothing but a collection of extensions to consume then the developer is forced to conceptualize the framework in their head and then remember it over time. I think it's much easier to leverage a style framework if it's exposed through a well-known/well-defined interface.
The two extension classes take this approach.