Status badge

[airikej]

https://github.com/TEHIK-EE/tedi-design-system/issues/130

Component name: Badge Figma design?node-id=2385-24154&m=dev)

Community Tag component will break into 2 components: Badge and Tag:

• A badge is a status label that indicates the state of a process, person, document, or something similar. It provides the user with information about which stage the given process is in.
• A tag displays keywords, topics, applied filters, or other selections related to a document

Badge API:

Name	Required/Optional	Descrption	Type	Possible values	Default
children	Required	The content to be displayed inside the Badge	React.ReactNode
className	Optional	Additional class name(s) to apply to the element	string
color	Optional	Specifies the color scheme of the Badge (e.g., primary, warning, etc.)	BadgeColor	'default' \| 'primary' \| 'accent' \| 'positive' \| 'warning' \| 'important'	default
variant	Optional	Determines the style or visual type of the Tag (e.g., filled, outlined, etc.)	BadgeVariant	'filled' \| 'filled-bordered' \| 'outlined'	default
size	Optional	Specifies the size of the Badge, such as default, or large	BadgeSize	'default' \| 'large'	default
id	Optional	ID attribute	string
title	Optional	Provides the full text or description when the Badge represents an abbreviation. This is typically shown as a tooltip on hover	string

Changes:

• Renamed type prop to variant: The type prop has been renamed to variant to better reflect its purpose of controlling the visual style of the Badge component. Previously, type could be misunderstood as also handling color, which was not the case. The new variant prop more clearly differentiates between styling options like "filled" or "bordered"
• Removed isDisabled prop: The isDisabled prop has been removed as it was not being used in the current implementation. Since it didn’t serve any functional purpose, removing it simplifies the component’s API.
• Removed iconOnly and iconName props: The iconOnly and iconName props have been removed in favor of a more flexible approach. Now, developers can directly pass an Icon component inside the Badge. This allows for more versatile layouts where you can combine text, icons, or other elements as needed, rather than relying on specific props for icon management.
• Clarified rounded prop usage: The rounded prop was primarily used when the Community Tag component included an icon. Since the Icon component now supports background option, the rounded prop is less relevant at the Badge level and can be managed directly within the Icon component, leading to more concise and modular code.

Need clarification from community:

• hasArrow prop
• status prop

Suggestions for development/future ideas:

• add showTooltip prop in conjunction with title?

[airikej]

hasArrow prop will be removed, status prop will be added.

Design questions: Right now "invisible" and "default" types are missing in the new Badge

[karolin-kivisikk]

Status badge with dot-indicator has been added to Figma?node-id=2385-24154&t=pQAO0g4IeKdgAGJz-4).

Potential migration Community tag vs TEDI status badge solution:	Community	TEDI-ready
Color=default	Variant=default
Color=primary	Variant=primary
Color=accent	Variant=accent
Color=positive	Variant=success
Color=warning	Variant=warning
Color=important	Variant=danger
Type=default	HasFillcolor=True + HasBorder=true (if bright color is used only for contrast from the background then switching tedi new badge border on should do the trick)
Type=secondary	HasFillcolor=True
Type=ghost	HasBorder=true
Type=invisible	use text variables, status-badge-text-default, status-badge-text-primary etc..
Arrow=true	-
Status=true	ShowStatusIndicator=true
Rounded=true	-
Size=large	Size=large
IconOnly=true	IconOnly=true
-	ShowIcon=true (adds icon to text)
-	IconOnly=true

As I understand rounded and hasArrow are not relevant anymore so the migration is not necessary? Bright colors were only used to add contrast (used on elements that have grey surfaces)? If that's the case then new badge border should solve this problem. If not then I would like to know some specific use cases to decide if bright colors are needed in the base component set cause it's not common to have multiple sets of status colors in the selection.