Awesome
Awesome copied to clipboard
Reorganize Awesome
The issue #33 triggered a thought that is nagging me for a while already. Currently the library is structured like this
Awesome - Style - Icon
This is probably due to how FontAwesome structured their fonts. But I feel it would be much more natural to structure the library like this
Awesome - Icon - Style
This way one could much more easily switch between different styles (like when picking an icon from a list).
Basically we might be able to have one enum called for example Awesome
and this would have a name, description and style property like .regular, .solid, light, .brand
or so.
The .asImage
methods would then be attached to the style, so a bold car icon would be
Awesome.car.light
If an icon is not available for a certain style, the factory methods could return nil. Also maybe we could allow for a way to iterate over the available styles per icon by checking the font?
As far as I can see the same icon has the same unicode value across different styles, so we could drastically downsize the library even more as we would only need on alphabetical enum with all icon names.
Looking forward to your thoughts and comments.
I think it does make sense but would like to hear more opinions from the current users
I have to say... I upvote this! The only drawback is the availability for a style. It means every references will be optional and thus forcing us to to unwrap somehow
This would make things a lot easier
Well, I would like to keep the original style but maybe we could create two enums which would live side by side. Potentialy in separate modules? The drawback on that one would be a dual interface making the system less clear ... thoughts?
Maybe we could leverage the parser to create an intermediate file with the extracted icon information and then have a another script that creates each enum out of this. This way we would not need to mix the different enum creations in one script.
I'm good with this. It's a little confusing to have both, but it seems like it's the right direction. This would kill the need for the Amazing protocol, correct?
I don't think supporting two competing styles at once is the right way. If there's reasons to choose one over the other, remove the other. If the current one is good enough and the other one just also looks nice, don't adopt the other one. Having two adds unnecessary bloat and feels like one's undecisive.
What about to add something like this for that case?
extension Awesome {
public enum AwesomeStyle: String {
case brand, solid, regular
}
static func getAwesomeImage(for brand: Brand, style: AwesomeStyle = .brand, size: CGSize, color: Color, backgroundColor: Color) -> Image? {
return getAwesomeImage(for: brand.rawValue, style: style, size: size, color: color, backgroundColor: backgroundColor)
}
static func getAwesomeImage(for solid: Solid, style: AwesomeStyle = .solid, size: CGSize, color: Color, backgroundColor: Color) -> Image? {
return getAwesomeImage(for: solid.rawValue, style: style, size: size, color: color, backgroundColor: backgroundColor)
}
static func getAwesomeImage(for regular: Regular, style: AwesomeStyle = .regular, size: CGSize, color: Color, backgroundColor: Color) -> Image? {
return getAwesomeImage(for: regular.rawValue, style: style, size: size, color: color, backgroundColor: backgroundColor)
}
static func getAwesomeImage(for name: String, style: AwesomeStyle, size: CGSize, color: Color, backgroundColor: Color) -> Image? {
switch style {
case .brand:
guard let amazing = Brand(rawValue: name) else { return nil }
return amazing.asImage(size: size, color: color, backgroundColor: backgroundColor)
case .solid:
guard let amazing = Solid(rawValue: name) else { return nil }
return amazing.asImage(size: size, color: color, backgroundColor: backgroundColor)
case .regular:
guard let amazing = Regular(rawValue: name) else { return nil }
return amazing.asImage(size: size, color: color, backgroundColor: backgroundColor)
}
}
}