v5 component refactor: Label

[ksolanki7]

Abstract

As part of the v5 Elements release, each component will be reviewed and refactored to ensure best practice and design system alignment

Specification

• Is new component or existing? Existing
• Is the component being re-named? No
• Is the component design signed off by product and design? Yes
• Guide to component structure & documentation in storybook
• Link to DS in Figma
• Link to Elements

Developer Checklist

• Styles alignment between Design System and Elements
• Check design tokens in Figma and implement CSS variable tokens if available for relevant component
• Align with accessibility standards / spec as per above
• If relevant, break down component into Styles Only and React component structures
• Ensure all variants of components are documented as appropriate
• Ensure unit test coverage is adequate for component
• Update documentation in MDX file as per guidelines
• Changelog updated to reflect a single beta version per component ideally

Release Checklist

• Approved PR merged to main
• Design & product review and feedback addressed by developer
• Beta release by product / engineering lead to next beta version

[ksolanki7]

@HollyJoyPhillips I have created this issue for new element Label which dev ready over figma.

[rpt-rfoxy]

Hello Genks,
cc @kurtdoherty && @ksolanki7

From the Figma design, the new Label design only requires adding new parameters, Here's my proposed solution:

---

Updates to the Label Component

1. UI Updates

• No new design is required, only two variants will be added.
• add new two size (--font-size-xs and --font-size-sm )
• add * mark as required info

2. New Parameters

Label Solution Design

The Label will have the following main prop interface

Prop	Value	Default	Usage
variant?: union	"soft" , "strong", undefined	soft	label variant depend on text color
size?: union	"small" , "medium", undefined	medium	label size using --font-size-xs and --font-size-sm
required?: boolean	true, false, undefined	undefined	to set * mark in the end of element child

---

• Text Overflow
  By default, the text overflow will continue on a new line, depending on the wrapper.

---

Code Concept

to see the detail implementation, you can check it here (POC) please let me know if the link didnt work

// types.ts
export interface LabelProps extends LabelHTMLAttributes<HTMLLabelElement> {
  variant?: "soft" | "strong";
  size?: "small" | "medium";
  required?: boolean;
}

// Label.tsx
export const Label: FC<LabelProps> = ({
  children,
  required,
  size = "medium",
  variant = "soft",
  ...rest
}) => {
  return (
    <ElLabel {...rest} data-size={size} data-variant={variant}>
      {children}
      {required && " *"}
    </ElLabel>
  );
};

//style.ts

export const ElLabel = styled.label`
  &[data-size="small"] {
    font-size: var(--font-size-xs);
  }
  &[data-size="medium"] {
    font-size: var(--font-size-sm);
  }
  &[data-variant="soft"] {
    color: var(--neutral-500);
  }
  &[data-variant="strong"] {
    color: var(--text-primary);
  }
`;

[ksolanki7]

praise: Thank you @rpt-rfoxy for coming up with the solution for your 1st ticket.

suggestion: It is always a good idea to deprecate the old component and create a new one. Here's why:

• Maintain consistency: Upgrading a design system aligns it with updated standards while deprecating old components ensures consistency and a cohesive user experience.
• Simplify Maintenance: Deprecating outdated components reduces complexity and technical debt, simplifying maintenance and evolution of the design system.
• Best practice and QA: Deprecating older components encourage the adoption of improved, modern ones with better accessibility, performance, and usability, reducing regressions and simplifying testing.

note: In terms of UI updates, there are differences in the color, font, and other CSS properties in the new DS for the label component, so highly recommend deprecating the existing v4 label and creating a new v5 label.

suggestion: I would personally recommend using variant or a similar approach instead of intent to align with other v5 components.

suggestion: It would be great if the solution document includes what actual props will be used and their role in the component. Check this for ref: #242

suggestion: I believe using a data attribute provides a more component-centric and semantic approach compared to class names. For instance, if the React component prop is size, the corresponding styled component could utilize a data-size attribute. The styles would then target elements with selectors like &[data-size="small"] { ... } or &[data-size="medium"] { ... }. In contrast, class names such as elSizeSmall and elSizeMedium can feel overly generic and less tied to the specific component context.

[rpt-rfoxy]

praise: hi @ksolanki7 thanks for the feedback for the Design solution.
note: i already update the Design Solution, and i add the link to the POC too, please let me know if there is anything to update

[ksolanki7]

@rpt-rfoxy praise Thanks for updating the solution.

suggestion: From the POC - It is unnecessary to create a separate file for types when there are only a few interfaces and not shared. Including them directly within the component file is a more streamlined approach, enhancing readability and maintaining context.