Module Federation 共享 Effector 跨框架状态-北京尧图网络

开头先从一个真实到不能再真实的场景说起React 团队维护商品详情页Vue3 团队维护购物车浮层两边都要显示同一个已加购 X 件的角标。你点了详情页的加购按钮数字动了切到浮层数字还是旧的。原因很简单——两套状态树各跑各的。这个标题里的module-federation-examples思路本质上就是在解决这类多个框架各自为政的状态撕裂问题而 Effector 恰好是少数几个能把 store 从框架里彻底剥离出来的状态管理库。我下面要讲的是怎么用 Module Federation 把一份 Effector store 作为运行时共享单元暴露出去让 React 18 和 Vue3 两个消费端订阅同一份实例、触发同一批事件、拿到同一个结果。适合已经上手过 Webpack 模块联邦、但对跨框架共享运行时状态还停留在事件总线或者window.xxx阶段的前端同学。文中所有代码都能在你的本地环境跑起来包括那些我第一次接的时候踩到怀疑人生的坑——比如明明配了shared两边状态就是不联动最后发现是 Effector 被打了两份。1. 两个框架两套状态从一次角标不刷新的事故说起1.1 微前端里最容易被低估的成本是状态撕裂先说清楚问题的形状。假设你有一个主应用React和一个子应用Vue3它们通过模块联邦拼在一起。主应用负责商品详情子应用负责购物车浮层。两个应用都需要购物车里有几件商品这个数据。最常见的三种做法各有各的毛病各存各的React 用useState或者 ZustandVue 用ref或者 Pinia。加购之后两边谁也不知道对方改了只能靠轮询接口或者刷新页面。用户体验上是断的。事件总线在window上挂一个EventTarget谁改了状态就dispatchEvent一下。这个方案能跑但一旦状态结构复杂起来比如购物车项要增删改、要算总价、要做乐观更新你就会写出一堆手动同步的胶水代码而且时序问题极难排查——事件什么时候发、发几次、监听器有没有重复注册全靠人肉保证。只放在宿主应用里远端通过 props 或者回调传这在组件嵌套层级深的时候会变成典型的 prop drilling而且 Vue 组件被 React 渲染的时候传 props 的边界非常别扭。这三种方案的共同问题是状态的所有权和框架的渲染边界被绑死了。谁的组件树在跑状态就归谁管。一旦跨框架就必须有人做翻译。Effector 的价值就在这里。它的store、event、effect是一套完全独立于任何 UI 框架的运行时对象React 的useUnit和 Vue 的useUnit只是在这个运行时上做了一层订阅适配。换句话说store 是数据源两个框架的 hook 是两种不同的插头插的是同一个插座。这个特性在单框架项目里不太显眼因为你只会用其中一种插头。但在模块联邦多框架的场景里它就是整套方案能不能成立的地基。1.2 为什么不是 Redux、不是 Pinia、不是 Zustand有人会问Redux 也能跨框架用啊。理论上是的redux核心包和react-redux是分开的Vue 也有对应的绑定。但实际用起来有几个明显的摩擦点方案框架无关性跨框架绑定成熟度订阅粒度控制运行时共享难度Redux Toolkit核心无关但createSlice生态偏 ReactVue 侧绑定库维护活跃度一般需要useSelector 手写比较中需要处理 store 单例Pinia强依赖 Vue 响应式系统基本没有 React 侧方案Vue 原生高几乎绑死 VueZustand核心无关React 为主其他框架需自适配selector 友好中Effector完全无关自带响应式内核官方维护 React / Vue / Svelte 绑定useUnit selector低天然单例友好关键在最后一列。Effector 的 store 实例本身没有必须挂载到某个框架的概念effector-react和effector-vue只是消费者。这意味着只要你能保证两边拿到的是同一个 effector 模块实例状态就是同一份。而这恰好是模块联邦shared: { singleton: true }能保证的事。反过来说Pinia 就别想了它的 store 建立在 Vue 的reactive之上React 侧根本订阅不了。Redux 可以但你要自己处理useSelector的引用比较和批量更新在跨框架场景下调试成本会翻倍。所以选型结论很直接跨框架共享状态Effector 是目前心智负担最低的选择。下面所有的坑基本都是工程配置层面的不是模型层面的。2. Effector 的框架无关内核一份 store 如何被两个框架同时消费2.1 domain、store、event 的订阅模型到底长什么样先把这个内核讲透不然后面排查问题你会抓瞎。Effector 内部有一张计算图graph。每次你调用createStore、createEvent、createEffect都会往这张图里加节点。节点之间通过.on()、.map()、sample()、combine()建立边。当你调用一个 event值会沿着边往下游传播最终通知所有订阅了这个 store 的监听器。这里有个非常关键的点这张图是模块级的不是组件级的。你import一个 store拿到的是图里的一个节点引用。无论在 React 组件里还是在 Vue 组件里useUnit它本质上都是往这个节点上注册一个订阅回调。所以跨框架共享这件事在 Effector 的语义里根本不是一个特殊场景——它天然支持。真正的问题只剩下一个两个应用拿到的是不是同一个模块实例。模块联邦解决的正是这个问题Webpack 在运行时维护一个共享容器share scope所有标记为singleton的包第一次被请求时求值一次之后所有消费方拿到的都是同一份导出对象。如果没配singleton或者版本没对齐Webpack 会给你两份独立的模块两张独立的计算图状态自然不联动。我写一个最小的心智模型帮你记住Effector 的计算图一个全局单例对象。模块联邦的singleton保证的就是这个全局只存在于运行时一次。2.2 effector-react 和 effector-vue 的 useUnit 差异在哪两个绑定库的 API 名字一样行为有细微差别这些差别会直接影响你写代码的方式。React 侧import { useUnit } from effector-react import { $count, $items, addItem } from cart-store function Badge() { // 数组形式返回元组顺序对应传入顺序 const [count, items, onAdd] useUnit([$count, $items, addItem]) return span onClick{() onAdd({ id: 1, title: x, price: 9.9 })}{count}/span }useUnit在 React 里返回的是普通值。组件在 store 更新时通过useSyncExternalStore新版本触发重渲染。你需要注意两点一是传数组比多次调用useUnit更好因为多次调用会注册多个订阅虽然最终合并成一次渲染但内部开销更大二是这个 hook 必须在组件顶层调用不能放在条件分支里。Vue3 侧script setup langts import { useUnit } from effector-vue/composition import { $count, $items, addItem } from cart-store const count useUnit($count) // 返回 Refnumber const items useUnit($items) // 返回 RefCartItem[] const onAdd useUnit(addItem) // 返回普通函数 /script template span clickonAdd({ id: 1, title: x, price: 9.9 }){{ count }}/span /template注意effector-vue/composition这个子路径——如果你从effector-vue根路径导入拿到的是 Options API 时代的useStore、useEvent甚至可能直接报找不到导出。这是我在第一次接的时候卡了快半小时的地方文档里两个路径都提了但没写清哪个对应哪个。Vue 的useUnit返回Ref模板里会自动解包但在script里你要用.value访问。另外useUnit内部用的是watchEffectonScopeDispose所以只能在setup同步执行阶段调用放在setTimeout或者await之后调用会丢失作用域监听器不会被自动清理逐渐泄漏。还有一个差别React 的 hook 重渲染粒度和组件绑定Vue 的 ref 更新粒度是谁用了这个 ref 谁更新。理论上 Vue 侧的重渲染控制更精细但如果你在computed里同时读了好几个 ref那还是会一起触发需要拆分。2.3 共享包的边界应该怎么切这个决定影响后续所有维护成本。我的建议是三层切分cart-store/ ├─ src/ │ ├─ model.ts // 纯 effector 模型store / event / effect │ ├─ index.ts // 对外导出model 组合 hook 的纯函数版本 │ └─ types.ts // 所有跨边界的类型 ├─ package.json // peerDependencies: effector └─ tsconfig.jsonmodel.ts里只放 Effector 原语不 import 任何框架相关的东西。index.ts里可以放一些框架无关的选择器函数比如// index.ts export * from ./model export type { CartItem } from ./types export const selectIsEmpty (items: CartItem[]) items.length 0为什么不直接把useUnit封装好一起导出因为一旦index.ts里import { useUnit } from effector-react这个包就被钉死在 React 上了Vue 侧引入会直接报模块找不到。正确的做法是让两个消费端各自引入自己的绑定库共享包只提供数据。如果你的项目里确实想少写重复代码可以在index.ts之外再开一个react.ts和vue.ts子入口通过package.json的exports字段导出{ name: cart-store, exports: { .: ./dist/index.js, ./react: ./dist/react.js, ./vue: ./dist/vue.js }, peerDependencies: { effector: ^23.0.0, effector-react: ^23.0.0, effector-vue: ^23.0.0 }, peerDependenciesMeta: { effector-react: { optional: true }, effector-vue: { optional: true } } }peerDependenciesMeta里把两个绑定库标为可选这样任何一个消费端不装另一侧的绑定也不会触发 npm 警告。这个小细节在 monorepo 里能省掉一堆噪音。3. Module Federation 的共享契约exposes 与 shared 怎么配才不留隐患3.1 host 和 remote 的角色划分在跨框架场景下谁是 host、谁是 remote 其实取决于加载方向。我的 Demo 里采用双向结构react-host端口 3001承载商品详情页同时通过 remote 加载 Vue 的购物车浮层。vue-remote端口 3002独立运行时可作为购物车应用被 host 加载时暴露mount函数。关键点在于两个应用都要把cart-store和effector放进shared。任何一个漏了就会变成两份。目录结构mf-effector-demo/ ├─ packages/ │ └─ cart-store/ │ ├─ src/model.ts │ ├─ src/index.ts │ └─ src/types.ts ├─ apps/ │ ├─ react-host/ │ │ ├─ src/App.tsx │ │ ├─ src/bootstrap.tsx │ │ └─ webpack.config.js │ └─ vue-remote/ │ ├─ src/main.ts │ ├─ src/CartBadge.vue │ ├─ src/mount.ts │ └─ webpack.config.js └─ package.json注意react-host里我把入口拆成了bootstrap.tsx和index.tsx两个文件。这是模块联邦的经典写法因为shared是异步加载的入口里直接importReact 会报 shared module is not available for eager consumption。后面第 5 节会细说这个错误的排查。3.2 shared 里的 singleton 是这套方案的生死线直接上配置。先看 host 侧// apps/react-host/webpack.config.js const { ModuleFederationPlugin } require(webpack).container module.exports { entry: ./src/index.tsx, output: { publicPath: auto, uniqueName: reactHost }, plugins: [ new ModuleFederationPlugin({ name: reactHost, filename: remoteEntry.js, remotes: { vueRemote: vueRemotehttp://localhost:3002/remoteEntry.js, }, exposes: { ./CartHostApi: ./src/cartHostApi.ts, }, shared: { effector: { singleton: true, eager: true, requiredVersion: ^23.0.0, strictVersion: true, }, cart-store: { singleton: true, eager: true, requiredVersion: ^1.0.0, strictVersion: true, }, react: { singleton: true, requiredVersion: ^18.2.0 }, react-dom: { singleton: true, requiredVersion: ^18.2.0 }, }, }), ], }再看 Vue 侧// apps/vue-remote/webpack.config.js const { ModuleFederationPlugin } require(webpack).container const { VueLoaderPlugin } require(vue-loader) module.exports { entry: ./src/main.ts, output: { publicPath: auto, uniqueName: vueRemote }, plugins: [ new VueLoaderPlugin(), new ModuleFederationPlugin({ name: vueRemote, filename: remoteEntry.js, exposes: { ./CartBadge: ./src/mount.ts, }, shared: { effector: { singleton: true, eager: true, requiredVersion: ^23.0.0, strictVersion: true, }, cart-store: { singleton: true, eager: true, requiredVersion: ^1.0.0, strictVersion: true, }, vue: { singleton: true, requiredVersion: ^3.4.0 }, }, }), ], }几个参数必须解释清楚singleton: true告诉 Webpack 这个模块在整个运行时的 share scope 里只能有一份实例。这是整套方案的核心。没有它host 会用自己的cart-storeremote 会根据自己的依赖解析出一份两边各自求值两张计算图。eager: true让这个共享模块在初始化阶段就被求值而不是等到第一次import时。对effector和cart-store这类需要在应用启动时就建立计算图的包必须开。不开的话Vue 应用可能先于 React 加载导致 share scope 里先注册的是 Vue 那份行为虽然通常正确但在热更新场景下容易出幺蛾子。requiredVersion申明消费方预期的版本区间。如果运行时提供的版本不在区间内Webpack 会给出警告或者strictVersion时直接抛错。strictVersion: true开发阶段强烈建议开。它会让版本不匹配从静默降级变成显式报错避免你花半天时间排查为什么状态不联动结果发现是版本错位。3.3 版本对齐这件事比你想的脆弱effector、effector-react、effector-vue这三个包的版本号是严格对齐的。effector-react23依赖effector23的内部实现跨大版本混用会出问题——不是编译报错是运行时行为诡异比如订阅注册了但回调不触发。我的做法是在根目录的package.json里用overridesnpm 8或者resolutionsyarn强制统一{ overrides: { effector: 23.x, effector-react: 23.x, effector-vue: 23.x } }同时cart-store的peerDependencies里写effector: ^23.0.0而不是dependencies。写进dependencies的风险是打包时会把它内联进来即使模块联邦配了shared构建产物体积也会膨胀而且某些配置下会绕开共享容器。注意如果你在cart-store里把effector写成了dependencies并且被打进了 bundle那shared配置对它就完全失效了——因为它在构建期已经被内联运行时根本不会去 share scope 里查找。这是配了 singleton 但不生效最常见的原因之一。排查方法后面会讲先记住一条纪律任何需要跨应用共享的运行时包都必须是 peerDependency。4. 把 Demo 跑起来React 与 Vue3 两个消费端的完整接入4.1 共享 store 的模型定义先写model.ts这里决定了两个框架能拿到什么// packages/cart-store/src/model.ts import { createDomain, createEffect } from effector import type { CartItem } from ./types export const cartDomain createDomain(cart) export const addItem cartDomain.createEventCartItem() export const removeItem cartDomain.createEventstring() export const setQuantity cartDomain.createEvent{ id: string; quantity: number }() export const clearCart cartDomain.createEvent() export const fetchCartFx createEffect(async (userId: string) { const res await fetch(/api/cart?user${userId}) return (await res.json()) as CartItem[] }) export const $items cartDomain .createStoreCartItem[]([]) .on(addItem, (items, item) { const existing items.find((i) i.id item.id) if (existing) { return items.map((i) (i.id item.id ? { ...i, quantity: i.quantity 1 } : i)) } return [...items, { ...item, quantity: 1 }] }) .on(removeItem, (items, id) items.filter((i) i.id ! id)) .on(setQuantity, (items, { id, quantity }) items.map((i) (i.id id ? { ...i, quantity } : i)) ) .on(clearCart, () []) .on(fetchCartFx.doneData, (_, items) items) export const $count $items.map((items) items.reduce((sum, i) sum i.quantity, 0) ) export const $total $items.map((items) items.reduce((sum, i) sum i.price * i.quantity, 0) )用createDomain而不是零散的createStore好处是同一个 domain 下的所有单元共享一个命名空间和生命周期调试时在 DevTools 里能一眼看到这个 domain 下的全部 store也会自动带上cart/前缀。跨应用共享的时候这个前缀特别有用——你在日志里看到cart/$count changed就知道是哪个 domain 发出的。$count和$total用.map派生。这里有个性能细节.map创建的是一个新的派生 storeEffector 会做缓存——只有源 store 引用变化时才重算。所以你在组件里订阅$total不会因为$items里某个无关字段变了就重算。但要注意$items的更新必须是不可变的上面的.on里全都返回了新数组这是必须遵守的纪律。如果直接items.push(...)然后返回原引用派生 store 不会更新你会得到点了加购但总价不变的经典 bug。4.2 React 侧用 useUnit 订阅用 mount 桥接 VueReact 这里没什么特别的就是标准的useUnit// apps/react-host/src/CartPanel.tsx import { useUnit } from effector-react import { $items, $count, $total, addItem, removeItem, clearCart } from cart-store export function CartPanel() { const [items, count, total] useUnit([$items, $count, $total]) const [onAdd, onRemove, onClear] useUnit([addItem, removeItem, clearCart]) return ( div header已加购 {count} 件合计 ¥{total.toFixed(2)}/header ul {items.map((item) ( li key{item.id} {item.title} × {item.quantity} button onClick{() onRemove(item.id)}移除/button /li ))} /ul button onClick{() onAdd({ id: sku-1, title: 示例商品, price: 39.9 })} 加购 /button button onClick{() onClear()}清空/button /div ) }再写一个桥接组件把 Vue 的浮层挂进来// apps/react-host/src/VueCartBadge.tsx import { useEffect, useRef } from react export function VueCartBadge() { const hostRef useRefHTMLDivElement(null) useEffect(() { let dispose: (() void) | undefined let cancelled false import(vueRemote/CartBadge).then((mod) { if (cancelled || !hostRef.current) return dispose mod.mount(hostRef.current) }) return () { cancelled true dispose?.() } }, []) return div ref{hostRef}>script setup langts import { useUnit } from effector-vue/composition import { $items, $count, $total, removeItem, clearCart } from cart-store const items useUnit($items) const count useUnit($count) const total useUnit($total) const onRemove useUnit(removeItem) const onClear useUnit(clearCart) /script template aside classcart-badge span{{ count }}/span span¥{{ total.toFixed(2) }}/span ul v-ifitems.length li v-foritem in items :keyitem.id {{ item.title }} × {{ item.quantity }} button clickonRemove(item.id)移除/button /li /ul button v-else clickonClear清空/button /aside /template暴露给 React 的mount.ts// apps/vue-remote/src/mount.ts import { createApp, type App } from vue import CartBadge from ./CartBadge.vue export function mount(el: HTMLElement): () void { const app: App createApp(CartBadge) app.mount(el) return () { app.unmount() } }注意这里没有往mount.ts里引任何 effector 相关的东西。看起来多余其实很关键如果你在mount.ts里import { createEvent } from effectorWebpack 在构建 remote 的exposes时会把 effector 当成一个普通依赖处理。虽然配了shared之后它最终还是会走共享容器但eager和singleton的求值顺序在一些边缘场景下会出问题。保持exposes入口尽可能薄只做挂载这一件事是降低风险的有效手段。还有一个坑CSS 污染。Vue 单文件组件里的style默认是全局的挂到 React 页面里会污染宿主样式。解决方案是用style scoped或者干脆用 CSS Module。我在 Demo 里用的是style module因为 scoped 在跨框架挂载时偶尔会因为>// 临时诊断代码上线前删掉 if (typeof window ! undefined) { const w window as any w.__effectorBootCount (w.__effectorBootCount ?? 0) 1 console.log([effector] model evaluated, count , w.__effectorBootCount) }打开页面看 console。如果打印了两次model evaluated说明cart-store被打成了两份问题基本锁定。第二步确认 effector 本身是不是两份。在model.ts里再打一个探针这次打的是 effector 模块本身import { createDomain } from effector import * as effectorModule from effector if (typeof window ! undefined) { const w window as any w.__effectorModules w.__effectorModules ?? new Set() w.__effectorModules.add(effectorModule) console.log([effector] module instances , w.__effectorModules.size) }用Set存模块对象引用如果 size 变成 2说明effector包被加载了两次——即使配了singleton。这时候要看的是effector是不是被写进了cart-store的dependencies而不是peerDependencies。两个应用的shared配置里effector的requiredVersion是否一致。如果 host 写^23.0.0、remote 写^22.0.0Webpack 会认为它们不兼容各加载一份。有没有哪个应用漏配了shared.effector。第三步验证运行时 share scope。Webpack 5 在浏览器全局挂了一个__webpack_share_scopes__对象可以直接在 console 里查Object.keys(window.__webpack_share_scopes__.default.effector)如果返回的版本 key 有多个比如23.0.0和22.8.0各一个就是版本不统一。如果只有一个但size还是 2那基本可以确定是某个应用把 effector 内联进 bundle 了——去检查那个应用的package.json把effector从dependencies挪到peerDependencies并在构建配置里用externals或者shared正确声明。我第一次遇到这个问题排查了将近两个小时最后发现是cart-store在package.json里把effector写成了dependencies且cart-store被两个应用各自从本地路径 link 了一份。改成 peer 统一提升到根node_modules之后立刻正常。5.2 HMR 之后 store 被重置模块热替换的重建陷阱开发阶段开着 devServer 的时候你改了model.ts里一行代码页面热更新了然后你发现购物车清空了。这不是 bug是 HMR 的正常行为——model.ts被重新求值createStore重新执行状态回到初始值。问题在于两个应用的 HMR 行为可能不一致。host 的model.ts更新了remote 那边还是旧模块引用就会出现React 侧是新的计算图、Vue 侧还是旧的计算图两边彻底断开。更恶心的是它不会报错只是状态对不上。几种缓解手段在model.ts末尾加 HMR 接受逻辑让状态在热更新时保留if (process.env.NODE_ENV development module.hot) { const snapshot $items.getState() module.hot.dispose(() { ;(window as any).__cartSnapshot snapshot }) module.hot.accept() const restored (window as any).__cartSnapshot if (restored) $items.setState(restored) }注意这段代码只在cart-store被单独热替换时有效。如果它是通过模块联邦的shared加载的HMR 的行为会更复杂——Webpack 对 shared 模块的热替换支持一直是半吊子状态。更务实的做法接受重启。改cart-store的模型代码时手动刷新浏览器。跨应用共享的模型改动频率本来就不高为了省一次刷新去搞 HMR 保活投入产出比不划算。我在项目里的做法是给cart-store单独配一条 dev 命令改模型时两个应用同时重启比修 HMR bug 快多了。另一个容易忽略的点如果你用eager: truecart-store会在应用启动时就求值。这时候热更新触发的是整个 share scope 的重建两个应用会同时重建反而比非 eager 的情况更一致。这也是我建议对cart-store开eager的原因之一。5.3 消费端的类型全变成 any模块联邦在运行时是动态加载的但 TypeScript 在编译期完全不知道vueRemote/CartBadge是什么类型。默认情况下你会得到anyIDE 里点不进去参数写错了也不报错。这在跨团队协作里是个隐患——远端的mount签名改了消费方完全无感。解决方案有三种按工程量从轻到重方案一手写声明文件。在react-host/src下建一个remotes.d.tsdeclare module vueRemote/CartBadge { export function mount(el: HTMLElement): () void }简单粗暴但对于稳定不变的远端契约足够用。缺点是远端改了签名消费方必须手动同步没有编译期保障。方案二用module-federation/typescript自动生成。这个插件能在构建时把远端的.d.ts拉过来消费端直接享受类型检查。代价是构建链路多一个环节且对 monorepo 的路径配置比较敏感。我用过一段时间收益是有的但在 CI 环境里偶尔会因为网络或者路径问题失败需要额外容错。方案三把契约抽成独立的类型包。我目前最推荐这个。cart-store里已经有types.ts了把mount的签名也放进去// packages/cart-store/src/contract.ts import type { CartItem } from ./types export interface CartRemoteContract { mount(el: HTMLElement): () void } export interface CartHostApi { getSnapshot(): CartItem[] subscribe(fn: (items: CartItem[]) void): () void }两个应用都import type { CartRemoteContract } from cart-store然后mount.ts里用satisfies CartRemoteContract约束实现。这样远端实现和消费方引用的是同一个类型定义改契约时两边同时报错问题在编译期就暴露了不会拖到联调。这个方案的成本很低——类型文件本来就是共享包里的一部分顺手的事——但收益很高。我在一个三人协作的项目里推行这个做法之后联调发现接口对不上的情况基本消失了。6. 上生产前还得补的几件事6.1 订阅粒度决定了这套方案会不会拖慢性能useUnit的便利之处也是它的陷阱你在组件里订阅了$items那$items里任何一个商品的quantity变了整个组件都重渲染。在一个有二十个商品行的购物车里改一行数量会触发二十行加外层的重渲染。React 侧的控制手段是selectorimport { useUnit } from effector-react import { $items } from cart-store function CartRow({ id }: { id: string }) { // 第二个参数是 selector只在选出的值变化时重渲染 const item useUnit($items, (items) items.find((i) i.id id)) if (!item) return null return li{item.title} × {item.quantity}/li }注意 selector 返回的是对象引用。如果items.find(...)每次返回新对象Effector 会用比较引用变了就重渲染。所以上一节强调的不可变更新在这里有个反作用——你map出新数组、find出新的 item 对象引用必然变。要真正避免重渲染得在 model 里做细粒度拆分比如用createStore为每个 sku 单独维护一个 store或者用combine 一个稳定的 id 列表。实操上我的建议是默认不做极致优化先用useUnit跑通用 React DevTools 的 Profiler 看实际渲染次数超过 30ms 的渲染再去拆。过早拆细粒度 store 会让 model 变得难以理解维护成本远高于收益。真要优化优先优化$total这种派生计算——用combine替代多次.map链式能减少中间节点。Vue 侧的情况稍好因为useUnit返回的 ref 是细粒度响应式的但同样存在在同一个computed里读了多个 ref导致的合并触发。写的时候尽量一个 ref 对应模板里一个绑定位置。6.2 事件契约的版本管理跨团队共享 store 之后你会面临一个很现实的问题Vue 那个团队想给addItem加一个source字段但 React 那边暂时不传。如果直接在类型上改成必填React 侧立刻编译报错。我的做法是事件参数永远用对象且新增字段一律可选export interface AddItemPayload { id: string title: string price: number /** since 1.2 加购来源用于埋点默认 unknown */ source?: detail | list | unknown }配合上面的类型包两边的版本感知就有了。如果要做破坏性变更用exposes的子路径做并行版本exposes: { ./CartBadge: ./src/mount.ts, ./CartBadgeV2: ./src/mountV2.ts, }消费方可以渐进迁移不用一刀切。代价是维护成本翻倍所以破坏性变更的频率要严格控制——我给自己定的规矩是一年不超过两次其余的全靠可选字段向后兼容。还有一条纪律值得写进团队规范remote 永远不要主动修改 host 的 store除非通过暴露的 event。我在 review 代码时见过有人直接在 Vue 组件里$items.setState([])这等于绕过了所有on里定义的业务逻辑React 侧的派生 store 计算全乱。setState只应该在测试和 SSR 水合的时候用。6.3 调试、测试与回滚调试Effector 自带effector/babel-plugin能给每个单元自动加上name配合 DevTools 的日志面板能看到完整的事件流。跨应用共享时要确保两个应用用的是同一个 plugin 配置否则 name 对不上日志里一堆$store3这种自动生成的标识等于没开。线上排查建议挂一个轻量的日志上报import { createDomain } from effector if (process.env.NODE_ENV production) { cartDomain.onCreateStore((store) { store.watch((value) { // 只上报关键 store避免日志量爆炸 if (store.shortName $items) { reportToMonitor(cart.items.changed, { size: Array.isArray(value) ? value.length : 0 }) } }) }) }注意store.watch是同步的里面别做重活。上报用sendBeacon或者批量队列。测试Effector 的测试相对干净因为它不依赖组件渲染。直接测 modelimport { fork, allSettled } from effector import { $count, addItem, clearCart } from cart-store test(加购后数量增加, async () { const scope fork() await allSettled(addItem, { scope, params: { id: 1, title: x, price: 1 } }) expect(scope.getState($count)).toBe(1) await allSettled(clearCart, { scope }) expect(scope.getState($count)).toBe(0) })fork创建的是一份隔离的 scope不会污染全局状态。这是 Effector 相比 Redux 的一个明显优势——不需要 mock store不需要清理天然可并行执行。跨框架共享的 model 用这种方式测两个框架的消费端都不用起测试速度快得离谱。回滚模块联邦的回滚比普通应用复杂因为 host 依赖 remote 的remoteEntry.js运行时加载。我的做法是给remoteEntry.js加版本前缀/v1.4.2/remoteEntry.jshost 配置里引用固定版本号。出问题时把 host 的配置指回上一个版本即可不需要重新构建 host。这要求 CDN 或静态服务器保留历史版本成本不高但救命。最后分享几点实操体会这套方案我用了大概一年接了三四个跨框架的共享模块。最大的感受是技术选型的复杂度其实集中在前期配置真正的维护成本全在纪律上。Effector 的模型本身很好懂模块联邦的配置也只是一次性的但不许把 effector 写进 dependencies、事件参数必须用对象、remote 不许直接改 host 的 store这些规矩靠的是团队共识不是工具能强制的。另一个体会是先跑通最小闭环再谈优化。我见过有人一上来就搞细粒度 store 拆分、搞 SSR scope 传递、搞 type federation 自动生成结果卡在shared没配对导致状态不联动上折腾三天没跑起来一个 demo。正确顺序应该是一个$count、一个addItem、两个应用各显示一个数字能联动之后再往上加东西。这个最小闭环大概二十分钟能搭完跑通之后你会发现剩下的全是细节而且这些细节出问题时你有一个可对照的已知正确状态。如果后面要扩展我会优先考虑把cart-store做成一个独立的可发布包而不是 monorepo 里的本地目录。这样远端应用可以独立升级版本号本身就是契约的一部分比本地 link 一份代码可控得多。

Module Federation 共享 Effector 跨框架状态

相关推荐

YOLOv8改进模型在口腔疾病智能检测中的应用

工作流即契约：LLM规划+编译器生成的确定性SQL系统

CentOS7目录结构可视化与高效管理指南

更多资讯

碳交易机制下的综合能源优化调度：Matlab+YALMIP建模指南

从老旧Word文档到结构化题库：doc转docx与公式识别全流程

SLAM技术实战：从激光到视觉的工程优化

DeepSeek Harness桌面端：Node.js 20+驱动的本地LLM工作流系统

数字孪生技术在工业质量预测中的实践与应用

楼宇自动化控制系统(BA)设计与实施全解析

今日更新

学生选课系统DFD图绘制指南：边界划分与分层校验实战

JIRA敏捷落地：Scrum角色权限、Sprint与燃尽图避坑指南

SEMI S8人机工程验收实战：从条款拆解到现场实测的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？