Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize Awesome #34

Open
ghost opened this issue Nov 24, 2018 · 8 comments
Open

Reorganize Awesome #34

ghost opened this issue Nov 24, 2018 · 8 comments
Labels

Comments

@ghost
Copy link

ghost commented Nov 24, 2018

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.

@ghost ghost added the idea label Nov 24, 2018
@rafiki270
Copy link
Collaborator

I think it does make sense but would like to hear more opinions from the current users

@ipodishima
Copy link

ipodishima commented Dec 13, 2018

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

@beamercola
Copy link

This would make things a lot easier

@rafiki270
Copy link
Collaborator

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?

@ghost
Copy link
Author

ghost commented Jan 30, 2019

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.

@beamercola
Copy link

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?

@padarom
Copy link
Contributor

padarom commented Feb 7, 2019

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.

@vytick
Copy link

vytick commented Mar 27, 2019

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)
        }
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants