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

[Refactoring] Refactoring of theme with wrappers #79

Open
pylapp opened this issue Aug 26, 2024 · 2 comments
Open

[Refactoring] Refactoring of theme with wrappers #79

pylapp opened this issue Aug 26, 2024 · 2 comments
Assignees
Labels
⚠️ on hold Not blocked but should not be processed yet

Comments

@pylapp
Copy link
Member

pylapp commented Aug 26, 2024

Today, it is the duty of a theme to embed, override and provide any raw tokens, semantic tokens and future component tokens. It implies to have finaly a class with thousands of objects.

Indeed this is acceptable because the logic behing OUDS is based on themes which are in fact combinations of values for any tokens.

Today a theme is a Swift class which is not a singleton because we don't want to instanciate such massive objects if we don't use it. Using a singleton won't help to override classes so as to have subthemes.

Howeer we can agree that having thousands properties in one object does not bring a good developer experience (DX), and we may implement another solution with wrappers.

We may in fact define as many wrappers as "family" of tokens, i.e. ColorsWrapper, BorderWrapper, TypographiesWrapper, DimensionsWrapper etc. Each wrapper must implement (in the same way as the actual implementation of a theme) a protocol to embed specific items of tokens which will be still overridable. Thus a theme won't implement such protocols anymore but will have inside it all wrappers.
If a theme must be subclasses, it should only create a subclass of a wrapper and add it to the theme.

If could result to something like:

// Basic use

open class MyTheme {

    let colors: ColorsWrapper
    let borders: BordersWrapper
    ...

    init(colors: ColorsWrapper, borders: BordersWrapper() {
        self.colors = colors
        sef.borders = borders
    }
}

open class ColorsWrapper: ColorsSemanticTokens {
    // Implement tokens
}

// Alternative use

final class CustomTheme: MyTheme {

    // Init super
    init() {
        super.init(colors: MyColorsWrapper(), borders: BordersWrapper())
    }
}

final class MyColorsWrapper: ColorsWrapper {
    // Override the semantic token we want
}

Then the old line may move to something else:

// Before
theme.buttonBackgroundColorEmphasisHigh
// After
theme.colors.buttonBackgroundEmphasisHigh // If we suppose we wrap it in a "ColorsWrappers" and not a component token

Way may focus to this topic later when we'll have components tokens and tokens to implement.
This solution is quite elgant and may improve DX buy we may face isues with memory and performances because we keep using plenty of Swift classes in the end.

@pylapp pylapp added the ⚠️ on hold Not blocked but should not be processed yet label Aug 26, 2024
@pylapp
Copy link
Member Author

pylapp commented Aug 26, 2024

cc @ludovic35

@pylapp pylapp changed the title Refactoring of theme with wrappers [Refactoring] Refactoring of theme with wrappers Oct 2, 2024
@pylapp
Copy link
Member Author

pylapp commented Oct 2, 2024

on hold until the library architure is battle-tested with components definition and apps integrations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⚠️ on hold Not blocked but should not be processed yet
Projects
Status: Todo
Development

No branches or pull requests

1 participant