feat(ios-swift): adding extension formatter

[antoniogamizbadger]

Issue #, if available: #719

Description of changes:

I have added a formatter to swift to allow the use of extension. For instance:

//
// StyleDictionarySize.swift
//

// Do not edit directly
// Generated on Mon, 25 Oct 2021 13:31:16 GMT

import UIKit
import SwiftUI

 extension CGFloat {
    static let bodyM = CGFloat(224.00)
    static let bodyMini = CGFloat(144.00)
    static let bodyS = CGFloat(192.00)
    static let bodyXmini = CGFloat(128.00)
    static let bodyXs = CGFloat(160.00)
    static let headingL = CGFloat(256.00)
    static let headingXl = CGFloat(320.00)
    static let title = CGFloat(320.00)
}

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

[dbanksdesign]

This is a great start! Thanks for taking this work on. Just 2 minor comments. If you can, it would be good to include some integration tests so we can verify the output. You can use these integration tests as inspiration: https://github.com/amzn/style-dictionary/blob/main/__integration__/iOSObjectiveC.test.js

[dbanksdesign]

Are all extensions enums? Or does that need to be configurable too?

[gabischima]

sorry for my intrusion (: i came here to check what's already in progress that could meet my needs
but could this be achieved by passing a parameter for prefix and type?
prefix would be access level say public or internal, and type if enum, class, struct or extension.
i have a use case where i need my tokens to be internal access where only my SPM has access to it.

if no prefix is passed could be public by default.

Suggested change

	public enum <%= file.className %> {
	<%= file. prefix ? 'public' : file.prefix %> <%= file.type %> <%= file.className %> {

[EDIT]
i understand if it's too specific use case (: is just an idea for maybe not having to create multiple templates for each type class/enum/extension.
[/EDIT]

[chazzmoney]

This seems like a good idea. Thanks @gabischima

[antoniogamizbadger]

In the case of extension the className has to be the name of the type you are extending. Right now this parameter has to be provided by the user manually, is there a problem with that?

[antoniogamizbadger]

All extensions are not enums, that was my mistake.

[antoniogamizbadger]

Just a small doubt, how would we unify the three templates into one while keeping backward compatibility? I mean, with a template for every type we can do something like this:

  {
    "destination": "StyleDictionarySize.swift",
    "format": "ios-swift/extension.swift",
    "className": "CGFloat",
    "filter": {
      "attributes": {
        "category": "size"
      }
    }
  }

Without specifying any type option. If we only use one template, I think we have two options:

• Option 1: use the configuration above adding type and specifying the formatter on format.
• Option 2: only specify format and override type option in format.js. Something like:

  'ios-swift/extension.swift': function({dictionary, options, file}) {
    const template = _template(
      fs.readFileSync(__dirname + '/templates/ios-swift/swift.template')
    );
    let allTokens;
    const { outputReferences } = options;
    file['type'] = 'extension';
    const formatProperty = createPropertyFormatter({
      outputReferences,
      dictionary,
      formatting: {
        type: 'extension',
        suffix: ''
      }
    });

And the same change would be done for class and enum.

[chazzmoney]

These changes (and your intuition) are spot on. I think @dbanksdesign has a couple comments, but beyond that I think we have a solid PR here. Thank you!

[dbanksdesign]

Love the direction! Just a few minor comments

[dbanksdesign]

Are there any issue with including both UIKit and SwitfUI? I would assume most people use one or the other? Should we make this a configuration as well?

[antoniogamizbadger]

No, there's no additional drawback to have them both imported. We could make it a part of the configuration, but the only benefit would to have one line less of code. Import them both also does not affect app size because they are both available in every iOS environment anyway.

[doozMen]

The drawback would be that this could potentially be used on macos which does not have UIKit! But it does have SwiftUI. So to be more Apple Platform agnostic it would have been better to leave this out. I have been struggling with just that now.

[chazzmoney]

We merged #734 instead of this one, but credited you in the commit message and the release notes. Thank you for your contribution - it was an important need and very much appreciated!