前端环境和启动前端工程

相关推荐

• 组件

  前端自定义组件之单页面步骤条

  本文将讲解如何通过自定义，实现单页面的步骤条组件。其中每个步骤的元素里都是界面设计器拖出来的。 实现路径 整体的实现思路是界面设计器拖个选项卡组件，自定义这个选项卡，里面的每个选项页都当成一步渲染出来，每一步的名称是选项页的标题。 1. 界面设计器拖出页面 我们界面设计器拖个选项卡组件，然后在每个选项页里拖拽任意元素。完成后点击右上角九宫格，选中选项卡，填入组件 api 名称，作用是把选项卡切换成我们自定义的步骤条组件，这里的 api 名称和自定义组件的 widget 对应。最后发布页面，并绑定菜单。 2. 组件实现 widget 组件重写了选项卡，核心函数 renderStep，通过 DslRender.render 方法渲染界面设计器拖拽的元素，每一步的 step 又是解析选卡页得到的。 import { SPI, Widget, DefaultTabsWidget, BasePackWidget, DslDefinition, DslRender, DslDefinitionType, CallChaining, customMutation } from '@oinone/kunlun-dependencies'; import { VNode } from 'vue'; import NextStepSinglePage from './NextStepSinglePage.vue'; @SPI.ClassFactory(BasePackWidget.Token({ widget: 'NextStepSinglePage' })) export class NextStepSinglePageWidget extends DefaultTabsWidget { public initialize(props) { super.initialize(props); this.setComponent(NextStepSinglePage); return this; } @Widget.Reactive() public get invisible() { return false; } // 配置的每一步名称，解析选项页的标题 @Widget.Reactive() public get titles() { return this.template?.widgets?.map((item) => item.title) || []; } // region 上一步下一步配置 // 步骤数组，数组里的元素即步骤要渲染的内容 @Widget.Reactive() public get steps(): DslDefinition[] { // 每个 tab 是一个步骤，这里会有多个步骤 // 每个步骤里有多个元素，又是数组 // 所以这里是二维数组 const tabDsls: DslDefinition[][] = this.template?.widgets.map((item) => item.widgets) || []; // 对每个步骤的子元素们，外侧包一层 row 布局，所以变回了一维数组 return tabDsls.map((tabDsl) => { return { …(this.template || {}), dslNodeType: DslDefinitionType.PACK, widgets: tabDsl, widget: 'row', resolveOptions: { mode: 1 } }; }); } // 渲染步骤，每个步骤有多个子元素 @Widget.Method() public renderStep(step: DslDefinition): VNode | undefined { return DslRender.render(step); } // region 校验相关 // 校验的钩子 @Widget.Reactive() @Widget.Inject('validatorCallChaining') protected parentValidatorCallChaining: CallChaining<boolean> | undefined; // 校验步骤表单 @Widget.Method() public async onValidator(): Promise<boolean> { const res = await this.parentValidatorCallChaining?.syncCall(); return res…

  银时

  2025年7月8日

  777000
• 前端

  自定义组件之手动渲染基础（v4）

  阅读之前 你应该： 了解DSL相关内容。母版-布局-DSL 渲染基础（v4） 了解SPI机制相关内容。组件SPI机制（v4.3.0） 了解组件相关内容。 Class Component(ts)（v4） 自定义组件之自动渲染（组件插槽的使用）（v4） 为什么需要手动渲染 在自定义组件之自动渲染（组件插槽的使用）（v4）文章中，我们介绍了带有具名插槽的组件可以使用DSL模板进行自动化渲染，并且可以用相对简单的方式与元数据进行结合。 虽然自动化渲染在实现基本业务逻辑的情况下，有着良好的表现，但自动化渲染方式也有着不可避免的局限性。 比如：当需要多个视图在同一个位置进行切换。 在我们的平台中，界面设计器的设计页面，在任何一个组件在选中后，需要渲染对应的右侧属性面板。每个面板的视图信息是保存在对应的元件中的。根据元件的不同，找到对应的视图进行渲染。在单个视图中使用自动化渲染是无法处理这一问题的，我们需要一种可以局部渲染指定视图的方式，来解决这一问题。 获取一个视图 使用ViewCache获取视图 export class ViewCache { /** * 通过模型编码和名称获取视图 * @param model 模型编码 * @param name 名称 * @param force 强制查询 * @return 运行时视图 */ public static async get(model: string, name: string, force = false): Promise<RuntimeView | undefined> /** * 通过模型编码、自定义名称和模板获取编译后的视图（此视图非完整视图，仅用于自定义渲染使用） * @param model 模型编码 * @param name 名称（用作缓存key） * @param template 视图模板 * @param force 强制查询 * @return 运行时视图 */ public static async compile( model: string, name: string, template: string, force = false ): Promise<RuntimeView | undefined> } ViewCache#get：用于服务端定义视图，客户端直接获取完整视图信息。 ViewCache#compile：用于客户端定义视图，通过服务端编译填充元数据相关信息，但不包含视图其他信息。 自定义一个带有具名插槽的组件，并提供切换视图的相关按钮 以下是一个自定义组件的完整示例，其使用ViewCache#compile方法获取视图。 view.ts const template1 = `<view> <field data="id" invisible="true" /> <field data="code" label="编码" /> <field data="name" label="名称" /> </view>`; const template2 = `<view> <field data="id" invisible="true" /> <field data="name" label="名称" /> <field data="code" label="编码" /> </view>`; export const templates = { template1, template2 }; ManualDemoWidget.ts import { BaseElementWidget, createRuntimeContextForWidget, FormWidget, RuntimeView, SPI, ViewCache, ViewType, Widget } from '@kunlun/dependencies'; import ManualDemo from './ManualDemo.vue'; import { templates } from './view'; @SPI.ClassFactory(BaseElementWidget.Token({ widget: 'ManualDemo' })) export class ManualDemoWidget extends BaseElementWidget { private formWidget: FormWidget | undefined; public…

  数式-海波

  2023年11月1日

  1.1K000
• 前端

  如何自定义表格字段？

  目录 一、表单字段注册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.0K000
• 前端

  前端graphql拼接复杂的数据类型结构

  在前端开发中，有时需要自定义视图，但手写 GraphQL 查询语句非常繁琐，特别是当查询很复杂时。本文将介绍如何使用平台内置的API buildSingleItemParam 来简化这个过程。 使用方法 buildSingleItemParam 方法接受两个参数： 字段结构 数据 下面是一个示例代码： import { IModelField, buildSingleItemParam } from '@kunlun/dependencies'; const onSaveViewData = async (data) => { // 定义字段的数据结构 const modelFields = [ { name: 'conversationId', ttype: ModelFieldType.String }, { name: 'msgId', ttype: ModelFieldType.String }, { name: 'rating', ttype: ModelFieldType.Integer }, { name: 'tags', ttype: ModelFieldType.OneToMany, modelFields: [ { name: 'id', ttype: ModelFieldType.String }, { name: 'name', ttype: ModelFieldType.String } ] }, { name: 'text', ttype: ModelFieldType.String } ] as IModelField[]; // 构建 GraphQL 查询语句 const gqlStr = await buildSingleItemParam(modelFields, data); const gqlBody = `mutation { chatMessageFeedbackMutation { create( data: ${gqlStr} ) { conversationId msgId rating tags { id } text } } }`; // 向服务器发送请求 const rst = await http.query('ModuleName', gqlBody) // todo }; // 调用示例 onSaveViewData({ conversationId: '12', msgId: '123', tags: [ { id: '122', name: '222' }, { id: '122', name: '222' } ] }); 以上是使用 buildSingleItemParam 简化 GraphQL 查询语句的示例代码。通过这种方式，我们可以更高效地构建复杂的查询语句，提高开发效率。

  oinone

  2023年11月1日

  2.8K000
• 前端

  组件数据交互基础（v4）

  阅读之前 你应该： 了解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…

  oinone

  2023年11月1日

  1.7K000