Adding common transforms for Swift in iOS #255

tonyheupel · 2019-03-11T00:06:58Z

Issue #, if available: #161

Description of changes:
Adding ability to use ios-swift and ios-swift-separate transform groups. Examples:

ios-swift: all in one dictionary class file

//
// StyleDictionary.swift
//
// Do not edit directly
// Generated on Tue, 19 Mar 2019 18:31:55 GMT
//

import UIKit

public class StyleDictionary {
    static let colorBaseGrayDark = UIColor(red: 0.07, green: 0.07, blue: 0.07, alpha:1)
    static let colorBaseGrayLight = UIColor(red: 0.80, green: 0.80, blue: 0.80, alpha:1)
    static let colorBaseGrayMedium = UIColor(red: 0.60, green: 0.60, blue: 0.60, alpha:1)
    static let colorBaseGreen = UIColor(red: 0.00, green: 1.00, blue: 0.00, alpha:1)
    static let colorBaseRed = UIColor(red: 1.00, green: 0.00, blue: 0.00, alpha:1)
    static let colorFontBase = UIColor(red: 1.00, green: 0.00, blue: 0.00, alpha:1)
    static let colorFontSecondary = UIColor(red: 0.00, green: 1.00, blue: 0.00, alpha:1)
    static let colorFontTertiary = UIColor(red: 0.80, green: 0.80, blue: 0.80, alpha:1)
    static let sizeFontBase = CGFloat(16.00)
    static let sizeFontLarge = CGFloat(32.00)
    static let sizeFontMedium = CGFloat(16.00)
    static let sizeFontSmall = CGFloat(12.00)
}

ios-swift-separate: allow enum-looking use so each category is separated into different files

//
// StyleDictionaryColor.swift
//
// Do not edit directly
// Generated on Sun, 10 Mar 2019 23:02:19 GMT
//

import UIKit

public enum StyleDictionaryColor {
    static let baseGrayLight = UIColor(red: 0.80, green: 0.80, blue: 0.80, alpha:1)
    static let baseGrayMedium = UIColor(red: 0.60, green: 0.60, blue: 0.60, alpha:1)
    static let baseGrayDark = UIColor(red: 0.07, green: 0.07, blue: 0.07, alpha:1)
    static let baseRed = UIColor(red: 1.00, green: 0.00, blue: 0.00, alpha:1)
    static let baseGreen = UIColor(red: 0.00, green: 1.00, blue: 0.00, alpha:1)
    static let fontBase = UIColor(red: 1.00, green: 0.00, blue: 0.00, alpha:1)
    static let fontSecondary = UIColor(red: 0.00, green: 1.00, blue: 0.00, alpha:1)
    static let fontTertiary = UIColor(red: 0.80, green: 0.80, blue: 0.80, alpha:1)
}

//
// StyleDictionarySize.swift
//
// Do not edit directly
// Generated on Sun, 10 Mar 2019 23:02:19 GMT
//

import UIKit

public enum StyleDictionarySize {
    static let fontSmall: CGFloat = 12.00
    static let fontMedium: CGFloat = 16.00
    static let fontLarge: CGFloat = 32.00
    static let fontBase: CGFloat = 16.00
}

For ios-swift-separate (as shown above), it creates public enums but adds static members to the enum class without any case statements. If we were to type the enum and then set values, every time someone wants to use them they would have to do something like:

let size = StyleDictionarySize.fontBase.rawValue

By doing it the way we do in the proposed changes, we allow for:

let size = StyleDictionary.fontBase

Also added the following transforms:

name/ti/camel: supports camel-case without the leading category (Swift encourages succinct names); also added supporting tests.
size/swift/remToCGFloat: like the already-in-place color/UIColorSwift, this adds support for CGFloat, which is used in UIKit for decimal values; swift will view a literal number with decimal point values as a Double without a class initializer.
content/swift/literal: the content/objC/literal prepends the @; swift doesn't use this for literals.
font/swift/literal: the font/objC/literal prepends the @; swift doesn't use this for literals.
asset/swift/literal: the asset/objC/literal prepends the @; swift doesn't use this for literals.

Added the ios-swift and ios-swift-separate transform groups using the new transforms as appropriate.

Added support for two specific templates:

ios-swift/class.swift: leverages Swift's type inference to allow any literal that is supported (e.g., String, UIColor, CGFloat) to be added as a property to a class.
ios-swift/enum.swift: leverages Swift's type inference to allow any literal that is supported (e.g., String, UIColor, CGFloat) but puts it into an enum instead of a class.

Updated the basic example to show size and color to match the Objective-C version by leveraging ios-swift-separate and also added a single ios-swift output to show how they can all be used in one StyleDictionary class instead.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

dbanksdesign · 2019-03-11T16:37:25Z

This is awesome! I will take a look this week, but thank you so much for doing this!

davixyz · 2019-03-13T04:03:13Z

👍

dbanksdesign

WTF I thought I submitted a review already.. oh well.. Anyways, great job on this PR! Looks great, I just have a few minor comments

lib/common/templates/ios-swift/static.swift.template

lib/common/transformGroups.js

lib/common/transforms.js

tonyheupel · 2019-03-13T21:57:27Z

Review comments addressed, added isAsset along with helper methods for wrapping prop values with characters like single and double quotes. Updated transforms.md with the new transforms and fixed a couple copy/paste errors.
@dbanksdesign

chazzmoney · 2019-03-14T17:34:49Z

Hey, this is GREAT! We have wanted to add Swift support for awhile (I'm pretty amateur w/ Swift), so thank you for doing this.

I do have one concern; the setup appears to require the user to output all sizes in one file and all other properties in another. It requires this decision making to happen in the config. Instead, it would be great if there was only a single Swift format and the properties themselves were used to determine when/how to add in type information.

Maybe we create a new transform to add an attribute containing the token type (tokenType? classType?). Then when the formatter is run, it can use that information to output the type info correctly.

Does that make sense? Or am I misinterpreting something about Swift?

tonyheupel · 2019-03-15T03:48:48Z

Honestly, that's a good point. I had considered that, with the way "autocomplete/intellisense" works in XCode, that having to type StyleDictionary.color or StyleDictionary.size is a lot to type to still have a ton of options. That being said, before merging this, let me play with some ideas that can make it more flexible and potentially even allow folks to choose one or the other.

It's the transform groups where we essentially "decide" the conventions for the language, so I'll play with it and get back to you.

tonyheupel · 2019-03-19T21:03:46Z

I've added the default ios-swift transform group that can support just adding everything that meets the filter into one class. I also added ios-swift-separate to support having separate classes and/or enums by filter but that doesn't have the category name in the name of the property. (see the pull request description for the two examples). Ready for you to accept if you are OK with it, @dbanksdesign !

dbanksdesign · 2019-03-23T09:11:00Z

My apologies for the lateness, I am currently in Europe right now. I will dig into the code tonight (in about 12 hours), but reading over your comment and description it sounds good! Thank you again for all your work on this.

dbanksdesign

2 super minor things, after that I'm good to go. Thank you again for your work on this!

dbanksdesign · 2019-03-23T20:55:26Z

examples/basic/config.json

+        "destination": "StyleDictionary.swift",
+        "format": "ios-swift/class.swift",
+        "className": "StyleDictionary",
+        "type": "StyleDictionaryColorName",


It still doesn't look like 'type' here is being used, I can't see it in the format code. Is this meant to do something or could we remove it?

dbanksdesign · 2019-03-23T21:01:51Z

lib/common/templates/ios-swift/enum.swift.template

+  // Filter to only those props wanted based on the filter, then sort
+  // them by category so we keep like props together, then by name
+  // so they are easier to find alphabetically.
+  var filteredProps = _.filter(allProperties, this.filter); 


I'm 99% sure you can remove this, I believe when we properly added the filter functionality we actually run the filters before the format so the format code itself doesn't have to worry about implementing filters. Take a look here

dbanksdesign · 2019-03-23T21:02:40Z

lib/common/transforms.js

@@ -578,7 +628,7 @@ module.exports = {
      return prop.attributes.category === 'content';
    },
    transformer: function(prop) {
-      return '\'' + prop.value + '\'';
+      return  wrapValueWith('\'', prop);


Love this addition!

tonyheupel · 2019-03-25T18:23:17Z

Thanks! Will make the updates and get back to you. Thanks again!

…

On Sat, Mar 23, 2019 at 2:07 PM Danny Banks ***@***.***> wrote: ***@***.**** commented on this pull request. 2 super minor things, after that I'm good to go. Thank you again for your work on this! ------------------------------ In examples/basic/config.json <#255 (comment)>: > @@ -64,6 +64,42 @@ } } }] + }, + "ios-swift": { + "transformGroup": "ios-swift", + "buildPath": "build/ios-swift/", + "files": [{ + "destination": "StyleDictionary.swift", + "format": "ios-swift/class.swift", + "className": "StyleDictionary", + "type": "StyleDictionaryColorName", It still doesn't look like 'type' here is being used, I can't see it in the format code. Is this meant to do something or could we remove it? ------------------------------ In lib/common/templates/ios-swift/enum.swift.template <#255 (comment)>: > +// <%= this.destination %> +// +<% + // for backward compatibility we need to have the user explicitly hide it + var showFileHeader = (this.options && this.options.hasOwnProperty('showFileHeader')) ? this.options.showFileHeader : true; + if(showFileHeader) { + print("// Do not edit directly\n"); + print("// Generated on " + new Date().toUTCString()); + } +%> +// +<% + // Filter to only those props wanted based on the filter, then sort + // them by category so we keep like props together, then by name + // so they are easier to find alphabetically. + var filteredProps = _.filter(allProperties, this.filter); I'm 99% sure you can remove this, I believe when we properly added the filter functionality we actually run the filters before the format so the format code itself doesn't have to worry about implementing filters. Take a look here <https://github.com/amzn/style-dictionary/blob/master/lib/buildFile.js#L45> ------------------------------ In lib/common/transforms.js <#255 (comment)>: > @@ -578,7 +628,7 @@ module.exports = { return prop.attributes.category === 'content'; }, transformer: function(prop) { - return '\'' + prop.value + '\''; + return wrapValueWith('\'', prop); Love this addition! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#255 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAObpWV4Wbc8WSPcKQD-A5FJgSfZSPD-ks5vZpeogaJpZM4bnl85> .

-- *when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.* - _why

chazzmoney · 2019-04-21T00:33:59Z

@tchype Thank again for all your hard work on this. We would love to get this functionality merged in for everyone to use - let me know if we can do anything to help ☺️

tonyheupel · 2019-04-22T15:54:09Z

Sorry -- thought I finished this. Will finish today @chazzmoney !

tonyheupel · 2019-04-22T20:37:10Z

Ready for review/merge @chazzmoney @dbanksdesign . Thanks!

chazzmoney · 2019-04-22T23:05:46Z

LGTM!

dbanksdesign

LGTM!

Based on swift implementation ( #255 ), it adds swift transforms, transformGroups, formats, and example: * flutter/class.dart format * flutter and flutter-separate transformGroups * color/hex8flutter, content/flutter/literal, asset/flutter/literal, font/flutter/literal, and size/flutter/remToDouble transforms * advanced/flutter example fixes #288 Co-authored-by: MDemetrio <[email protected]> Co-authored-by: Danny Banks <[email protected]>

tonyheupel added 3 commits March 10, 2019 14:34

feat(ios-swift): initial ios-swift commit with colors working

4973a33

feat(ios-swift): size and color working

f9d8a45

feat(ios-swift): added transforms tests for name/ti/camel

d470919

dbanksdesign reviewed Mar 13, 2019

View reviewed changes

lib/common/templates/ios-swift/static.swift.template Outdated Show resolved Hide resolved

lib/common/transformGroups.js Outdated Show resolved Hide resolved

lib/common/transforms.js Outdated Show resolved Hide resolved

lib/common/transforms.js Outdated Show resolved Hide resolved

feat(ios-swift): refactoring and cleanup from pull request feedback

a70a61e

feat(ios-swift): single dictionary class or multiple separate enum files

1f7d1af

fdzsergio mentioned this pull request Mar 20, 2019

[Dependencies] Add Swift support NextChance/chatme-style-dictionary#9

Open

dbanksdesign reviewed Mar 23, 2019

View reviewed changes

feat(ios-swift): removing unused types and filters

7268bfa

dbanksdesign approved these changes Apr 23, 2019

View reviewed changes

dbanksdesign merged commit 749db69 into amzn:master Apr 23, 2019

dbanksdesign mentioned this pull request Jun 7, 2019

How can we add Flutter support #288

Closed

MDemetrio mentioned this pull request Sep 2, 2019

feat: flutter support #320

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding common transforms for Swift in iOS #255

Adding common transforms for Swift in iOS #255

tonyheupel commented Mar 11, 2019 •

edited

Loading

dbanksdesign commented Mar 11, 2019

davixyz commented Mar 13, 2019

dbanksdesign left a comment

tonyheupel commented Mar 13, 2019 •

edited

Loading

chazzmoney commented Mar 14, 2019

tonyheupel commented Mar 15, 2019

tonyheupel commented Mar 19, 2019

dbanksdesign commented Mar 23, 2019

dbanksdesign left a comment

dbanksdesign Mar 23, 2019

dbanksdesign Mar 23, 2019

dbanksdesign Mar 23, 2019

tonyheupel commented Mar 25, 2019 via email

chazzmoney commented Apr 21, 2019 •

edited

Loading

tonyheupel commented Apr 22, 2019

tonyheupel commented Apr 22, 2019

chazzmoney commented Apr 22, 2019

dbanksdesign left a comment

Adding common transforms for Swift in iOS #255

Adding common transforms for Swift in iOS #255

Conversation

tonyheupel commented Mar 11, 2019 • edited Loading

dbanksdesign commented Mar 11, 2019

davixyz commented Mar 13, 2019

dbanksdesign left a comment

Choose a reason for hiding this comment

tonyheupel commented Mar 13, 2019 • edited Loading

chazzmoney commented Mar 14, 2019

tonyheupel commented Mar 15, 2019

tonyheupel commented Mar 19, 2019

dbanksdesign commented Mar 23, 2019

dbanksdesign left a comment

Choose a reason for hiding this comment

dbanksdesign Mar 23, 2019

Choose a reason for hiding this comment

dbanksdesign Mar 23, 2019

Choose a reason for hiding this comment

dbanksdesign Mar 23, 2019

Choose a reason for hiding this comment

tonyheupel commented Mar 25, 2019 via email

chazzmoney commented Apr 21, 2019 • edited Loading

tonyheupel commented Apr 22, 2019

tonyheupel commented Apr 22, 2019

chazzmoney commented Apr 22, 2019

dbanksdesign left a comment

Choose a reason for hiding this comment

tonyheupel commented Mar 11, 2019 •

edited

Loading

tonyheupel commented Mar 13, 2019 •

edited

Loading

chazzmoney commented Apr 21, 2019 •

edited

Loading