I think the issues you mentioned with the current version of Echarts do exist.
You pointed out that there are three ways to change colors and styles, which
can really lead to a lack of uniformity and consistency. Design tokens are a
great solution to cleverly unify those three approaches.
Hardcoded text in the source code:
Using design tokens can effectively solve this problem. Tokens provide a
consistent way to reference style properties like colors and line widths,
avoiding the use of specific values directly in the code. This approach
enhances the readability and maintainability of the code.
Uniformity in Theming:
By using tokens, achieving consistency and uniformity in themes becomes much
easier. Users can simply change the value of a token to alter the appearance of
the entire chart without worrying about the color settings for each specific
component.
Simplified Configuration Options:
Allowing users to use token names instead of specific color values in the
setOption method can greatly simplify the configuration process. Users only
need to specify a few tokens to affect the styles of multiple components.
Support for Night Mode:
By introducing a one-click switch for night mode, the token values can be
automatically adjusted according to preset rules, allowing for a quick change
in the chart's appearance. This can ease the developers' workload and enhance
the user experience.
At 2024-07-26 16:34:06, "Ovilia" <oviliazh...@gmail.com> wrote:
>Current Issues
>Currently, ECharts' themes (colors, line widths, etc.) have the following
>sources, listed in order from lowest to highest priority:
>
>Hardcoded literals within the source code for various components.
>Theme files introduced via echarts.registerTheme.
>Settings applied through chart.setOption.
>The issues are:
>
>The hardcoded literals in the source code are scattered across various
>components, lacking consistent and unified management, leading to arbitrary
>use of default color values.
>When users customize themes, they mostly rely on themes exported from the
>theme editor due to the lack of systematic documentation for the
>registerTheme parameters. The theme editor also sets colors by directly
>selecting literal values, lacking consistency and unity.
>Setting themes through configuration options usually requires modifications
>in various different settings, making it cumbersome.
>The night mode is essentially a hardcoded theme file. If developers
>customize the day mode, they usually need additional development work to
>adapt it for night mode, making it impossible to switch modes with a single
>click.
>
>Technical Solutions
>Source Code:
>Design Token Mechanism:
>
>Introduce a new set of Design Tokens. When using properties like color and
>line width, components and chart series will use token names instead of
>literal values.
>
>New API:
>Introduce a new echarts.registerTokens API to replace the previous
>echarts.registerTheme API. This new API will be used to replace default
>token values and can also specify custom tokens.
>Configuration Upgrade:
>
>Upgrade to support setting using token names instead of literals in
>chart.setOption.
>Night Mode:
>
>Introduce a new API for one-click switching to night mode. This API will
>automatically convert day colors to night colors based on a color
>conversion algorithm (considering different algorithms for text,
>background, border colors, etc.).
>Theme Editor:
>New Theme Editor:
>Redevelop a theme editor, which includes management of tokens (users can
>change token values using a color picker) and specifies which tokens are
>used for various properties in chart components and series.
>
>Discussion
>Do you think the above issues exist, and can using Design Tokens help
>resolve these issues?
>
>
>Thanks
>
>*Ovilia*
