Update FontType protocol with RawRepresentable.

[o-nnerb]

The idea is to use RawRepresentable to simplify the creations for Fonts using Material. In one project, we have to add 2 more functions and using the defaults methods made us write a lot of code. So, to simplify things, we added to Material the conformation for FontType to RawRepresentable, turning into a enum where cases are strings with the name of Font. There is two options to keep the old code, FontType.caseValue.font or FontType.caseValue.size(CGFloat), both will return UIFont.

[daniel-jonathan]

Nicely done @brennobemoura. We will take a look this week and merge it in.

[adamdahan]

@danieldahan I will take over this @brennobemoura Testing this PR in a few scenarios and will get back to you in a few days.

👍

[daniel-jonathan]

Awesome! Thank you @adamdahan

[adamdahan]

@brennobemoura Thank you for the PR. It has definitely stimulated some internal conversation as to how Material will introduce the theming of fonts in our upcoming updates for Material 4. The PR has merit and introduces a more dry approach to creating different fonts.

I was hoping you could clarify the intention of the FontTheme and it's associated protocol FontThemeable.

Let's consider a font like Roboto. A font that is made up of these different styles: Thin Thin Italic Light Light Italic Regular Regular Italic Medium Medium Italic Bold Bold Italic Black Black Italic

In what situation would you need the FontThemable protocol?

label.font = RobotoFont.thin.size(32.0) // *Without* the protocol
label.font = RobotoFont.Theme.thin(with: 32.0) // *With* the protocol 

I am trying to understand the reasoning behind your design and your comment caught my attention: "we have to add 2 more functions and using the defaults methods made us write a lot of code.".

I would love to learn more about the use case you solved with this design :)

• Some of our internal goals for font theming in Material 4 would be to create a generic font interface that has a single configurable entry point and have the ability to override that configuration in certain areas when necessary.

Looking forward to your response!

[o-nnerb]

So, if you are writing the code to set fonts to some font, in this case that @adamdahan was trying to figure out, I would say to use the FontType class RobotoFont.thin.size(32.0). But Material use the Theme class, that I am not familiar, and in its fuctions it cannot constraint to FontType with visible bold, regular and medium cases, so I write the FontThemeable to be visible for Theme methods.

There is other options to continue the support for Theme class to turn the default cases visible to the class, but I am not sure about the right approach.

[o-nnerb]

As I mentioned, there is one way that I learned recently to turn generic cases visible to other classes using protocol, some better approach for FontThemeable that is using associated type. Maybe it can be applied here.

[adamdahan]

@brennobemoura

Yes, I was thinking the same thing. In the next couple weeks we are going to be launching some exciting stuff and your contribution with FontType will definitely be included.

I will leave this PR up so we can merge it in next week with our other updates for theming 👍

Great job!

[o-nnerb]

These last days I was studying and developing labels with dynamic font types. This made me change the FontType protocol to be able to use the UIFontMetric. I created the FontDynamicType that implements the .style(: UIFont.TextStyle), .style(: UIFont.TextStyle, maxScale: CGFloat) inside the FontType and return some UIFont.

[o-nnerb]

I made a new commit including TextStyle support. I saw that Material has DynamicFontType protocol, but I am using this UIFont.TextStyle that I wrote and has been so easy to stylize labels and text fields, supporting even the accessibility scales