zhennann (zhennann)

在 Vue3 中如何实现四种全局状态数据的统一管理？

zhennann — Thu, 10 Oct 2024 19:36:22 +0800

四种全局状态数据

在实际开发当中，会遇到四种全局状态数据：异步数据（一般来自服务端）、同步数据。同步数据又分为三种：localstorage、cookie、内存。在传统的 Vue3 当中，分别采用不同的机制来处理这些状态数据，而在 Zova 中只需要采用统一的Model机制

状态数据	传统的 Vue3	Zova
异步数据	Pinia	Model
localstorage	Pinia + Localstorage	Model
cookie	Pinia + Cookie	Model
内存	Pinia	Model

采用 Model 机制统一管理这些全局状态数据，就可以提供一些通用的系统能力，比如，内存优化、持久化和SSR支持等等，从而规范数据使用方式，简化代码结构，提升代码的可维护性

特性 1. 支持异步数据和同步数据

Zova Model 的基座是TanStack Query。TanStack Query 提供了强大的数据获取、缓存和更新能力。如果你没有使用过类似 TanStack Query 的数据管理机制，那么强烈建议了解一下，相信你一定会受到思想的洗礼但是，TanStack Query 的核心是对异步数据（一般来自服务端）进行管理。Zova Model 在 TanStack Query 的基础上做了扩展，因此也支持同步数据的管理。换而言之，以下所述所有特性和能力同时适用于异步数据和同步数据

特性 2. 自动缓存

对获取的异步数据进行本地缓存，避免重复获取。对于同步数据，会自动针对 localstorage 或者 cookie 进行读写操作

特性 3. 自动更新

提供数据过期策略，在合适的时机自动更新

特性 4. 减少重复请求

在程序的多个地方同时访问数据，将只调用一次服务端 api。如果是同步数据，也只针对 localstorage 或者 cookie 调用一次操作

特性 5. 内存优化

通过 Zova Model 管理的数据，虽然是全局范围的状态，但是并不总是占用内存，而是提供了内存释放与回收的机制。具体而言，就是在创建 Vue 组件实例时根据业务的需要创建缓存数据，当 Vue 组件实例卸载时释放对缓存数据的引用，到达约定的过期时间如果仍然没有其他 Vue 组件引用，就会触发回收机制 (GC)，完成对内存的释放，从而节约内存占用。这对于大型项目，用户需要长时间进行界面交互的场景，具有显著的好处

特性 6. 持久化

本地缓存可以持久化，当页面刷新时可以自动恢复，避免服务端调用。如果是异步数据，就会自动持久化到 IndexDB 中，从而满足大数据量的存储需要。如果是同步数据，就会自动持久化到 localstorage 或者 cookie

内存优化与持久化配合发挥作用，对于大型项目效果更佳明显。比如，第一次从服务端获取的数据，会生成本地缓存，并自动持久化。当页面不再使用并且过期时，会自动销毁本地缓存，从而释放内存。当再次访问该数据时，会自动从持久化中恢复本地缓存数据，而不是再次从服务端获取数据

特性 7. SSR 支持

不同类型的状态数据，在 SSR 模式下也会有不同的实现机制。Zova Model 把这些状态数据的差异进行抹平，并且采用统一的机制进行水合，从而让 SSR 的实现更加自然、直观，显著降低了心智负担

特性 8. 自动命名空间隔离

Zova 通过 Model Bean 来管理数据。而 Bean 本身有唯一的标识，可以作为数据的命名空间，从而自动保证了 Bean 内部状态数据命名的唯一性，避免数据冲突

参见：Bean 标识

如何创建一个 Model Bean

Zova 提供了 VS Code 插件，通过右键菜单可以非常便利的创建一个 Model Bean

右键菜单 - [模块路径]: Zova Create/Bean: Model

依据提示输入 model bean 的名称，比如todo，VSCode 插件会自动添加 model bean 的代码骨架

比如，在 demo-todo 模块中创建一个 Model Bean todo

demo-todo/src/bean/model.todo.ts

import { Model } from 'zova';
import { BeanModelBase } from 'zova-module-a-model';

@Model()
export class ModelTodo extends BeanModelBase {}

使用@Model 装饰器
继承自基类 BeanModelBase

异步数据

TanStack Query 的核心是对服务端数据进行管理。为简化起见，这里仅展示 select 方法的定义与使用：

完整代码示例，请参见：demo-todo

如何定义

@Model()
export class ModelTodo {
  select() {
    return this.$useQueryExisting({
      queryKey: ['select'],
      queryFn: async () => {
        return this.scope.service.todo.select();
      },
    });
  }
}

调用$useQueryExisting 创建 Query 对象
- 为何不使用$useQuery方法？因为异步数据一般是在需要时才进行异步加载。因此我们需要确保在多次调用select方法时始终返回同一个 Query 对象，所以必须使用$useQueryExisting方法
传入 queryKey，确保本地缓存的唯一性
传入 queryFn，在合适的时机调用此函数获取服务端数据
- service.todo.select：参见Api 服务

如何使用

demo-todo/src/page/todo/controller.ts

import { ModelTodo } from '../../bean/model.todo.js';

export class ControllerPageTodo {
  @Use()
  $$modelTodo: ModelTodo;
}

注入 Model Bean 实例：$$modelTodo

demo-todo/src/page/todo/render.tsx

export class RenderTodo {
  render() {
    const todos = this.$$modelTodo.select();
    return (
      <div>
        <div>isLoading: {todos.isLoading}</div>
        <div>
          {todos.data?.map(item => {
            return <div>{item.title}</div>;
          })}
        </div>
      </div>
    );
  }
}

调用 select 方法获取 Query 对象
- render 方法会多次执行，重复调用 select 方法返回的是同一个 Query 对象
直接使用 Query 对象中的状态和数据
- 参见：TanStack Query: Queries

如何支持 SSR

在 SSR 模式下，我们需要这样使用异步数据：在服务端加载状态数据，然后通过 render 方法渲染成 html 字符串。状态数据和 html 字符串会同时发送到客户端，客户端在进行水合时仍然使用此相同的状态数据，从而保持状态的一致性

要实现以上逻辑，在 Zova Model 中只需要执行一个步骤：

demo-todo/src/page/todo/controller.ts

import { ModelTodo } from '../../bean/model.todo.js';

export class ControllerPageTodo {
  @Use()
  $$modelTodo: ModelTodo;

  protected async __init__() {
    const queryTodos = this.$$modelTodo.select();
    await queryTodos.suspense();
    if (queryTodos.error) throw queryTodos.error;
  }
}

只需要在__init__方法中调用suspense等待异步数据加载完成

同步数据：localstorage

由于服务端不支持window.localStorage，因此 localstorage 状态数据不参与 SSR 的水合过程

下面演示把用户信息存入 localstorage，当页面刷新时也会保持状态

如何定义

export class ModelUser extends BeanModelBase {
  user?: ServiceUserEntity;

  protected async __init__() {
    this.user = this.$useQueryLocal({
      queryKey: ['user'],
    });
  }
}

与异步数据定义不同，同步数据直接在初始化方法__init__中定义
调用$useQueryLocal 创建 Query 对象
传入 queryKey，确保本地缓存的唯一性

如何使用

直接像常规变量一样读取和设置数据

const user = this.user;
this.user = newUser;

在服务端会自动使用Request Header中的 Cookies，在客户端会自动使用document.cookie，因此会自动保证 SSR 水合过程中 cookie 状态数据的一致性

下面演示把用户 Token 存入 cookie，当页面刷新时也会保持状态。这样，在 SSR 模式下，客户端和服务端都可以使用相同的jwt token访问后端 API 服务

如何定义

export class ModelUser extends BeanModelBase {
  token?: string;

  protected async __init__() {
    this.token = this.$useQueryCookie({
      queryKey: ['token'],
    });
  }
}

与异步数据定义不同，同步数据直接在初始化方法__init__中定义
调用$useQueryCookie 创建 Query 对象
传入 queryKey，确保本地缓存的唯一性

如何使用

直接像常规变量一样读取和设置数据

const token = this.token;
this.token = newToken;

同步数据：内存

在 SSR 模式下，服务端定义的全局状态数据会同步到客户端，并自动完成水合

下面演示基于内存的全局状态数据

如何定义

zova-ui-quasar/src/suite-vendor/a-quasar/modules/quasar-adapter/src/bean/model.theme.ts

export class ModelTheme extends BeanModelBase {
  cBrand: string;

  protected async __init__() {
    this.cBrand = this.$useQueryMem({
      queryKey: ['cBrand'],
    });
  }
}

与异步数据定义不同，同步数据直接在初始化方法__init__中定义
调用$useQueryMem 创建 Query 对象
传入 queryKey，确保本地缓存的唯一性

如何使用

直接像常规变量一样读取和设置数据

const cBrand = this.cBrand;
this.cBrand = newValue;

结语

Zova 是一款支持 IOC 容器的 Vue3 框架，在代码风格上结合了 Vue/React/Angular 的优点，同时规避他们的缺点，让我们的开发体验更加优雅，减轻心智负担。Zova 已经内置了大量实用、有趣的功能特性，Model 机制仅仅是其中一个

Zova 框架已经开源，欢迎关注，参与共建：https://github.com/cabloy/zova。可添加我的微信，入群交流：yangjian2025

在一个项目中同时实现“后台管理系统”和“前台应用”

zhennann — Thu, 27 Oct 2022 07:14:27 +0800

微信一起点菜

一个月紧张而愉快的开发又过去了。在这个月，开发了一个微信一起点菜项目，用来再次验证CabloyJS全栈框架定制开发的灵活性和扩展性。实践再次证明，使用 CabloyJS 全栈框架开发项目确实可以做到多快好省。因为：

只需一个项目，既可同时实现“后台管理系统”和“前台应用
只需一个项目，既可同时跨端 pc、mobile。mobile 端是接近原生体验

下面就以微信一起点菜为例：

前台点菜应用：https://test.cabloy.com/?appKey=diancai-h5%3AappDianCaiWechatH5&appIsolate=true
后台商家管理系统：https://test.cabloy.com/
以上两个链接可以分别用 pc 和 mobile 打开。全新交互体验，全新架构设计，试过便知

截图

后台商家管理系统

PC 端

Mobile 端

前台点菜应用

PC 端

Mobile 端

CabloyJS 4.22 重磅推出弹出式页面交互风格

zhennann — Thu, 30 Jun 2022 21:45:27 +0800

升级说明

我们知道 CabloyJS 提供了pc=mobile+pad自适应布局机制，可以通过一套代码同时适配 mobile 端和 pc 端。基本思路就是优先适配 mobile 端，然后再把 mobile 端的交互体验带入 pc 端。因此，pc 端可以看作是许多 mobile 尺寸和 pad 尺寸页面组件的组合。在旧版本中，这些页面组件就像大大小小的手机和平板依次向右展开，可以称作展开式交互风格

新版本CabloyJS 4.22提供了弹出式交互风格。这样，用户可以根据 pc 电脑的尺寸大小和个人喜好，在这两个交互风格中随时切换

关于pc=mobile+pad自适应布局机制的详细信息，请参见文档：自适应布局：pc = mobile + pad

意义

CabloyJS 4.22的发布，重磅引入弹出式页面交互风格，是及其主要的里程碑，将 CabloyJS 推入一个新的发展阶段

是以为记 2022 年 6 月 30 日

预览

1. PC 端（展开式）

2. PC 端（弹出式）

3. Mobile 端

演示站点

直接浏览 CabloyJS 的演示站点，增加更直观的感性认知

体验 CabloyJS 应对大型项目的三驾马车：套件、模块、App应用
体验与众不同的pc=mobile+pad自适应布局风格，强烈推荐：分别用PC和Mobile单独体验演示站点。此言不虚，请您品鉴！！！

演示站点：https://test.cabloy.com/
演示站点的二维码：

且看这个 Node 全栈框架，实现了个 Cli 终端引擎，可无限扩充命令集

zhennann — Wed, 08 Jun 2022 19:21:27 +0800

背景介绍

一般而言，大多数框架都会提供Cli终端工具，用于通过命令行执行一些工具类脚本

CabloyJS 提供的Cli终端工具却与众不同。更确切的说，CabloyJS 提供的是Cli终端引擎，由一套Cli终端运行机制+众多命令集组成。CabloyJS 是一个基于模块化体系的全栈框架，因此，命令集也由具体的模块提供。因此，我们可以通过安装各种模块来动态添加可以运行的命令集，从而让 CabloyJS 的Cli终端变得无比强大、功能也无比丰富

特点

可无限扩充：由于是通过安装模块来提供命令集，因此可以无限扩充
同时支持开发环境和生产环境：当我们在命令行输入指令后，系统会自动调用后端服务的 API 接口，执行具体的脚本逻辑。而后端服务既可以是在本地运行的开发服务，也可以是在远程运行的生成环境
简化系统管理和运维工作：正是由于Cli终端可以用于生产环境，所以许多后台管理工作都可以通过 API 接口暴露出来，从而可以直接通过命令行进行驱动
完善的权限控制：后端服务暴露的所有 API 接口都使用资源授权机制进行控制，Cli终端通过开放认证Token进行受控访问

如何使用

Cli终端的使用规范如下：

$ npm run cli [command] [args] -- [options]

- command

命名规范：由于 command 由业务模块提供，为了进一步规范管理，在业务模块内部还将提供的 commands 进行分组。因此，command 命名规范如下：

moduleName:groupName:commandName

比如，模块a-clibooster提供了一个分组create，分组create提供了一个module 命令，那么，完整的 command 命名就是：a-clibooster:create:module

特殊约定：为了简化 command 的输入，特别做了如下约定：
1. 如果模块名称是a-clibooster，则可以不输入
2. 如果分组名称是default，则可以不输入

举例如下：

全称	简称
a-clibooster:default:list	::list
a-clibooster:create:module	:create:module
test-party:default:demo	test-party::demo

- args

命令后是否可以跟随参数，跟随多少参数，由具体的命令决定，例如：

# 安装模块test-flow和test-note
$ npm run cli :store:sync test-flow test-note

- options

命令后是否可以跟随选项，跟随多少选项，也由具体的命令决定，例如：

# 向套件test-suite1添加模块test-module1
$ npm run cli :create:module test-module1 -- --suite=test-suite1

- help

如果我们不知道如何使用某个命令，可以直接打印出帮助信息，例如

$ npm run cli :create:module -- --help

- version

还可查询某个命令的版本号，例如：

$ npm run cli :create:module -- --version

- 列出命令

如果要查询当前系统一共支持多少命令，可以按如下操作：

# 列出所有命令
$ npm run cli ::list
# 列出模块test-party提供的命令
$ npm run cli ::list  -- --module=test-party
# 列出模块a-clibooster内create分组提供的命令
$ npm run cli ::list  -- --module=a-clibooster --group=create

内置命令

CabloyJS 通过模块a-clibooster内置了大量常用的命令，具体如下：

命令	描述
::list	列出所有命令

:token:add	添加开放认证 Token
:token:delete	删除开放认证 Token
:token:list	列出所有开放认证 Token

:tools:babel	编译 JS 文件
:tools:icons	处理图标模块

:create:suite	新建套件
:create:module	新建模块
:create:atom	新建原子类型
:create:controller	新建控制器（包括 Route、Controller、Service 一套文件）

:store:sync	安装来自 Cabloy 商店的`套件/模块`
:store:publish	将本地开发的`套件/模块`发布到 Cabloy 商店

简写命令

CabloyJS 还提供了更多简写命令，可以亲自体验一番，一定会显著提升开发效率

$ npm run cli
$ npm run cli :
$ npm run cli ::
$ npm run cli :default:
$ npm run cli :create:
$ npm run cli test-party:
$ npm run cli test-party::
$ npm run cli test-party:default:

如何创建 Cli 命令

如果我们想创建自己的 Cli 命令，也非常简便，参见文档：如何创建 Cli 命令

看看 CabloyJS 是如何实现编辑页面脏标记的

zhennann — Tue, 18 Jan 2022 22:06:04 +0800

应用场景

我们在使用 Word、Excel 时，当修改了内容之后在标题栏会显示脏标记，从而可以明确的告知用户内容有变动。此外，如果在没有保存的情况下关闭窗口，系统会弹出提示框，让用户选择是否放弃修改

那么，在 Web 系统中，我们是否也可以支持这种脏标记机制呢？

答案是肯定的，CabloyJS 就提供了这种脏标记机制，而且 CabloyJS 内置的所有可以编辑的页面都支持了这种效果

效果演示

如何使用

下面以模块test-party为例，演示如何向编辑页面添加脏标记机制。演示代码都在下面的文件中：

src/module-vendor/test-party/front/src/kitchen-sink/pages/markdownEditor.vue

1. 引入脏标记组件

import Vue from 'vue';
const ebPageDirty = Vue.prototype.$meta.module.get('a-components').options.mixins.ebPageDirty;
export default {
  mixins: [ebPageDirty],
  ...
}

ebPageDirty是由模块a-components提供的组件，放入当前页面组件的mixins中

2. Title 显示脏标记

<template>
  <eb-page>
    <eb-navbar :title="page_title" eb-back-link="Back">
      ...
    </eb-navbar>
  </eb-page>
</template>
<script>
import Vue from 'vue';
const ebPageDirty = Vue.prototype.$meta.module.get('a-components').options.mixins.ebPageDirty;
export default {
  mixins: [ebPageDirty],
  ...
  computed: {
    page_title() {
      const title = this.$text('Markdown Editor');
      return this.page_getDirtyTitle(title);
    },
  },
};
</script>

行 16：获取国际化处理后的标题
行 17：调用page_getDirtyTitle方法向title动态添加脏标记
行 3：动态绑定page_title

3. 修改脏标记

export default {
  ...
  methods: {
    async onPerformSave() {
      if (!this.$refs.editor) return;
      await this.$refs.editor.checkContent();
      this.$view.toast.show({ text: this.$text('Saved') });
      this.page_setDirty(false);
    },
    onInput(data) {
      if (this.content === data) return;
      this.content = data;
      this.page_setDirty(true);
    },
  },
};

行 13：当用户输入内容时，调用page_setDirty方法将脏标记置为true
行 8：当保存内容时，调用page_setDirty方法将脏标记置为false

组件 ebPageDirty 的方法

名称	说明
page_getDirtyTitle	向 Title 动态添加脏标记
page_setDirty	修改脏标记

CabloyJS 4.12 震撼发布，及新版教程尝鲜

zhennann — Mon, 29 Nov 2021 22:15:21 +0800

引言

凡是可以用 JavaScript 来写的应用，最终都会用 JavaScript 来写 | Atwood 定律

目前市面上出现的大多数与 NodeJS 相关的框架，基本都将 NodeJS 定位在工具层、中间层、代理层，很少在业务层面进行深耕，认为这是 JAVA 的领域，NodeJS 不适合。这种思潮明显是与Atwood 定律相悖的

如果您想感受与众不同的 NodeJS 全栈开发体验，一定要试试自带工作流引擎的 CabloyJS 全栈开源框架。为了提升业务层面的开发效率和开发体验，CabloyJS 在前端和后端均提供了大量实用的工具和组件

CabloyJS 4.12

CabloyJS 从4.11升级到4.12，历时 5 个月，Github 提交数从6000+一路干到8000+，这次的功能更新绝对是诚意满满，一次爽到爆

新增特性
- 数据：增加 simple 模式
- 默认的业务数据都具有生命周期，即三个阶段：草稿、正式、历史。草稿到正式之间还可以加入审批流
- 新增的simple模式，就是可以简化业务数据的生命周期，只保留正式版本，从而满足一些简单业务数据的管理
- 脏标记机制：所有 Form 表单均支持脏标记机制。当有字段值变动时，Form 表单标题就会有醒目提示，并且当关闭当前表单页面时，也会提示用户表单数据没有保存
- 测试：增加新的测试模块test-note
- 演示数据列表的布局切换：列表/卡片/表格
- 演示数据条目的布局切换：信息/正文 (Markdown)
- 演示如何增加便签部件，从而可以在仪表板中直接编辑和查看便签数据
- 测试：test-party 模块
- 演示如何增加简单聊天部件，从而可以在仪表板中进行直接的聊天互动
- 工作流引擎：
- 增加转办
- 增加代办
- 工作流引擎：
- 增加行为机制：从而实现与 activiti 中边界事件所对应的应用场景
  - 一个节点可以附加多个行为
  - 行为可以指定专属的边，从而进行节点的迁移
- 增加一个具体的行为实现：超时处理
  - 可以指定某个审批节点的超时行为，一旦超时就跳转到指定的流程节点
- 工作流引擎：
- 增加网关节点，包括：
  - 排他网关
  - 并行网关
  - 包含网关
- 数据字典：
- 支持版本控制
- 支持对字典单独授权
- 支持多级树形字典
- 内置：美国城市区划、中国城市区划
- 通用的后端逻辑处理
- 通用的前端渲染组件
增强
- Markdown：实现了一个所见即所得的Markdown富文本编辑器，绝对好用，一定要体验一下
- JSON：重构了带格式化的JSON编辑器

文档与教程：

伴随着 CabloyJS 4.12 新版功能的推出，还全新制作了一套教程。为了体现 CabloyJS低代码的开箱即用和专业代码的灵活定制，教程也由浅到深相应的分为几个部分：

演示站点

通过这套教程，可以让我们更快的了解 CabloyJS 的开发风格，以及可以用来做哪些事情。欢迎大家尝鲜、拍砖

也可以在阅读教程的同时，直接浏览 CabloyJS 的演示站点，增加更直观的感性认知

演示站点：https://test.cabloy.com/

为了体验与众不同的pc=mobile+pad自适应布局风格，一定要分别用PC和Mobile单独体验演示站点。此言不虚，请您品鉴！！！

演示站点的二维码：

CabloyJS 基于 EggJS 实现的模块编译与发布

zhennann — Sun, 04 Jul 2021 16:43:55 +0800

背景

现在，EggJS被许多开发团队所采用。有的团队基于商业知识产权的考量，往往会提一个问题：是否可以把EggJS当中的代码编译打包，然后再把代码丑化？

模块编译的机制

EggJS为何不能便利的实现编译的特性？

在EggJS中，代码文件都是通过约定代码位置的方式组织并加载的。也就是说，代码文件都放置在约定的目录结构当中，EggJS 在启动系统时，在约定的位置扫描加载约定的代码文件。因此，在这种机制下，不能便利的实现编译特性

CabloyJS是如何实现编译特性的？

EggJS作为企业级框架提供了足够灵活的机制，比如，允许上层框架提供自定义的加载器。CabloyJS就是基于EggJS的这种机制实现了一套自定义的加载器

在CabloyJS中，模块当中的代码文件都是通过require的方式显式组织并加载的。这种加载机制为模块内部的源码文件提供了清晰的调用依赖关系，因此我们就可以采用Webpack完成编译打包，以及丑化代码的工作

模块编译的意义

模块复用、构建生态：模块可单独编译，从而可以单独发布、单独部署，单独升级，从而促进 CabloyJS 整个生态圈的繁荣，进一步加速实际业务的开发
知识产权：模块可单独编译，也可以满足保护商业代码的需求

如何编译模块

# 进入模块所在目录
$ cd /path/to/module
# 编译模块前端代码
$ npm run build:front
# 编译模块后端代码
$ npm run build:backend

编译参数

所有模块均采用缺省的编译参数，当然也可以提供自定义的编译参数，以模块test-party为例：

src/module/test-party/build/config.js

module.exports = {
  front: {
    productionSourceMap: false,
    uglify: true,
  },
  backend: {
    productionSourceMap: false,
    uglify: true,
  },
};

名称	说明
productionSourceMap	是否生成`SourceMap`文件
uglify	是否`uglify`代码

模块加载约定

在模块目录下，既有src源代码文件，也有dist打包文件。那么什么时候加载src，什么时候加载dist呢？

模块有两类：全局模块和局部模块。这两类模块有不同的加载约定：

全局模块：位于项目的node_modules目录中，系统总是加载全局模块的dist打包文件
局部模块：位于项目的src/module目录中，系统优先查找src目录并加载模块源码，如果没有找到则加载局部模块的dist打包文件

理解了全局模块与局部模块的代码加载约定，在将项目部署在生产环境时有利于做出正确的配置（主要的诉求就是：如何保护商业代码）

最佳实践（模块前端）

在部署时，项目前端总是要进行整体编译，把所有全局模块和局部模块的前端源码和前端资源都打包，然后输出到项目的dist目录

如果模块作为局部模块而存在，则不需要考虑模块前端的编译环节

如果模块要发布为全局模块，则必须先进行模块前端的编译

最佳实践（模块后端）

1. 不进行模块编译

如果没有保护商业代码的需求，那么就不用考虑模块编译的环节。在部署时，直接作为局部模块加载源码运行即可

2. 进行模块编译

如果要进行模块编译，那么在部署时有两个选择：

作为局部模块
1. 模块仍然位于项目的src/module目录
2. 将模块编译后，在生产环境删除模块的src源码目录即可
作为全局模块
1. 将模块编译后，发布至公司的私有仓库
2. 在项目中将模块作为全局模块安装至node_modules目录
3. 如果没有私有仓库，也可以采用npm link机制安装为全局模块

模块发布

当项目中的模块代码稳定后，可以将模块公开发布，贡献到开源社区。也可以在公司内部建立 npm 私有仓库，然后把模块发布到私有仓库，形成公司资产，便于重复使用

$ cd /path/to/module
$ npm run build:front
$ npm run build:backend
$ npm publish

由于发布到 npm 仓库的模块将作为全局模块来使用，因此需要先编译模块的前端和后端

效果图（模块后端编译）

编译之前的源码结构

编译之后的输出文件

CabloyJS 实现了一款基于 X6 的工作流可视化编辑器

zhennann — Mon, 26 Apr 2021 08:44:33 +0800

介绍

文档演示：CMS 审批工作流演示了如何通过JSON来直接创建一个工作流定义，通常用于为具体的业务数据生成预定义或内置审批工作流的场景

CabloyJS 4.8.0 采用X6 图编辑引擎实现了一款工作流可视化编辑器，从而可以在系统运行过程中，随时、动态、可视化的创建工作流定义

特别要感谢X6提供了非常强大的图编辑引擎，而且也提供了非常灵活的开发接口和扩展接口。基于 X6 的有力支撑，工作流可视化编辑器的复杂部分反而不再是图编辑本身了，而是各个节点的属性编辑表单，以及表单背后的 API 接口的配套支持

如果大家对X6 图编辑引擎有兴趣，一定要看看 CabloyJS 4.8.0，这会是一个非常清晰的入门案例

演示

Mobile

PC

如何在 Uniapp 中访问 CabloyJS 后端管理系统 API

zhennann — Sun, 24 Jan 2021 20:31:30 +0800

介绍

CabloyJS是一款免费开源的 NodeJS 全栈开发框架，采用前后端分离设计，具备开箱即用的后台管理系统

Cabloy-SDK是专门为 Uniapp 应用量身定制的前端 SDK，用于便捷的访问 CabloyJS 提供的所有 API 接口，让 Uniapp 前端开发再无后顾之忧

特性

各个平台的小程序后端 API 系统，最复杂的就是账号体系对接。CabloyJS 提供了一个模块化的生态，需要开发什么平台下的小程序应用，只需安装相应的模块即可

目前Cabloy-SDK支持以下平台小程序的开箱即用：

如何使用 - 前端

1. 导入插件

进入Uniapp 插件页面，点击按钮使用HBuilderX导入插件，将Cabloy-SDK插件导入 Uniapp 项目中

强烈建议下载示例项目查看插件的基本用法

2. 修改 main.js

在main.js文件中添加如下代码：

import Vue from 'vue'
import App from './App'

import Cabloy from './js_sdk/cabloy-sdk/main.js'

// 初始化cabloy
const cabloyOptions = {
  base: {
    scene: 'default',
    locale: 'en-us',
  },
  api: {
    baseURL: 'https://yourdomain.com',
  },
}

Vue.prototype.$cabloy = Cabloy(Vue, cabloyOptions)

// 登录
Vue.prototype.$cabloy.util.login().then(res => {
  // 由于 login 是网络请求，可能会在 Page.onLoad 之后才返回
  // 所以此处加入 callback 以防止这种情况
  if (Vue.prototype.$cabloy.__loginReadyCallback) {
    Vue.prototype.$cabloy.__loginReadyCallback(res);
  }
}).catch(err => {
  console.log(err)
})

Vue.config.productionTip = false

App.mpType = 'app'

const app = new Vue({
    ...App
})
app.$mount()

首先要初始化一个cabloy实例，并保存至 Vue.prototype.$cabloy，便于在所有 Vue 组件中引用

其次调用cabloy.util.login进行登录

cabloyOptions

名称	说明
base.scene	小程序场景名，默认为`default`
base.locale	前端默认使用的语言
api.baseURL	后端服务的 API 地址

base.scene：CabloyJS 后端可以支持创建多个小程序，前端通过此参数设置要对接的小程序场景名，默认为default

3. API 清单

插件Cabloy-SDK主要提供了以下 API 组件

名称	说明
cabloy	根对象
cabloy.util	工具函数
cabloy.api	访问后端 API 接口
cabloy.data	状态数据存储
cabloy.config	配置参数

如何使用 - 后端

CabloyJS 提供了一个模块化的生态，需要开发什么平台下的小程序应用，只需安装相应的模块即可

1. 微信小程序

2. 企业微信小程序

3. 钉钉小程序

CabloyJS 自带工作流引擎的文档清单

zhennann — Fri, 15 Jan 2021 18:47:37 +0800

文档清单

CabloyJS 自带工作流引擎文档已经整理出来，欢迎大家围观、拍砖

介绍
流程定义
流程实例
转移线
- 环境对象
- 顺序流
活动节点
- 基本概念
- 环境对象
- 开始事件
- 空开始事件
- 定时开始事件
- 原子起草开始事件
- 结束事件
- 空结束事件
- 活动
- 空活动
- 服务活动
- 用户任务活动
用户任务
进阶篇（待续...）

什么是 CabloyJS 自带工作流引擎

众所周知，NodeJS 作为后端开发语言和运行环境，样样都好，就差一个NodeJS工作流引擎。CabloyJS 4.0 重点开发了NodeJS工作流引擎，并作为内置的基础核心模块，近一步拓展了 NodeJS 在后端的应用场景，为深入研发各类商业业务逻辑，提供了基础支撑

NodeJS 工作流引擎的特点

更简便的配置：采用JSON进行流程定义的配置，告别 XML 配置文件的冗杂
流程定义：支持历史版本、支持启用/禁用
更清晰的架构：采用三个核心模块用分层的机制实现工作流引擎的架构，让工作流不再神秘，源码也不再叠床架屋

模块名称	说明
a-flow	流程定义、流程实例
a-flownode	流程节点（活动节点）
a-flowtask	流程任务

支持业务流程和审批流程
与原子数据生命周期结合，内置了一套基于原子数据的审批工作流。参见：原子阶段（数据生命周期）
与表单验证结合，支持分别配置不同流程节点的读取字段权限和修改字段权限。参见：表单验证
可通过AOP机制定制工作流逻辑。参见：AOP
可通过Listener机制定制工作流逻辑。参见：listener 规范
开放式的架构，支持更多流程节点的定制开发
包含大量测试驱动代码，可快速上手使用工作流

与`Activiti`的对比

流程定义是工作流引擎的灵魂，一个合理的流程定义规范，既要考虑使用的便利性，又要考虑功能特性的可扩展性

Activiti无疑是 Java 语言领域工作流引擎的标杆，依据BPMN2.0规范采用XML格式来定义工作流

1. JAVA + BPMN + XML

BPMN + XML的优点是标准统一，与JAVA语言的开发调性相匹配。当然，缺点是繁琐，如果脱离了图形化编辑工具，采用手写 XML 定义，非常不便利

2. JS + 类 BPMN + JSON

CabloyJS 经过反复的评估与权衡，决定仍然参考BPMN规范的特性集，但是采用JSON格式进行定义。虽然属于自定义格式，但符合JS语言的调性，优点是简约、易写、易读，同样具备优秀的可迁移性

基于原生 JS 实现的 Bean 容器和 AOP 编程

zhennann — Wed, 06 Jan 2021 10:42:59 +0800

Bean 是什么

我们知道Bean是Spring最基础的核心构件，大多数逻辑代码都通过Bean进行管理。NestJS基于TypeScript和依赖注入也实现了类似于Spring Bean的机制：服务提供者（Provider）

CabloyJS 则是在原生JS（Vanilla JS）上实现了更轻量、更灵活的 Bean 容器

理念

CabloyJS 在设计 Bean 容器机制时，遵循了以下 3 个理念：

1. 几乎所有事物都是 Bean

我们绝大多数逻辑代码都通过 Bean 组件进行管理，比如：Controller、Service、Model、Middleware、Event、Queue、Broadcast、Schedule、Startup、Flow、Flow Task，等等

CabloyJS 4.0 在实现了 Bean 容器之后，基本上所有核心组件都以 Bean 为基础进行了重构。比如基于 EggJS 的 Controller、Service、Middleware，也实现了 Bean 组件化

2. Bean 支持 AOP

所有 Bean 组件都可以通过 AOP 组件进行逻辑扩展

3. AOP 也是一种 Bean

AOP 组件既然也是 Bean，那么也可以通过其他 AOP 组件进行逻辑扩展

这种递归设计，为系统的可定制性和延展性，提供了强大的想象空间

定义 Bean

CabloyJS 约定了两种定义 Bean 的模式：app 和 ctx。由于 Bean 被容器托管，可以很方便的跨模块调用。因此，为了清晰的辨识 Bean 被应用的场景，一般约定：如果 Bean 只被本模块内部调用，那么就使用 app 模式；如果大概率会被其他模块调用，那么就使用 ctx 模式

1. app 模式

比如：Controller、Service 都采用 app 模式

src/module/test-party/backend/src/bean/test.app.js

module.exports = app => {

  class appBean extends app.meta.BeanBase {

    actionSync({ a, b }) {
      return a + b;
    }

    async actionAsync({ a, b }) {
      return Promise.resolve(a + b);
    }

  }

  return appBean;
};

2. ctx 模式

比如：ctx.bean.atom、ctx.bean.user、ctx.bean.role都采用 ctx 模式

src/module/test-party/backend/src/bean/test.ctx.js

module.exports = ctx => {
  class ctxBean {

    constructor(moduleName) {
      this._name = moduleName || ctx.module.info.relativeName;
    }

    get name() {
      return this._name;
    }

    set name(value) {
      this._name = value;
    }

    actionSync({ a, b }) {
      return a + b;
    }

    async actionAsync({ a, b }) {
      return Promise.resolve(a + b);
    }

  }

  return ctxBean;
};

ctx.module.info.relativeName: 由于 ctx 模式的 Bean 经常被其他模块调用，那么可以通过此属性取得调用方模块的名称

注册 Bean

对于大多数组件，EggJS 采用约定优先的策略，会在指定的位置查找资源，并自动加载。而 CabloyJS 采用显式注册，从而 Webpack 可以收集所有后端源码，实现模块编译的特性

src/module/test-party/backend/src/beans.js

const testApp = require('./bean/test.app.js');
const testCtx = require('./bean/test.ctx.js');

module.exports = app => {
  const beans = {
    // test
    'test.app': {
      mode: 'app',
      bean: testApp,
    },
    testctx: {
      mode: 'ctx',
      bean: testCtx,
      global: true,
    },
  };
  return beans;
};

名称	说明
mode	模式：app/ctx
bean	bean 组件
global	是否是全局组件

使用 Bean

1. beanFullName

每一个注册的 Bean 组件都被分配了全称，具体规则如下

注册名称	场景	所属模块	global	beanFullName
test.app	test	test-party	false	test-party.test.app
testctx		test-party	true	testctx

全局 Bean（global:true）: 当一个 Bean 组件可以作为一个核心的基础组件的时候，可以设置为全局 Bean，方便其他模块的调用，比如：atom、user、role、flow、flowTask，等等

本地 Bean（global:false）: 当一个 Bean 组件一般只用于本模块时，可以设置为本地 Bean，从而避免命名冲突

场景：对于本地Bean，我们一般为其分配一个场景名称作为前缀，一方面便于 Bean 的分类管理，另一方面也便于辨识 Bean 的用途

2. 基本调用

可以直接通过this.ctx.bean取得 Bean 容器，然后通过beanFullName获取 Bean 实例

src/module/test-party/backend/src/controller/test/feat/bean.js


// global: false
this.ctx.bean['test-party.test.app'].actionSync({ a, b }); 
await this.ctx.bean['test-party.test.app'].actionAsync({ a, b });

// global: true
this.ctx.bean.testctx.actionSync({ a, b });
await this.ctx.bean.testctx.actionAsync({ a, b });

3. 新建 Bean 实例

通过this.ctx.bean获取 Bean 实例，那么这个实例对当前ctx而言是单例的。如果需要新建 Bean 实例，可以按如下方式进行：

ctx.bean._newBean(beanFullName, ...args)

比如我们要新建一个 Flow 实例：

src/module-system/a-flow/backend/src/bean/bean.flow.js

_createFlowInstance({ flowDef }) {
  const flowInstance = ctx.bean._newBean(`${moduleInfo.relativeName}.local.flow.flow`, {
    flowDef,
  });
  return flowInstance;
}

4. 跨模块调用本地 Bean

本地 Bean 也可以被跨模块调用

跨模块调用的本质：新建一个 ctx 上下文环境，该 ctx 的 module 信息与本地 Bean 一致，然后通过新容器ctx.bean来调用本地 Bean

await ctx.executeBean({ locale, subdomain, beanModule, beanFullName, context, fn, transaction })

名称	可选	说明
locale	可选	默认等于 ctx.locale
subdomain	可选	默认等于 ctx.subdomain
beanModule	必需	本地 Bean 所属模块名称
beanFullName	必需	本地 Bean 的全称
context	可选	调用本地 Bean 时传入的参数
fn	必需	调用本地 Bean 的方法名
transaction	可选	是否要启用数据库事务

比如我们要调用模块a-file的本地 Bean: service.file，直接上传用户的 avatar，并返回 downloadUrl

src/module-system/a-base-sync/backend/src/bean/bean.user.js

// upload
const res2 = await ctx.executeBean({
  beanModule: 'a-file',
  beanFullName: 'a-file.service.file',
  context: { fileContent: res.data, meta, user: null },
  fn: '_upload',
});
// hold
profile._avatar = res2.downloadUrl;

5. app.bean

ctx.bean是每个请求初始化一个容器，而app.bean则可以实现整个应用使用一个容器，从而实现 Bean 组件的应用级别的单例模式

src/module/test-party/backend/src/controller/test/feat/bean.js

app.bean['test-party.test.app'].actionSync({ a, b }); 
await app.bean['test-party.test.app'].actionAsync({ a, b });

AOP 编程

限于篇幅，关于AOP编程请参见：cabloy-aop

CabloyJS 也有工作流引擎了，是你想要的吗？

zhennann — Mon, 21 Dec 2020 15:53:51 +0800

前言

NodeJS 工作流引擎的特点

更简便的配置：采用JSON进行流程定义的配置，告别 XML 配置文件的冗杂
流程定义：支持历史版本、支持启用/禁用
更清晰的架构：采用三个核心模块用分层的机制实现工作流引擎的架构，让工作流不再神秘，源码也不再叠床架屋

模块名称	说明
a-flow	流程定义、流程实例
a-flownode	流程节点（活动节点）
a-flowtask	流程任务

支持业务流程和审批流程
与Atom三生三世结合，内置了一套基于 Atom 的审批工作流。参见：原子阶段（三生三世）
与表单验证结合，支持分别配置不同流程节点的读取字段权限和修改字段权限。参见：表单验证
可通过AOP机制定制工作流逻辑
可通过Listener机制定制工作流逻辑
开放式的架构，支持更多流程节点的定制开发
包含大量测试驱动代码，可快速上手使用工作流

工作流演示

新建一个草稿：采购订单
选择要使用的流程定义，然后提交，草稿进入相应的审批流程
签收任务、并处理任务
流程结束，草稿转为归档

一个最简工作流定义

src/module/test-flow/backend/src/config/static/flowDef/set00_simple.js

{
  listener: null,
  process: {
    nodes: [
      {
        id: 'startEvent_1',
        name: 'Start',
        type: 'startEventNone',
      },
      {
        id: 'endEvent_1',
        name: 'End',
        type: 'endEventNone',
      },
    ],
    edges: [
      {
        id: 'edge_1',
        source: 'startEvent_1',
        target: 'endEvent_1',
      },
    ],
  },
}

名称	说明
listener	监听器，可监听 flow/node/task 各类事件
process.nodes	流程节点
process.nodes.type	流程节点类型
process.edges	流程转移线
process.edges.source	来源
process.edges.target	去向

一个审批流程定义

src/module/test-flow/backend/src/config/static/flowDef/set01_atomUserTask.js

{
  listener: null,
  process: {
    nodes: [
      {
        id: 'startEvent_1',
        name: 'Drafting',
        type: 'startEventAtom',
        options: {
          atom: {
            module: moduleInfo.relativeName,
            atomClassName: 'purchaseOrder',
          },
          conditionExpression: 'atom._flowDefKey===\'set01_atomUserTask\'',
        },
      },
      {
        id: 'activity_1',
        name: 'Review',
        type: 'activityUserTask',
        options: {
          assignees: {
            // users: '1,2',
            // roles: '1,2',
            vars: 'flowUser',
          },
          confirmation: false,
          bidding: false,
          completionCondition: {
            // passed: 1,
            // rejected: '100%',
          },
          // rejectedNode:null,
          // allowRejectTask: true,
          // allowCancelFlow: false,
          schema: {
            write: [
              'atomName',
              {
                name: 'description',
                property: {
                  type: 'string',
                  ebType: 'text',
                  ebTitle: 'Description',
                },
              },
            ],
          },
        },
      },
      {
        id: 'endEvent_1',
        name: 'End',
        type: 'endEventNone',
      },
    ],
    edges: [
      {
        id: 'edge_1',
        source: 'startEvent_1',
        target: 'activity_1',
      },
      {
        id: 'edge_2',
        source: 'activity_1',
        target: 'endEvent_1',
      },
    ],
  },
}

process.nodes.type

名称	说明
startEventAtom	`开始事件节点（起草）`：通过 options.atom 和 options.conditionExpression 与指定的 Atom 类型绑定。当指定的 Atom 提交时自动启动相匹配的工作流定义
activityUserTask	`用户任务节点`：可指定参与人、是否竞签、完成条件、读字段权限、写字段权限，等等
endEventNone	`结束事件节点`

CabloyJS v4.0.0 支持工作流引擎及更多 🎉

zhennann — Mon, 21 Dec 2020 15:33:38 +0800

截至 2020 年 12 月 21 日冬至，花了近 5 年时间作出最小可用 NodeJS 开源全栈框架，这就是 CabloyJS V4.0.0

5 年，90 个模块，30 万行代码，5400 次提交 (Commits)，开启 NodeJS 全栈开发的全新体验

CabloyJS V4.0.0 主要完成了以下特性

采用 lerna 将 cabloy 所有核心模块集中在一个源码仓库管理
基于原生 JS 的 Bean 容器和 AOP 架构
- 几乎所有事物都是 Bean
- Bean 支持 AOP
- AOP 也是一种 Bean
通用的 NodeJS 工作流引擎
原子三生三世（数据的生命周期管理）：草稿->归档->历史
基于 NodeJS 工作流引擎的草稿审核业务流
PC 端与移动端自适应：页面组件只需要开发一次。不是采用media query，也不是采用iframe，而是真正的把手机操控体验带入 PC 端。只要用一下，就会有一种相逢恨晚的感觉
统计值自动更新与推送架构。比如，我有多少待办一目了然。这是一个通用的架构，可以简便的匹配到任何场景
接口对接：微信公众号、企业微信、钉钉企业应用
基于 Redis 的原生分布式架构
- Queue
- Schedule
- Broadcast
- Cache
- Startup
基于 socketio 的消息推送架构
具有部件间数据绑定机制的“仪表板”架构
高度定制化的 PC 端布局：header、sidebar、statusbar

CabloyJS 微信模块、企业微信模块已出齐

zhennann — Fri, 26 Jun 2020 21:46:21 +0800

前言

当Cabloy-企业微信模块完成时，加上之前已完成的Cabloy-微信模块，关于在 CabloyJS 中与微信/企业微信对接的任务已经完成了。这些模块的目标就是，只需填入各类服务的参数，就可以直接进入具体的业务开发，从而达到开箱即用的效果

背景分析

1. 账户体系

微信/企业微信的开发，有诸多的坑，而最大的坑就是账户体系了

首先，微信与企业微信是不同的账户体系
在微信中，openid 是识别用户的唯一标识，如果开通了微信开放平台，那么就可以通过 unionid 把散落在微信公共号、微信小程序等不同服务的 openid 关联起来，标识同一个用户。那么，如何把 openid 与系统中的用户系统对接起来？如果开通了 unionid，又如何对接？unionid 开通之前的旧账户是否也可以平滑迁移？
在企业微信中，通过 userid 来识别每个企业成员。与微信不同的是，企业微信通过部门树来管理成员，从而为资源授权和分配提供组织依据。那么，我们在进行系统初始化的第一步就是要把企业的部门和成员同步到系统中，并实现双向查找功能

2. 杂项

除了纷繁复杂的账户体系对接任务，接下来我们还要面对一些随时开发随时遇到的小问题。因为微信/企业微信开发涉及到的场景、概念和术语有很多，往往需要通读官方文档。而官方文档对有些概念的表述语焉不详，惜墨如金，于是不得不写代码来验证一些猜测，然后再回头重温文档。当这一遍走完把项目完成后，如果有一个新项目，很可能还要再走一遍。这里仅仅列举一些经常出现的问题：

JSON 与 XML：微信公共号的消息推送系统采用 XML 作为数据格式，而小程序既要支持 XML 也要支持 JSON。同时又有明文模式、兼容模式、安全模式之别。
openid/unionid与openId/unionId：在进行账号登录时，微信公共号返回的是openid/unionid，而小程序返回的openId/unionId。如果稍不留意，就掉在坑里了
企业微信支持不同的应用：内置的应用、第三方应用、自建应用、关联的小程序等等。这些应用如何进行架构，提供统一便捷的 API 调用模型
企业微信小程序本体是微信小程序，然后关联到企业微信成为一个企业微信应用。只有明白了这些概念和关系，才能准确的进行对接

核心目标

1、常见微信 API SDK 的问题

不同的开发语言，都能找到对应的微信 API SDK。但这些微信 API SDK 往往是把官方提供的 http api 进行了一个语言层面的封装，很少走得更远的。比如，通过微信 API SDK，我们可以很方便的获取 AccessToken，可以获取 User 信息，但是如何把获取到的 User 与系统对接，如何处理 openid 和 unionid 之间的关联，仍然需要我们自己设计和开发

再比如，通过微信 API SDK 可以很方便的获取企业微信的部门和成员。但是如何与系统中的角色和用户对接，并支持不同的场景和登录方式，仍然有大量的工作需要做

2. 开箱即用

而 CabloyJS 的微信/企业微信模块的核心目标就是提供开箱即用的效果。只需配置好参数，所有的对接工作全部自动完成，使我们一步跨过纷繁的细节，直接进入具体的业务开发当中。当然，CabloyJS 的微信/企业微信模块是完全开源的，我们仍然可以从中清晰地看到这些细节，以及处理的方式

为什么 CabloyJS 可以做到开箱即用的效果？就是因为 CabloyJS 是全栈 NodeJS 框架，可以把前端组件、后端服务、数据存储与访问等等，有机的结合在一起

比如，CabloyJS 模块通过这些前后端的配合，直接实现了企业微信中部门与用户的同步工作，甚至还通过 CabloyJS 底层提供的SocketIO机制实现了前端同步进度的实时显示

两大亮点

基于 CabloyJS 全栈业务开发框架本身提供的特性，使得Cabloy-企业微信模块具有以下两个显著的亮点：

1. PC、Mobile 自适应

许多企业微信应用存在这样一个问题：在 Mobile 端只能使用一部分功能，其他更多功能则需要登录 PC 系统进行操作

而 CabloyJS 框架下的Cabloy-企业微信允许所有的业务功能同时支持 PC 和 Mobile 使用。同时又能保证以下两点：

通过角色权限系统，控制不同用户使用不同功能
前端页面采用异步加载策略，从而适应大型项目的开发

Mobile 端效果

PC 端效果

2. 数据孤岛

企业从不同服务提供商采购不同的企业微信应用，必然导致数据孤岛的出现，而且这些数据散存在不同服务商的后台，缺乏数据联动与共享机制

而 CabloyJS 框架本身就是基于业务模块构建的。企业自建的模块或者使用第三方的模块，都汇集在一个 CabloyJS 项目之中，并进行私有部署，从而从根本上解决了数据孤岛的问题，不仅能实现数据联动与共享，也可以更灵活的进行数据采集、处理和分析

归根结底一句话，数据和程序都掌握在自己的手中

特性

基于 CabloyJS 全栈框架提供的便利性和灵活性，Cabloy-企业微信主要有如下特性：

1. 一站式整合

当前整合了企业微信自建应用和企业微信小程序的接口，具体如下：

场景	名称	说明
自建应用	消息推送系统	自动完成接口对接，并对用户进行认证
自建应用	网页登录	自动跳转微信登录，并对用户进行认证
自建应用	网页 JSSDK	自动注入 JSSDK，并自动完成配置
小程序	后台登录接口	自动完成接口对接，并对用户进行认证
小程序	前端 SDK	提供 SDK，便于企业微信小程序前端直接访问 CabloyJS 后端 API

2. 开箱即用

只需配置好企业微信账号参数，所有接口自动完成对接

3. 多小程序支持

企业微信可以关联多个企业微信小程序，因此，模块也提供了多小程序支持

4. 多站点支持

通过 CabloyJS 提供的多实例特性，可以实现多站点支持，比如为不同的企业提供企业微信服务。请参见：EggBornJS：多实例

zhennann (zhennann)

在 Vue3 中如何实现四种全局状态数据的统一管理？

四种全局状态数据

特性 1. 支持异步数据和同步数据

特性 2. 自动缓存

特性 3. 自动更新

特性 4. 减少重复请求

特性 5. 内存优化

特性 6. 持久化

特性 7. SSR 支持

特性 8. 自动命名空间隔离

如何创建一个 Model Bean

异步数据

如何定义

如何使用

如何支持 SSR

同步数据：localstorage

如何定义

如何使用

同步数据：cookie

如何定义

如何使用

同步数据：内存

如何定义

如何使用

结语

在一个项目中同时实现“后台管理系统”和“前台应用”

微信一起点菜

截图

后台商家管理系统

前台点菜应用

CabloyJS 4.22 重磅推出弹出式页面交互风格

升级说明

意义

预览

1. PC 端（展开式）

2. PC 端（弹出式）

3. Mobile 端

演示站点

相关链接

且看这个 Node 全栈框架，实现了个 Cli 终端引擎，可无限扩充命令集

背景介绍

特点

如何使用

- command

- args

- options

- help

- version

- 列出命令

内置命令

简写命令

如何创建 Cli 命令

相关链接

看看 CabloyJS 是如何实现编辑页面脏标记的

应用场景

效果演示

如何使用

1. 引入脏标记组件

2. Title 显示脏标记

3. 修改脏标记

组件 ebPageDirty 的方法

相关链接

CabloyJS 4.12 震撼发布，及新版教程尝鲜

引言

CabloyJS 4.12

文档与教程：

演示站点

CabloyJS 基于 EggJS 实现的模块编译与发布

背景

模块编译的机制

模块编译的意义

如何编译模块

编译参数

模块加载约定

最佳实践（模块前端）

最佳实践（模块后端）

1. 不进行模块编译

2. 进行模块编译

模块发布

与`Activiti`的对比