Mutability

[Eric Horacek]

/cc @fcanas

I'm unhappy with the current state of mutability in the project

• AUTTheme should be entirely immutable to consumers. I want to think of a good syntax for initializing a theme from a set of JSON files that isn't cumbersome to use but is able to provide errors as well. Basically addAttributesFromThemeAtURL:error: should not exist in the public interface, and it instead should occur on an initWith-stye initialization.

[Fabian Cañas]

I have a couple of branches up, where I'm mostly thinking aloud in code.

The basic approach is to make a composite theme. One branch that does this by reloading the raw theme for each new composite theme is working fine. In the other branch I've started exploring the possibility of themes being hierarchical, and that's not working because of the expectations that symbols can be cross-referenced across themes.

I found hierarchical themes extremely useful. It's not in Trim, but in a previous styling library I wrote that I can't share. In each app I've had the pleasure of defining a style system in I've created a sort of hierarchy (maybe due to my own mania about dependency graphs). It's appealing for all sorts of use-cases ranging from light IAP customization on top of a larger style in an app we both worked on, to independent components that bring their own styles (e.g. edge insets) but should inherit other styles from the application.

[Eric Horacek]

I've implemented themes as hierarchical in the sense that you implement hierarchies by adding themes in a specific order. You can see this in the dynamic themes example, where the theme hierarchy is "colors", then "typography", then the theme-specific mappings ("day"/"night"), "navigation", and finally "buttons". It's a hierarchy in the sense that the constants from "colors" are reused in the "day"/"night" theme, and then mapped again into the final component. That way, the hierarchy is as such:

"RedLightColor": "#fc8078" → "DestructiveColor": "RedLightColor" → "tintColor": "DestructiveColor",

Did you mean hierarchy in a difference sense?

As for the examples, I really like the direction you're moving in. Reloading the raw theme is definitely the right approach. However, when you're creating a theme via themeWithThemes:, it becomes hard to ensure that the pass-by-reference error is properly propagated back to the caller

Could you elaborate on the second approach?

[Fabian Cañas]

Roughly, I mean that when themes are combined the originals stick around and interact to create the behavior of the new composite theme, instead of taking the raw data and processing it into the structure that is the new composite theme.

I don't know if that makes sense. I'll try and elaborate in code.

[Eric Horacek]

Think this is pretty much fixed with the initializers on MTFTheme ✨