【前端】工程结构最佳实践(v4)

阅读之前

你应该:

  • 了解node与npm相关内容
  • 了解lerna包管理工具的相关内容
  • 了解git仓库的相关内容
  • 了解rollup的相关内容

工程结构包示例

Vue项目结构包下载

工程结构详解

工程结构
├── packages
│   ├── kunlun-boot
│   │   ├── package.json
│   │   ├── public
│   │   │   ├── favicon.ico
│   │   │   └── index.html
│   │   ├── src
│   │   │   ├── main.ts
│   │   │   └── shim-vue.d.ts
│   │   ├── tsconfig.json
│   │   └── vue.config.js
│   ├── kunlun-module-demo
│   │   ├── scripts
│   │   │   ├── postpublish.js
│   │   │   └── prepublish-only.js
│   │   ├── src
│   │   │   ├── index.ts
│   │   │   └── shim-vue.d.ts
│   │   ├── index.ts
│   │   ├── package.json
│   │   ├── rollup.config.js
│   │   └── tsconfig.json
│   └── kunlun-modules-demo
│       ├── scripts
│       │   ├── build.config.js
│       │   ├── postpublish.js
│       │   └── prepublish-only.js
│       ├── packages
│       │   ├── module-demo1
│       │   │   ├── index.ts
│       │   │   ├── package.json
│       │   │   ├── rollup.config.js
│       │   │   └── src
│       │   │       ├── index.ts
│       │   │       └── shim-vue.d.ts
│       │   ├── module-demo2
│       │   │   ├── index.ts
│       │   │   ├── package.json
│       │   │   ├── rollup.config.js
│       │   │   └── src
│       │   │       ├── index.ts
│       │   │       └── shim-vue.d.ts
│       │   └── module-dependencies
│       │       ├── index.ts
│       │       ├── package.json
│       │       └── src
│       │           └── dependencies.ts
│       ├── lerna.json
│       ├── tsconfig.json
│       └── package.json
├── lerna.json
└── package.json

壳工程

├── packages
│   └── ......
├── lerna.json
└── package.json

壳工程仅用于将多个包进行统一安装,并通过lerna包管理工具进行相关的软链接操作。

壳工程包含了除了node和npm外其他相关的安装依赖,如lernarimraf等。这样可以避免由于开发环境差异带来的一系列问题。

我们建议所有开发人员均使用相同的壳工程进行开发,因此,我们有必要将其提交并推送到git远程仓库进行共享。

壳工程目录下执行npm install命令即可完成一系列安装操作。

需要注意的是,lerna.json中定义了所有需要统一安装的子工程路径,安装前需要确认是否满足当前需要,但这些修改都应该只在本地完成,而不应该推送到git远程仓库

安装完成后,所有公共依赖均会安装在壳工程node_modules目录下,每个子工程的node_modules中仅包含软链接目录。并且在壳工程node_modules目录下不会出现本地已经存在的工程依赖。

单工程包管理

├── packages
│   └── kunlun-module-demo
│       ├── scripts
│       │   ├── postpublish.js
│       │   └── prepublish-only.js
│       ├── src
│       │   ├── index.ts
│       │   └── shim-vue.d.ts
│       ├── index.ts
│       ├── package.json
│       ├── rollup.config.js
│       └── tsconfig.json
├── lerna.json
└── package.json

作为一个独立的工程,它可以是一个项目的总工程,也可以是多个项目共同使用的子工程。这也是最常见的工程包结构。

通常情况下,kunlun-module-demo工程会使用一个独立的git仓库进行管理。

通过kunlun-module-demo打包生成的@kunlun/module-demo包,将可以被发布到npm仓库或其他地方,供其他工程或项目使用。

启动工程中的package.json中添加"@kunlun/module-demo": "~1.0.0"相关依赖进行引入。并在入口文件main.ts中导入相关的js和css相关内容。

如示例中所示:

// 按需引入
import '@kunlun/module-demo/dist/kunlun-module-demo.css';

import '@kunlun/module-demo';

需要注意的是,在本地开发中,css文件相关内容应该是被临时注释的,因为通过import '@kunlun/module-demo';已经将相关内容引入,无需使用打包好的css文件。

多工程包管理

├── packages
│   └── kunlun-modules-demo
│       ├── scripts
│       │   ├── build.config.js
│       │   ├── postpublish.js
│       │   └── prepublish-only.js
│       ├── packages
│       │   ├── module-demo1
│       │   │   ├── index.ts
│       │   │   ├── package.json
│       │   │   ├── rollup.config.js
│       │   │   └── src
│       │   │       ├── index.ts
│       │   │       └── shim-vue.d.ts
│       │   ├── module-demo2
│       │   │   ├── index.ts
│       │   │   ├── package.json
│       │   │   ├── rollup.config.js
│       │   │   └── src
│       │   │       ├── index.ts
│       │   │       └── shim-vue.d.ts
│       │   └── module-dependencies
│       │       ├── index.ts
│       │       ├── package.json
│       │       └── src
│       │           └── dependencies.ts
│       ├── lerna.json
│       ├── tsconfig.json
│       └── package.json
├── lerna.json
└── package.json

单工程包管理类似,多工程包管理方案为了解决整体结构复杂,并且功能需要做最小化拆分的场景。在多工程包中提供的module-dependencies作为整个工程包的总入口向外提供功能。

如示例中所示:

// 视情况按需引入
// import '@kunlun/module-demo/dist/kunlun-module-demo1.css';
// import '@kunlun/module-demo/dist/kunlun-module-demo2.css';

import '@kunlun/modules-dependencies';

与单工程包唯一的区别在于启动工程的导入方式有所不同,仅需通过import '@kunlun/modules-dependencies';导入所有功能即可。在总入口处将对所有子工程包进行统一的导出并且包含了对应的css相关内容。

特别的是,如果多个工程间的css样式出现冲突,但又需要依赖js文件时,css相关内容将不能在总入口处进行导入,需要放在对应的启动工程中进行导入处理。原则上,我们应该避免这种情况的发生。

启动工程

├── packages
│   └── kunlun-boot
│       ├── package.json
│       ├── public
│       │   ├── favicon.ico
│       │   └── index.html
│       ├── src
│       │   ├── main.ts
│       │   └── shim-vue.d.ts
│       ├── tsconfig.json
│       └── vue.config.js
├── lerna.json
└── package.json

作为vue项目的启动工程,它应该仅用于工程组合,即选择性的使用某几个工程进行启动。

rollup脚本简述

通过package.json构建所需工程名称

const packagePrefix = 'kunlun-';

const buildName = (name) => {
  const libraryName = name.replace('@', '').replace('/', '-');
  const pathName = libraryName.substring(packagePrefix.length);
  const camelCaseName = libraryName.replace(/-(\w)/g, (all, letter) => letter.toUpperCase());
  return { libraryName, pathName, camelCaseName };
};

使用方法:

import pkg from './package.json';

const res = buildName(pkg.name);
const libraryName = res.libraryName;

转换结果:

  • libraryName:@kunlun/module-demo -> kunlun-module-demo
  • pathName:@kunlun/module-demo -> module-demo
  • camelCaseName:@kunlun/module-demo -> kunlunModuleDemo

这三个名称在单工程和多工程中都有使用,以实现统一脚本命令的自动化构建。

需要注意的是:

  • package.json中使用的名称需要手动和packagePrefix定义的变量进行匹配。
  • 在多工程中,每个子工程目录对应的名称应该与pathName属性完全一致。

多工程包构建脚本的使用

方法签名
function rollupConfig(name = '', external = [], hasSCSS = true, extendPlugins)
示例脚本
import pkg from './package.json';
import rollupConfig from '../../scripts/build.config.js';

export default rollupConfig(pkg.name, [
  'vue',
  'lodash-es',
  'ant-design-vue',
  '@ant-design/icons-vue',
  'element-plus',
  '@element-plus/icons-vue',
  '@kunlun/dependencies',
  '@kunlun/vue-ui-antd',
  '@kunlun/vue-ui-el'
], false);
  • pkg.name:通过当前路径的package.json获取name属性。
  • external:打包时排除当前工程中导入的第三方包,原则上需要全部排除,否则会出现内存变量不一致的问题。
  • hasSCSS:是否进行scss编译。当使用scss时,必须开启。
  • extendPlugins:扩展插件。

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

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

Like (0)
nation's avatarnation数式员工
Previous 2023年6月20日 pm4:07
Next 2023年11月2日 pm1:58

相关推荐

  • GraphQL请求详解(v4)

    阅读之前 什么是GraphQL? Oinone官方解读GraphQL入门 可视化请求工具 insomnia下载 概述 (以下内容简称GQL) 众所周知,平台的所有功能都是通过一系列元数据定义来驱动的,而GQL作为服务端和客户端交互协议,其重要性不言而喻。下面会从以下几个方面介绍GQL在平台中是如何运作的: 服务端定义元数据生成GQL对应的schema 通过HttpClient发起一个GQL请求 通过window.open使用GET方式发起一个GQL请求 客户端泛化调用任意API服务 客户端通过运行时上下文RuntimeContext发起GQL请求 准备工作 在开始介绍GQL之前,我们需要定义一个可以被GQL请求的服务端函数,以此来介绍我们的相关内容。(对服务端不感兴趣的同学可以跳过代码部分) DemoModel.java @Model.model(DemoModel.MODEL_MODEL) @Model(displayName = "演示模型", labelFields = {"name"}) public class DemoModel extends IdModel { private static final long serialVersionUID = -7211802945795866154L; public static final String MODEL_MODEL = "demo.DemoModel"; @Field(displayName = "名称") private String name; @Field(displayName = "是否启用") private Boolean isEnabled; } DemoModelAction.java @Model.model(DemoModel.MODEL_MODEL) public class DemoModelAction { @Action(displayName = "启用") public DemoModel enable(DemoModel data) { data.setIsEnabled(true); data.updateById(); return data; } @Action(displayName = "禁用") public DemoModel disable(DemoModel data) { data.setIsEnabled(false); data.updateById(); return data; } } 上面的java代码定义了演示模型的字段和动作: 字段 field id:ID 整数 Integer name:名称 字符串 String isEnabled:是否启用 布尔 Boolean 动作 action enable:启用 提交动作 ServerAction disable:禁用 提交动作 ServerAction 服务端定义元数据生成GQL对应的schema 模型和字段 type DemoModel { id: Long name: String isEnabled: Boolean } 动作 type DemoModelInput { id: Long name: String isEnabled: Boolean } type DemoModelQuery { queryOne(query: DemoModelInput): DemoModel …… } type DemoModelMutation { enable(data: DemoModelInput): DemoModel disable(data: DemoModelInput): DemoModel …… } PS:平台内置了多种Query和Mutation定义,通过模型继承关系将自动生成,无需手动定义。比如Query定义包括queryOne、queryPage等;Mutation定义包括create、update等。特殊情况下,默认逻辑无法满足时,服务端通常采用函数重载的方式进行替换,客户端则无需关心。 生成规则 type DemoModel:通过模型编码demo.DemoModel取.分隔后的最后一位,并转换为大驼峰格式。字段与声明类型一致。 type DemoModelInput:动作入参定义,未做特殊声明的情况下与模型定义一致。 type DemoModelQuery和type DemoModelMutation:Query和Mutation为固定后缀,分别生成动作相关类型。当函数类型为QUERY时,使用Query后缀,其他情况使用Mutation后缀。 (此处仅做简单解释,详细生成规则过于复杂,客户端无需关心) Query类型的GQL示例 query { demoModelQuery { queryOne(query: { id: ${id} }) { id name isEnabled } } } Mutation类型的GQL示例 mutation…

    2023年11月1日
    2.4K00
  • 自定义组件之手动渲染任意视图(v4)

    private metadataViewWidget: MetadataViewWidget | null | undefined; private async renderCustomView(model: string, viewName: string, slotName?: string) { const view = await ViewCache.get(model, viewName); if (!view) { return; } if (this.metadataViewWidget) { this.metadataViewWidget.dispose(); this.metadataViewWidget = null; } const metadataViewWidget = this.createWidget(MetadataViewWidget, slotName, { metadataHandle: this.metadataHandle, rootHandle: this.rootHandle, internal: true, inline: true, automatic: true }); this.metadataViewWidget = metadataViewWidget; metadataViewWidget.initContextByView(view); this.forceUpdate(); }

    2025年3月6日
    1.4K00
  • oio-button 按钮

    主按钮:用于主行动点,一个操作区域只能有一个主按钮。 默认按钮:用于没有主次之分的一组行动点。 虚线按钮:常用于添加操作。 文本按钮:用于最次级的行动点。 链接按钮:一般用于链接,即导航至某位置。 以及四种状态属性与上面配合使用。 危险:删除/移动/修改权限等危险操作,一般需要二次确认。 禁用:行动点不可用的时候,一般需要文案解释。 加载中:用于异步操作等待反馈的时候,也可以避免多次提交。 API 按钮的属性说明如下: 属性 说明 类型 默认值 版本 block 将按钮宽度调整为其父宽度的选项 boolean false disabled 按钮失效状态 boolean false icon 设置按钮的图标类型 v-slot – loading 设置按钮载入状态 boolean | { delay: number } false type 设置按钮类型 primary | ghost | dashed | link | text | default default 事件 事件名称 说明 回调参数 版本 click 点击按钮时的回调 (event) => void 支持原生 button 的其他所有属性。

    2023年12月18日
    79200
  • 如何自定义 GraphQL 请求

    在开发过程中,有时需要自定义 GraphQL 请求来实现更灵活的数据查询和操作。本文将介绍两种主要的自定义 GraphQL 请求方式:手写 GraphQL 请求和调用平台 API。 方式一:手写 GraphQL 请求 手写 GraphQL 请求是一种直接编写查询或变更语句的方式,适用于更复杂或特定的业务需求。以下分别是 query 和 mutation 请求的示例。 1. 手写 Query 请求 以下是一个自定义 query 请求的示例,用于查询某个资源的语言信息列表。 const customQuery = async () => { const query = `{ resourceLangQuery { queryListByEntity(query: {active: ACTIVE, installState: true}) { id name active installState code isoCode } } }`; const result = await http.query('resource', query); this.list = result.data['resourceLangQuery']['queryListByEntity']; }; 说明: query 语句定义了一个请求,查询 resourceLangQuery 下的语言信息。 查询的条件是 active 和 installState,只返回符合条件的结果。 查询结果包括 id、name、active、installState 等字段。 2. 手写 Mutation 请求 以下是一个 mutation 请求的示例,用于创建新的资源分类信息。 const customMutation = async () => { const code = Date.now() const name = `测试${code}` const mutation = `mutation { resourceTaxKindMutation { create(data: {code: "${code}", name: "${name}"}) { id code name createDate writeDate createUid writeUid } } }`; const res = await http.mutate('resource', mutation); console.log(res); }; 说明: mutation 语句用于创建一个新的资源分类。 create 操作的参数是一个对象,包含 code 和 name 字段。 返回值包括 id、createDate 等字段。 方式二:调用平台的 API 平台 API 提供了简化的 GraphQL 调用方法,可以通过封装的函数来发送 query 和 mutation 请求。这种方式减少了手写 GraphQL 语句的复杂性,更加简洁和易于维护。 1. 调用平台的 Mutation API 使用平台的 customMutation 方法可以简化 Mutation 请求。 /** * 自定义请求方法 * @param modelModel 模型编码 * @param method 方法名或方法对象 * @param records 请求参数,可以是单体对象或者对象的列表 * @param requestFields…

    2024年9月21日
    1.9K00
  • 「前端」获取系统配置

    「前端」获取系统配置 简介 系统配置对于前端开发至关重要,它包含了许多关键信息,通过调用「systemMajorConfig」API,可以轻松地获取这些关键配置信息。除了主要的系统配置外,底层还提供了一些快捷的API,比如获取当前主题、当前主题大小、登录页面主题、版权状态和默认浏览器信息。 使用步骤 调用「systemMajorConfig」API获取系统配置数据。 使用返回的数据对象来访问特定的系统配置参数,如企业名称、企业官网等。 使用底层提供的快捷API来获取与系统配置相关的特定信息。 系统配置参数 logo (string): 应用logo(未折叠状态) appSideLogo (string): 应用logo(折叠状态) smallLogo (string): 小型logo slogan (string): 企业slogan favicon (string): 浏览器logo browserTitle (string): 浏览器标题 loginPageLogo (string): 登录页logo loginBackground (string): 登录页背景 loginLayoutType (any): 登录页布局主题 mode (any): 主题模式 size (string): 主题大小 快捷API列表 getCurrentTheme: 获取当前主题信息。 getCurrentThemeSize: 获取当前主题大小。 getLoginTheme: 获取登录页面主题信息。 getCopyrightStatus: 获取版权状态信息。 getDefaultBrowser: 获取默认浏览器信息。 示例代码 import { systemConfig, getCurrentTheme } from ‘@kunlun/dependencies’ // 访问特定系统配置参数 console.log(systemConfig.logo); // 输出企业名称 // 使用快捷API获取特定信息 console.log(getCurrentTheme());

    2023年11月1日
    1.2K00

Leave a Reply

Please Login to Comment