一、mf/README.md#

结构说明#

• apps/host：主应用，Vue 3 + Vue Router；子应用路由使用标准 MF 动态 import：component: () => import('remote1/PageA')，首次进入该路由时 Webpack 按需加载对应 remote 的 remoteEntry；加载 remote3（React） 时使用 @module-federation/bridge-vue3 的 createRemoteAppComponent 做应用级 Bridge 集成。
• apps/remote1：子应用 1（Vue），暴露 PageA、PageB、Widget；使用 ModuleFederationComponentPlugin + mf-vue-section-loader 做根节点包裹，配合 postcss-selector-namespace 对暴露组件的 CSS 做 .remote1-mf 命名空间隔离。
• apps/remote2：子应用 2（Vue），暴露 Dashboard；同样使用插件/loader + .remote2-mf 命名空间做样式隔离。
• apps/remote3：子应用 3（React），通过 Bridge 以应用级暴露 export-app；使用 @module-federation/bridge-react 的 createBridgeComponent 包装根组件，供 Vue Host 用 createRemoteAppComponent 加载。详见 docs/BRIDGE-HETEROGENEOUS.md。
• packages/mf-vue-isolation：共享的 MF 样式隔离插件与 loader。

编码范式：标准 MF 按需加载#

• 主应用在路由中直接使用 动态 import：component: () => import('remote1/PageA')、import('remote2/Dashboard')。
• Webpack 会为每个 remote 生成异步 chunk，首次进入该子应用路由时才加载对应 remoteEntry，未访问的子应用不加载。
• Remote URL 在 host 的 webpack.config.js 的 remotes 中配置；需运行时配置时可改为 Promise 型 remotes。

CSS 样式隔离#

• 子应用使用 packages/mf-vue-isolation 中的：

  • ModuleFederationComponentPlugin：识别被 Module Federation 暴露的 Vue/JS 模块，为其请求添加 ?mf，并注入 mf-vue-section-loader。
  • mf-vue-section-loader：对带 ?mf 的 Vue 文件，将 template 根与 render 根包裹在 <section class="wrapperClassName"> 中（remote1 为 remote1-mf，remote2 为 remote2-mf）。

• 子应用 Webpack 中对 带 resourceQuery: /mf/ 的 CSS 使用 postcss-selector-namespace，为选择器加上命名空间（如 .remote1-mf），从而只影响该 section 内的样式，与主应用及其他子应用隔离。

• 方案与业界对比、优缺点说明见 docs/CSS-ISOLATION.md。

如何运行#

1
# 安装依赖（根目录）
2
pnpm install
3

4
# 同时启动 host + remote1 + remote2 + remote3（推荐）
5
pnpm dev
6

7
# 或分别启动
8
pnpm dev:host    # http://localhost:3000
9
pnpm dev:remote1 # http://localhost:3001
10
pnpm dev:remote2 # http://localhost:3002
11
pnpm dev:remote3 # http://localhost:3003

1. 打开 http://localhost:3000（主应用）。
2. 点击「Remote1 PageA」或「Remote1 PageB」：此时才会请求 http://localhost:3001/remoteEntry.js。
3. 点击「Remote2 Dashboard」：此时才会请求 http://localhost:3002/remoteEntry.js。
4. 点击「Remote3 (React)」：此时才会请求 http://localhost:3003/remoteEntry.js，并通过 Bridge 在 Vue 主应用中挂载 React 子应用。
5. 仅访问首页或 About 时，不会加载任何子应用 remoteEntry。

构建#

1
pnpm build        # 构建所有应用
2
pnpm build:host
3
pnpm build:remote1
4
pnpm build:remote2
5
pnpm build:remote3

生产环境需将 host 的 webpack.config.js 中 remotes 的 URL 改为实际部署的 remoteEntry 地址（或 CDN）。

异构框架（Bridge）#

• remote3 为 React 子应用，通过 Module Federation 官方的 Bridge 方案与 Vue 主应用集成。
• 子应用使用 @module-federation/bridge-react 的 createBridgeComponent 导出应用；主应用使用 @module-federation/bridge-vue3 的 createRemoteAppComponent 加载并挂载。
• 原理与最佳实践见 docs/BRIDGE-HETEROGENEOUS.md。

跨应用共享（状态 / API / 路由）#

• Host 通过 MF 暴露：./store（Pinia）、./sharedStateBridge（与框架无关的状态桥）、./api（统一 API 客户端）、./navigate（驱动主应用路由）。
• Vue 子应用：使用 host/store、Vue Router；可按需使用 host/api、host/navigate。
• React 子应用（remote3）：使用 host/sharedStateBridge 与 Pinia 双向同步；使用 host/api 在 @tanstack/react-query 中请求；使用 host/navigate 跳转主应用路由。
• 详见 docs/CROSS-APP-SHARING.md。

二、mf/docs/CROSS-APP-SHARING.md#

1. 总体原则#

• 框架相关的运行时（Vue 组件、Pinia、Vue Router、React 组件、Zustand、React Router）不能跨框架直接复用，只能通过「契约 + 桥接」间接协作。
• 可共享的是：与框架无关的模块——纯 TS/JS 的状态桥、API 客户端、导航函数、类型与常量。
• 推荐：Host 作为能力提供方，通过 Module Federation 的 exposes 暴露「状态桥、API、导航」等；Vue 子应用继续用 Pinia/Vue Router，React 子应用用 Zustand/React Query/React Router，但数据与行为统一来自 Host 暴露的模块。

2. 组件跨框架复用#

结论：异构场景下组件级复用成本高，优先做应用级集成（Bridge）+ 共享数据与能力（状态桥、API、导航）。

3. 状态共享：Pinia（Vue）与 Zustand（React）#

• Pinia 只能在 Vue 环境用，Zustand 只能在 React 环境用，二者不能共用同一个 store 实例。
• 做法：由 Host 暴露一个与框架无关的「状态桥」（纯 TS：getState / setState / subscribe），Vue 用 Pinia 与之同步，React 用 Zustand 或 useSyncExternalStore 与之同步，实现逻辑上的同一份全局状态。

4. 路由协作#

• 主路由由 Host 的 Vue Router 控制；子应用（含 remote3）以子路径挂载（如 /remote3），Bridge 的 basename 已支持。
• 跨应用跳转：Host 可暴露一个导航函数 navigate(path: string)（内部用 window.history.pushState + 派发 popstate，或直接 window.location.assign），React 子应用调用该函数即可跳转到任意主应用路由；Vue 子应用已与 Host 共享 Vue Router，直接 router.push(path) 即可。

5. 数据层：axios（Vue）与 React Query（React）#

• axios 与 @tanstack/react-query 职责不同：前者是 HTTP 客户端，后者是请求 + 缓存 + 状态管理；二者可以并存。
• 推荐：共享「请求能力」与「接口契约」，不强行共享具体库。

6. 本仓库已实现示例#

7. 参考#

• 状态桥模式与 useSyncExternalStore：React 文档 - useSyncExternalStore
• 跨应用通信与共享依赖：Module Federation 官方 Shared、Bridge

三、mf/docs/BUNDLE-ANALYSIS.md#

1. 构建产物一览#

主应用 不会 把 PageA/PageB/Dashboard 的 Vue 源码打进自己的 bundle，只打进去「如何按需拉取」的逻辑和配置。

2. 主包里「包含」了哪些与子应用相关的内容？#

主包（main.js）里与子应用相关的只有下面几类，不包含子应用组件的业务代码。

1
remote-module modules 18 bytes (remote) 18 bytes (share-init)
2
  remote remote1/PageA  6 bytes (remote) 6 bytes (share-init)
3
  + 2 modules  (即 remote1/PageB、remote2/Dashboard)

3. 主包「不包含」什么？#

也就是说：子应用的「业务代码」和「依赖」都在子应用自己的 remoteEntry（及子应用自己的 chunk）里，主包只含「如何找到并加载这些 remote」的配置和胶水。

4. 加载顺序（运行时）#

1. 用户打开主应用 → 只下载 main.js（以及可能预加载的 320.js 等主应用自己的 chunk）。

2. 用户点击「Remote1 PageA」→ 路由触发 import('remote1/PageA')：

   • 主包里的 remote 占位 执行；
   • 发现 remote1 的 container 未加载 → 按配置请求 http://localhost:3001/remoteEntry.js；
   • 执行 remoteEntry，得到 container，再 container.get('./PageA')；
   • 返回的 factory 执行后得到 Vue 组件，渲染。

3. 若之后再点「Remote2 Dashboard」，再按同样流程加载 remote2/remoteEntry.js 并 get('./Dashboard')。

所以：主包「包含」的是子应用的「引用方式 + 加载方式」，不包含子应用的真实实现代码。 子应用代码始终在各自 remote 的 remoteEntry（及子应用自己的 chunk）里，按需加载。

5. 和 main 分支（loadScript 方案）的对比#

若要「主包完全不包含任何子应用 URL/名称」，需使用 main 分支的 loadScript 方案；若可接受主包内带 remote 的 URL 和占位逻辑，则 standard-mf 即可，且能享受标准 MF 的按需加载与类型声明（如 remotes.d.ts）。

6. 主包「零引用」是不是必要？实际优势在哪？#

结论：零引用不是必要能力，只是多了一种架构选择。是否值得做，取决于你是否需要下面这些能力。

7. shared 单例与 lodash：依赖是否打进各子应用包？#

在 apps 中安装 lodash，在 Module Federation 的 shared 里配置 单例，各应用均以按需引入方式使用（如 import get from 'lodash/get'、import capitalize from 'lodash/capitalize'、import sum from 'lodash/sum'），然后执行 pnpm build 观察构建产物。

四、mf/docs/CSS-ISOLATION.md#

1. 本项目采用的方案#

采用 「根节点包裹 + 选择器命名空间」 的构建时方案，在子应用（producer）侧完成隔离，与 Module Federation 官方建议一致。

2. 与业界 / 官方的一致性#

方向一致。

Module Federation 官方 Style Isolation 明确 不内置 CSS 隔离，原因包括：

• 与 shared 依赖复用冲突，隔离边界难以控制
• 运行时处理样式存在大量边界情况，排查困难
• Shadow DOM 与各类组件库兼容问题多

官方建议：

• 在 模块/子应用生产者（producer）侧 处理 CSS，保证在任意消费环境中表现一致
• 可选用：CSS Modules、组件库前缀、统一版本，或直接导出 Shadow DOM 组件

本项目的「wrapper + postcss-selector-namespace」即在 producer 构建时 处理 CSS，与上述建议一致；「根节点包裹 + 选择器命名空间」也是 MF 与微前端社区常见做法之一。

3. 常见方案对比#

4. 本方案优缺点小结#

5. 结论#

当前 CSS 隔离方案与业界常见做法及 Module Federation 官方「在 producer 侧、构建时处理样式」的建议一致；采用「根节点包裹 + postcss-selector-namespace」在隔离强度、兼容性和实现复杂度之间取得较好平衡，适合作为本 MF demo 的默认方案。

五、mf/docs/BRIDGE-HETEROGENEOUS.md#

1. 为什么需要 Bridge？#

Module Federation 本身只做「模块加载 + 共享依赖」，不关心具体前端框架。不同框架（Vue / React）的组件无法互相直接渲染，因此需要一层应用级契约：

• Remote 不直接导出组件，而是导出一个 Provider：提供 render(dom) 与 destroy(dom)，在给定 DOM 上挂载/卸载应用。
• Host 只负责：准备一个 DOM 容器 → 加载远程模块 → 调用 render(dom)，卸载时调用 destroy(dom)。

这样 Host 与 Remote 通过「DOM + 生命周期」对接，与具体框架无关。Module Federation 官方将这套契约的实现称为 Bridge。

2. 本仓库中的实现#

1
import App from './App';
2
import { createBridgeComponent } from '@module-federation/bridge-react';
3

4
export default createBridgeComponent({
5
        rootComponent: App,
6
});

1
<script setup lang="ts">
2
import * as bridge from '@module-federation/bridge-vue3';
3
import { getRemoteComponent } from '../framework/micro';
4

5
const Remote3App = bridge.createRemoteAppComponent({
6
        loader: () => getRemoteComponent('remote3', 'export-app'),
7
        rootAttrs: { class: 'remote3-root' },
8
});
9
</script>
10

11
<template>
12
        <div class="remote3-wrapper">
13
                <Remote3App basename="/remote3" />
14
        </div>
15
</template>

3. 业界最佳实践摘要#

1. 各用各的 shared

   • Host（Vue）只共享 vue、vue-router、pinia 等。
   • React Remote 只共享 react、react-dom 等。
   • 不要跨框架共享 UI 库；通用库（如 lodash）可按需在两边都声明 shared。

2. Bridge 契约

   • Remote 使用 createBridgeComponent 导出应用级模块（含根组件与可选路由）。
   • Host 使用 createRemoteAppComponent 的 loader 加载该模块，由 Bridge 负责在容器 DOM 上挂载/卸载。

3. 路由

   • Bridge 支持通过 basename、memoryRoute 等与主应用路由协作。
   • 若 React 子应用使用 React Router，可在构建侧开启 enableBridgeRouter，由 Bridge 注入 basename 与路由上下文。

4. 生命周期

   • 挂载：Host 提供 DOM → 调用 provider.render(dom) → 子应用挂载。
   • 卸载：路由离开或组件销毁时调用 provider.destroy(dom)，避免重复挂载与内存泄漏。

4. 参考#

• Module Federation - Bridge Overview
• React Bridge - Export / Load App、Load App
• Vue Bridge (Vue 3)

六、mf/docs/SHARED-DEPENDENCIES-PITFALLS.md#

坑一：版本冲突#

1
cd mf && pnpm install
2
pnpm dev

坑二：幽灵依赖#

解决方案概览#

1
{
2
        "pnpm": {
3
                "overrides": {
4
                        "vue": "3.4.x",
5
                        "vue-router": "4.2.x",
6
                        "pinia": "2.1.x",
7
                        "element-plus": "2.4.x"
8
                }
9
        }
10
}

本仓库相关文件#

• 运行 pnpm run shared-manifest 可重新生成 shared-manifest.json。
• 运行 pnpm run validate-shared 可查看每个 shared 依赖被谁消费及按应用汇总。

七、micro-app/README.md#

Micro-App 实现方式简述#

• 技术原理：基于 WebComponents，通过 CustomElement 定义 <micro-app> 标签，结合 自定义 Shadow DOM 加载子应用 HTML，在沙箱中执行子应用 JS、隔离样式。
• 加载方式：主应用通过 <micro-app name="xxx" url="子应用 index.html 地址" /> 嵌入子应用；url 必须指向子应用的 index.html，micro-app 会解析 HTML 并补全静态资源（js、css）地址。
• 子应用改造：子应用只需 支持跨域（如 Vite server.cors: true）；可选在微前端环境下使用 window.__MICRO_APP_BASE_ROUTE__ 设置 Vue Router / React Router 的 base，以配合主应用路由。
• 与 MF / Wujie 对比：见下方表格。

运行方式#

1
# 在 micro-app 目录下
2
pnpm install
3
pnpm dev

会并行启动：Host http://localhost:5000；**Remote1** 5001；Remote2 5002；Remote3 5003。浏览器访问 http://localhost:5000，通过主导航切换「首页 / About / 样式隔离 / Remote1 PageA·PageB / Remote2 Dashboard / Remote3」。

也可单独启动：pnpm dev:host、pnpm dev:remote1 等。

三种微前端方案对比#

目录结构#

micro-app/ 下 apps/host、remote1、remote2、remote3；docs/STYLE-ISOLATION.md；package.json；pnpm-workspace.yaml；README.md。

关键实现要点#

1. 主应用 (host)：安装 @micro-zoe/micro-app，在 main.ts 中执行 microApp.start()。Vue 3 需在 Vite 的 vue 插件中配置 compilerOptions.isCustomElement: (tag) => tag === 'micro-app'。各子应用页面对应一个路由组件，使用 <micro-app name="唯一名" :url="子应用 index.html 地址" default-page="子应用内路径" />。Vite 子应用需使用 iframe 沙箱：本 demo 在 main.ts 中已配置 microApp.start({ iframe: true })。
2. 子应用 (remote1/2/3)：普通 Vite 项目，配置 server.port 与 server.cors: true。无需强制改造入口；若需与主应用路由一致，可在创建 router 时使用 window.__MICRO_APP_BASE_ROUTE__ || '/' 作为 base。
3. 与 mf / wujie 的对比：MF 主应用和子应用可共享 Vue/Router/Pinia 等运行时。Wujie 主、子 iframe 隔离，通信靠 props、bus。Micro-App 主、子在同一文档下的 Shadow DOM 与沙箱中，可依赖数据通信 API（如 microApp.setData、子应用 window.microApp.addDataListener）做通信。

子应用使用 Host 的 Pinia#

因 micro-app 下主、子应用 JS 隔离，子应用不能直接 import('host/store')。本 demo 通过 micro-app 数据通信 同步：主应用在 useSubAppState.ts 中 setupHostStoreSync() 订阅 Pinia，store 变化时对各个子应用 name 调用 microApp.setData(name, { hostStore: { count, userName } })；监听各 <micro-app> 的 @datachange，若 data.type === ‘host’ 则执行 store 的 increment / setUserName。子应用在 composable（Vue）或 hook（React）中 window.microApp.addDataListener 更新本地 ref/state；按钮调用 window.microApp.dispatch({ type: 'host:action', payload })。子应用侧封装：useHostStore()。

Host 使用子应用的状态#

子应用内部维护自己的状态（如 remote1 的 localCount、message，remote2 的 statsClicks），在变化时通过 dispatch 上报：子应用 window.microApp.dispatch({ type: 'remote1:store', localCount, message })；主应用在各 <micro-app> 上监听 @datachange，在 useSubAppState() 的 handleDatachange 中解析 data.type，更新 remote1State / remote2State，在顶部「子应用状态」面板展示。

样式隔离#

主应用导航中提供「样式隔离」（路由 /style-isolation）。方案说明见 docs/STYLE-ISOLATION.md。要点：默认（scopecss 开启）子应用选择器加 micro-app[name=xxx] 前缀，防子 → 主；不防主 → 子（with 沙箱时）。iframe 沙箱（本 demo）主/子应用分属不同文档，样式天然双向隔离。disable-scopecss 关闭样式隔离，可提升性能，需避免应用间类名冲突。

参考#

• Micro-App 官方文档
• GitHub @micro-zoe/micro-app

八、micro-app/docs/STYLE-ISOLATION.md#

一、Micro-App 默认行为（scopecss 开启）#

• 子应用 → 主应用：框架会为子应用加载的 CSS 选择器添加 micro-app[name=xxx] 前缀，使子应用的样式只作用于对应的 <micro-app> 容器内部，从而 防止子应用样式泄漏到主应用，避免与主应用或其它子应用的类名冲突。
• 主应用 → 子应用：该机制 不能阻止主应用样式影响子应用。主应用文档中的全局样式（如标签选择器 div、p，或未加前缀的类选择器）仍可能命中子应用根下的 DOM（在 with 沙箱下子应用与主应用同文档），造成主应用「污染」子应用。

因此，若使用 with 沙箱，建议主应用尽量保持样式收敛（如仅使用 scoped、BEM 或主应用统一前缀），或通过约定/工具给主应用选择器加前缀。

二、disable-scopecss：关闭样式隔离#

• 配置方式：在 microApp.start() 中传入 'disable-scopecss': true 全局关闭，或在单个 <micro-app> 上设置 disable-scopecss 属性。
• 效果：子应用 CSS 不再添加 micro-app[name=xxx] 前缀，子应用样式可能影响主应用及其它子应用。
• 适用场景：需要提升渲染性能、且能保证各应用之间无类名/选择器冲突时；或需要子应用样式覆盖主应用某区域时（慎用）。

三、沙箱模式对样式的影响#

本 demo 使用 iframe 沙箱（microApp.start({ iframe: true })），主应用与子应用分属不同文档，因此 主/子应用样式天然互不影响，无需依赖 scopecss 即可实现双向隔离。scopecss 在 iframe 模式下仍会对子应用内部样式做前缀处理，但对「主 ↔ 子」隔离无额外影响。

四、常见问题与建议#

1. 主应用样式影响到子应用（with 沙箱）：给主应用样式加统一前缀（如 PostCSS 插件），或使用 Vue scoped / CSS Modules，减少全局选择器；或改用 iframe 沙箱。
2. 子应用样式影响到主应用：保持 scopecss 开启（默认）；若关闭，需保证子应用类名与主应用不冲突，或子应用自身使用 BEM/前缀。
3. 弹窗、抽屉等挂到 body 的组件：若挂载到主文档 body，会受主应用样式影响；可考虑挂到子应用根节点内，或通过主应用提供的「全局弹窗」能力由主应用渲染。
4. 性能：关闭 disable-scopecss 可减少样式处理开销，在确认无冲突前提下可按需开启。

五、与其它微前端方案对比#

六、本 demo 中的演示#

主应用导航中提供「样式隔离」入口（/style-isolation），内含方案说明摘要、主应用区域与子应用区域的并排演示（iframe 沙箱下两区域样式互不污染）、与其它方案的对比表。详细方案说明以本文档为准。

九、micro-app/docs/SANDBOX-AND-ESCAPE-ANALYSIS.md#

一、沙箱实现思路对比#

二、逃逸问题处理方式对比#

• 沙箱逃逸：子应用访问或修改到真实 window/document 或其它子应用环境，导致隔离失效。合理逃逸：某些全局单例必须挂在真实 window 上，需要「受控逃逸」。
• Qiankun：set 只写 fakeWindow，防污染；但 get 的 fallback 与 bound 带来不可配置属性、同名变量等边界问题（如 Issue #2456）。
• Micro-App：显式逃逸列表 escapeProperties/staticEscapeProperties；set 这些 key 时同时 Reflect.set(rawWindow)，并加入 escapeKeys；卸载时遍历 escapeKeys 执行 deleteProperty(rawWindow)，恢复主应用环境。scopeProperties（如 Vue、webpackJsonp、onpopstate）只在 microAppWindow 上读写。injectedKeys 与 escapeKeys 在卸载时分别从 microAppWindow 和 rawWindow 上 delete。逃逸路径明确，更容易控制和排查。

三、性能对比#

结论：Micro-app 显式逃逸列表 + 按需读 rawWindow，沙箱边界清晰度与逃逸可控性更优；iframe 沙箱下性能和隔离都最好。Qiankun 在读路径上的 fallback、bound 以及不可配置属性、压缩后同名变量等场景下，逃逸与兼容问题更复杂。

十、wujie/README.md#

运行方式#

1
# 在 wujie 目录下
2
pnpm install
3
pnpm dev

会并行启动：Host http://localhost:4000；**Remote1** 4001；Remote2 4002；Remote3 4003。浏览器访问 http://localhost:4000，通过主导航切换「首页 / About / Remote1 PageA·PageB / Remote2 Dashboard / Remote3」。也可单独启动：pnpm dev、pnpm dev 等。

Wujie 与 MF 的差异#

目录结构#

wujie/ 下 apps/host、remote1、remote2、remote3；package.json；pnpm-workspace.yaml；README.md。

关键实现要点#

1. 主应用 (host)：使用 wujie-vue3，在 main.ts 中 app.use(WujieVue)。各子应用页面对应一个路由组件，使用 <WujieVue name="唯一名" :url="子应用完整 URL" :alive="true" />。
2. 子应用 (remote1/2/3)：普通 Vite 项目，配置 server.port 与 server.cors: true。无需 Wujie 生命周期改造。主应用通过不同 path 加载不同页面。
3. 与 mf 的对比：MF 主应用和子应用共享 Vue/Router/Pinia；Wujie 主、子应用隔离，若需通信可使用无界 bus 或主应用通过 props 向子应用传参。

子应用使用 Host 的 Pinia#

因 iframe 与主应用 JS 隔离，不能直接 import(‘host/store’)。本 demo 通过 bus 事件 同步：Host 在 bus/index.ts 中订阅 Pinia，store 变化时 bus.$emit('host:store', { count, userName })；监听 host:action、host:requestStore。子应用 bus.$on(‘host’, …) 更新本地 ref/state，按钮调用 bus.$emit(‘host’, { type, payload })。子应用侧封装：useHostStore()。

Host 使用子应用的状态#

子应用在变化时通过 bus 上报：bus.$emit('remote1:store', { localCount, message })（remote2 同理）。Host 在 useSubAppState() 中 bus.$on(‘remote1’, …) / bus.$on(‘remote2’, …)，将结果展示在顶部「子应用状态」面板。

全局弹窗（iframe 方案下的常见痛点）#

在 iframe 内写的弹窗只能盖住该 iframe 区域。本 demo：弹窗由主应用提供，在 Host 中挂载 <GlobalModal />（Teleport to=“body”），监听 bus 事件 global / global。子应用只负责「发起」：bus.$emit(‘global’, { title, content })；主应用在主文档中渲染遮罩和弹窗，可覆盖整个视口。

参考#

• 无界官方文档
• wujie-vue3