组件数据交互基础（v4）

oinone • 2023年11月1日 pm6:40 • 前端 • 1794 views

阅读之前

你应该：

了解DSL相关内容。母版-布局-DSL 渲染基础（v4）
了解SPI机制相关内容。组件SPI机制（v4）
了解组件相关内容。
- Class Component(ts)（v4）
- 组件生命周期（v4）

组件数据交互概述

数据结构设计

数据结构分为三大类，列表（List）、对象（Object）以及弹出层（Popup）。

列表（List）：用于多条数据的展示，主要包括搜索（用户端）、自定义条件（产品端）、排序、分页、数据选中、数据提交、数据校验功能。
对象（Object）：用于单条数据的展示，主要包括数据提交、数据校验功能。
弹出层（Popup）：用于在一块独立的空间展示对应类型的数据。

数据结构与对于的内置视图类型：

列表（List）：表格视图（TABLE）、画廊视图（GALLERY）
对象（Object）：表单视图（FORM）、详情视图（DETAIL）

数据交互设计原则

组件与组件之间的结构关系是独立的，组件与组件之间的数据是关联的。因此，数据交互整体采用“作用域隔离（View），行为互通（CallChaining），数据互通（ActiveRecords）”这样的基本原则进行设计。实现时，围绕不同视图类型定义了一类数据结构所需的基本属性。

在弹出层进行设计时，使用Submetadata的方式，将包括弹出层在内的所有组件包含在内，以形成新的作用域。

通用属性及方法

属性

rootData：根数据源
dataSource：当前数据源
activeRecords：当前激活数据源

为了在实现时包含所有数据结构，我们统一采用ActiveRecord[]类型为所有数据源的类型，这些数据源在不同类型的视图中表示不同的含义：

列表（List）：dataSource为列表当前数据源，activeRecords为列表中被选中的数据。特别的，showDataSource为当前展示的数据源，它是dataSource经过搜索、排序、分页等处理后的数据源，也是我们在组件中真正使用的数据源。
对象（Object）：daraSource和activeRecords总是完全一致的，且长度永远为1。因此我们有时也在组件中定义formData属性，并提供默认实现：this.activeRecords?.[0] || {}。

方法

reloadDataSource：重载当前数据源
reloadActiveRecords：重载当前激活数据源

由于底层实现并不能正确判断当前使用的数据类型，因此我们无法采用统一标准的数据源修改方法，这时候需要开发者们自行判断。

重载列表数据源

cosnt dataSource: ActiveRecord[] = 新的数据源
// 重载数据源
this.reloadDataSource(dataSource);
// 重置选中行
this.reloadActiveRecords([]);

重载表单数据源

cosnt dataSource: ActiveRecord[] = 新的数据源（数组中有且仅有一项）
// 重载数据源
this.reloadDataSource(dataSource);
// 此处必须保持相同引用
this.reloadActiveRecords(dataSource);

内置CallChaining（链式调用）

在自动化渲染过程中，我们通常无法明确知道当前组件与子组件交互的具体情况，甚至我们在定义当前组件时，并不需要关心（某些情况下可能无法关心）子组件的具体情况。这也决定了我们无法在任何一个组件中完整定义所需的一切功能。

为了保证组件行为的一致性，我们需要某些行为在各个组件的实现需要做到组件自治。以表格视图为例：当view标签在挂载时，我们无法确定应该怎样正确的加载数据，因此，我们需要交给一个具体的element标签来完成这一功能。当element标签对应的组件发生变化时，只需按照既定的重载方式将数据源提交给view标签即可。

除了保证组件行为的一致性外，我们不能完全的信任第三方框架对组件生命周期的处理顺序。因此，我们还需要对组件行为进行进一步的有序处理。以表格视图为例：我们希望搜索视图（SEARCH）的处理总是在加载数据前就处理完成的，这样将可以保证我们加载数据可以正确处理搜索条件，而这一特性并不随着模板结构的变化而发生变化。

平台内置的CallChaining

mountedCallChaining：挂载时钩子；
refreshCallChaining：刷新时钩子；
submitCallChaining：提交时钩子；
validatorCallChaining：验证时钩子；

优先级常量

VIEW_WIDGET_PRIORITY（0）：视图组件优先级
FETCH_DATA_WIDGET_PRIORITY（100）：数据提供者组件优先级
SUBVIEW_WIDGET_PRIORITY（200）：子视图组件优先级

未设置优先级的hook将最后执行，在通常情况下，你无需关心优先级的问题。

注意事项

CallChaining通常不需要手动初始化，仅需通过inject方式获取即可。
CallChaining的hook/unhook方法需要在组件生命周期的mounted/unmounted分别执行，如无特殊情况，一般通过this.path作为挂载钩子的唯一键。

在`字段组件`中使用`mountedCallChaing`

@Widget.Reactive()
@Widget.Inject()
protected mountedCallChaining: CallChaining | undefined;

protected mountedProcess() {
  // 挂载时处理
}

protected mounted() {
  super.mounted();
  this.mountedCallChaining?.hook(this.path, () => {
    this.mountedProcess();
  });
}

protected unmounted() {
  super.unmounted();
  this.mountedCallChaining?.unhook(this.path);
}

字段组件的mountedCallChaing并不是必须的，因此我们未进行内置处理。

一般的，当视图数据被加载完成时，字段组件的formData和value等属性，将通过响应式自动获取对应的值，因此在大多数情况下是不需要使用这一特性的。

当我们需要对字段获取的值做进一步初始化处理时，我们将需要使用这一特性。例如TreeSelect组件，必须在初始化时填充树下拉所需的结构化数据，这样才能正确展示对应的值。

当字段组件的mounted方法被执行时，我们还未执行视图数据加载，因此，在我们无法在mounted方法中操作formData和value等属性，只有在mountedCallChaining被view标签执行时，按照执行顺序，此时字段的mountedChaining将在视图数据被加载完成后执行。

数据源持有者和数据源提供者

在设计上，我们通常将view标签设计为数据源持有者，将element标签设计为数据源提供者。

原则上，在一个视图中有且仅有一个数据源提供者。

即：当一个element标签的实现组件通过reloadDataSource方法向view标签设置数据源，我们就称该实现组件为当前view标签的数据源提供者，view标签为数据源持有者。

provider/inject

阅读该章节需要理解vue的依赖注入原理

在实现上，我们通过provider/inject机制将上述通用属性/方法进行交替处理，就可以实现根据模板定义的结构进行隔离和共享功能。

例如dataSource属性的实现：

/**
 * 上级数据源
 * @protected
 */
@Widget.Reactive()
@Widget.Inject('dataSource')
protected parentDataSource: ActiveRecord[] | undefined;

/**
 * 当前数据源
 * @protected
 */
@Widget.Reactive()
private currentDataSource: ActiveRecord[] | null | undefined;

/**
 * 提供给下级的数据源
 * @protected
 */
@Widget.Reactive()
@Widget.Provide()
public get dataSource(): ActiveRecord[] | undefined {
  return this.currentDataSource || this.parentDataSource;
}

不足的是，由于provider/inject机制特性决定，通过provider提供的属性和方法，在某些情况下可能会进行穿透，导致组件通过inject获取的属性和方法并非是我们所期望的那样，因此，我们仍然需要进行一些特殊的处理，才能正确的处理子视图的数据交互，这一点在对象（Object）类型的视图中会详细介绍。

运行时上下文（metadataHandle/rootHandle）

在之前的文章中，我们知道前端的字段/动作组件渲染和后端元数据之间是密不可分的。

在数据交互方面，后端元数据对于字段类型的定义，将决定从API接口中获取的字段、数据类型和格式，以及通过API接口提交数据到后端时的字段、数据类型和格式。

数据类型和格式可以通过field标签的data属性，获取到经过后端编译的相关字段元数据。

那么，我们该如何决定，当数据提供者向后端发起请求时，应该获取哪些字段呢？

因此，我们设计了RuntimeContext机制，并通过metadataHandle/rootHandle机制，在任何一个组件都可以通过view标签正确获取已经实现隔离的运行时上下文机制。

以表单视图为例，我们来看这样一个经过合并后的完整视图模板：

（以下模板所展示的并非实际的运行时的结果，而是为了方便描述所提供的完整视图模板）

<view type="FORM">
    <element widget="actions">
        <action name="create" invisible="activeRecord.id" />
        <action name="update" invisible="!activeRecord.id" />
    </element>
    <element widget="fields">
        <field data="id" invisible="true" />
        <field data="code" />
        <field data="name" />
        <field data="relationOne" widget="Form">
            <view type="FORM">
                <element widget="form">
                    <field data="id" invisible="true" />
                    <field data="code" />
                    <field data="name" />
                </element>
            </view>
        </field>
        <field data="relationMany" widget="Table">
            <view type="TABLE">
                <element widget="actionBar">
                    <action name="openCreateDialog">
                        <view type="FORM">
                            <element widget="fields">
                                <field data="id" invisible="true" />
                                <field data="code" />
                                <field data="name" />
                            </element>
                        </view>
                    </action>
                </element>
                <element widget="table">
                    <field data="id" invisible="true" />
                    <field data="code" />
                    <field data="name" />
                    <element widget="rowActions">
                        <action name="openEditDialog">
                            <view type="FORM">
                                <element widget="fields">
                                    <field data="id" invisible="true" />
                                    <field data="code" />
                                    <field data="name" />
                                </element>
                            </view>
                        </action>
                    </element>
                </element>
            </view>
        </field>
    </element>
</view>

其中：

relationOne字段：代表M2O字段，它使用Form组件将字段展开为子表单视图。（O2O类型基本一致）
relationMany字段：代表O2M字段，它使用Table组件将字段展开为子表格视图。（M2M类型基本一致）
- openCreateDialog：代表打开一个创建弹窗，它是一个上下文类型为上下文无关的跳转动作。
- openEditDialog：代表打开一个编辑弹窗，它是一个上下文类型为单行的跳转动作。

PS：这里我们关注的是组件之间的数据交互，至于动作相关内容，我们会在其他文章中做进一步介绍。在这里我们只需要了解，当按钮的上下文类型为上下文无关时，该按钮将不会携带任何数据到下一个视图中；当按钮的上下文类型为单行时，该按钮将携带activeRecords[0]的数据到下一个视图中。

通过这个视图模板，我们将构建出如下图所示的RuntimeContext结构：

由此可见，我们的metadataHandle可能通过页面入口(ViewAction)提供，也可能通过字段(field标签)提供，还可能通过动作(action标签)提供。无一例外的是，所有的view标签都将生成一个与之对应的rootHandle。

在编码过程中，我们可以通过this.metadataRuntimeContext和this.rootRuntimeContext获取到对应的运行时上下文。前端运行时上下文API文档

列表（List）数据交互

对于列表（List）数据结构来说，我们目前提供了两种具体的视图：表格视图（TABLE）、画廊视图（GALLERY），这两种视图分别对应不同的数据展示形态。

表格视图（TABLE）：字段代表表格中的列（Column），每一列的数据使用相同方式展示，无法使用布局特性。
画廊视图（GALLERY）：使用list - item形式进行渲染，每一个item可以通过DSL描述其布局特性。

特别的是，搜索视图（SEARCH）是对列表（List）数据结构提供搜索（用户端）相关功能的子视图，其独立存在于页面中是没有意义的。

默认表格视图（TABLE）

<view type="TABLE">
    <pack widget="group">
        <view type="SEARCH">
            <element widget="search" slot="search" />
        </view>
    </pack>
    <pack widget="group" slot="tableGroup">
        <element widget="actionBar" slot="actionBar">
            <xslot name="actions" />
        </element>
        <element widget="table" slot="table">
            <element widget="expandColumn" slot="expandRow" />
            <xslot name="fields" />
            <element widget="rowActions" slot="rowActions" />
        </element>
    </pack>
</view>

在之前的文章中，我们了解了布局和标签的基本概念，为了能更好的说明数据交互相关的特征，我们将上述视图进行简化，仅留下与数据交互相关的标签。

<view type="TABLE">
    <view type="SEARCH">
        <element widget="search" slot="search" />
    </view>
    <element widget="actionBar" slot="actionBar">
        <xslot name="actions" />
    </element>
    <element widget="table" slot="table">
        <xslot name="fields" />
        <element widget="rowActions" slot="rowActions" />
    </element>
</view>

在这个视图中，我们可以获得如下信息：

主视图为表格（TABLE）视图。
包含一个搜索（SEARCH）子视图。
包含两个主要的element组件：widget="actionBar"和widget="table"。
在widget="table"中内置了一个element组件：widget="rowActions"。

在我们内置的组件实现中，widget="table"这个组件通过调用后端接口，为整个视图提供数据源。

组件挂载时序图

在上图中，我们可以看到，mountedCallChaining是在所有组件全部渲染并挂载完成后，通过最上层的view标签进行调用的，并且按照一定的优先级顺序执行了每个组件实现的挂载钩子函数。

组件数据源加载

当widget="search"组件执行了挂载钩子函数时，将从url参数中获取所需的searchBody和searchCondition属性，并通过flushSearchParameters方法将这两个参数提交到表格视图（TABLE）。

当widget="table"组件执行了挂载钩子函数时，将执行加载数据相关功能，并通过reloadDataSource和reloadActiveRecords方法对数据源进行向上提交。

用户行为触发的数据交互

这里列举了一些列表（List）常用的数据交互时序图，用于帮助大家对数据交互的整体逻辑可以有更清晰的理解。

点击搜索

排序/分页

表格勾选（table checkbox/radio）

对象（Object）数据交互

对于对象（Object）数据结构来说，我们目前提供了两种具体的视图：表单视图（FORM）、详情视图（DETAIL），这两种视图分别对应不同的数据展示形态。

表单视图（FORM）：主要用于数据的填写和提交；可以通过DSL描述其布局特性。
详情视图（DETAIL）：主要用于数据的展示，所有字段强制为只读态（与表单的只读态有所不同）；可以通过DSL描述其布局特性。

特别的是，表单视图（FORM）和详情视图（DETAIL）在对子视图的处理上并不完全相同。主要体现在数据提交类型(submitType)和关联关系更新类型（relationUpdateType）这两个属性的处理上。

数据提交类型(submitType)

/**
 * 数据提交类型
 */
export enum SubmitType {
  /**
   * <h3>默认</h3>
   * <p>
   * 基础字段使用全量提交，关联关系字段使用关联关系提交
   * </p>
   */
  default = 'default',
  /**
   * 不提交
   */
  none = 'none',
  /**
   * 关联关系字段关系提交(仅对关联关系字段有效)
   */
  relation = 'relation',
  /**
   * 关联关系字段增量提交(仅对关联关系字段有效)
   */
  increment = 'increment',
  /**
   * 全量提交
   */
  all = 'all'
}

关联关系更新类型（relationUpdateType）

/**
 * 关联关系数据更新类型
 */
export enum RelationUpdateType {
  /**
   * <h3>默认</h3>
   * <p>
   * 默认根据数据提交类型进行自动识别
   * </p>
   */
  default = 'default',
  /**
   * 使用特定接口进行差量更新（关联关系字段强制使用增量提交）
   */
  diff = 'diff',
  /**
   * 使用batch接口进行差量更新（关联关系字段强制使用增量提交）
   */
  batch = 'batch',
  /**
   * 全量更新
   */
  all = 'all'
}

下面分别列举了一些字段组件在不同视图中的默认功能。

表单视图（FORM）

组件 (widget)	一对一(O2O)	多对一(M2O)	一对多(O2M)	多对多(M2M)
Table	/	/	前端搜索、分页、排序 submitType="all" relationUpdateType="all"	前端搜索、分页、排序 submitType="relation" relationUpdateType="all"
Form	submitType="all" relationUpdateType="all"	submitType="all" relationUpdateType="all"	/	/
Select	submitType="relation" relationUpdateType="all"	submitType="relation" relationUpdateType="all"	submitType="relation" relationUpdateType="all"	submitType="relation" relationUpdateType="all"

详情视图（DETAIL）

组件 (widget)	一对一(O2O)	多对一(M2O)	一对多(O2M)	多对多(M2M)
Table	/	/	后端搜索、分页、排序不支持数据提交	后端搜索、分页、排序不支持数据提交
Form	仅用于查看 submitType="relation" relationUpdateType="all"	仅用于查看 submitType="relation" relationUpdateType="all"	/	/
Select	仅用于查看 submitType="relation" relationUpdateType="all"	仅用于查看 submitType="relation" relationUpdateType="all"	仅用于查看 submitType="relation" relationUpdateType="all"	仅用于查看 submitType="relation" relationUpdateType="all"

默认表单视图（FORM）

<view type="FORM">
    <element widget="actionBar" slot="actionBar">
        <xslot name="actions" />
    </element>
    <element widget="form" slot="form">
        <xslot name="fields" />
    </element>
</view>

在这个视图中，我们可以获得如下信息：

主视图为表单（FORM）视图。
包含两个主要的element组件：widget="actionBar"和widget="form"。

在我们内置的组件实现中，widget="form"这个组件通过调用后端接口，为整个视图提供数据源。

组件挂载时序图

组件数据源加载

用户行为触发的数据交互

这里列举了一些对象（Object）常用的数据交互时序图，用于帮助大家对数据交互的整体逻辑可以有更清晰的理解。

点击`提交动作（ServerAction）`（创建/编辑）

Oinone社区作者：oinone原创文章，如若转载，请注明出处：https://doc.oinone.top/frontend/26.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

前端项目开发知识要点

Like (0)

oinone

0 0

4.2.x版本更新说明-20230607

Previous 2023年6月20日 pm4:07

4.6.x版本升级说明-20231207

Next 2023年11月2日 pm1:58

前端

组件SPI机制（v4）

阅读之前你应该：了解DSL相关内容。母版-布局-DSL 渲染基础（v4）组件SPI简介不论是母版、布局还是DSL，所有定义在模板中的标签都是通过组件SPI机制获取到对应Class Component(ts)并继续执行渲染逻辑。基本概念：标签：xml中的标签，json中的dslNodeType属性。 Token组件：用于收集一组Class Component(ts)的基础组件。通常该基础组件包含了对应的一组基础能力（属性、函数等）维度（dsl属性）：用于从Token组件收集的所有Class Component(ts)组件中查找最佳匹配的参数。组件SPI机制将通过指定维度按照有权重的最长路径匹配算法获取最佳匹配的组件。组件注册到指定Token组件以BaseFieldWidget这个SPIToken组件为例，可以用如下方式，注册一个可以被field标签处理的自定义组件：（以下示例仅仅为了体现SPI注册的维度，而并非实际业务中使用的组件代码）注册一个String类型组件维度：视图类型：表单(FORM) 字段业务类型：String类型说明：该字段组件可以在表单(FORM)视图中使用并且该字段的业务类型是String类型 @SPI.ClassFactory( BaseFieldWidget.Token({ viewType: ViewType.Form, ttype: ModelFieldType.String }) ) export class FormStringFieldWidget extends BaseFieldWidget { …… } 注册一个多值的String类型组件维度：视图类型：表单(FORM) 字段业务类型：String类型是否多值：是说明：该字段组件可以在表单(FORM)视图中使用并且该字段的业务类型是String类型并且该字段为多值字段 @SPI.ClassFactory( BaseFieldWidget.Token({ viewType: ViewType.Form, ttype: ModelFieldType.String, multi: true }) ) export class FormStringMultiFieldWidget extends BaseFieldWidget { …… } 注册一个String类型的Hyperlinks组件维度：视图类型：表单(FORM) 字段业务类型：String类型组件名称：Hyperlinks 说明：该字段组件仅可以在表单(FORM)视图中使用并且该字段的业务类型是String类型并且组件名称必须指定为Hyperlinks @SPI.ClassFactory( BaseFieldWidget.Token({ viewType: ViewType.Form, ttype: ModelFieldType.String, widget: 'Hyperlinks' }) ) export class FormStringHyperlinksFieldWidget extends BaseFieldWidget { …… } 当上述组件全部按顺序注册在BaseFieldWidget这个SPIToken组件中时，将形成一个以BaseFieldWidget为根节点的树： “` mermaidgraph TDBaseFieldWidget —> FormStringFieldWidgetBaseFieldWidget —> FormStringMultiFieldWidgetFormStringFieldWidget —> FormStringHyperlinksFieldWidget“` 树的构建上述形成的组件树实际并非真实的存储结构，真实的存储结构是通过维度进行存储的，如下图所示：（圆角矩形表示维度上的属性和值，矩形表示对应的组件） “` mermaidgraph TDviewType([viewType: ViewType.Form]) —>ttype([ttype: ModelFieldType.Strng]) —>multi([multi: true]) & widget([widget: 'Hyperlinks']) direction LRttype —> FormStringFieldWidgetmulti —> FormStringMultiFieldWidgetwidget —> FormStringHyperlinksFieldWidget“` 有权重的最长路径匹配同样以上述BaseFieldWidget组件为例，该组件可用的维度有： viewType：ViewType[Enum] ttype：ModelFieldType[Enum] multi：[Boolean] widget：[String] model：[String] viewName：[String] name：[String] 当field标签被渲染时，我们会组装一个描述当前获取维度的对象： { "viewType": "FORM", "ttype": "STRING", "multi": false, "widget": "", // 在dsl中定义的任意值 "model": "", // 在dsl编译后自动填充 "viewName": "", // 当前视图名称 "name": "" // 字段的name属性，在dsl编译后自动填充 } 当我们需要使用FormStringHyperlinksFieldWidget这个组件时，我们在dsl中会使用如下方式定义： <view type="FORM" title="演示表单" name="演示模型form" model="demo.DemoModel"> <field data="name" widget="Hyperlinks" /> </view> 此时，我们虽然没有在dsl中定义维度中的其他信息，但在dsl返回到前端时，经过了后端编译填充了对应元数据相关属性，我们可以得到如下所示的对象： { "viewType": "FORM", "ttype": "STRING", "multi": false, "widget":…

oinone
2023年11月1日
1.2K001
前端

如何自定义表格字段？

目录一、表单字段注册vue组件实现机制二、表格字段注册vue组件实现机制三、机制对比分析四、表格字段完整案例表单字段注册vue组件实现机制核心代码 public initialize(props) { super.initialize(props); this.setComponent(VueComponent); return this; } 表格字段注册vue组件实现机制核心代码 @Widget.Method() public renderDefaultSlot(context: RowContext) { const value = this.compute(context); return [createVNode(CustomTableString, { value })]; } 因为表格有行跟列，每一列都是一个单独的字段（对应的是TS文件），但是每列里面的单元格承载的是Vue组件，所以通过这种方式可以实现表格每个字段对应的TS文件是同一份，而单元格的组件入口是通过renderDefaultSlot函数动态渲染的vue组件，只需要通过createVNode创建对应的vue组件，然后将props传递进去就行上下文接口 interface RowContext<T = unknown> { /** * 当前唯一键, 默认使用__draftId, 若不存在时，使用第三方组件内置唯一键（如VxeTable使用{@link VXE_TABLE_X_ID}） */ key: string; /** * 当前行数据 */ data: Record<string, unknown>; /** * 当前行索引 */ index: number; /** * 第三方组件原始上下文 */ origin: T; } 机制对比分析表单字段 vs 表格字段渲染机制对比表对比维度表单字段实现方案表格字段实现方案绑定时机 initialize 阶段静态绑定 renderDefaultSlot 阶段动态创建组件声明方式 this.setComponent(Component) createVNode(Component, props) 上下文传递通过类成员变量访问显式接收 RowContext 参数渲染控制粒度字段级（表单控件）单元格级表格字段完整案例 import { SPI, ViewType, BaseFieldWidget, Widget, TableNumberWidget, ModelFieldType, RowContext } from '@kunlun/dependencies'; import CustomTableString from './CustomTableString.vue'; import { createVNode } from 'vue'; @SPI.ClassFactory( BaseFieldWidget.Token({ ttype: ModelFieldType.String, viewType: [ViewType.Table], widget: 'CustomTableStringWidget' }) ) export class CustomTableStringWidget extends BaseTableFieldWidget { @Widget.Method() public renderDefaultSlot(context:RowContext) { const value = this.compute(context); // 当前字段的值 const rowData = context.data // 当前行的数据 const dataSource = this.dataSource // 表格数据 if (value) { // 自定义组件入口在此处 return [createVNode(CustomTableString, { value })]; } return []; } } <template> <div>当前值： {{value}}</div> </template> <script lang="ts"> import { defineComponent } from 'vue'…

汤乾华
2023年11月6日
2.2K000
前端

前端自定义请求入门版

在开发过程中，为了满足业务场景、增加灵活性，前端自定义请求不可避免。下面将会从——自定义 mask、自定义表格(表单等)、自定义字段三个实际场景的角度，介绍自定义请求。这篇文章把请求都写在了 ts 中，这样便于继承重写，如果不习惯 ts 的写法，把请求写在 vue 里也是可以的。 1. 自定义 mask mask 组件通常会有一个特点：在不同页面不同模型或不同应用下都展示，与业务模型无关，且往往只需要请求一次。同时可能有精确控制请求体大小的需求，这就很适合采取手写 GraphQL 的方式。例如，我要重写顶部 mask 中的用户组件，展示用户信息。这个请求就只需请求一次，而且不需要复用，就很适合手写 GraphQL。这里继承平台的用户组件，然后在代码中写死 GraphQL 发起请求。但是 GraphQL 语句怎么拼呢？我们可以去默认页面，打开浏览器控制台，找到相应的请求，把 GraphQL 语句复制出来，这里复制下默认的用户请求。 http.query 参数的构造、相应结果的获取都能从请求中得到。可以看到我这里精简了请求，只取了用户名。 TS import { SPI, UserWidget, MaskWidget, Widget, http } from '@kunlun/dependencies'; import Test from './Test.vue'; @SPI.ClassFactory(MaskWidget.Token({ widget: 'user' })) export class TestWidget extends UserWidget { public initialize(props) { super.initialize(props); this.setComponent(Test); return this; } // 添加响应式注解，这样能在 vue 中接受到 ts 中的变量 @Widget.Reactive() public testUserInfo: { pamirsUser: { name: string } } | undefined; public async queryUser() { const query = ` { topBarUserBlockQuery { construct(data: {}) { pamirsUser { name } } } } `; const result = await http.query('user', query); this.testUserInfo = result.data['topBarUserBlockQuery']['construct'] as { pamirsUser: { name: string } }; } public mounted() { this.queryUser(); } } VUE <template> <div class="Test"> {{ testUserInfo }} </div> </template> <script lang="ts"> import { defineComponent } from 'vue'; export default defineComponent({ name: 'Test', props: ['testUserInfo'] }); </script> 效果如下： 2. 自定义表格(表单)等视图元素组件 2-1. 自定义表格 2-1-1. 自定义表格自动获取数据 Oinone 提供了前端组件的默认实现。所以生成默认页面的时候，请求数据都是通的，可以看到表格、表单、表单里的字段等组件数据都是能回填的。所以这里继承平台的表格组件，就有了平台表格自动获取数据的能力。 TS import { BaseElementWidget, SPI, TABLE_WIDGET, TableWidget, ViewType } from '@kunlun/dependencies'; import Test from './Test.vue'; @SPI.ClassFactory( BaseElementWidget.Token({ viewType: ViewType.Table, widget:…

银时
2025年4月17日
705000
低无一体

如何自定义表格单元格样式

介绍 OinOne的表格是基于Vxe-Table实现的，我们将Vxe-table内置的关于单元格样式的方法、属性开放到了表格组件TableWidget上 Vxe-Table相关文档 vxe-table的单元格样式 vxe-table的单元格动态样式单元格样式行的样式、单元格样式，表头的样式、表尾的样式、全部都可以完全自定义，通过设置 cellClassName、headerCellClassName、rowClassName …等参数（注：当自定义样式之后可能会覆盖表格的样式，比如选中行..等，记得自行处理好相关样式）单元格动态样式行的动态样式、单元格动态样式，表头的动态样式、表尾的动态样式、可以通过设置 cellStyle、headerCellStyle、rowStyle …等参数（注：当自定义样式之后可能会覆盖表格的样式，比如选中行..等，记得自行处理好相关样式）示例代码这里仅演示cellClassName和cellStyle，其他方法的出入参数请参考上面的Vxe-Table文档 import { BaseElementWidget, SPI, TableWidget, ViewType, Widget } from '@kunlun/dependencies'; @SPI.ClassFactory(BaseElementWidget.Token({ viewType: ViewType.Table, widget: 'CustomStyleTableWidget', })) export class CustomStyleTableWidget extends TableWidget { @Widget.Method() protected cellClassName({ row, rowIndex, $rowIndex, column, columnIndex, $columnIndex }) { if (column.field === 'field00019') { return `demo-cell-${column.field}`; } return ''; } @Widget.Method() protected cellStyle({ row, rowIndex, $rowIndex, column, columnIndex, $columnIndex }) { if (column.field === 'field00019') { return { backgroundColor: '#f60', color: '#ffffff' }; } return ''; } } 效果预览

nation
2024年10月30日
1.4K000
前端

前端自定义左树右表中的树

在 oinone 平台中，提供了默认的左树右表的视图，用户可以通过界面设计器配置，默认的树视图不一定满足所有需求，尤其当需要自定义功能或复杂的交互时，我们可以通过自定义视图来实现更灵活的展现。本文将带你一步步了解如何自定义左树右表视图中的树组件。自定义树视图 1. 使用界面设计器配置视图首先，我们需要通过界面设计器生成基础的左树右表视图。界面设计器允许用户根据不同需求进行拖拽配置，快速创建可视化界面。配置完视图之后，我们可以重写左侧的树组件。Oinone 的默认树组件是 TableSearchTreeWidget，通过自定义的方式，我们可以实现更高级的功能。 2. 重写 TableSearchTreeWidget import { BaseElementWidget, SPI, TableSearchTreeWidget, ViewType } from '@kunlun/dependencies'; import CustomTableSearchTree from './CustomTableSearchTree.vue'; @SPI.ClassFactory( BaseElementWidget.Token({ viewType: [ViewType.Table, ViewType.Form], widget: 'tree', model: 'resource.k2.Model0000000100' // 改成自己的模型 }) ) export class CustomTableSearchTreeWidget extends TableSearchTreeWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomTableSearchTree); return this; } } 3. 定义 Vue 树组件接下来，我们来实现 CustomTableSearchTree.vue 组件。这个组件将处理树的数据加载、节点选中等逻辑。你可以根据项目的需要修改其中的交互逻辑或 UI 设计。 <template> <a-tree :load-data="onLoadData" :tree-data="treeData" @select="onSelected" /> </template> <script lang="ts"> import { OioTreeNode, TreeUtils } from '@kunlun/dependencies'; import { computed, defineComponent } from 'vue'; export default defineComponent({ props: { rootNode: { type: Object }, loadData: { type: Function, required: true }, onSelected: { type: Function, required: true } }, setup(props) { // // 计算树的数据源，使用 TreeUtils 处理 const treeData = computed(() => { return TreeUtils.fillLoadMoreAction([…(props.rootNode?.children || [])]); }); // 异步加载子节点 const onLoadData = async (node) => { return await props.loadData(node.dataRef); }; // 处理节点选中事件 const onSelected = ( selectedKeys: string[], e: { nativeEvent: PointerEvent; node: { dataRef: OioTreeNode }; selected: boolean } ) => { props.onSelected?.(e.node.dataRef, e.selected); }; return { treeData, onLoadData, onSelected }; } }); </script> 4. 自定义…

汤乾华
2024年10月21日
2.9K000

Please Login to Comment

shao 2024年11月25日

支持其他的国家的语言，需要在资源里面创建，如果有其他的疑问，也可以群内联系我们哈

Comment on 6.4 国际化之多语言
xiao3 2024年11月25日

只支持英语吗？如何添加其他语种？

Comment on 6.4 国际化之多语言
psyy 2024年8月21日

1.4 Oinone对软件特性的思考，技术原理一段，几余（几->冗） 1.4 Oinone对软件特性的思考，协同演进一段，新特生（生->性）

Comment on 1.4 Oinone对软件特性的思考
望闲 2024年6月21日

感谢反馈，已修正

Comment on 1.5 Oinone与行业对比
xinf 2024年6月14日

bug反馈：采用无一体设计 -> 采用低无一体设计

Comment on 1.5 Oinone与行业对比

组件数据交互基础（v4）

阅读之前

组件数据交互概述

数据结构设计

数据交互设计原则

通用属性及方法

属性

方法

重载列表数据源

重载表单数据源

内置CallChaining（链式调用）

平台内置的CallChaining

优先级常量

注意事项

在字段组件中使用mountedCallChaing

数据源持有者和数据源提供者

provider/inject

阅读该章节需要理解vue的依赖注入原理

运行时上下文（metadataHandle/rootHandle）

列表（List）数据交互

默认表格视图（TABLE）

组件挂载时序图

组件数据源加载

用户行为触发的数据交互

点击搜索

排序/分页

表格勾选（table checkbox/radio）

对象（Object）数据交互

数据提交类型(submitType)

关联关系更新类型（relationUpdateType）

表单视图（FORM）

详情视图（DETAIL）

默认表单视图（FORM）

组件挂载时序图

组件数据源加载

用户行为触发的数据交互

点击提交动作（ServerAction）（创建/编辑）

相关推荐

组件SPI机制（v4）

如何自定义表格字段？

前端自定义请求入门版

如何自定义表格单元格样式

前端自定义左树右表中的树

Leave a Reply

在`字段组件`中使用`mountedCallChaing`

点击`提交动作（ServerAction）`（创建/编辑）