@grund/theme v0.0.85

Misc

Keywords:

• Token
• Lexer
• Parser

• Generate

• Source

• Theme

• Bag

• Clause

• Statement
• Expression

TODO

• Functions
  • math
    • calc
    • subtract
    • add

Thoughts

• We should enable the feature of having multiple themes.

  • How do we want to make use of multiple themes? Do we want to use the styled-component's ThemeProvider to send in the entire theme?
  • Or do we want to use the our own ThemeProvider in which we just send in the theme name?
  • Or a combination?

• One should be able to compose different themes in the settings.

  • All components in @grund/ui should be in the theme "grund".
  • It is overridable simply by adding the key path to your "default" theme.
  • The theme names should be unique - or should they? Maybe if one wants to split up the theme config into multiple files? Then it should be possible to concat them.
    • Should we add a extends keyword? It seems unecessary if we can compose the themes on a higher level.
    • Should we a way to import other files? It would be an easy way of splitting files while still only having to point to one file in the cli.
      • We could also enable importing by glob.

• Theming of grund components should use the same name as the component itself (example below)

  • The question is if one should also be able to style the individual sub components (e.g. Wrapper) or if one should just be able to define the variables on a higher level. Worth noting is that this only applies for the styling of grund components.
  • Another question is how we should define the default values.
    • Should they be in a grund.theme file in the @grund/ui package? Or should they

    {
        input {
            StandardInput {
                height          =   48
            }
            InputField {}
        }
        buttons {
            StandardButton {
                Wrapper {
                    height		=	48
                }
            }
            IconButton {
                Wrapper {
                    height      =   36
                }
            }
  		}
  	}

• We need to figure out how we want to be able to use the helper functions in styled components.
  • The will most probably not be styled-component dependent by design since we have the "themeKey" setting.
  • How do we want to be able to filter out the key? Both for the user and in typescript autocompletion. Recursive keyof?

More thoughts

Splitting up files

• Syntax for importing other files (relative to the importing one)
• A cli flag where we can point to the entry theme file

Working with @grund/ui

• Usage of @grund/ui without @grund/theme
  • Default values
    • Use explicit default values in the code?
    • Use postinstall to ensure .grund/theme always exists
    • Or we can just force people who wants to use @grund/ui to use @grund/theme?
• How do we want to namespace the ui default variables?
  • We want to avoid to make the autocompletion "messy" but still having access to everything we want.
    • Do we want all variables from grund to be namespaced beneath "grund"?
      • It would probably be nice. But we also want to support exposing the values without having to use "grund" in every theme getter.
      • Expose a few more settings that will initiate the grund defaults into another namespace of theme (e.g. colors = grund.colors).
    • Do we want to be able to extend certain values from the grund theme?
      • colors = $.grund.values & { ... }
      • Do we want to be able to pick what values from grund we want to add to our theme?

Grund components

• We want to be able to style the components in an easy, yet all covering, manner.
• To accomplish this, we have the following rules:
  1. All grund styling should be in the grund namespace.
  2. All components should have the same name in both implementation and theme.
  3. All components should have all commond styling props in the root of this component - not in the sub component namespace the styling will apply to.
  4. All sub components should be able to be individually styled in some way. The resulting style from this will be injected directly into the styled component styling. The syntax for this is a bit unclear, but a proposal would be something like below.

StandardButton {
    subComponents {
        Wrapper {
            fontSize      =     10
            lineHeight    =     16
        }
    }
}

Possible version 2

• Create a real proxy that takes in the tokenized values (e.g. String, Number, Variable, Function) and evaluates them at runtime.
• We could also make them evaluated at runtime if they contain a variable.
• This makes it possible to change certain values in runtime and make them propagate to other values.
• A challange would be how to work with default and overriding themes.