微前端听课笔记

1. 项目大之后应该如何拆分

1.1 单 SPA 页面的结构应该是什么样的？

  • 组件层
  • 页面层（对应 route｝

    有时还要有一个容器层，用处装载多个组件（但不是页面）的情况

  • 网络层
  • 脚本
  • 配置项
  • 静态资源
  • 工具类

那么拆分的依据是什么呢？有时候是基于业务拆分（水平拆分），有时候是基于体量拆分（垂直拆分）

1.2 多个前端项目需要对接同一套服务端，因为每个项目的团队不同，如何让大家遵循同一套规范？

  • 写文档 + 代码 review，通过人工的方式进行规范。
  • 封装一个请求库，大家统一调用。

1.2.1 思考：如果需要对请求库进行封装，那么应该考虑哪些方面？

包含内容：

  • 缓存
  • 请求合并
  • 时间窗口
  • 指数补偿
  • ....

请求库原则：

  1. 开箱即用
  2. 独立工作

  3. 稳定不出错（其实我觉得这个应该排第一）

    1.2.2 拓展学习 & 借鉴

  4. qs 源码研究

  5. skedo 源码研究

2. 微前端

微前端的本质是拆分

  • 微前端指的是按照一定的规则拆分前端项目直到不可再分。

    • 基于业务(核心）：广告、商品、即时通讯
    • 基于技术（支撑）：组件库、请求库、领域对象、脚手架、打包工具
    • 基于共性（通用）：通信库、单点登陆、公共组件、数据收集、监控

  • 微前端的每个项目可以独立开发、测试、部署、上线。

  • 微前端的前提是有完善、健全的前端生态，而这种生态的积累、技术沉淀需要日积月累。只有充足的前端生态建设，才有微前端使用的可能。

  • 微前端为什么不用 iFrame？因为 iFrame 有一定的性能损耗；iFrame 会割裂技术栈。

    3. 微前端の难题

  • 多个前端项目是否需要互相通信？

  • 当共性项目发生变更时如何通知？
  • 多个项目间如何共享配置？
  • 一个应用上线如何做到影响最小？
  • 公共依赖怎么处理？

4. 网络 SDK 和前端网关

5. 场景训练：前端共享配置

简单的说是使用 zookeeper + node 搭建了一套数据库读写

6. 新知识点了解、学习

7. 课后疑问

  • 网络请求库的时间窗口是什么？
  • 针对前端共享配置，本质上还是微服务的网关 + api 的那一套，无非是这个微服务是由前端来维护的。这就是微前端吗？

results matching ""

    No results matching ""