Open yayxs opened 4 years ago
我们可能听说过微服务 但到目前为止前端已经不仅仅是前端 ,我们接下来要探讨的就是微前端 (Micro Frontends)。
微服务
前端
微前端
在前端的前一阶段,我们还是仅仅切图 然后后端进行套页面。慢慢地慢慢地我们开始进行前后端分离。慢慢的出现三大框架,也是主流的框架。前端还得会PS
切图
PS
那在2016 年时候,被提出,也是和微服务概念 有异曲同工之妙
2016
微服务概念
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
我们可以称:微前端是一种方案,或者策略方法技术。我们可以实现由不同的团队 不同的技术 构建统一化的现代web应用程序
不同的团队
不同的技术
一个是路由的问题,一般的TOC 的项目,页面少的话也还说,但是像100+的页面即使是异步加载,也会性能会受到影响
TOC
100+
一个就是技术栈的问题,一个小组可能喜欢React 一个小组就是喜欢写Vue ,跨前端技术栈不一样
React
Vue
bug
即使我们不在自己的项目实践微前端,但是在面试 或者一些其他的场景中,难免会提及,就像是TypeScript 一样,凡是流行的,就是大家关注的。我们可能会想得到这样一个效果
面试
TypeScript
服务发现
运行隔离
环境一致
能够增量的方式升级,更新甚至重写前端的代码
独立部署
那么既然有许多优势,我们实际操作起来又会遇到什么问题呢?比如说像是js代码的隔离 css样式的冲突 按需加载资源 。一些冲突我们可想而知,是再所难免的。为什么这样说,因为一个简单的项目由不同的开发人员参与难免还会出现命名的冲突。
js代码的隔离
css样式的冲突
按需加载资源
我们会在一些大型成熟的开发框架中,看到渐进式 为什么大家大家那么看重。但在实际的操作中,总是找不到一个合适的地方将功能集成到现有的代码中。我们可以想一想自己日常工作的项目中,是不是具有强耦合。正是因为项目的复杂性让我们每个人都在相互踩脚。不够“干净” 。那面向B端的客户,更会在不同的场景提出不同的需求,开发人员改起来代码瑟瑟发抖
我们想到的一种方法是将每一个微前端发布一个单独的包,那我们的package.json
package.json
{ "name": "@root/container", "version": "1.0.0", "description": "A weiqianduan web app", "dependencies": { "@root/part1": "^1.2.3", "@root/part2": "^4.5.6", "@root/part3": "^7.8.9" } }
但是不建议这种思路,我们应该找到一种在运行时,并不是在构建时集成的微前端方法
iframe
没错我们可以通过iframe 将应用程序在“浏览器” 中组合在一起,一方面可以轻松的实现子页面的独立;另一方面样式和全局变量互不干扰。并且还有很高的隔离度
微前端
我们可能听说过
微服务
但到目前为止前端已经不仅仅是前端
,我们接下来要探讨的就是微前端
(Micro Frontends)。什么是微前端
历史
在前端的前一阶段,我们还是仅仅
切图
然后后端进行套页面。慢慢地慢慢地我们开始进行前后端分离。慢慢的出现三大框架,也是主流的框架。前端还得会PS
那在
2016
年时候,被提出,也是和微服务概念
有异曲同工之妙概念
我们可以称:微前端是一种方案,或者策略方法技术。我们可以实现由
不同的团队
不同的技术
构建统一化的现代web应用程序核心思想
目前项目问题以及期待
问题
一个是路由的问题,一般的
TOC
的项目,页面少的话也还说,但是像100+
的页面即使是异步加载,也会性能会受到影响一个就是技术栈的问题,一个小组可能喜欢
React
一个小组就是喜欢写Vue
,跨前端技术栈不一样bug
大海捞针优势与挑战
即使我们不在自己的项目实践微前端,但是在
面试
或者一些其他的场景中,难免会提及,就像是TypeScript
一样,凡是流行的,就是大家关注的。我们可能会想得到这样一个效果服务发现
运行隔离
环境一致
能够增量的方式升级,更新甚至重写前端的代码
独立部署
那么既然有许多优势,我们实际操作起来又会遇到什么问题呢?比如说像是
js代码的隔离
css样式的冲突
按需加载资源
。一些冲突我们可想而知,是再所难免的。为什么这样说,因为一个简单的项目由不同的开发人员参与难免还会出现命名的冲突。我们会在一些大型成熟的开发框架中,看到渐进式 为什么大家大家那么看重。但在实际的操作中,总是找不到一个合适的地方将功能集成到现有的代码中。我们可以想一想自己日常工作的项目中,是不是具有强耦合。正是因为项目的复杂性让我们每个人都在相互踩脚。不够“干净” 。那面向B端的客户,更会在不同的场景提出不同的需求,开发人员改起来代码瑟瑟发抖
方案思路
建立整合的时间
我们想到的一种方法是将每一个微前端发布一个单独的包,那我们的
package.json
但是不建议这种思路,我们应该找到一种在运行时,并不是在构建时集成的微前端方法
不起眼的
iframe
没错我们可以通过
iframe
将应用程序在“浏览器” 中组合在一起,一方面可以轻松的实现子页面的独立;另一方面样式和全局变量互不干扰。并且还有很高的隔离度相关链接