网站做计算功能,wordpress query,西安手机网站建设,python flask做网站一、项目背景 目前#xff0c;我们开发维护的项目主要有 6 个#xff0c;但是分别对应 PC 和 H5 两个端#xff1a; 如上图所示#xff0c;我们 6个项目最开始是一个一个进行开发维护的#xff0c;但是到后期#xff0c;这几个项目之间有的部分会有业务逻辑不同#xff… 一、项目背景 目前我们开发维护的项目主要有 6 个但是分别对应 PC 和 H5 两个端 如上图所示我们 6个项目最开始是一个一个进行开发维护的但是到后期这几个项目之间有的部分会有业务逻辑不同UI 基本相似的情况出现。而这几个项目前端维护人员较少 这个时候就要考虑开发效率问题我们希望相同部分共用而不是每次都去项目里面进行复 制粘贴重写逻辑。我们引入微前端将相似的部分抽离出来创建一个仓库实现下图效果 但是上图也会造成一个问题就是我们每抽离一个模块需要单独申请一个仓库去进行维护 这样子维护起来也很麻烦我们在这个基础上进行改进引入 MonoRepoqiankun最终实 现下图效果。所有模块放在一个仓库中每次出现新的模块我们在这一个仓库下面去创建 项目只维护一个仓库但是可以在不同项目之间进行切换。 二、微前端方案技术选型 微前端架构旨在解决单体应用在一个相对长的时间跨度下由于参与的人员、团队 的增多、变迁从一个普通应用演变成一个巨石应用后随之而来的应用维护难成本越来越大的问题。 三、目前阶段流行的微前端方案 1、single-spa 在官网中被自称是一个元框架可以实现在一个页面将多个不同的框架整合。很多微前端方案基于此进行二次开发或者是灵感来源支持 esm。基本原理是把 render 函数和 mounted 函数等钩子暴露出来在远端引入后在合适的时机执行把组件挂载到 DOM 上。 缺点如果不是用成型的框架如 qiankun从 0 开始搭建比较繁琐。 优点技术栈无关对代码侵入性不强 2、qiankun 基于single-spa 的微前端解决方案,生产可用阿里出品。 目前在交易平台项目中订单模块投入使用。 具体代码可以参考购小店的订单模块和购小店的使用方式。 3、MicroApp 一种用于构建微前端应用的极简方案支持 esm需要关闭沙箱京东出品。 优点qiankun 更多的是用路由的方式引入microApp 更多是组件方式 官方文档比较全面开发文档比 qiankun 强多了。 4、emp 基于 Webpack5 Module Federation 搭建的微前端解决方案使用起来更优雅使用远端的组件就好像本地组件一样但是必须得是 webpack5。 官方对于跨框架调用不是很推荐但是提供了Vue3 调用Vue2 组件 VueReact 互相调用。 5、Garfish 包含构建微前端系统时所需要的基本能力任意前端框架均可使用。接入简单可轻松将多个前端应用组合成内聚的单个产品。沙箱隔离机制更完善。 6、Npm npm 的方式相对来说更加传统一些如果用 npm 来做微前端的话可能需要把原来业务可复用模块抽离出来在原来项目重新引入。专门维护一个公共模块的库编译时候引入导致最终的文件变大。 7、iframe 限制太大。除了特殊场合不太推荐使用。 8、MonoRepo 严格来说MonoRepo不算是微前端的解决方案类似npm方式但是也可以达到很方便的共享代码的效果。多个相似项目的代码在一个仓库里把共用的业务逻辑或者组件抽离到单独 的项目中去维护。 四、技术选型 因为所有的 C 端代码都是用的spack所以排除了微前端中的 webpack模式不想对项目改动太大所以也排除了npm模式和 iframe 模式。想要各个项目共享组件所以采用monoRepoqiankun把多个项目在一个仓库中维护 五、项目实践关键点 1、在项目根目录下面创建 packages 文件夹用来存放我们各种包然后在根目录新建 pnpm 的工作区文件 pnpm-workspace.yaml输入下面代码就可以将包进行关联 2、路由页面 必须保证微应用加载时主应用这个路由页面也加载了。 主应用注册这个路由时给 path 加一个 *注意如果这个路由有其他子路由需要另外 注册一个路由仍然使用这个组件即可。这里我们根据不同的项目activeRule 通过主项目传值的方式告诉子项目。 微应用的 activeRule 需要包含主应用的这个路由 path。 3、安装 qiankun在主应用注册微应用 4、在微应用导出相应生命周期钩子并配置微应用打包工具 至此MonoRepoqiankun 项目搭建完成可以在子项目中进行各自逻辑开发。 六、遇到问题 1、子项目如何知道应该走对应模块的逻辑 将模块属性进行抽象根据不同模块创建不同实例对象在子项目mount 阶段根据主项目传的平台标识进行实例创建。 2、子应用跟主应用不在同一个域名下跨域问题 因为不同子应用申请的不同域名单独打包部署qiankun框架实际上是引入子应用打包生成的js文件会出现跨域问题。开发环境要在子项目里面设置允许跨域。生产环境我们在nginx对应子项目的域名下面设置允许跨域。 3、登录cookie 我们项目里面没有将域名统一拉取微应用 entry 的请求都是跨域的所以通过自定义 fetch 的方式开启 fetch的 cors 模式. 4、CSS隔离 样式的隔离有很多种处理方式如BEM、CSS Module、css 前缀、动态加载/卸载样式表、Web Components 自带隔离机制等。 5、JS沙箱 如何确保子应用之间的全局变量不会互相干扰实现js的隔离。普遍的做法是给全局变量添加前缀这种方式类似css的BEM通过约定的方式来避免冲突。这种方式简单但不是很靠谱。qiankun 内部的实现方式是通过Proxy 来实现的沙箱模式即在应用的 bootstrap 及 mount 两个生命周期开始之前分别给全局状态打下快照然后当应用切出/卸载时将状态回滚至 bootstrap 开始之前的阶段确保应用对全局状态的污染全部清零 6、数据通信 可以使用官方的initGlobalState方法 我们这个项目应用之间不涉及数据共享所以没有顶级 store 的概念。模块之间的简单通信可以通过 eventEmitter来实现。 7、子应用缓存问题 子应用文件更新之后访问的还是之前版本的内容没有及时更新。 服务器需要给微应用的 index.html 配置一个响应头Cache-Control no-cache意思就是每次请求都检查是否更新。在nginx上配置location /index.html { add_header Cache-Control no-cache; }
