Theming/Styling contained Widgets

[kitsonk]

User Story

As a developer, when creating a contained themed widget, I want to be able to influence the theme and styling of the contained widgets.

Specific Use Case

I have created a re-usable panel, which has a border and contains a button and a slider. Based on the configuration of the panel, I want to change the background colour of the button and the thumbnail colour of the the slider.

[smhigley]

It seems like the way we’re moving towards for pretty much any style change for an existing widget is extension with a new @theme directive. I don’t believe framing it from the view of creating a container widget is all that relevant, since it should be up to the component widgets to support every possible visual style throughout the app. I can think of two general approaches: either create a separate widget for each visual style, or create a single extended widget that supports multiple visual styles, toggled by a property.

Solution 1, multiple widgets:

Buttons:

@theme(css)
export class RedButton extends Button { }

@theme(css)
export class BlueButton extends Button { }

Usage in Container:

render() {
  const { buttonType } = this.properties;
  return v(‘div’, [
    w(buttonType === ‘red’ ? RedButton : BlueButton, [ ‘ Button Text ’ ])
  ]);
}

Solution 2, property controlling appearance:

Button:

export interface MyButtonProperties extends ButtonProperties {
  appearance: ‘default’ | ‘alternate’;
}

@theme(css)
export class MyButton extends Button<MyButtonProperties> {
  getModifierClasses() {
    const { disabled, appearance } = this.properties;
    return this.classes(
      disabled ? css.disabled : null,
      appearance === ‘default’ ? css.red : css.blue
    );
  }
}

Usage in Container:

render() {
  const { buttonType } = this.properties;
  return v(‘div’, [
    w(MyButton, {
      appearance: buttonType
    }, [ ‘Button Text’ ])
  ]);
}

The first solution looks cleaner at first, but I’m worried that a larger number of variations will result in an explosion of different widgets and CSS module files. There’s also the problem that simple variations like red vs. blue are easy, but what about cases where you might have two different types of variation, e.g. color and size. With the first solution you would need RedButton, LargeRedButton, BlueButton, LargeBlueButton, etc., whereas for the second you would only need to add buttonType and size properties.

There’s also the CSS organization issue. If we approach this by suggesting separate modules for each slight variation in styling, each module will need to duplicate multiple styles like font-face, line-height, border, etc. just to change background-color on the root class. This seems like it would become brittle and difficult to maintain. Adding additional classes to the root node controlled through properties would more closely mirror the way I prefer to organize styles even without modules, i.e. <button class=“button large callout”> as opposed to <button class=“largeCalloutButton”>.

We could somewhat mitigate the duplication issue with composes, but I worry the over-use of composes will make it difficult to sort through which styles come from where. I would personally prefer to explicitly have all my button styles in a single css module file than try to sort through five to find the border-width declaration.

[bitpshr]

This is directly related to #270, since as @smhigley pointed out, it's not extremely relevant if a component is contained or not. This boils down to styling a component instance based on properties, which lends itself perfectly to an extended component using an extended properties interface as captured by #314.

Action items:

• Create a ticket to add a tutorial for this content Tutorial for widget extensibility dojo.io#290
• Close this ticket