Discussion: Alignment with material components

[martahj]

The intention of this issue is to clarify the relationship between this library, [material-components-web]https://github.com/material-components/material-components-web), and material design.

In addition to the discussion about versioning, the impetus behind opening this issue is the following situation. The card demo uses an avatar, which as of right now is defined in this library at src/components/Card/Avatar. It poses a challenge for the following reasons:

• It seems reasonable that someone might want to import a generic Avatar component so it can be used in other contexts, such as list items. As such, there exists an argument for adding it as a component to the styled-material-components library.
• No avatar component exists in the material-components-web package. In fact, no avatar CSS is provided even in the card component. The avatar is defined only inside the demo (see .demo-card__avatar), meaning the avatar is not included in the library.
• The .demo-card__avatar conflicts with the material design spec. In particular, it has a circumference of 2.5rem, while the material design guidelines imply a circumference of 40px (72 - 16 * 2).
• The avatar is also not considered a component in material design.

Given the desire to be programmatic around how to transfer material design into this library, any thoughts on how to approach these conflicting needs?

[martahj]

@ConciergeAuctions/technical-steering-commitee @iamdavid0091

[iamdavid0091]

@martahj I WANT THE AVATAR. lol kidding. I'm definitely open to suggestions and even more so, at the mercy of the greater coding minds in our team than myself. ;)

[brad-decker]

@martahj While i think our inspiration should come from the material components offering from Google, i think that we have some power to make changes to make it more usable for us. We are also building a React version of their package which favors re-usability even more so than their syntax.

I think this is a GREAT example use case for the static style names. @AriLFrankel asked me about the reasoning behind this so i'm using this as an opportunity to do a code example.

For example, lets say we have a .smc-card component and a .smc-avatar component.

.smc-avatar has styling on it that, by default, is set at 40px width and a border radius of 50% (this is a contrived example, forgive me.

const Avatar = styled.div`
  background-image: ${props => props.src};
  border-radius: 50%;
  width: 40px;
`;

But lets say that when an avatar exists inside a Card component it has 25px width and border radius of 100%. styled-components, by default, adds a dynamically generated, non-sensical class name to the component. If we add a static class to every component we can do things like this:

const Card = styled.div`
  ${elevation(${props => props.depth || 1})}
  padding: 10px;
  & .smc-avatar {
    width: 25px;
    border-radius: 100%;
  }
`;

Anytime you use & in styled-components it gets replaced with the dynamic class name generated for the current component. So this allows us to control how components looked like when composed within one another.

[martahj]

@brad-decker Point well taken about the advantages of static style names 👍

I am still having a bit of trouble seeing a direct path to a rule-based approach (not meant in an overly rigid way, just in the sense of coming up with an approach that could be explained to a new contributor and would allow them to determine if a new component or style change was correct or not) to porting material design and/or material components in to this library. Could you provide a little more detail on what you're envisioning that process looking like and what our "source of truth" is for which components and styles should be brought into this library?

[brad-decker]

I think the more we talk about this i am leaning away from the source of truth aspect and instead making the material components implementation be our inspiration and a constant reference point and less about making our stuff match it 100%. The overall goal is we are spec compliant and we can rely on our wonderful @ConciergeAuctions/product-designers to help us be faithful to that spec.

[AriLFrankel]

@brad-decker I definitely see the use case for static style here