【前端】环境配置(v4)

环境配置

前端环境配置包含.env编译时配置和RuntimeConfig运行时配置

编译时配置 .env

属性 类型 默认值 作用
BASE_PATH [String] 统一配置URL请求路径前缀
STATIC_IMG [String] 静态资源路径
RUNTIME_CONFIG_BASE_URL [String] 运行时配置文件URL请求路径前缀
RUNTIME_CONFIG_FILENAME [String] manifest 运行时配置文件名
MESSAGE_LEVEL DEBUG、SUCCESS、INFO、WARN、ERROR 消息级别

BASE_PATH

当配置BASE_PATH=/test时,前端所有请求就将添加该前缀。

/login登录页,将自动修改为/test/login

MESSAGE_LEVEL

当配置消息级别时,全局的消息通知将根据消息级别进行过滤。

  • DEBUG:允许全部级别的消息通知。
  • SUCCESS:仅允许ERRORWARNINFOSUCCESS级别的消息通知。
  • INFO:仅允许ERRORWARNINFO级别的消息通知。
  • WARN:仅允许ERRORWARN级别的消息通知。
  • ERROR:仅允许ERROR级别的消息通知。

运行时配置 RuntimeConfig

运行时配置是作为编译时配置的补充。

manifest.js
runtimeConfigResolve({
  ......
});
开发时使用运行时配置

创建{PROJECT_NAME}/public/manifest.js文件。

kunlun-boot/public/manifest.js

生产环境使用运行时配置

nginx中配置的dist访问路径下,创建manifest.js文件。

若将/opt/pamirs/frontend/dist作为访问路径,则创建/opt/pamirs/frontend/dist/manifest.js文件。

注意事项
  • 编译时可能使用编译时配置改变运行时配置文件的路径和文件名,注意文件名和访问路径必须匹配。
  • 在浏览器中访问时,nginx或者浏览器会对js文件会进行缓存处理,会导致运行时配置不能及时生效。最好的办法是配置nginx时,禁用manifest.js文件缓存。
  • manifest.js文件中建议不要包含任何与配置项无关的字符(包括注释),该文件在通过网络传输过程中,无法处理这些无效内容。

面包屑配置 breadcrumb

配置方式
runtimeConfigResolve({
  breadcrumb?: boolean | BreadcrumbConfig
});
BreadcrumbConfig
/**
 * 面包屑配置
 */
export interface BreadcrumbConfig extends RuntimeConfigOptions, EnabledConfig {
  /**
   * <h3>是否启用</h3>
   * <p>启用时,需配合mask渲染对应的面包屑组件</p>
   * <p>默认: 开启</p>
   */
  enabled?: boolean;
  /**
   * <h3>首页配置</h3>
   * <p>boolean值与{@link BreadcrumbHomepageConfig#enabled}等效</p>
   */
  homepage?: boolean | BreadcrumbHomepageConfig;
}

/**
 * 首页配置
 */
export interface BreadcrumbHomepageConfig extends RuntimeConfigOptions, EnabledConfig {
  /**
   * <h3>首项显示首页</h3>
   * <p>默认: 开启</p>
   */
  enabled?: boolean;
  /**
   * <h3>首页类型</h3>
   * <p>默认: 'application'</p>
   */
  type?: 'application' | 'module';
}

多选项卡配置 multiTabs

配置方式
runtimeConfigResolve({
  multiTabs?: boolean | MultiTabsConfig
});
MultiTabsConfig
/**
 * 多标签页配置
 */
export interface MultiTabsConfig extends RuntimeConfigOptions, EnabledConfig {
  /**
   * <h3>是否启用(非运行时)</h3>
   * <p>启用时,需配合mask渲染对应的多标签页管理组件</p>
   * <p>默认: 开启</p>
   */
  enabled?: boolean;
  /**
   * <h3>是否使用内联多标签页</h3>
   * <p>仅在使用默认mask时生效</p>
   */
  inline?: boolean;
  /**
   * <h3>显示模块Logo</h3>
   * <p>默认: 开启</p>
   */
  showModuleLogo?: boolean;

  /**
   * <h3>最多标签页数量</h3>
   * <p>在页面中显示的标签页总数,标签页显示在页面中,但标签页的页面不一定被缓存</p>
   * <p>当打开的标签页数量超过该配置时,将自动关闭最早打开的标签页</p>
   */
  maxCount?: number;

  /**
   * <h3>最多缓存标签页数量</h3>
   * <p>当缓存的标签页数量超过该配置时,将自动清理最早打开的标签页,但不会关闭该标签页。当标签页被重新激活时,页面将重新加载。</p>
   * <p>默认: 10</p>
   */
  maxCacheCount?: number;

  /**
   * <h3>是否启用拖拽排序</h3>
   * <p>默认: 开启</p>
   */
  draggable?: boolean;

  /**
   * <h3>应用首页配置</h3>
   * <p>boolean值与{@link MultiTabsApplicationHomepageConfig#enabled}等效</p>
   */
  homepage?: boolean | MultiTabsApplicationHomepageConfig;

  /**
   * <h3>模块首页配置</h3>
   * <p>boolean值与{@link MultiTabsModuleHomepageConfig#enabled}等效</p>
   */
  moduleHomepage?: boolean | MultiTabsModuleHomepageConfig;

  /**
   * 模块过滤
   */
  filter?: string[];
}

/**
 * 应用首页配置
 */
export interface MultiTabsApplicationHomepageConfig extends RuntimeConfigOptions, EnabledConfig {
  /**
   * <h3>是否启用应用首页</h3>
   * <p>将应用首页进行特殊标记,并永远插入到标签页的首个位置</p>
   * <p>默认: 开启</p>
   */
  enabled?: boolean;
  /**
   * <h3>自动获取应用首页</h3>
   * <p>默认: 开启</p>
   */
  auto?: boolean;
  /**
   * <h3>当前激活标签页为首页时是否自动隐藏</h3>
   * <p>在未使用模块首页时生效</p>
   * <p>默认: 非内联时默认开启,内联时默认关闭</p>
   */
  autoInvisible?: boolean;
}

/**
 * 模块首页配置
 */
export interface MultiTabsModuleHomepageConfig extends RuntimeConfigOptions, EnabledConfig {
  /**
   * <h3>是否启用模块首页</h3>
   * <p>多标签页在切换模块时进行初始化</p>
   * <p>默认: 关闭</p>
   */
  enabled?: boolean;
  /**
   * <h3>自动获取模块首页</h3>
   * <p>默认: 开启</p>
   */
  auto?: boolean;
}

登录相关配置

参考文档:登录页自定义配置如何使用

插件配置 plugins

配置方式
runtimeConfigResolve({
  plugins?: PluginsLoaderConfig
});
PluginsLoaderConfig
/**
 * 插件加载配置
 */
export interface PluginsLoaderConfig {
  /**
   * 挂载指定外部js和css;数组默认使用js加载
   */
  mounted?: string[] | { js: string[]; css: string[] };
  /**
   * 使用低无一体组件;默认为false
   */
  usingRemote?: boolean;
}

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

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

(0)
oinone的头像oinone
上一篇 2023年6月20日 pm4:07
下一篇 2023年11月2日 pm1:58

相关推荐

  • 自定义表格支持合并或列、表头分组

    本文将讲解如何通过自定义实现表格支持单元格合并和表头分组。 点击下载对应的代码 在学习该文章之前,你需要先了解: 1: 自定义视图2: 自定义视图、字段只修改 UI,不修改数据和逻辑3: 自定义视图动态渲染界面设计器配置的视图、动作 1. 自定义 widget 创建自定义的 MergeTableWidget,用于支持合并单元格和表头分组。 // MergeTableWidget.ts import { BaseElementWidget, SPI, ViewType, TableWidget, Widget, DslRender } from '@kunlun/dependencies'; import MergeTable from './MergeTable.vue'; @SPI.ClassFactory( BaseElementWidget.Token({ viewType: ViewType.Table, widget: 'MergeTableWidget' }) ) export class MergeTableWidget extends TableWidget { public initialize(props) { super.initialize(props); this.setComponent(MergeTable); return this; } /** * 表格展示字段 */ @Widget.Reactive() public get currentModelFields() { return this.metadataRuntimeContext.model.modelFields.filter((f) => !f.invisible); } /** * 渲染行内动作VNode */ @Widget.Method() protected renderRowActionVNodes() { const table = this.metadataRuntimeContext.viewDsl!; const rowAction = table?.widgets.find((w) => w.slot === 'rowActions'); if (rowAction) { return rowAction.widgets.map((w) => DslRender.render(w)); } return null; } } 2. 创建对应的 Vue 组件 定义一个支持合并单元格与表头分组的 Vue 组件。 <!– MergeTable.vue –> <template> <vxe-table border height="500" :column-config="{ resizable: true }" :merge-cells="mergeCells" :data="showDataSource" @checkbox-change="checkboxChange" @checkbox-all="checkedAllChange" > <vxe-column type="checkbox" width="50"></vxe-column> <!– 渲染界面设计器配置的字段 –> <vxe-column v-for="field in currentModelFields" :key="field.name" :field="field.name" :title="field.label" ></vxe-column> <!– 表头分组 https://vxetable.cn/v4.6/#/table/base/group –> <vxe-colgroup title="更多信息"> <vxe-column field="role" title="Role"></vxe-column> <vxe-colgroup title="详细信息"> <vxe-column field="sex" title="Sex"></vxe-column> <vxe-column field="age" title="Age"></vxe-column> </vxe-colgroup> </vxe-colgroup> <vxe-column title="操作" width="120"> <template #default="{ row, $rowIndex }"> <!– 渲染界面设计器配置的行内动作 –> <row-action-render :renderRowActionVNodes="renderRowActionVNodes" :row="row" :rowIndex="$rowIndex" :parentHandle="currentHandle" ></row-action-render> </template> </vxe-column> </vxe-table> <!– 分页 –> <oio-pagination :pageSizeOptions="pageSizeOptions" :currentPage="pagination.current"…

    2025年1月9日
    1.4K00
  • 提交数据动作如何把弹窗内的数据完全返回

    场景介绍 表格行的操作列有一个打开弹窗的动作 弹窗内为表格行数据的表单,表单内有一个o2m字段,展示了除关联关系字段(大部分场景为id)外的其他字段 弹窗底部动作区域有一个提交数据的客户端动作,该动作会将弹窗内表单的数据回写到表格行的数据上 场景截图 问题现象 点击提交数据的客户端动作,会将数据回写到表格行的数据上,但是表格行拿到的o2m字段的数据只有id字段,o2m字段的编码和名称并不会提交到表格行,o2m字段默认提交规则是只会提交关联关系字段(大部分场景为id)的数据 解决方案 该方案适合5.x版本,4.x版本新建的字段组件无法自动生成属性面板,建议拿下面的组件在SPI加上model和name注册实现 自定义o2m字段所在的组件,m2m字段或者其他类似问题的组件也是如下面组件一样覆写submit方法即可 import { BaseFieldWidget, FormO2MTableFieldWidget, ModelFieldType, SPI, SubmitRelationValue, SubmitValue, ViewType } from '@kunlun/dependencies'; @SPI.ClassFactory( BaseFieldWidget.Token({ viewType: ViewType.Form, ttype: ModelFieldType.OneToMany, widget: 'SubmitAllDataO2MTable' }) ) export class MyFormO2MTableFieldWidget extends FormO2MTableFieldWidget { public async submit(submitValue: SubmitValue): Promise<Record<string, unknown> | SubmitRelationValue | undefined> { return { [this.itemName]: this.value }; } } 在界面设计器的组件功能内新增对应业务类型的自定义组件,组件内的元件api名称填写上面组件的名称SubmitAllDataO2MTable 在界面设计器的设计页面切换o2m字段组件为SubmitAllDataO2MTable 参考文档 自定义组件文档

    2024年6月28日
    1.4K00
  • 【动作】-路由动作跳转后如何主动刷新页面数据

    介绍 当我们使用多tab组件的时候,如果一个viewAction已经打开了一个tab页,再次用该viewAction打开页面的时候,会发现不会根据路由上的业务参数(如详情和编辑页的id参数)主动刷新数据,这个时候可以通过以下方法解决该问题 // 该方法可以在进入新路由页面后刷新数据,推荐将该方法放到工具类 function refreshViewAction(action: any) { const onRefreshTabWithActive = (manager: MultiTabsManager, instance: MultiTabInstance) => { // 进入路由后刷新页面数据 manager.refresh(instance.key); manager.clearOnActive(onRefreshTabWithActive); }; MultiTabsManager.INSTANCE.onActive(onRefreshTabWithActive); executeViewAction(action); } 将原本调用executeViewAction的方法改为refreshViewAction 如果需要扩展executeViewAction的其他入参请自行拓展refreshViewAction的入参

    2024年6月18日
    1.1K00
  • 组件数据交互基础(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…

    2023年11月1日
    1.5K00
  • 创建与编辑一体化

    在业务操作中,用户通常期望能够在创建页面后立即进行编辑,以减少频繁切换页面的步骤。我们可以充分利用Oinone平台提供的创建与编辑一体化功能,使操作更加高效便捷。 通过拖拽实现表单页面设计 在界面设计器中,我们首先需要设计出对应的页面。完成页面设计后,将需要的动作拖入设计好的页面。这个动作的关键在于支持一个功能,即根据前端传入的数据是否包含id来判断是创建操作还是编辑操作。 动作的属性配置如下: 前端自定义动作 一旦页面配置完成,前端需要对这个动作进行自定义。以下是一个示例的代码: @SPI.ClassFactory( ActionWidget.Token({ actionType: [ActionType.Server], model: '模型', name: '动作的名称' }) ) export class CreateOrUpdateServerActionWidget extends ServerActionWidget { @Widget.Reactive() protected get updateData(): boolean { return true; } } 通过以上步骤,我们实现了一个更智能的操作流程,使用户能够在创建页面的同时进行即时的编辑,从而提高了整体操作效率。这种创建与编辑一体化的功能不仅使操作更加顺畅,同时也为用户提供了更灵活的工作流程。

    2023年11月21日
    1.6K00

Leave a Reply

登录后才能评论