talend / design-system

Talend Design System

The Design System has moved to Talend/ui

design-system's Issues

Get a domain

[RFC] Replace Styled Components

Status

In progress

Context

Styled Components are great for managing a design system with several themes or modes.
They have been chosen because we needed multi-themes support and including IE11 support. So CSS custom properties were not an option.
We've since dropped the support of IE11. We can challenge that choice.

Problems

They intertwine styles and components in a way that muddles the component's typings.
Its as property is too permissive for a design system, enabling users to break the intended patterns using any HTML element or React component.
There is no guarantee about the tokens you use (or not) in your styles.
You cannot quickly identify which DOM node will be generated because of the exported Styled Components.
You must precise the displayName for each component and their variations

What do we need

• A styling solution that does not pollute the components' typing
• A styling solution that handles theming (white-labeling as much as a possible dark theme)
• A styling solution that easily exploits tokens and variables
• We must be able consume variables that represent tokens

What would we like

• Exportable themes-as-variables: our customers (the front-end engineers) mostly use CSS modules with Sass variables in their projects. When the design system doesn't provide everything they need, we should still give them variables accessing the theme.
• Global stylesheets
• Something simple and familiar to use
• No need for displayName

Solutions

Try several options:

• CSS Modules #267
• Vanilla Extract #261
• Other?

Fonts

Get the good fonts from Webpack build

Create a new package @talend/fonts to rely on

feat(ARCH-323): backport IconsProvider et Icon from components

Rewrite them in TS here and proxy them in TUI

Use ThemeProvider on Talend/UI

Styled components need to instantiate a ThemeProvider to get theme colors

• A possible solution is to use Layout and add this for once
• Another one may be to declare a new CMF module

chore(ARCH-323): react popper migration in tui

Design system rely on @popperjs-core and TUI has the previous major version of this lib.

RFC: [data-test] attributes

Status

Validation

Context

Quality Assurance teams perform automated tests on Products for non-regression testing.

Problems

QA teams lean on HTML ID attributes or XPath to automate tests on UI, and updates on the shared library can break these scenarios.

Solutions

I suggest including [data-testid] in the components or layout markup.
1 — By documenting them, the first benefit will be to act on a contract with our QA team.
2 — By using them, after all, the second benefit will also be to perform component testing.

Consequences

We need to agree on a specific vocabulary to use for their values.

I suggest this pattern: <component_name>.<element_type>.<interactive_action>

Identifier	Description
component_name	Component identifier from our design language (ex: modal, search, password, inlineediting, etc.)
element_type	Element or its type used (ex: button, link, input, textarea, etc.)
interactive_action	Interactive action as an identifier (ex: cancel, edit, submit, etc.)

For example, for the button Edit used in the Ìnline editing

<Button data-testid="inlineediting.button.edit">Edit</Button>

Or for a search bar used as Filter in a list

<Search data-testid="filter.input" />

test(ARCH-323): add tests coverage to 60 % and cleanup lint errors (255)