提交数据动作如何把弹窗内的数据完全返回

相关推荐

• 前端

  组件数据交互基础（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.9K000
• 前端

  OioProvider详解

  OioProvider OioProvider是平台的初始化入口。 示例入口 main.ts import { VueOioProvider } from '@kunlun/dependencies'; VueOioProvider(); 网络请求/响应配置 http 平台统一使用apollo作为统一的http请求发起服务，并使用GraphQL协议作为前后端协议。 参考文档： apollo-client graphql 配置方式 VueOioProvider({ http?: OioHttpConfig }); OioHttpConfig /** * OioHttp配置 */ export interface OioHttpConfig { /** * base url */ url: string; /** * 拦截器配置 */ interceptor?: Partial<InterceptorOptions>; /** * 中间件配置（优先于拦截器） */ middleware?: NetworkMiddlewareHandler | NetworkMiddlewareHandler[]; } 内置拦截器可选项 InterceptorOptions /** * 拦截器可选项 */ export interface InterceptorOptions { /** * 网络错误拦截器 */ networkError: NetworkInterceptor; /** * 请求成功拦截器 (success) */ requestSuccess: NetworkInterceptor; /** * 重定向拦截器 (success) */ actionRedirect: NetworkInterceptor; /** * 登录重定向拦截器 (error) */ loginRedirect: NetworkInterceptor; /** * 请求错误拦截器 (error) */ requestError: NetworkInterceptor; /** * MessageHub拦截器 (success/error) */ messageHub: NetworkInterceptor; /** * 前置拦截器 */ beforeInterceptors: NetworkInterceptor | NetworkInterceptor[]; /** * 后置拦截器 */ afterInterceptors: NetworkInterceptor | NetworkInterceptor[]; } 内置拦截器执行顺序: beforeInterceptors：前置拦截器 networkError：网络错误 actionRedirect：重定向 requestSuccess 请求成功 loginRedirect：登录重定向 requestError：请求错误 messageHub：MessageHub afterInterceptors：后置拦截器 NetworkInterceptor /** * <h3>网络请求拦截器</h3> * <ul> * <li>拦截器将按照注册顺序依次执行</li> * <li>当任何一个拦截器返回false时，将中断拦截器执行</li> * <li>内置拦截器总是优先于自定义拦截器执行</li> * </ul> * */ export interface NetworkInterceptor { /** * 成功拦截 * @param response 响应结果 */ success?(response: IResponseResult): ReturnPromise<boolean>; /** * 错误拦截 * @param response 响应结果 */ error?(response: IResponseErrorResult): ReturnPromise<boolean>; } 自定义路由配置 router 配置方式 VueOioProvider({ router?: RouterPath[]…

  汤乾华

  2023年11月6日

  2.0K000
• 前端

  如何通过浏览器开发者工具提高调试效率

  1.通过vue devtool查看vue组件和oinone组件的信息 平台字段、动作、视图组件都是以Widget结尾的，可以通过关键字快速找到组件 安装vue devtool插件 chrome安装最新版的vue devtool插件 谷歌应用商店插件地址，隐藏窗口需要在扩展程序的详情页额外设置才能使用该插件 安装好插件后，可以通过插件选中html页面中的元素查看相关信息 相关特性了解 组件自动创建的vue组件以组件的class类名命名，据此特性可以得出自定义组件的时候，可继承该命名的父类 一般oinone的组件以Widget后缀命名，也推荐大家也以此为后缀，方便在vue调试面板快速看出哪些是oinone组件 选中oinone组件后可以在右侧面板看到相关的组件信息，部分属性介绍 template属性为dsl的配置 activeRecords、formData、rootData、parentData、dataSource等属性为常用数据属性 action为动作的元数据 field为字段的元数据 2.直接在浏览器开发者工具的源码处调试源码 打开浏览器开发者工具，进入标签页源代码/来源(英文版为Source)，win系统用快捷键ctrl+O，mac系统用快捷键cmd+O, 可以打开文件搜索面板，通过关键字搜索文件名找到代码文件，可直接在里面debug调试或者查看执行逻辑

  nation

  2024年9月9日

  2.1K000
• 前端

  自定义组件之自动渲染（组件插槽的使用）（v4）

  阅读之前 你应该： 了解DSL相关内容。母版-布局-DSL 渲染基础（v4） 了解SPI机制相关内容。组件SPI机制（v4.3.0） 自定义组件简介 前面我们简单介绍过一个简单的自定义组件该如何被定义，并应用于页面中。这篇文章将对自定义组件进行详细介绍。 自定义一个带有具名插槽的容器组件（一般用于Object数据类型的视图中） 使用BasePackWidget组件进行注册，最终体现在DSL模板中为<pack widget="SlotDemo">。 SlotDemoWidget.ts import { BasePackWidget, SPI } from '@kunlun/dependencies'; import SlotDemo from './SlotDemo.vue'; @SPI.ClassFactory(BasePackWidget.Token({ widget: 'SlotDemo' })) export class SlotDemoWidget extends BasePackWidget { public initialize(props) { super.initialize(props); this.setComponent(SlotDemo); return this; } } 定义一个Vue组件，包含三个插槽，分别是default不具名插槽、title具名插槽、footer具名插槽。 SlotDemo.vue <template> <div class="slot-demo-wrapper" v-show="!invisible"> <div class="title"> <slot name="title" /> </div> <div class="content"> <slot /> </div> <div class="footer"> <slot name="footer" /> </div> </div> </template> <script lang="ts"> import { defineComponent } from 'vue'; export default defineComponent({ name: 'SlotDemo', props: { invisible: { type: Boolean, default: undefined } } }); </script> 在一个表单（FORM）的DSL模板中，我们可以这样使用这三个插槽： <view type="FORM"> <pack widget="SlotDemo"> <template slot="default"> <field data="id" /> </template> <template slot="title"> <field data="name" /> </template> <template slot="footer"> <field data="isEnabled" /> </template> </pack> </view> 这样定义的一个组件插槽和DSL模板就进行了渲染上的结合。 针对不具名插槽的特性，我们可以缺省slot="default"标签，缺少template标签包裹的所有元素都将被收集到default不具名插槽中进行渲染，则上述DSL模板可以改为： <view type="FORM"> <pack widget="SlotDemo"> <field data="id" /> <template slot="title"> <field data="name" /> </template> <template slot="footer"> <field data="isEnabled" /> </template> </pack> </view> 自定义一个数组渲染组件（一般用于List数据类型的视图中） 由于表格无法体现DSL模板渲染的相关能力，因此我们以画廊视图(GALLERY)进行演示。 先定义一个数组每一项的数据结构： typing.ts export interface ListItem { key: string; data: Record<string, unknown>; index: number; } ListRenderDemoWidget.ts import { BaseElementListViewWidget, BaseElementWidget, SPI } from '@kunlun/dependencies'; import ListRenderDemo from './ListRenderDemo.vue'; @SPI.ClassFactory(BaseElementWidget.Token({ widget: 'ListRenderDemo' })) export class ListRenderDemoWidget extends BaseElementListViewWidget { public initialize(props)…

  oinone

  2023年11月1日

  1.2K000
• 前端

  【前端】生产环境部署及性能调优

  概述 前端工程使用vue-cli-service进行构建，生成dist静态资源目录，其中包括html、css、javascript以及其他项目中使用到的所有资源。 在生产环境中，我们通常使用Nginx开启访问服务，并定位其访问目录至dist目录下的index.html，以此来实现前端工程的访问。 不仅如此，为了使得前端发起请求时，可以正确访问到后端服务，也需要在nginx中配置相应的代理，使得访问过程在同域中进行，以达到Cookie共享的目的。 当然，服务部署的形式可以有多种，上述的部署方式也是较为常用的部署方式。 部署 使用production模式进行打包 使用dotenv-webpack插件启用process.env 配置chainWebpack调整资源加载顺序 使用thread-loader进行打包加速 性能调优 使用compression-webpack-plugin插件进行压缩打包 启用Nginx的gzip和gzip_static功能 使用OSS加速静态资源访问（可选） 使用production模式进行打包 在package.json中添加执行脚本 { "scripts": { "build": "vue-cli-service build –mode production" } } 执行打包命令 npm run build 使用dotenv-webpack插件启用process.env 参考资料 dotenv-webpack 在package.json中添加依赖或使用npm安装 { "devDependencies": { "dotenv-webpack": "1.7.0" } } npm install dotenv-webpack@1.7.0 –save-dev 在vue.config.js中添加配置 const Dotenv = require('dotenv-webpack'); module.exports = { publicPath: '/', productionSourceMap: false, lintOnSave: false, configureWebpack: { plugins: [ new Dotenv() ] } }; .env加载顺序 使用不同模式，加载的文件不同。文件按照从上到下依次加载。 development .env .env.development production .env .env.production 配置chainWebpack调整资源加载顺序 chainWebpack对资源加载顺序取决于name属性，而不是priority属性。如示例中的加载顺序为：chunk-a –> chunk-b –> chunk-c。 code>test属性决定其打包范围，但集合之间会自动去重。如chunk-a打包node_modules下所有内容，chunk-b打包node_modules/@kunlun下所有内容。因此在chunk-a中将不再包含node_modules/@kunlun中的内容。没有

  张博昊

  2024年4月19日

  1.4K000