[RFC] Decouple variables passed to child components from parent component's logic

[kuzhelov]

from @levithomason post:

Motivation

Any variables or styles used directly in a component's logic implicitly become part of a global theming interface.

All themes will have to implement variables.typePrimaryColor, for instance, in order for this to work. Additionally, we are removing the styling from the theme and baking it into the component instead.

We would like all theming values and theming logic living in the theme's files. This way, each theme is free to choose the values and logic behind their styles. The question is how?

Proposal 1 - Component part variables

Component variables files could define variables for each component parts as well. Then, variable values and logic for component parts can be left to the theme and not dictated to all themes by the component. Here's an example of the Button theme defining an icon part in its variables.

// themes/teams/components/Button/buttonVariables.tsx

export default (siteVariables) => {
  const variables = {
    color: undefined,
    typePrimaryColor: siteVariables.white,
    typeSecondaryColor: siteVariables.black,
  }

  variables.icon = {
    color:
      type === "primary"
        ? variables.typePrimaryColor
        : type === "secondary"
          ? variables.typeSecondaryColor
          : variables.color
  }

  return variables
}

Now, the component simply implements a contract that says "we pass variables[part] to each component part":

// Button.tsx

Icon.create(icon, {
  defaultProps: {
    variables: variables.icon
  }
})

This would also allow us to do this consistently for all components, including the styles for each component part. That then would allow us to write a conformance test for it. This would make the API easier to understand and work with as well since there is only one concept, "components pass variables/styles to each component part".

Proposal 2 - A high-level theme interface

This proposal would introduce a new concept. Something like a lightweight theme interface that is allowed to pass between components. It would consist of backgroundColor, foregroundColor, and perhaps an accentColor initially (names and keys are inspired by present convergence talks with several teams at Microsoft).

The Button in this case would define these three values for its bounds. Then, they would passed to the Icon.

/cc @levithomason, @miroslavstastny

[kuzhelov]

Agree with all the points provided. We've had similar discussion with @miroslavstastny where exactly the same points were raised by him - at that point we've decided to pass variables directly in component's logic, primarily for the sake of not introducing additional complexity for theme mechanisms that were just introduced then (and, thus, were not exploited enough to be considered as robust solution).

Speaking of the options suggested - I would definitely support the first one, as it suggests clear path that doesn't change but extends the approach we are using now - and, thus, it is not associated with significant increase of complexity. Also, this one seems to be flexible enough, so that with this one we would be able to address quite broad set of scenarios.

Not saying 'no' to the second option, though - but would rather wait once this concept will solidify in our minds, for the sake of us being absolutely sure about what we are buying for additional efforts laid in this direction, as well as whether this concept is able to cover all the cases we are interested in (and how flexible it would be to cover potentially emerged edge-cases)

[levithomason]

After thinking this through more, I also think proposal 1 is ideal. It introduces no new concepts or patterns. It is both more simple than proposal 2 and more powerful.

[kuzhelov]

thanks - let me introduce PR for having more concrete discussion over the first option then..

[miroslavstastny]

My (still the same) opinion is if we access theme variables in component source, layers are broken.
I completely agree with the proposal to decouple it, I love Proposal 1.