VISALL和StandardChart主题机制设计

解决什么问题

架构统一，降低理解和管理的复杂度 通过架构约束，提升程序质量 增加可扩展性和可修改性，降低开发成本，给业务方提供自定义能力 改善visall的职责

终态

VISALL中没有任何主题相关的内容。 VISALL的theme、token、ThemeConfig都应该是透传到SD的: src/core/api.ts

/**
 * 规范设计参考了 Vega-Lite 和 Plot
 *
 * @see https://vega.github.io/vega-lite/docs/spec.html
 * @see https://observablehq.com/plot/getting-started
 */
export interface Specification {
  /** Hook API */
  hook: Partial<Hook>;
  /** 预设 hook */
  presetHook: Partial<Hook>;
  /** 设计 tokens */
  token: Partial<Token>;
  /** 布局 */
  layout: (typeof LAYOUT)[keyof typeof LAYOUT];
  /** 数据集 */
  data: { metadata?: unknown; values: TabularData }[];
  /**
   * 视图配置，分块
   *
   * - 例如主副图视图中，主图为一个块，副图为另一个块
   */
  view: {
    /** 主图 */
    main: NormalViewSpec | StandardChartViewSpec | HXKLineViewSpec;
    /** 副图 */
    secondary?: SimpleKLineViewSpec;
  };
  /** 是否代理（透传StandardChart） */
  proxy: boolean;
  /** StandardChart 主题（旧版，保持兼容） */
  theme?: string;
  /** 新版主题配置 */
  themeConfig?: ThemeConfig;
}

方案评审：CXH的第一版方案

存在的问题

1、机制没抽取和统一，SD和VISALL的主题机制能不能统一 2、主题模块和VISALL的边界没分清楚、UI组件的职责 3、主题没分包，存在冗余资源加载的问题(用户只用到了一个主题，但是需要加载所有的代码；或者业务方只用StandardChart) 4、搬功能，而不是优化机制

建议改进流程

1、微内核 2、看下ECharts的theme的设计、i18n的设计 3、流程跑通，写几个不同的use case场景的代码(应用SD、VISALL、开发主题等等) 4、确认VISALL的hook是否都可以下沉至StandardChart之上的theme模块

机制的职责范围

register、apply、unregister token定义：设计师定，业务方配置 theme：配置项预处理函数parser数组(函数名字、逻辑、执行顺序可以自己定，约束输入和输出既可) hook：生命周期，固定的，用户不可修改，由我们定

可以提供一个default theme，即跨业务线通用的那部分主题。

其他问题

公共函数该不该放theme模块中？

比如merge等，这种其实是跨项目通用的，应该单独提个团队级别的npm工具包

StandardChart和VISALL的token如何融合？

取并集 VISALL中有这个自定义的token：

[token:string]: unknown

这个其实是历史遗留问题，一开始设计师想设计一套Token涵盖我们的可视化库和沈佳棋的HexinUI组件库，所以我们设计了这个自定义的token，以兼容HexinUI组件库和其他的非可视化的UI库。实际上这个目前并未用到。

UI组件怎么办？

UI组件应该是和SD同一层级的概念。 layer其实是一个容器的设计，在layer中进行SD和UI组件的组合。