Open adrian-reapit opened 1 month ago
issue (blocking): Personally, I think we need to be careful about introducing components that are not explicitly represented in the Design System itself. That is, since there is no SupplementaryInfo
or HorizontalDetailList
component specified by the Design System, we should be very hesitant introducing one ourselves. In previous Working Group discussions, we've outlined the desire to keep Elements aligned with the Design System as closely as possible, which includes (in my mind), what components we do and do not implement.
The main risk I see with doing what you suggest in this issue is that we would be explicitly coupling things that look visually similar, but are in no other way related. It is the responsibility of the Design System to couple/decouple common concerns between components, not Elements, nor front-end engineers. For example, the Page Header component also has a "supplementary info" slot, but its reasonable that the requirements for its supplementary info will change independently to the requirements for the visually similar supplementary info in the drawer header. If we explicitly couple these concerns via a HorizontalDetailList
, we are creating a meaningful abstraction in Elements that doesn't exist in the Design System, which increases the risk profile of Elements (and the potential cost of change) when the Design System evolves and these two visually similar things diverge.
Where I do think its reasonable and safe to introduce components in Elements that don't exist in the Design System is when those components encapsulate common CSS patterns (what the Console FE team would loosely term a "CSS utility" component). Instead of a HorizontalDetailList
, we have a Stack
component that encapsulates a narrow portion of the CSS flex API in a simple component: it can render its children as a horizontal or vertical "stack", with a consistent spacing between them (optional), and a "divider" element (also optional). Since there's no semantic meaning to the Stack (it's only there to provide some CSS), we avoid the issue I mention above.
That said, I'm personally on the fence as to whether Elements truly needs a similar Stack
component or not, but I don't think we should be introducing a HorizontalDetailList
. We have it because its better/easier than dealing with CSS directly, but in Elements, it seems easier to simply solve that challenge with CSS via styled
🤔
note: I'd make a similar argument against the addition of an IconLabel
component.
Drawer component design has a horizontal detail list component which we have used in a number of places. It would be useful to have these components available for the new Drawer to use and on their own
Our component uses these options
The detail with an Icon uses an IconLabel component which we use in a number of places