Add support for *.txt and *.json colors format

[moto0000]

Hi, plese add support for .txt and .json file formats with colors.

Something like that: R.Colors.txt

Cyan-Color       : 0xff66ccff
ArticleTitle     : #33fe66
ArticleBody      : 339666
ArticleFootnote  : ff66ccff
Translucent      : ffffffcc

R.Colors.json

{
    "Cyan-Color"       : "0xff66ccff",
    "ArticleTitle"     : "#33fe66",
    "ArticleBody"      : "339666",
    "ArticleFootnote"  : "ff66ccff",
    "Translucent"      : "ffffffcc"
}

[tomlokhorst]

I've seen this idea before, but I don't quite understand the reasons behind it.

Currently, R.swift only parses different file formats from Apple. It generates strongly typed references for identifier strings from files such as .xcodeproj, .storyboard, .xib.

The idea being: You'd rather have strongly typed references everywhere in your Swift code, but Apple doesn't support that in things like storyboard files. So, as a workaround, given that you need these stringly typed files anyway, lets take those as source to generate strongly typed equivalents.

Inventing our own stringly typed file format and parsing that, seems a bit backwards.

My preferred method for having a consistent, shared list of colors is putting them in a Swift file, something like:

struct Colors {
  static let CyanColor = UIColor(hex: 0xff66ccff)
  static let ArticleTitle = UIColor(hex: 0x33fe66)
  static let ArticleBody = UIColor(hex: ox339666)
  static let ArticleFootnote = UIColor(hex: 0xff66ccff)
  static let Translucent = UIColor(hex: 0xffffffcc)
}

[mac-cain13]

I agree with @tomlokhorst, but I'm open to hear about why a txt file or json file is better in your workflow to see if it would be something to support. Maybe you could tell us a little bit more about it @moto0000?

For reference you could also look into the discussion about colors in the strings issue and the CLR color issue where some of us already discussed some posibilities.

[moto0000]

Hi, In our team we working on Windows (Designer, Android Developer) and OS X devices, so designer often sends to us colors palette in *.txt files.

The *.txt files is easy to edit, now I cerate UIColor extension but when I decited to use R.swift I would like to have everything in one place :)

[mac-cain13]

Thanks for the input, I can see why that is handy. Personally I would teach my designer how to edit a Swift struct, but I can see that not everybody is in the position to do that.

I'm still a bit in doubt if this is something for R.swift to support. I know some competitors do support it, but if we support an arbitrary color text file format, why wouldn't we support an arbitrary animation text file? I think it's better for R.swift to focus on official resource files and support them as good as possible.

If there are more people that think supporting txt color files is a must have I would love to hear about it. At this time I'm not really convinced that it is the way to go for us.

Thanks for bringing it up and discussing it with us, it's great to hear back from R.swift users!

[alexiscreuzot]

Right now this is the only thing preventing me to use RSwift instead of SwiftGen (with maybe templating).

Why us .txt instead of .clr in my opinion ?

• It's widely use
• It's easy to read and understand through teams (designers, project managers, developers)
• It's easier to manage in a versioned environment (it even say so in the documentation)
• And last, even if it's not per say a standard, it's at least a convention in many places

[mac-cain13]

@kirualex Thanks for your input, I agree that .clr isn't really a nice format since it's binary and quite hard to edit/use. I can also see why .txt is a better option, still it feels a bit weird since it's not the same type of resources that we are currently parsing. But I'll think a bit about and reconsider the decision.

Note to self; Now we have wide color support in iOS 10 we probably shouldn't support hex, but use rgba/hsba values in a json form or so. At least this should work correctly.

[mac-cain13]

During WWDC17 Apple announced support voor named Color Assets in Xcode asset folders. I think this is the way forward for predefined colors. So in R.swift 4 we will deprecate clr support and add support voor the named Color Assets. This has already been released in the 4.0.0.alpha.2 thanks to @tomlokhorst.

Therefore I will close this issue, since txt/json files is not something R.swift is going to support.

[igorkravchenko]

Color Assets support seems to be really good choice. The only problem with current implementation is that it is iOS 11 only. @tomlokhorst @mac-cain13 what do you think about adding manual parsing of Color Assets json when targeting iOS version lower than 11?

[mac-cain13]

I'm not really a fan of backporting these kind of features in general, if a party should think about this it's Apple and they think it's okay to not create an iOS 10 and below solution. Specifically for R.swift I think it is out of scope, we should expose Apples API in a nicer (typed) way, but not much more.

So I can see why you want it, but I think it should be a feature in a separate project.

[tomlokhorst]

Interesting suggestion @igorkravchenko. Quickly searching online, I found the ColorAssetCatalog library that appears to do the json parsing you suggested.

I agree with @mac-cain13 that it is out of scope for R.swift to completely integrate something like this, but we can make using other libraries easier.

Currently, we're restricting the complete R.color struct to iOS 11. When we technically could restrict just the functions returning UIColors to iOS 11, that way you could still access the different ColorResources.

Then you could use something like the ColorAssetCatalog library to access those colours in a type safe way:

// For iOS 11 only, with pure R.swift
myView.backgroundColor = R.color.myColor()

// For iOS 10, with the ColorAssetCatalog library + R.swift
myView.backgroundColor = UIColor(asset: R.color.myColor.name)

[igorkravchenko]

@mac-cain13 thanks for explanation and such great project. @tomasharkema thank you for the link and suggestions. Cool stuff.