levithomason
commented
5 years ago @codepretty Let's normalize sizes before they get too far out of hand. We currently have many ways of sizing components. Let's see if we can normalize all components to:
largest larger large medium small smaller smallest
For themes that may want 5 sizes, just have the largest/smallest sizes use the same values as larger/smaller to limit them.
Theme-provided or theme-restricted Enumeration?
How can a theme restrict usage of possible variables, or provide a custom range of variables. And how can other theme-specific information be provided in a more abstract/customizable/flexible way?
Problem
Right now there are multiple enums which are defined in src. Specifically there are (for the Text component) Sizes and Weights. I can easily imagine there will soon be additional application-specific enums, such as AvatarSizes, PresenceStates and other components as well.
The basic questions are: What happens when the design team providing a theme wants to limit the number of Text sizes available, or wants to "outlaw" certain font weights? How do they do that? What happens if a size/weight becomes deprecated? What about making various combinations of sizes/weights allowed or disallowed?
Related question: What about things that are somewhat more application-specific, like in the case of Avatar, AvatarSizes and PresenceStates? Would it be possible to make the theme (and business logic) provide the data for those? For AvatarSizes Stardust might say "we need S, M, L and XL avatar sizes" and it would be nice if the theme definition could say "M is not allowed, don't let M be used." But what about PresenceStates? Presence seems very specific, the idea of "Available" or "Away" is pretty heavily tied to a chat app... What if some other product that uses Stardust has representations of people and wants to use Avatar, but has very different ideas of what an avatar's "state" could be? If we've hard-coded "presence" enum to be specific to our application (available, away, etc) that doesn't seem to be a very open/flexible system.
Another related question: Would it be possible to streamline/simplify the amount of redundancy between the siteVariables and the multiple component-specific files? Using Text as an example again: siteVariables feeds into textVariables, which feeds into textStyles files? Having a more systematic way to provide/consume the styles might streamline the existing approach.
Possible solution:
Could an interface or json object format be a solution for this? Stardust could have an ITextStyle interface, and the theme could provide text style objects that conform to the interface. One of the properties the interface requires could be a "valid" or "deprecated" Boolean. Perhaps another "object" that the theme could provide is a "map to" which would tell stardust what sizes/weights are valid and/or what sizes/weights to substitute?
A similar approach could also be used for elements of avatar. AvatarType could include the name-type and shape of the avatar and the AvatarState could include the name-type, shape, and color of the "presence."
I do see that the TextVariables.ts file defines an Interface, but that file is within the theme, so it isn't exactly telling other themes how to interact with Stardust. Simultaneously the Text component in Stardust src has a pretty direct/explicit/inflexible relationship with what is defined in the various theme files for Text.
Comments please